Що таке тестування доступності? (Приклади)

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

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

Допоміжні технології допомагають людям з інвалідністю працювати з програмним продуктом. Типові приклади включають:

• Програмне забезпечення для розпізнавання мовлення – Перетворює розмовні слова на текст, який слугує вхідними даними для комп’ютера.
• Програма зчитування з екрана – Зчитує текст та елементи інтерфейсу, що відображаються на екрані.
• Програмне забезпечення для збільшення екрана – Збільшує частини монітора, щоб полегшити читання користувачам із вадами зору.
• Спеціалізовані клавіатури – Розроблено для користувачів з труднощами в управлінні моторикою, щоб зробитиping простіше.
• Перемикач і око-tracкоролівські пристрої – Дозволити користувачам з важкими порушеннями рухових функцій навігацію та вибір елементів інтерфейсу.

Чому тестування доступності?

Причина 1Звернення до ринку користувачів з інвалідністю.

За даними Всесвітньої організації охорони здоров'я, близько 1.3 мільярда людей у ​​світі, або приблизно кожна шоста, живуть зі значною інвалідністю.

• Кожна десята людина має тяжку інвалідність.
• Кожна друга людина старше 65 років має знижені працездатності.

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

Причина 2Дотримуйтесь законодавства про доступність.

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

• Сполучені Штати: Закон про американців з інвалідністю (ADA, 1990) та Розділ 508 Закону про реабілітацію.
• Велика Британія: Закон про рівність 2010 року (який замінив Закон про дискримінацію інвалідів 1995 року).
• Європейський Союз: Європейський акт про доступність, який набув чинності для багатьох продуктів і послуг у червні 2025 року, та стандарт EN 301 549.
• Австралія: Закон про дискримінацію інвалідів 1992 року.
• Ірландія: Закон про інвалідність 2005 року.
• Канада: Закон про доступну Канаду 2019 року.

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

Причина 3Уникайте потенційних судових позовів.

Великі компанії неодноразово отримували позовів через те, що їхні цифрові продукти були недоступні. Ось кілька відомих випадків:

• Національна федерація сліпих (NFB) проти. Target (2006, врегульовано 2008).
• Угода NFB проти AOL (1999).
• Роблес проти Domino's Pizza (2019), де США SupremСуд залишив у силі рішення про те, що Закон про американців з інвалідністю застосовується до веб-сайтів та мобільних додатків.
• Гіл проти Вінн-Діксі (2017), перший вирок суду в США, який вимагав виправлення недоступного вебсайту.

Кількість позовів щодо веб-доступності у Сполучених Штатах зростає з кожним роком, і з 2022 року щорічно подається понад 4,000 цифрових справ за Законом про американців з інвалідністю, розділ III. Створення доступних продуктів з самого початку дозволяє уникнути цих витрат і захищає бренд.

Які вади підтримати?

Заявка повинна підтримувати людей з інвалідністю, таких як:

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

Стандарти та рекомендації щодо доступності

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

• WCAG 2.2 – Опубліковані W3C у жовтні 2023 року, Керівні принципи доступності веб-контенту 2.2 є чинним глобальним еталоном. Вони визначають три рівні відповідності: A (базовий), AA (мінімальний рівень відповідності, встановлений законодавством у більшості країн) та AAA (найвищий).
• WCAG 3.0 – Робочий проект W3C, який запроваджує модель оцінювання на основі результатів. Він все ще перебуває в розробці та не замінив WCAG 2.2.
• Розділ 508 – Правило федеральних закупівель США, яке вимагає, щоб електронні та інформаційні технології, що закуповуються федеральними агентствами, відповідали критеріям WCAG 2.0 рівня AA.
• 301 549 – Європейський гармонізований стандарт доступності ІКТ, що використовується для демонстрації відповідності Європейському акту про доступність.
• Розділ III Закону про американців з інвалідністю – Законодавство США про громадянські права застосовується до веб-сайтів та мобільних додатків громадських місць проживання; суди зазвичай використовують WCAG 2.1 або 2.2 AA як орієнтир.

Більшість команд ставляться WCAG 2.2 Рівень AA як їхню робочу ціль, оскільки це одночасно спільна правова база та практична інженерна мета.

Як провести тестування доступності?

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

1. Мануал
2. Автоматизований

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

1) Інвалідність зору

Уявіть, що ви взагалі нічого не бачите, і вам потрібно скористатися веб-сайтом XYZ. Єдиним практичним варіантом є програма для читання з екрана. Програма для читання з екрана – це програмне забезпечення, яке озвучує вміст веб-сторінки, включаючи текст, посилання, радіокнопки, зображення та відео, щоб незрячий користувач міг сприймати інтерфейс. Популярні програми для читання з екрана включають JAWS, NVDA, Apple VoiceOver та Android Відповісти.

Коли ви запускаєте JAWS, а потім відкриваєте браузер, JAWS озвучує назву сторінки. Якщо ви переміщуєте фокус до адресного рядка, JAWS вимовляє «Адресний рядок», а потім читає кожен введений вами символ. Наприклад, typing google.com видає оголошення такого вигляду:

Address Bar, w, w, w, period, g, o, o, g, l, e, period, c, o, m.
When the page finishes loading, JAWS announces "Google.com home page".
When focus reaches the search field, JAWS announces "Google search, edit".

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

2) Дальтонізм

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

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

3) Слабкий зір

Користувачам із слабким зором або іншими захворюваннями сітківки потрібна додаткова допомога для користування сайтом:

1. Уникайте дуже дрібного тексту. WCAG рекомендує використовувати розмір основного тексту за замовчуванням, який зручно масштабується без масштабування.
2. Переконайтеся, що макет перекомпоновується акуратно, коли текст збільшується до 200 відсотків (критерій успішності WCAG 2.2). Рядки не повинні обрізатися, а вміст не повинен перекриватися.
3. Підтримуйте мінімальний коефіцієнт контрастності 4.5:1 для звичайного тексту та 3:1 для великого тексту.

4) Рухові та інші порушення

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

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

Alternative text should be provided for every image, audio file, and video so that screen readers can convey their meaning. Keyboard shortcuts should be available for important actions, and skip-to-content links should let keyboard users bypass repeated navigation.

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

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

Зразки тестових випадків для тестування доступності

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

1. Чи надаються еквіваленти клавіатури для кожної операції миші та діалогового вікна?
2. Чи пояснюється в документації користувача, як керувати застосунком за допомогою допоміжних технологій?
3. Чи порядок табуляції логічний, щоб навігація проходила природно?
4. Чи передбачені комбінації клавіш для основних меню?
5. Чи підтримує програма всі цільові операційні системи та програми зчитування з екрана?
6. Чи чітко повідомлено час відгуку кожного екрана або сторінки, щоб користувачі знали, скільки часу чекати?
7. Чи всі підписи написані правильно та програмно пов'язані з їхніми елементами керування?
8. Чи є вибір кольорів гнучким та перевіреним на симуляторах дальтонізму?
9. Чи використовуються зображення, значки та емодзі у спосіб, зрозумілий кінцевим користувачам?
10. Чи надає програма звукові сповіщення там, де вони корисні?
11. Чи може користувач налаштовувати або вимкнути звук елементів керування звуком та відео?
12. Чи може користувач перевизначити шрифти за замовчуванням для друку та тексту на екрані?
13. Чи може користувач налаштувати або вимкнути миготливі, обертові або рухомі дисплеї?
14. Переконайтеся, що колір ніколи не використовується як єдиний засіб передачі інформації.
15. Чи все ще видно підсвічування, коли системні кольори інвертовані? Перевірте, змінивши коефіцієнти контрастності.
16. Чи доступні аудіо- та відеотранскрипти або субтитри для користувачів, які погано чують?
17. Чи проводиться навчання для користувачів з інвалідністю, щоб допомогти їм ознайомитися з програмою?
18. Чи всі інтерактивні елементи керування доступні, керовані та закриваються лише за допомогою клавіатури?

Як штучний інтелект змінює тестування доступності

Штучний інтелект – це решаping тестування доступності трьома практичними способами. По-перше, сканери машинного навчання тепер зчитують візуалізований DOM разом із моделями комп’ютерного зору, щоб виявляти проблеми, які пропускають інструменти на основі правил, такі як невідповідний текст alt або комбінації кольорів, які не працюють у реальних макетах. По-друге, генеративний ШІ пропонує зрозумілі для людини виправлення, включаючи кращий текст alt, чіткіші повідомлення про помилки та атрибути ARIA для користувацьких компонентів. По-третє, ШІ пріоритезує результати за впливом на користувача, тому команди можуть витрачати свій бюджет на проблеми, які є найважливішими. Такі інструменти, як Deque axe AI, Evinced, UserWay та Siteimprove, тепер включають функції ШІ. ШІ не замінює ручне тестування зчитувача з екрана або дослідження користувачів з людьми з інвалідністю, але він значно зменшує робоче навантаження ручного сортування та допомагає змістити доступність ліворуч у цикл розробки.

Міфи про тестування доступності

Нижче наведено поширені міфи про тестування доступності разом із фактами:

Міф: Створення доступного вебсайту є дорогим.

Факт: Це не так. Врахування доступності під час проектування разом із базовим тестуванням заощаджує кошти порівняно з модернізацією та зменшує витрати на переробку.

Міф: Зміна недоступного веб-сайту на доступний є занадто трудомістким і дорогим процесом.

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

Міф: Доступність проста та нудна.

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

Міф: Доступність доступна лише для незрячих та користувачів з інвалідністю.

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

Поширені запитання