Web-разработка

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

Ознакомьтесь с имеющимся руководством. За детальной информацией обратитесь к рекомендациям по web-разработке.

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

Следите за корректностью верстки: от нее зависит доступность и правильная работа скринридера.

Проводите автоматизированное тестирование доступности в процессе разработки.

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

Пользователи

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

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

При проектировании учитывайте особенности людей

Нарушение зрения

Слепота, близорукость или дальнозоркость, дальтонизм.

Нарушение слуха

Глухота или тугоухость, звон в ушах.

Нарушение моторики

Дрожание рук, деформация или отсутствие конечностей.

Проблемы восприятия

Дислексия, деменция, депривация сна.

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

Вспомогательные технологии

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

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

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

Уровень владения вспомогательными технологиями отличается от человека к человеку и зависят от наличия, типа инвалидности, возраста человека и других факторов. Некоторые вспомогательные технологии скорее всего вам знакомы — голосовое управление в телефоне, эргономичная клавиатура, функция увеличения страницы в браузере. Другие вспомогательные технологии, возможно, менее для вас знакомы: программы экранного доступа (screen reader), виртуальные контроллеры (switch devices), экранные лупы и другие.

Программы экранного доступа

Для взаимодействия с компьютером и смартфоном незрячие люди используют голосовой интерфейс программ экранного доступа. Попробуйте в действии программы экранного доступа (VoiceOver на Маке, VoiceOver на iOS, TalkBack на Android, NVDA или JAWS для Windows) — так вы узнаете, как люди взаимодействуют с интерфейсом и сможете самостоятельно проводить первичное тестирование.

Скринридер выводит информацию блоками. Какая именно информация попадёт в блок определяет разработчик приложения и операционная система. Если курсор скринридера встал на кнопку, то в блок вывода речевого сообщения попадёт название кнопки от разработчика и тип этого элемента от операционной системы. Так пользователь понимает, что это за элемент и как с ним работать.

В большинстве случаев после секундной паузы скринридер подскажет, как взаимодействовать с этим типом элементов. Например в системе Android, если это что-то кликабельное (кнопка или ссылка), то скринридер озвучит: «Нажмите дважды, чтобы активировать». На заголовке, очевидно, этого не будет — программа скажет: «Заголовок».

Управление со скринридером

Использование VoiceOver на Mac

Включить VoiceOver

⌘ + F5

Начать взаимодействие с объектом

Ctrl + Alt + Shift + ↓

Навигация вправо

Ctrl + Alt + →

Навигация по заголовкам

Ctrl + Alt + ⌘ + H

Клик

Ctrl + Alt + Space

Активация ротора

Ctrl + Alt + U

Навигация по элементам ротора

Стрелки вверх-вниз-влево-вправо

Использование скринридеров JAWs и NVDA на Windows

Навигация к след./пред. элементу

Стрелки вниз/вверх

Чтение текста текущего элемента

Стрелки влево/вправо

Активация элемента

Enter или Пробел

Навигация по заголовкам

H

Навигация по кнопкам

B

Активация ротора

Ctrl + Alt + U

Навигация по полям ввода

E

Заголовок текущего окна

Insert + T

Доступ с клавиатуры

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

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

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

Пользователь должен иметь возможность выбрать и активировать любой интерактивный элемент на странице с помощью клавиш Tab, пробела и стрелок.

Для зрячих пользователей важно чтобы интерактивные элементы имели видимые и привычные состояния: focus, hover, active, и visited.

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

Когда готова верстка, проверьте с помощью клавиши Tab, что при управлении с клавиатуры видно, где фокус. Особенное внимание уделите страницам, которые используют JavaScript, и созданным без использования стандартных HTML-элементов.

При переходе по элементам в поисковике Google каждый элемент в фокусе подсвечен голубой рамкой

WCAG 2.1

Масштабирование

Убедитесь, что при увеличении контента до 200% страница читаема и функциональна, а пользователю не требуется прокручивать страницу по горизонтали.

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

У Ани нет компьютера, для выхода в сеть она всегда использует планшет. Когда сайт не адаптируется под экран, ей трудно управлять им.

Чтобы пользователь мог самостоятельно выбирать масштаб контента и при этом сайт оставался читаемым, лучший способ — использовать адаптивную верстку. Таким образом вы не только закроете потребности людей с нарушением зрения, но и обеспечите адаптируемость вашего сайта под любой размер устройства. Когда верстка готова, сделайте проверку: увеличьте экран до 200% с помощью комбинаций клавиш «Cmd +» или «Ctrl +».

Плохой пример масштабирования.
Хороший пример масштабирования.

WCAG 2.1

Навигация

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

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

Обеспечьте логичный переход фокуса на странице.

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

Плохо: «Доброе утро, Валерия!»

