Про тестування доступності

Тестування доступності (accessibility) — це тестування з метою впевнитись, що застосунок можливо і зручно використовувати людям з особливими потребами. Підтримка доступності має певний місіонерський характер, тому що сама наявність перевірки на доступність та її глибина в багатьох випадках досі залишаються добровільними, а отже різними за якістю або повністю проігнорованими. Залучати якомога більше людей в колективний людський простір — це хороша практика чи то пак місія. Крім того, ширшає перелік сфер та країн, розробка в яких вже напряму вимагає дотримання певних стандартів з доступності. Насамкінець, базове тестування доступності і виправлення проблем, пов’язаних із нею, робить застосунок більш зручним і структурованим для усіх — це ефект, який йде далеко за межі задоволення особливих потреб певних категорій людей.

Існує кілька стандартів з доступності, що їх розробили як бажані чи навіть обов’язкові практики, однак панівним серед них є [Web Content Accessibility Guidelines (WCAG)], розроблений організацією W3C. Це об’ємний документ, що вже має певне версіонування, пов’язане із розвиток хороших практик. Його розбито на три рівні:

1. Рівень А (must have) позначає обов’язкові практики, базис, без яких взагалі немає мови про доступність.

2. Рівень АА (should have) позначає сучасні практики, якими варто перейнятися для забезпечення достатнього рівня. Саме на цей рівень зазвичай посилаються при введенні нормативних актів, законів, домовленостей.

3. Рівень ААА (nice to have) радше намічає вектори, куди варто дивитися піонерам з доступних цифрових технологій. Цей рівень майже ніде не вважається обов’язковим. Проте якщо максимальна доступність є пріоритетом (наприклад, якщо аудиторія застосунку складатиметься прицільно з людей із особливими потребами), то цей рівень пропонує чимало цінних інсайтів.

WCAG є міжнародно прийнятим набором гайдлайнів.

Наприклад, [Europe Accessibility Act (EAA)] напряму пов’язаний з WCAG 2.1 AA у сформульованих ним вимогах. До речі, цей акт є прикладом поширення сфери обов’язкової доступності. Ринок США започаткував ці тенденції дещо раніше. Домен healthcare, відповідно, особливо в тій частині, яка призначена для використання пацієнтами, має ці вимоги за визначенням.

Почати свій шлях до WCAG 2.1 AA compliance можна з найпростіших речей —різноманітних утиліт для автоматизованої перевірки. Якщо ми кажемо про веб, то популярними є такі розширення для браузеру як WAVE чи aXe DevTools. Обидві утіліти посилаються на WCAG 2.1 AA (у випадку aXe це єдина доступна опція для безкоштовного акаунту).

Розгляньмо WAVE.

Це розширення робить аналіз існуючої структури та додає свої помітки безпосередньо в структуру відкритої сторінки, супроводжуючи їх статистикою і коментарями.

Сама сторінка може прийняти цілковито незрозумілий вигляд, але для нас найважливіше звернути увагу на інформацію в лівій частині, особливо якщо там є Errors чи Contrast Errors.

Табка Details продемонструє усі коментарі по категоріях. Я підкреслюю увагу на слові «коментарі» - оскільки це автоматизована тулза для базової перевірки, кожен поінт потребує додаткової перевірки і дискусії. Це далеко не завжди проблемні місця. Крім помилок і зауважень, WAVE пропонує аналіз фіч, структурний аналіз сторінки та ARIA-елементів. Це додаткові точки зору щодо існуючого функціоналу, тож я раджу звертати увагу і на них, а не тільки на проблеми. На будь-яку іконку з табки Details можна натиснути, або проскролити сторінку та підсвітити потрібний елемент.

Контрастні помилки — це ті місця, де між елементом та його фоном не дотримано контрастної пропорції. За WCAG 2.1 AA ця пропорція має становити не менше 4.5. Простіше кажучи, якщо елемент та його фон будуть недостатньо кольорово віддалені одне від одного, їх буде складно і незручно розрізняти, при чому навіть людям із цілком здоровим зором. Як і з усіма іншими аспектами якості, контрастну доступність найкраще закладати як практику мислення і розробки. Існують спеціальні утиліти для дизайнерів під різні середовища, що дозволяють відстежувати контрастні пропорції ще під час проектування сторінок.

Також окремо хочу сказати про табку Order. Вона виводить послідовність елементів, в якій вони будуть представлені скрінрідером (спеціальним додатком для людей із вадами зору), а також в якій вони будуть доступні через навігацію з клавіатури (наприклад, для людей із недієздатними чи відсутніми кінцівками). Важливо, щоби в цьому переліку не було нефункціональних елементів, інакше навігація для людей, яка й без того ускладнена існуючими обмеженнями, буде ще й уповільнена зайвими безсенсовими частинами сторінки.

Ще раз: аналіз через WAVE чи йому подібні утиліти — це мінімальний початковий етап, який відсіє найпростіші з помилок. Якщо підтримка рівня доступності є спеціально зазначеною вимогою на проєкті чи прийнятим стандартом в компанії, після автоматизованих інструментів має йти більш кропітке і креативне мануальне тестування доступності. Тут в нагоді стають, наприклад, скрінрідери, бо це ними будуть користуватися кінцеві юзери з особливими потребами.

Часто тестування усіх сторінок і можливих екранів на предмет доступності не є можливим за ресурсних і часових обмежень проєкту. В такому випадку хорошою практикою можуть бути періодичні тести із нечіткою схемою, наприклад:

1. Головна сторінка/лендінг/homepage

2. Дві-три найбільш популярних сторінки/екрани, на які найчастіше натраплятимуть юзери.

3. Випадкова сторінка без критеріїв вибору (відмінна від тих, що були в попередніх пунктах)

Така схема водночас покриває найбільш популярні сторінки, а отже максимізує хороший досвід використання для найбільшої кількості юзерів, в той же час факт того, що у пунктах 2 чи 3 не зазначені конкретні сторінки убезпечує тестування від ефекту пестициду — з кожною ітерацією ми перевірятимемо щось нове.