Дизайн для скринридеров
В конце 90-х в США к закону о реабилитации был добавлен раздел 508, который призывал разработчиков обеспечить равный доступ к информационно-коммуникационным технологиям для людей с ограниченными возможностями.
На фоне других гайдлайнов и актов он не так примечателен — он не был первым и не показывает конкретных путей решения проблемы доступности. Но в нем озвучивается один важный принцип:
302.1 Without Vision. Where a visual mode of operation is provided, ICT shall provide at least one mode of operation that does not require user vision. — Section 508 of the Rehabilitation Act. Chapter 2 Scoping Requirements
Там, где предполагается визуальный отклик системы, продумайте также такой способ взаимодействия, для которого не будет требоваться наличия зрения.
Как результат попытки решения проблемы доступности, был разработан Web Content Accessibility Guidelines (WCAG). Но этот список критериев от W3C не панацея. Сама по себе поддержка WCAG не гарантирует положительный опыт взаимодействия. Точно также как умение читать не гарантирует понимание текста. Давайте взглянем на сайт Теслы. Даже не так, давайте послушаем сайт Теслы.
Косил косой косой косой…
При попытке навигации между активными областями сайта мы наблюдаем такую картину:
Дабы понять, что тут происходит без визуального контекста надо сильно постараться.
При этом, с точки зрения WCAG, претензий к реализации этого блока нет.
1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose
Альтернативные атрибуты прописаны.
Но я скажу больше, именно эти атрибуты и вызывает проблему в данном случае.
Сначала он читает текст ссылки, а потом альт-картинки, которая также находится внутри ссылки. Еще сложности тут добавляет наличие атрибута title в самом теге ссылки, что несколько рандомизирует конечный результат прочтения в зависимости от производителя и версии ридера.
Вот так, к примеру, эти две кнопки будут звучать при использовании NVDA ридера, который читает тайтлы (и заодно намек на то, что не стоит использовать хедеры с нарушением семантики):
Ну и похоже маркетинг с дизайном как-то не предполагали, что названия моделей в таком словосочетании создадут какую-то скороговорку из шипящих звуков.
Поэтому, прежде чем приступить к проверке критериев WCAG, нам надо выстроить путь пользователя самостоятельно и уже от него отталкиваться.
Так или иначе, но нам придется вписывать опыт пользователей скринридеров в “визуальный” интерфейс. Просто хотя бы потому, что технически нет возможности определить использование читалок экрана. На заре WCAG говорили о необходимости такого функционала, но лет 6–7 назад поднялась большая буча о неэтичности такого подхода. Проблема оказалась куда более серьезной, подробнее можно прочитать в статье Detecting screen readers in analytics. Pros and cons.
Для решения этой задачи нам доступно три инструмента:
- Мы можем задать порядок чтения и иерархию контента.
- Мы можем скрыть от ридера определенные блоки.
- Мы можем дополнить или полностью заменить контент.
И так по порядку.
Порядок чтения и иерархия.
Когда мы используем клавиатуру для навигации, поисковик предполагает, что мы являемся пользователем скринридера и предлагает такую очередность чтения интерфейса.
- Предложить пользователю сразу перейти к результатам поиска и тем самым пропустить чтение меню..
- Дальше он предлагает воспользоваться помощью и оставить фидбек.
- После этого он переходит на меню.
- Потом на лого. .. и тд.
Как видите, порядок чтения блоков сильно изменен. Если использовать дефолтный переход табом, то он сначала прочитает все активные обласи хидера, прежде чем перейти к контенту, а это 20+ нажатий кнопок для каждого обновления страницы.
Скрыть контент от ридера
Тесла является хорошим примером того как не надо распоряжаться графической информацией.
Использование одинаковых альтов для всех картинок никак не помогает пользователям скринридеров.
3 клика — 4 раза одна и та же фраза.
В ряде случаев будет более полезным полностью скрыть картинку вместо того что бы заставлять себя выдумывать альты.
К примеру, на Apple практически все изображения скрыты. Причем многие валидаторы будут светится как новогодняя елка на этой строчке. Но это уже о нюансах реализации и противостоянии здравого смысла против систем автоматической проверки соответствия WCAG.
Важно. Мы можем скрыть не только изображения, а вообще любой тип контента.
Дополнение или замена контента.
Хорошим примером тут является Booking
Дизайнеры сайта позаботились о том, чтобы скринридеры произносили информацию, которую другие пользователи получают просто из визуального контекста.
Каждый продукт существует в каких то рамках — технические, социальные, физическая доступность и многие другие.
Задача дизайна состоит не только в том, чтобы создать идеальный продукт с учетом всех ограничений, но и в том, чтобы продумать реакцию продукта на случаи, которые будут выходить за рамки идеальной среды.
Поэтому спросите себя, а что будет если на ваш сайт попадет человек, который не может видеть?
Чтобы решить эту задачу на этапе дизайна, необходимо определить:
- в каком прядке надо озвучивать контент
- что можно скрыть
- как дополнить или изменить контент так, чтобы он стал понятен без визуального контекста.
Заинтересовала тема доступности?
Можно посмотреть
Для понимания контекста — канал Джеймса Раса. Он все объясняет в своем вступительном видео
Для понимания того, как люди пользуются скринридерами при взаимодействии с сайтами:
Немного про патерны навигации:
Реальный пример взаимодействия с неизвестным сайтом:
Доклад Станислава Зубовича на конференции Web Standards Days (больше для разработчиков)
Доступность от Google и Роба Дадсона
Почитать
WCAG
Первевод WCAG от Юзабилити лаб. Тут только новое по 2.1, но в тексте есть еще и ссылка на 2.0
Несколько упрощенный список на основе WCAG от a11yproject
Для общего понимания в чем разница между ADA, Section 508 и WCAG
Статистика по пользователям скринридеров
WebAim раз в пару лет проводит опросы среди пользователей скринридеров с выборкой в 1000+ человек. Как к примеру:
Куча ссылок на разные ресурсы, так или иначе связанные с вопросами доступности
О опыте взаимодействия с компьютером только используя клавиатуру:
