Подстраховка web-доступности семантических областей HTML5 через роли WAI-ARIA

[PopeyetheSailor]

Не очень хорошо знаком с ситуацией, подскажите, WAI-ARIA как-то согласуется с ГОСТ о accessibility?

[Tseikovets]

WAI-ARIA — это чисто технический стандарт, где описана конкретная технология: какие есть атрибуты, их значения, и когда и как всё это применять. ГОСТ же скорей относится к менеджерским документам, он декларирует, что интерфейс должен быть доступен в таких-то и таких-то условиях, но как именно этого достичь с технической точки зрения там, по большому счёту, не написано.

Вообще у ГОСТа Р52872-2007 есть две версии: старая, которая вообще мало с чем согласуется, и новая, у которой тоже куча проблем, но она в значительной степени построена на повторении идей стандарта WCAG 2.0 от W3C. WCAG 2.0 в общем-то тоже скорей менеджерский документ, но более комплексный и всеобъемлющий, плюс с более внятной методологией оценки соответствия, поэтому я бы советовал читать его, а не ГОСТ.

Если что, у WCAG 2.0 есть и уполномоченный русский перевод. Кстати, Р52872-2007 ссылается не на этот перевод WCAG, потому что его тогда ещё не было, так что к корректности самого этого ГОСТа в принципе есть вопросы, даже не говоря о том, что он покрывает лишь один аспект доступности, а WCAG всеобъемлющ.

[mvs]

Ну а для тегов header, main или footer вообще нет необходимости прописывать aria-label, так как они в принципе должны быть на странице лишь в единственном экземпляре и их назначение итак понятно.

Не совсем верно: header и footer могут быть вложены в section, article или ещё куда угодно, поэтому далеко не всегда будут в единственном экземпляре. А main должен быть уникален, да.

[Tseikovets]

Да, вы правы. Подкорректировал текст статьи. Спасибо.

[Hooter]

Вопрос, а почему main должен быть один? Например у меня бывают всплывающие модальные окна с role=«ariadialog», на рамках которых фокус удерживается принудительно. Там тоже могут быть теги main как понимаю.

Может правило не столь категоричное?

[YakovLitvin]

Вторая ссылка (в конце статьи) протухла.

Чтобы два раза не вставать: не посоветуете ли каких-то гайдов по обеспечению accessability – хотя бы для экранных читалок. Как-то в статьях редко разбирают, что именно будет прочитано для той или иной разметки; или там чего установить, чтобы потестировать

[Tseikovets]

> Вторая ссылка (в конце статьи) протухла.

Ссылку починил, но она там идёт на раздел большой спецификации, так что возможно не сразу очевидно. Нужен раздел «5. The Roles Model». Он тоже не маленький, так что можно по оглавлению посмотреть интересующий подраздел, если возник какой-то точечный вопрос. Конкретно роли семантических областей страницы, про которые и был этот пост, называются Landmark Roles (это раздел 5.3.4 спецификации).

> Чтобы два раза не вставать: не посоветуете ли каких-то гайдов по обеспечению accessability – хотя бы для экранных читалок.

Есть несколько источников, с которыми имеет смысл работать:

1. Web Content Accessibility Guidelines (WCAG) 2.1 — базовый стандарт от W3C. Он посвящён в основном концептуальным вопросам, то есть не освещает конкретные технические решения, а даёт понимание тех проблем, которые надо учитывать. Скорей что-то типа ориентира для формулировки ТЗ. Полезно для общего понимания проблематики web-доступности во всех аспектах.
2. Accessible Rich Internet Applications (WAI-ARIA) 1.1 — основная спецификация технологии обеспечения доступности rich internet applications от W3C. Это именно технический документ для разработчиков, описывающий то, как нужно решать задачи обеспечения web-доступности для программ чтения экрана и прочего вспомогательного ПО. Имеет смысл хотя бы раз ознакомительно пробежать весь документ, чтобы представлять набор решений и освоить его на уровне «кажется что-то про это я где-то видел», ну и потом уже прибегать к нему как к справочнику по конкретным ситуациям. Это часть целого набора спецификаций, сосредоточенная на основных проблемах, связанных с доступностью базовых элементов страницы, но в отдельных сложных случаях, типа обеспечения доступности SVG и прочего, могут понадобиться остальные документы, полный перечень которых есть на странице WAI-ARIA Overview.
3. WAI-ARIA Authoring Practices 1.1 — документ от W3C, описывающий некоторые неочевидные аспекты применения стандарта ARIA 1.1 и содержащий конкретные шаблоны проектирования интерфейса для базовых элементов. Вместо того, чтобы изобретать велосипед и пытаться имплементировать WAI-ARIA в свои кастомные элементы интерфейса, имеет смысл поискать здесь готовую реализацию.
4. Ну и конкретные задачи, типа обеспечения доступности выпадающего меню или чего-нибудь ещё, можно просто искать в Интернете с ключевыми словами, типа «web accessibility drop-down menu» или «accessible drop-down menu». В результатах, в первую очередь, стоит обращать внимание на отдельные материалы с примерами с сайтов W3C, браузеров и браузерных движков, а также крупных информационных ресурсов, типа MDN. Всякие статьи в личных блогах рейтингуйте ниже, потому что там не всё и не всегда правильно, а пока у вас не наработан опыт, вы можете это не заметить и повторить плохое решение.

