Тестування доступності: яке тестування можна вважати достатнім

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт, я Роман Савка, інженер з тестування доступності у компанії SoftServe, а також сертифікований CPACC-експерт Міжнародної асоціації професіоналів з доступності IAAP. Для мене доступність у галузі технологій має величезне значення, і не лише тому, що я є користувачем з інвалідністю, а й тому, що таких людей понад мільярд у світі.

Я понад три роки працюю в команді Accessibility Service в SoftServe, частина якої — це фахівці, що мають інвалідність. Нашим основним завданням є тестування вебсайтів, сервісів та мобільних аплікації на доступність для всіх користувачів, незалежно від їхніх можливостей. Зараз accessibility набирає обертів, і на багатьох проєктах є однією з базових вимог. Однак часто, коли розробники чи тестувальники стикаються з такими вимогами, вони не завжди знають, що робити і з чого почати. Саме тому в цьому матеріалі я хочу поділитися практичним досвідом, знаннями та методиками тестування доступності зі своїми колегами та всіма зацікавленими.

Що таке тестування на доступність

Тестування вебвмісту на доступність — це процес, який поєднує набір певних підходів, типів та інструментів з кінцевою метою перевірити, наскільки вебпродукт, сервіс чи мобільний застосунок придатний для використання людьми з інвалідністю.

Таке тестування проводиться згідно з вимогами та стандартами, які широко використовуються у світі або в конкретній країні. Найвідомішим та найпоширенішим стандартом у цій царині є Web Content Accessibility Guidelines (WCAG), на основі якого і базуються вимоги щодо відповідності цифрового вмісту та його доступності для людей з інвалідністю.

Отож, поговоримо далі, що повинен містити процес тестування на доступність і як наблизити його до достатнього об’єму.

Мануальне тестування та тестування з використанням допоміжних технологій

У цій частині поговоримо про мануальне тестування та тестування з використанням допоміжних технологій, окреслимо основні його складові та деякі базові типи..

Візуальна частина

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

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

Також важливо дати користувачу можливість отримати всю необхідну інформацію у форматі тексту. Це необхідно для людей із порушенням розпізнавання кольорів.

Не забуваймо, що відео має містити так звані кепшени, які передадуть важливу інформацію для людей з порушеннями слуху у форматі синхронізованих текстових субтитрів.

Screen readers

Screen readers — це програмне забезпечення, яке дозволяє незрячій людині, людині зі слабким зором чи навіть людині, яка не бачить та не чує, взаємодіяти з цифровим вмістом. Ця програма конвертує все те, що ви бачите на екрані, у звук або передає на брайлівський девайс.

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

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

Наприклад, зображення, які є частиною вебвмісту і мають важливе значення для користувача, повинні мати альтернативний текст, який дасть можливість незрячому користувачу зрозуміти, що на зображенні.

Не забуваймо і про медіавміст. Наприклад, відео, яке містить важливу візуальну інформацію, повинне мати аудіодискрипцію, яка у форматі звуку опише важливі моменти, або ж текстовий транскрипт, який буде помічником для людей із відсутністю зору та слуху.

Ще один важливий аспект — це послідовність зчитування та розпізнавання інтерактивних елементів, які повинні мати правильну назву (мітку), роль, значення та сповіщати користувача про зміни, які відбуваються із цими елементами під час взаємодії. Для користувачів, які не бачать екран, це єдиний спосіб зрозуміти, що відбувається.

Не менш важливою є семантична структура та взаємозв’язки: наявність відформатованих заголовків, лендмарок, списків, які структурно відображатимуть візуальний вміст для тих, хто користується скринрідерами. Розберемо випадок на одному з проєктів.

Клієнтський кейс, що стосується семантичної структури тексту

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

Для тих, хто бачить, все було зрозуміло. Однак для користувачів скринрідером, зокрема й для мене, це просто була секція з суцільним текстом (без структури «запитання — відповідь»). Відповідно, мені довелося скролити весь зміст і розбиратися, що до чого.

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

На щастя, питання вдалося вирішити на користь доступності. Я провів дзвінок з клієнтом і просто продемонстрував, як структура цієї сторінки виглядає для незрячої людини. Клієнт був вражений, наскільки така проста річ як семантична структура змінює користувацький досвід, і в короткі строки таки допрацював цю секцію.

Скринрідери бувають різні

Є платні та безкоштовні, вмонтовані в операційну систему або як сторонній софт, який потрібно встановити окремо.

Так, наприклад, JAWS screen reader від Freedom Scientific є платним і використовується для операційної системи Windows, тоді як Voiceover screen reader є одразу вмонтованим в операційну систему і використовується на всіх «яблучних» пристроях.

