Что такое тестирование доступности? (Примеры)

Что такое тестирование доступности?

Тестирование доступности Это тип тестирования программного обеспечения, проводимый для подтверждения пригодности приложения для использования людьми с ограниченными возможностями, включая пользователей с нарушениями зрения, слуха, двигательных функций, когнитивными способностями и возрастными изменениями. Это подмножество юзабилити-тестирование и проверяет, совместим ли продукт со вспомогательными технологиями, на которые эти пользователи полагаются каждый день.

Вспомогательные технологии помогают людям с ограниченными возможностями работать с программными продуктами. Типичные примеры включают:

• Программное обеспечение для распознавания речи – Преобразует произнесенные слова в текст, который служит входными данными для компьютера.
• Программное обеспечение для чтения с экрана – Озвучивает текст и элементы интерфейса, отображаемые на экране.
• Программное обеспечение для увеличения экрана – Увеличивает некоторые участки монитора, чтобы облегчить чтение для пользователей со слабым зрением.
• Специализированные клавиатуры – Разработано для пользователей с трудностями в управлении моторикой, чтобы облегчить им задачу.ping проще.
• Переключатель и глаз-tracкоролевские устройства – Предоставить пользователям с тяжелыми двигательными нарушениями возможность перемещаться по интерфейсу и выбирать его элементы.

Почему тестирование доступности?

Причина 1Ориентироваться на рынок пользователей с ограниченными возможностями.

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

• Каждый десятый человек имеет тяжелую форму инвалидности.
• У каждого второго человека старше 65 лет снижены функциональные возможности.

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

Причина 2Соблюдайте законодательство об обеспечении доступности.

Правительства разных стран мира приняли законы, требующие обеспечения доступности ИТ-продуктов для людей с ограниченными возможностями. К числу наиболее ярких примеров относятся:

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

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

Причина 3: Во избежание потенциальных судебных исков.

Крупные компании неоднократно подвергались судебным искам из-за недоступности своих цифровых продуктов. Вот несколько наиболее известных случаев:

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

Количество судебных исков, связанных с доступностью веб-сайтов в США, растет с каждым годом: с 2022 года ежегодно подается более 4,000 исков по статье III Закона об американцах с инвалидностью (ADA) в отношении цифровых продуктов. Создание доступных продуктов с самого начала позволяет избежать этих затрат и защитить бренд.

Какие инвалиды поддерживать?

Приложение должно быть ориентировано на людей с ограниченными возможностями, такими как:

Тип инвалидности	Инвалидность Descriptион
Инвалидность по зрению	Полная слепота, дальтонизм или слабое зрение. Чувствительность к визуальным стробоскопическим и мигающим эффектам.
Инвалидность	Неспособность пользоваться мышью или клавиатурой одной рукой. Нарушение моторики, включая ограниченную подвижность рук или замедление работы мышц.
Когнитивная инвалидность	Трудности в обучении, плохая память или проблемы с пониманием сложных сценариев.
Грамотность Инвалидность	Трудности с чтением, такие как дислексия.
Инвалидность по слуху	Проблемы со слухом, включая глухоту и нарушения слуха. Неспособность слышать звук или слышать его четко.

Стандарты и рекомендации по обеспечению доступности

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

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

Большинство команд относятся WCAG 2.2 Уровень AA в качестве рабочей цели, поскольку это одновременно и общепринятая правовая основа, и практическая инженерная задача.

Как провести тестирование доступности?

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

1. Ручной
2. Автоматический

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

1) Инвалидность по зрению

Представьте, что вы совершенно ничего не видите и вам нужно воспользоваться сайтом XYZ. Ваш единственный практический вариант — это программа для чтения с экрана. Программа для чтения с экрана — это программное обеспечение, которое озвучивает содержимое веб-страницы, включая текст, ссылки, переключатели, изображения и видео, чтобы слепой пользователь мог воспринимать интерфейс. Популярные программы для чтения с экрана включают в себя: JAWS, NVDAApple 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 вместе с моделями компьютерного зрения для обнаружения проблем, которые пропускают инструменты, основанные на правилах, например, неподходящий альтернативный текст или цветовые сочетания, которые не работают в реальных макетах. Во-вторых, генеративный ИИ предлагает удобочитаемые решения, включая улучшенный альтернативный текст, более понятные сообщения об ошибках и атрибуты ARIA для пользовательских компонентов. В-третьих, ИИ расставляет приоритеты в зависимости от влияния на пользователей, поэтому команды могут тратить свой бюджет на наиболее важные проблемы. Такие инструменты, как Deque axe AI, Evinced, UserWay и Siteimprove, теперь включают функции ИИ. ИИ не заменяет ручное тестирование с помощью программ чтения с экрана или исследования пользователей с ограниченными возможностями, но он значительно снижает объем ручной сортировки и помогает внедрить вопросы доступности на ранних этапах разработки.

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

Ниже приведены распространенные мифы о тестировании доступности, а также факты по этому поводу:

Миф: Создание доступного веб-сайта — дорогостоящее мероприятие.

Факт: Это не так. Учет доступности на этапе проектирования, наряду с базовым тестированием, позволяет сэкономить деньги по сравнению с модернизацией и сократить дорогостоящие доработки.

Миф: Преобразование недоступного веб-сайта в доступный — слишком трудоемкий и дорогостоящий процесс.

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

Миф: Доступность — это просто и скучно.

Факт: Страницы по-прежнему могут быть визуально привлекательными и при этом...tracПри этом обеспечивается соответствие рекомендациям WCAG 2.2. W3C категорически не рекомендует использовать только текстовые версии, отдавая предпочтение единому доступному интерфейсу для всех.

Миф: Доступность обеспечена только для слепых и людей с ограниченными возможностями.

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

Часто задаваемые вопросы (FAQ)