Хорошо: «Доброе утро, Валерия, подождите, идет загрузка».

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

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

Обеспечьте логичный переход фокуса между элементами.

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

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

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

Используйте лендмарк-элементы для быстрой навигации пользователей по странице.

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

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

Проработайте базовые лендмарк-элементы, которые задаются либо семантическими маркерами в HTML5, либо с помощью ARIA-ролей:

  • <header> для шапки сайта. Поместите вводные элементы сайта, которые есть на каждой странице — логотип, навигация, заголовок страницы, поиск;
  • <aside> для боковой колонки со списком статей, рекламы, архивных записей;
  • <section> для разделения страницы на смысловые части;
  • <footer> для нижнего блока страницы с информацией об авторе статьи, данные о копирайте и т. д.
  • <nav> для навигации по сайту;
  • <main> для основного содержимого страницы

Используйте такие же элементы для контента (section, article, aside), чтобы делить содержимое страницы на логические блоки.

Чтобы обозначить важные элементы страницы, добавьте role="banner" для шапки и role="contentinfo" для подвала на каждой странице.

Убедитесь, что заголовки отображают структуру страницы.

Используйте уровни заголовков h1—h6: где h1 — для самого верхнего уровня, h6 — для самого нижнего.

Не пропускайте уровни заголовков: всегда начинайте с h1, затем назначайте h2 и так далее.

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

По теме

WCAG 2.1

Элементы интерфейса

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

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

Вера — слепая. Она понимает, что изображено на картинке, по подписи к ней. Если таблица сверстана как картинка, скринридер не сможет прочитать ей содержимое ячеек.

У Васи медленный интернет, поэтому картинки и иконки не загружаются. Для него, как и для Веры, важны подписи в коде.

Что делать

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

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

У кастомных или более сложных элементов тип элемента может быть определен неверно; тогда необходимо определить тип самостоятельно.

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

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

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

Недекоративный элемент

<img src="card.png" alt="Молодёжная карта с подписью Егора Крида "Это мое">

Кнопка-иконка

<input type="image" src="location.gif" alt="Моё местоположение" />

Описывайте поля ввода с помощью label, атрибутов title или aria-label. Добавляйте инструкции и описания ошибок в виде текста. Не ссылайтесь в подсказках на внешний вид или расположение элементов.

Если элемент не представляет ценности для пользователя скринридера, его «видимость» для пользователя нужно отключить. Например, если картинка декоративная, используйте пустой alt текст (alt=" ").

Декоративное изображение

Добавьте пустой alt=" " или атрибуты role="presentation" и aria-hidden="true"

<img src="gradient.png" aria-hidden="true" alt=" ">

Подписывайте элементы с одинаковой функциональностью одинаково всегда.

Карта виза

Хорошо: «Тип карты, платежная система, последние 4 цифры, способ оплаты, слово «баланс», озвучка баланса с рублями и копейками, валюта»

Озвучка: Дебетовая Карта, VISA Classic, 4678, бесконтактная, баланс 20900 рублей 80 копеек

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

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

Хорошо: "ЖКХ и домашний телефон."

Следите за раскладкой клавиатуры. Помните, что английская буква C и русская буква С – это 2 абсолютно разных символа. Программа экранного доступа прочитывает символ, исходя из его кода в таблице символов, а не из начертания на экране. Наличие подобных опечаток сильно усложняет работу с текстом с помощью скринридеров незрячим людям. Например, назначая встречу в переговорке 15.C.04 следует даже ради одной буквы переключить раскладку клавиатуры, иначе пользователь программ экранного доступа будет искать переговорку «Эс», а не «Си».

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

Если на экране в результате действий пользователя появилась какая-то информация, которой до этого не было – пользователь должен об этом узнать. Это может быть появление клавиатуры при активации поля ввода, автоматическая замена символа «8» на «+7» при вводе номера телефона и т. п.

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

По теме

WCAG 2.1

Тестирование

Тестируйте автоматизированно и с пользователями.

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

Автоматизированное тестирование

Быстрая проверка: используйте инструменты для быстрой проверки на типичные ошибки — HTML CodeSniffer , aXe , Lighthouse Accessibility Audit или WAVE.

Процесс сборки: интегрируйте инструменты axe-core , Lighthouse Audits или AccessLint.js в ваш проект, чтобы программно добавлять тесты доступности и отлавливать ошибки при сборке интерфейса.

Постоянная интеграция: пользуйтесь инструментами вроде AccessLint, чтобы находить проблемы доступности во время пулла на GitHub.

Тестирование с незрячими пользователями

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

Убедитесь, что контент воспроизводится в правильно порядке: лейбл до поля, заголовки до контента и т.д.

Проверьте, что в коде указан язык и скринридер произносит слова без акцента.

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

По теме