Зазвичай при тестуванні зі скринрідером використовують комбінацію браузера та скринрідера, враховуючи сумісність обох.

Найпоширеніші комбінації:

• Google Chrome з JAWS (Windows)
• Firefox з NVDA (Windows)
• Voiceover з Safari (MacOS/IOS)
• Narrator з Edge (Windows)

Маленький інсайт: мені доводилось тестувати різні комбінації на Windows, і не лише як рекомендовано. Тому можу сказати що, наприклад, NVDA добре сумісний і з Google Chrome, і з Edge. Усе залежить від вимог проєкту, хоча зазвичай використовують стандартні комбінації.

Режими огляду скринрідерів

Також під час тестування варто врахувати, що скринрідери мають різні режими огляду та взаємодії із вебвмістом. Наприклад, NVDA має два режими огляду:

1. Режим перегляду (Browse mode), що використовується під час читання документів або вебсторінок. Зазвичай у цьому режимі користувачі використовують клавіші зі стрілками, аби ознайомитися та дослідити незнайомий їм вебвміст.
2. Режим фокусування (Focus mode), що використовується, коли користувач вводить дані у форму або інші поля, які вимагають введення користувачем інформації.

NVDA автоматично перемикається між режимами перегляду та фокусування, але користувач може перемикати їх вручну за допомогою комбінації клавіш Insert+Space.

Ще одна корисна фіча NVDA — це Speech viewer. Її увімкнення відкриває вікно, яке відображає все, що зчитує NVDA. Такі ж фічі є у JAWS та Voiceover. Це корисно для, наприклад, девелоперів та тестувальників, які навчаються використовувати NVDA з метою тестування.

Якщо ж цікаво спробувати самому, як це працює, то можна встановити безкоштовний скринрідер NVDA та відкрити у Firefox чи Google Chrome будь-який вебсайт.

Лайфхак

Хочу поділитися з вами однією цікавою методикою, яку зазвичай ми використовуємо на кожному з наших проєктів. Коли я, як незрячий тестувальник, перевіряю сторінку зі скринрідером, новий контент може з’являтися без мого відома. Наприклад, pop-ups, які я не бачу через поганий код чи контент, який динамічно змінюється, і я, звичайно ж, цього не помічаю.

У такому випадку ми використовуємо парне тестування. Я, як тестувальник зі скринрідером, і моя колежанка, яка займається візуальною частиною тестування, одночасно тестуємо ту ж саму сторінку, поширюючи екран у Zoom чи MS Teams.

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

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

Раджу спробувати, бо в парі працює принцип «одна голова добре, а дві — краще».

Клавіатура

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

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

Пам’ятайте, що зрячі користувачі мають бачити індикатор фокуса, аби знати, де вони перебувають і куди переходять. Також фокус ніколи не має потрапляти в пастку: тобто все, що активується з клавіатури, повинно мати таку ж можливість бути деактивованим, закритим чи обраним лише з клавіатури.

Скриншот головної сторінки вебсайту WebAIM з прикладом індикатора фокуса на посиланні Accessibility Training. Дефолтний стан посилання — текст посилання синього кольору на світло-блакитному тлі. При отриманні фокуса текст посилання стає червоним на жовтому тлі, навколо посилання з’являється чорна рамка.

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

Керування голосом

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

Тестування для інших типів інвалідності

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

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

Зрештою, чим простіше — тим краще. Простота, зрозумілість, передбачуваність цифрового вмісту є важливою складовою доступності незалежно від користувацького досвіду чи інвалідності.

Мануальне тестування та тестування з допоміжними технологіями є досить об’ємним та затратним по часу, і це не втиснути в одну статтю. Але якщо ви зацікавилися і хочете глибше дослідити стандарти мануального тестування та тестування з допоміжними технологіями, пропоную до вашої уваги Web Accessibility Checklist, Based on WCAG 2.1 AA | Deque.

Автоматизовані інструменти для тестування

Автоматизовані інструменти для тестування доступності є важливою частиною загальної розробки доступності та процесу контролю якості. Однак чи можна обмежитися винятково автоматизованим тестуванням? Ні. Згідно зі статистикою компанії Level Access, автоматизовані інструменти виявляють 20–30% наявних дефектів (хоча розробник одного з найпопулярніших автоматизованих інструментів для тестування заявляє про 57% виявлених дефектів, що однаково недостатній показник тестування).

Однак вони можуть виявити багато проблем з доступністю у цифровому вмісті, наприклад, зображення без тексту заміщення, елементи введення форми без міток тощо.

Розглянемо їхні сильні та слабкі сторони.

Сильні сторони

• Доступність. В інтернеті є багато автоматизованих інструментів для тестування, і здебільшого вони доступні та безкоштовні. Якщо цікаво спробувати, можете скористатися AXE DevTools, ARC Toolkit, Lighthouse. Є й платні версії, але в процесі тестування ми з колегами дійшли висновку, що їхні функції не надто випереджають безкоштовні.
• Простота у використанні. Ще одним плюсом є те, що навіть людина без особливого досвіду може провести тестування та отримати досить вичерпні дані про дефект, його розташування та поради щодо можливого виправлення. Хоча варто підкреслити, що лише фахівець з тестування доступності може дати вичерпну характеристику, опис дефекту та що з ним робити.
• Швидкість тестування. На відміну від мануального тестування, наприклад, тестування зі скринрідером, тестування з автоматизованими інструментами є значно швидшим та простішим.
• Чітке розпізнавання типів дефектів, зокрема тестування контрасту. Саме із цим тестуванням автоматизовані інструменти, такі як Color contrastchecker, допоможуть якнайкраще.

Слабкі сторони

Існують певні типи проблем, які важко визначити автоматизованим інструментам, наприклад:

• Якість і точність. Неточний або низькоякісний альтернативний текст не краще, ніж відсутність альтернативного тексту. Автоматизовані інструменти можуть лише визначити, чи є на зображенні альтернативний текст. Вони не можуть сказати, чи є альтернативний текст точним чи значущим. Те саме стосується текстових міток для елементів форми, підписів у таблицях, заголовків у таблицях даних тощо.
• Шаблони фокусування клавіатури. Автоматизовані інструменти не можуть надійно визначити, де має бути фокус клавіатури в будь-який момент часу. Коли користувач натискає кнопку, фокус має перейти до логічного пункту призначення, наприклад до діалогового вікна чи повідомлення про помилку, але автоматизований інструмент не може визначити відповідне розташування фокуса.
• Користувацькі віджети. Автоматичні інструменти не можуть виявити всі можливі способи неправильного створення та функціонування користувацьких віджетів, як от діалогових вікон, каруселей чи меню-акордеонів, особливо, коли йдеться про шаблони взаємодії з клавіатурою.

Найкраще використовувати автоматичні інструменти для тестування доступності в тандемі з мануальним тестуванням.

Скриншот сторінки Accessibility на веб-сайті MDN з відкритим інструментом axe DevTools та результатами автоматичного сканування. У результаті сканування сторінки знайдено 3 дефекти, один з яких Serious, інші два — Moderate. Serious дефект вказує на те, що лінки на сторінці мають розпізнаватися не лише за кольором, а й мати додаткові ознаки. Moderate дефекти пов’язані із лендмарками — контент сторінки має бути поділений на лендмарки та вони мають бути унікальні.

Значення опису дефектів для тестування

Як і в стандартному, так і у accessibility testing, важливе місце займає дефект і його правильний опис. Добре описаний дефект дає можливість не лише вказати на проблему та її відтворення, а й дозволяє розробнику, який буде виправляти дефект, зрозуміти що саме і де треба виправити.

Крім усіх обов’язкових атрибутів бага, таких як: summary, кроки для відтворення, наявний та очікуваний результат, середовище використання, пріоритет та інші поля, які в залежності від проєкту та вимог можуть бути як обов’язковими, так і опційними, хочу дати ще одну пораду з власної практики.

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

І тут дуже помічним може бути запис екрану або відео, де буде видно та чути, що говорить скринрідер. У такому відео я також стараюсь прокоментувати все, що відбувається, як навігуюсь, що активую та інше. Перевірено: коли ви прикріплюєте таку відеодемонстрацію до вашого дефекта, це додає розуміння суті проблеми та полегшує роботу як тестувальникам, так і розробникам.

Залучення людей з інвалідністю до тестування доступності

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

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

Висновки

Підсумовуючи, ще раз наголошу, що для достатнього тестування на доступність жоден з вищезгаданих аспектів не може бути винятком. Тобто ми не можемо лише запустити автоматичні інструменти та забути про тестування із скринрідером чи клавіатурою або навпаки.

Лише комбінація мануального тестування, тестування з допоміжними технологіями та використання автоматизованих інструментів для тестування, залучення до процесу реальних людей з інвалідністю разом з експертами в галузі доступності може забезпечити найкращі результати в процесі accessibility testing. (Але ж звісно не забезпечать вичерпність — оскільки це просто неможливо).

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

Доступність — це відповідальність не лише тестувальника, менеджера чи розробника; це процес, із яким мають ознайомитися всі — і не лише в команді, а й у компанії в цілому.

Хай буде з вами доступність! :)