Гайд по тестированию цифровой доступности интерфейсов

Онлайн-валидатор W3C поможет понять, насколько верстка соответствует международным стандартам цифровой доступности.

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

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

У Google есть отличный инструмент аудита — Lighthouse. Он помогает повысить производительность и доступность сайтов.

Чтобы запустить аудит, откройте в Chrome инструменты разработчика («⌥» + «⌘» + «I» или «F12»), переключитесь на вкладку Lighthouse, выберите пункт «Accessibility» и нажмите на кнопку «Generate report». По завершении аудита появляется итоговая оценка и свод рекомендаций, которые помогут повысить уровень доступности сайта.

В Firefox встроен похожий инструмент аудита. Чтобы сгенерировать отчет в нем, откройте инструменты веб-разработчика («⌥» + «⌘» + «I» или «F12»), переключитесь на вкладку «Поддержка доступности», в левом верхнем углу выберите «Проверка на проблемы: все проблемы».

Отчет Firefox не заменяет Lighthouse, а наоборот — лучше использовать оба инструмента для аудита. Так увеличится шанс найти и исправить максимальное количество возможных ошибок.

Accessibility Inspector — это функция в Xcode, которая помогает найти базовые проблемы доступности в приложении.

Инспектор находится в контекстном меню Xcode. Нужно зайти в пункт «Xcode», выбрать «Open Developer Tool», затем «Accessibility Inspector». После проведения аудита появится список с найденными ошибками и возможность подсветить конкретные элементы, в которых найдены недочеты.

Еще один способ проверить базовые ошибки — это использовать фреймворки. Самые распространенные среди них — UBKAccessibilityKit и GSCX.

Добавьте их в свой проект в Xcode, а после этого запустите приложение. Поверх интерфейса появится кнопка сканирования его на доступность. Как и в Accessibility Inspector появится список с найденными проблемами.

«Сканер доступности» — это инспектор кода от Google. С ним можно найти много базовых ошибок доступности, достаточно сделать скриншот или запись экрана.

Проверяйте вручную страницу с помощью клавиши Tab.

Следите, чтобы все интерактивные элементы были доступны с клавиатуры. Фокус должен быть видимым и хорошо различимым.

Фокус должен идти по порядку — слева направо, сверху вниз и нигде не застревать. А при открытии модального окна фокус сразу должен вставать на кнопку «Закрыть».

Проверьте, что страницу или отдельно текст можно увеличить минимум до 200%. Интерфейс при этом должен корректно перестроиться.

Убедитесь, что элементы не перекрывают друг друга, а поверх контента не лежит какой-нибудь огромный баннер.

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

Автоматизированное тестирование может указать на отсутствие названий у интерактивных элементов. Или сообщить о повторяющихся названиях — например, что на странице есть пять одинаковых кнопок «Купить». Но лаконичность и описательность этих названий нужно проверять вручную.

Убедитесь, что название состоит из одного слова или короткой фразы. По названию должно быть понятно, что за элемент перед пользователем и как с ним взаимодействовать. Например, «Введите имя» или «Слушать». Имя элемента не должно содержать его тип — скринридер и так автоматически озвучит его после имени.

Убедитесь, что альт-текст правильно и точно описывает суть изображения. В идеале описание должно умещаться в 130 символов, чтобы пользователь не устал его слушать.

Проверьте, что в описании нет слов «изображение», «картинка», «фото» и так далее. Скринридер и так произнесет формат контента.

У аудио должна быть текстовая расшифровка, у видео — субтитры. Все, что сказано в видео, должно быть в субтитрах, а все, что написано в субтитрах, должно быть в видео.

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

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

Если ваш продукт предназначен для специфичной аудитории, при подборе респондентов отталкивайтесь от особенностей конкретной аудитории.

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

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

Договоритесь о встрече. Подробно объясните респонденту, для чего проводится встреча, что на ней будет происходить и кто на ней будет присутствовать.

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

Уточните, что нужно человеку, чтобы чувствовать себя комфортно во время тестирования. Например, напитки и перерывы. Убедитесь, что респондент понимание цели и процесс тестирования.

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

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

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

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

Подумайте об этике общения с респондентом. Придерживайтесь концепции, где на первом месте — человек, а не его диагноз или особенность. Например, не «слепой», «а незрячий пользователь» или «пользователь с нарушением зрения». Если не знаете, как лучше обратится — спросите у самого пользователя.

Пользователь должен:

• Без проблем управлять интерфейсом с помощью клавиатуры, если речь о сайте. Фокус должен вести себя логично и не должен нигде застревать;
• Иметь возможность быстро изучить интерфейс без большого количества свайпов и нажиматий на Tab;
• Хорошо различать все элементы интерфейса, а незрячий пользователь слышит название и тип;
• Понимать, как взаимодействовать с элементами и что произойдет при их активации — куда он попадет, перейдя по ссылке или нажав на кнопку;
• Понимать, когда совершил ошибку и что сделать, чтобы ее исправить.

В процессе тестирования не стесняйтесь задавать респонденту дополнительные вопросы — комфортно ли ему взаимодействовать с продуктом, понятен ли контент и интерфейс, какие изменения можно было бы внести на его взгляд.