> Как-то в статьях редко разбирают, что именно будет прочитано для той или иной разметки; или там чего установить, чтобы потестировать

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

В целом, тестирование web-доступности, как и везде, делится на автоматизированное и ручное.

Из автоматизированных методов можно отметить такой инструмент как Axe, который можно встроить в систему непрерывной интеграции, а также внутренние инструменты в браузерах, а именно: аудит доступности в Chrome и Инспектор доступности в Firefox.

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

Лучше всего взять Windows и установить туда бесплатную программу NVDA (есть и portable вариант запуска). По команде Insert+N или через иконку в области задач можно открыть меню программы, где, помимо прочего, будет справка и настройки. На слух понимать программу со стандартным синтезатором речи, скорей всего, будет тяжело. Поэтому можно либо поставить более качественный бесплатный синтезатор речи RHVoice (версия в виде дополнения для NVDA), либо через меню «Сервис» включить функцию «Просмоторщик речи», которая отобразит на экране область, где будут выводиться текстом все фразы программы.

Далее открываем сайт в браузере и проверяем, читается ли весь контент и элементы управления, а также осуществляется ли с ними корректное взаимодействие. Имеет смысл по CTRL+Home переместиться в начало, а потом стрелкой вниз пройтись по всей странице. Конкретно семантические области страницы можно перебрать нажатием D (сверху вниз) и Shift+D (снизу вверх). Также можно по Insert+F7 открыть диалог агрегированного отображения элементов страницы, выбрать там переключателем «Ориентиры» и в этом окне будет показано иерархическое дерево семантических областей. Подробнее обо всех командах работы в Интернете можно почитать в руководстве NVDA, доступном через меню программы.

У многих разработчиков основной системой является macOS, где есть встроенная функция чтения экрана VoiceOver. К сожалению, VoiceOver довольно слабое решение в отношении обеспечения невизуальной доступности web-контента, да к тому же с рядом крайне спорных технологических решений, ну и в англоязычной среде имеющее распространение среди реальных пользователей меньше 10%, а в русскоязычной — меньше 5%. Это одна из проблем индустрии, потому что многие разработчики если что-то руками и проверяют, то как раз на VoiceOver, ну и порой получают не лучшее качество.

Впрочем, для совсем базовых вещей VoiceOver тоже можно использовать. Он активируется по команде CMD+F5 (в зависимости от настроек клавиатуры может быть FN+CMD+F5). Настройки открываются по CMD+Option+F8. В настройках можно включить так называемую панель субтитров, которая также будет выводить фразы в виде текста на экране.

С VoiceOver имеет смысл включить быструю навигацию по одновременному нажатию стрелок вправо и влево, а потом пройтись по содержимому страницы стрелкой вправо. Отдельные блоки контента он сворачивает в условные контейнеры, которые можно открыть командой Вниз+Вправо. Элемент активируется командой Вверх+Вниз. Справку по командам можно открыть по CMD+Option+H, ну и при запуске сразу будет открыто руководство для быстрого освоения, хотя раздела по обучению web-навигации там по-моему до сих пор нет. Полный учебник по VoiceOver лежит здесь.

Это я попытался ответить на ваш вопрос кратко, так что, как видите, поднятая тема очень обширная, если краткие ответы получаются такими длинными. :-)

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