Яндекс. Accessibility. Как мы делаем Яндекс доступным людям с ограниченными возможностями и почему считаем это важным [Яндекс] (docx) читать постранично, страница - 4

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

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

Важно осознать, что существуют не только мышка и touch screen и что использование клавиатуры — это нормальный способ взаимодействия с интерфейсом. Далее, следует помнить, что стандартные элементы управления интерфейса (как для web, так и для приложений) уже имеют встроенную реализацию доступности. Если использовать стандартные элементы по назначению, не придётся связываться с низкоуровневой разработкой accessibility.
Примеры из жизни

Впрочем, порой приходится придумывать нестандартные решения, не описанные в технических спецификациях.

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

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

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

Но, как уже говорилось, иногда приходится учитывать специфику или откровенные недоработки вспомогательных технологий, реализуя обходные пути. Например, зайдите на главную страницу Яндекса и откройте код страницы. Обратите внимание на оформление температуры в погодном блоке. Обычный текст ссылки продублирован атрибутом aria-label, предназначенным для добавления специальных меток для вспомогательных технологий. Казалось бы, зачем дублировать имеющийся текст?! За этим стоит решение достаточно серьёзной проблемы.

Дело в том, что в исходной вёрстке страницы отрицательные значения температуры оформляются при помощи символа вычитания «−» (U+2212), который является мало распространённым и не опознаётся программами экранного доступа как знак минус. В итоге, запись «−5» программой читается просто как «пять», а не «минус пять». В качестве символа отрицательного числа программы чтения экрана корректно воспринимают лишь стандартный ASCII-символ дефиса «-» (U+2D). Именно поэтому здесь прописан дублирующий атрибут aria-label, в котором специально для программ чтения экрана числа отдаются со знаком дефиса, тогда как для визуального интерфейса сохранён знак вычитания.



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

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

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



Невизуальный дизайн

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

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

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

Невизуальный дизайн Яндекса строится на нескольких базовых принципах.
• Любая часть страницы должна принадлежать