Відкрити ФОП, оплатити комуналку, завантажити виписки з ЦНАПу, проголосувати за улюбленого кандидата на Євробаченні? Укласти декларацію з сімейним лікарем, отримати рецепт, знайти і записатися до потрібного фахівця? Купити квитки в мандрівку, оплатити проїзд у громадському транспорті, прокласти маршрут у незнайомому місті? Організувати робочий процес, поставити завдання підлеглим, купити онлайн практично що завгодно? Вести журнал здоров’я, відстежувати фізичні активності, медитувати чи планувати здорове харчування? Смартфони вже давно не просто пристрої, за допомогою якої можна телефонувати чи писати SMS. Це елемент, без якого не обходиться будь-яка наша дія – від освіти та розваг до бізнесу та організації повсякденних справ. Але чи всім користувачам смартфону доступні ці можливості?
Всі сучасні смартфони мають функції доступності, які дозволяють користуватися смартфоном людям з інвалідністю. Наприклад, скрінрідер читає інтерфейс вголос для незрячих, люди з порушенням зору можуть використовувати збільшення екрану або налаштування контрасту, а люди з руховими порушеннями використовують керування однією кнопкою. Завдання розробника – підтримувати ці можливості.
Під час створення мобільного застосунку розробникам слід пам’ятати, що смартфони є у всіх. І в тих, хто погано бачить. І в тих, хто не чує. І в тих, хто має тимчасові чи постійні рухові порушення. І в літніх людей, і в маленьких дітей. Люди користуються смартфонами при різному освітленні та в різних умовах і станах: в темряві добираючись додому чи під палючим сонцем, що засліплює екран; в стані ейфорії, неуважності, стресу чи сп’яніння; в дорозі, тремтячими руками, замерзлими від холоду пальцями взимку. І все це також про доступність.
Команда Access Lab зібрала базові технічні рекомендації з підказками, як зробити мобільний застосунок безбар’єрним. Рекомендації базуються на ДСТУ EN 301 549:2022, WCAG та рекомендаціях з доступності платформ iOS та Android.
Це корисні рекомендації для початківців, що взялися створювати доступні застосунки, проте вони не є вичерпними. За більш детальною інформацією – рекомендуємо звертатися до рекомендацій Apple та Google.
10 правил доступного мобільного додатку
1. Використовуйте нативну розробку замість гібридної
У розробника є два основних шляхи створення застосунків. Перший – створити спільний застосунок і трансформувати його у окремі застосунки для різних операційних систем (гібридний застосунок). Другий – одразу створювати застосунки під кожну операційну систему окремо (нативні застосунки). Ми рекомендуємо другий спосіб, адже у цьому разі ви маєте повний контроль над кодом програми і прямий доступ до функцій операційної системи. У такому випадку ніщо вам не завадить зробити його повністю доступним.
Використовуючи гібрид, ви залежите від платформи, на якій цей гібрид створено. Якщо якась функція не підтримується платформою, то, скоріше за все, ви не зможете на це вплинути.
2. Надайте текстові мітки всім графічним елементам інтерфейсу
Якщо у вашому застосунку є кнопки або інші елементи керування без тексту – наприклад, кнопка play у вигляді трикутника; кнопка «далі» у вигляді стрілочки тощо – то незрячі користувачі можуть не зрозуміти призначення таких кнопок. Скрінрідер їм прочитає «кнопка» або «кнопка трикутник».
Рішення дуже просте: додайте приховану мітку для скрінрідера. Вона не буде відображатися візуально, але скрінрідер її прочитає. Для цього в iOS використовуйте властивість accessibilityLabel, а в Android – contentDescription.
Мітки повинні бути короткими і чіткими:
- правильно: «Далі»;
- неправильно: «Натисніть, щоб перейти далі».
Якщо ж кнопка вже має видимий текст, тобто на кнопці вже написано «Далі», то додатково мітки не потрібно додавати. Скрінрідер прочитає текст на кнопці.
3. Визначте програмно роль кожного елемента
Звучить трохи складно. Насправді, все просто. Коли зрячий користувач переглядає інтерфейс, він може візуально відрізнити кнопку від прапорця, заголовок від звичайного тексту, адже всі елементи мають характерний вигляд.
Скрінрідер не може описати зовнішній вигляд елемента, тому, якщо ролі (типи) елементів не визначені програмно, незрячі користувачі не зрозуміють, що є кнопкою, що – прапорцем, а що є просто текстом.
Що робити? Найпростіше рішення – використовувати нативні компоненти платформи, наприклад, button для створення кнопки, tabbar – для панелі вкладок тощо. Ці компоненти вже мають вбудовану семантику, тому скрінрідер скаже, що це кнопка чи панель вкладок, і надасть підказки для взаємодії з елементом. Тож, ми наполегливо рекомендуємо використовувати нативні компоненти замість кастомних.
Якщо ви використовуєте кастомні компоненти, то додайте до них властивості доступності на платформі iOS або класи – на Android.
4. Визначте програмно стан кожного інтерактивного елемента
Ця рекомендація перегукується з попередньою. Якщо певний елемент має кілька станів: наприклад, прапорець позначений або не позначений, вкладка обрана або не обрана – це легко визначити візуально. Однак без програмного визначення стану, ця інформація не буде доступною користувачам скрінрідерів.
Рішення таке саме: використовуйте нативні компоненти, стан яких визначається програмно без жодних дій з вашого боку, або, якщо у вас використані кастомні компоненти – додайте відповідні властивості доступності на iOS або описи стану – на Android.
5. Дотримуйтесь вимог контрастності
До цього ми говорили лише про доступність для незрячих людей. Але є інша група користувачів з порушенням зору, які мають залишок зору. Вони сприймають контент візуально. Для них важливо, щоб текст не зливався з тлом. Для цього стандартами доступності визначені мінімальні вимоги щодо контрасту: 4.5:1 для звичайного тексту та 3:1 – для великого, жирного тексту або нетекстових елементів.
Це мінімальні вимоги, однак враховуючи, що смартфон зазвичай має невеликий екран і його використовують в різних умовах, ми рекомендуємо використовувати ще більші коефіцієнти контрасту. Однак варіант чорним по білому теж не є хорошим.
6. Зробіть активні ділянки достатнього розміру
Часто дратує, коли ми не потрапляємо з першого разу на потрібну кнопку. Для людей з порушенням моторики це дуже поширена проблема.
Щоб зробити інтерфейс зручним для всіх, а особливо, для людей з порушенням моторики, зробіть ваші активні елементи, як от кнопки, та інші області для торкання, достатньо великими: від 48×48 PX. Навіть якщо безпосередньо кнопка є меншою, активна ділянка може бути збільшена за рахунок області навколо цієї кнопки.
7. Зробіть навігацію передбачуваною
Не використовуйте складних жестів. Якщо таки використовуєте – надайте їм заміну у вигляді простих звичних жестів.
Справа у тому, що скрінрідери змінюють стандартні жести і блокують всі нестандартні жести, тому користувач скрінрідера їх не зможе виконати. Крім того, складні багатоточкові жести або жести, засновані на траєкторії, складно відтворити людям з порушенням моторики.
8. Переконайтеся, що в застосунку підтримується збільшення розміру тексту
Якщо користувач збільшує розмір тексту у налаштуваннях спеціальних можливостей платформи, розмір тексту у застосунку теж повинен збільшуватися. При збільшенні розміру тексту принаймні до 200% контент повинен правильно перекомпоновуватися.
9. Зробіть інтерфейс доступним у двох положеннях екрана: портретному і горизонтальному
Іноді люди з руховими порушеннями використовують смартфон чи планшет лише в одному положенні і не можуть його змінити, тому важливо, щоб інтерфейс застосунку був доступним в обох положеннях екрана.
10. Зробіть контент у застосунку доступним більше, ніж через один сенсорний канал
Жоден контент у застосунку не повинен бути доступний лише через один сенсорний канал, наприклад, слух чи зір. Яке може бути рішення? Надати альтернативу для будь-якого нетекстового контенту:
- альтернативний текст для зображень, що пояснює їхній вміст для незрячих (він не відображається на екрані, але читається скрінрідером);
- текстова транскрипція аудіо або субтитри чи жестова мова у відео для нечуючих користувачів;
- опис візуальних сцен у відео для незрячих людей (зазвичай надається як окрема аудіодоріжка).
Є загальне правило для контенту: він завжди повинен мати текстову альтернативу. Текст – це універсальний формат, який легко перетворити на будь-який інший формат, зручний для користувача.
Що далі?
Якщо вагаєтесь, чи вдалось зробити ваш застосунок доступним та зручним для всіх, або ж хочете пересвідчитися у правильності ваших дій – можете звернутися до нас за консультацією.
Що ми можемо запропонувати?
Проведемо експертний аудит доступності вашого мобільного застосунку; напишемо детальні рекомендації для його покращення; можемо запропонувати технічну підтримку.
Чому це важливо?
Все дуже просто. Такі рішення допоможуть збільшити кількість вашої аудиторії та клієнтів. Ще у вересні 2023 року в Україні налічувалось 3 мільйони людей з інвалідністю. З 24 лютого по вересень 2023 їх кількість збільшилась на 300 тисяч. Повага до кожного громадянина та рівні можливості для всіх – це найменше, що ми можемо зробити. Справжня «держава в смартфоні» починається з кожного з нас.