Стандарт WAI-ARIA 1.0 получил официальный статус рекомендованного W3C: чего ожидать в будущем и куда бежать уже сейчас?

    В конце марта 2014 года Консорциум Всемирной паутины утвердил стандарт WAI-ARIA 1.0 (Web Accessibility Initiative — Accessible Rich Internet Applications (Инициатива web-доступности — Доступность высокотехнологичных Интернет-приложений)). Это набор приёмов и методов, которые позволяют сделать сложные динамические страницы и web-приложения доступными для пользователей с ограниченными возможностями. Дело в том, что ряд новых динамических web-технологий, да и просто применение кастомных элементов интерфейса, например, элементов форм или стилизованных под заголовки div вместо стандартных H1-H6, могут вызывать проблемы у некоторых пользователей, главным образом, у людей с нарушениями зрения и моторики.

    Разработка WAI-ARIA началась ещё в 2008 году, и начальная поддержка этой технологии появилась уже в таких браузерах как, например, Internet Explorer 8, Firefox 3.x или Opera 9.5. Правда из-за постоянного развития стандарта, а также отсутствия у него официального статуса, поддержка конструкций ARIA очень сильно варьируется от браузера к браузеру. Так, по последним исследованиям, Internet Explorer поддерживает около 37% всех возможностей, Firefox — 85%, а Chrome (тут же и Opera) — 47%. Помимо этого, и разное вспомогательное программное обеспечение, в частности, программы экранного доступа, которые применяют в своей работе незрячие пользователи, также поддерживают WAI-ARIA в разной степени и с разной спецификой.

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

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

    Что касается обычных web-разработчиков, то им следует начать знакомство с WAI-ARIA с общего обзора и заметке в блоге W3C, а потом перейти непосредственно к самому стандарту. Базовые вещи по дополнительной семантической вёрстки для программ экранного доступа, типа назначения базовых ролей и состояния элементов, поддерживаются уже достаточно широко и не предполагают сверхглубокого погружения в тему, поэтому соблюдение WAI-ARIA на таком уровне не требует серьёзных усилий, тогда как решает наиболее острые проблемы доступности. Также полезно использовать области навигации, то есть семантическое выделение ключевых областей страницы, типа шапки (role=«banner»), навигационной панели (role=«navigation»), основной области (role=«main»), подвала (role=«contentinfo») и других.

    Тем не менее, применяя WAI-ARIA, надо понимать, что, например, конструкции

    <div role="link">text</div>
    


    и

    <a href="...">text</a>
    


    не являются эквивалентными, так как дополнительная семантика WAI-ARIA предназначается исключительно для вспомогательного программного обеспечения и на поведение браузера влияние не оказывает. То есть первый пример будет считаться ссылкой с точки зрения программы чтения экрана, но с точки зрения браузера он по-прежнему останется обычным блоком и не будет фокусируемым с клавиатуры через табуляцию. В итоге, при первой реализации надо ещё добавлять атрибут tabindex. Так что возможно имеет смысл просто использовать стандартные структурные элементы HTML, чтобы упростить процесс вёрстки. В конце концов, если конфигурация пользователя не в достаточной степени поддерживает WAI-ARIA, то все усилия разработчика по поддержке этой технологии могут оказаться бессмысленными, тогда как использование ссылок, заголовков или списков в простом HTML избавит от необходимости дополнительно прописывать вещи типа role=«link/heading/list», но даст такой же эффект.

    Специалистам, задействованным в инфраструктурных web-проектах, например, в разработке браузеров, также имеет смысл ознакомиться с документом "WAI-ARIA 1.0 User Agent Implementation Guide" (Руководство по внедрению WAI-ARIA 1.0 для клиентских приложений).

    В целом, официальное утверждение WAI-ARIA в мире вспомогательных технологий является важной вехой, хотя возможно люди, далёкие от этого, не совсем чувствуют пафос момента. Всё необходимое для обеспечения высокой доступности современного Интернета теперь есть, остаётся только надеется, что это оценят не только специалисты в узкой сфере accessibility.
    • +17
    • 7.9k
    • 4
    Share post

    Similar posts

    Comments 4

      +3
      Вот, кстати, вопрос (может быть и глупый): как разработчику тестировать то, что он наверстал? Простого включения чего-то типа произношения текста будет достаточно или какие-то особые дополнения или опции требуются? Или можно смело полагаться на валидатор?
        +2
        Вопрос не глупый, а наоборот очень сложный и многоуровневый.

        Машинной проверки однозначно недостаточно. Существуют инструменты для автоматического тестирования доступности web-страниц, но они помогают лишь частично. Как правило, всё сводится к примерной оценки контрастности цветовой схемы, плюс отлавливанию вещей типа отсутствующего или пустого атрибута alt у картинок. По-хорошему тестироваться должно руками.

        Цветовые аспекты вы можете проконтролировать самостоятельно:

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

        Во-вторых, существуют инструменты, позволяющие просмотреть картинку с эмуляцией различных нарушений зрения.

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

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

        Тут вам пригодится атрибут tabindex, который позволяет включить элементы в цепочку клавиатурного фокусирования, а также задать порядок их перебора. Плюс для повышения удобства навигации с клавиатуры можно добавить вверху страницы ссылку «Перейти к основному содержимому», при нажатии на которую фокус будет перебрасываться к началу основной области (делается внутристраничной ссылкой — href="#main"), а также внизу страницы ссылку «Перейти наверх страницы», которая будет перебрасывать в самое начало. Это даст возможность быстрого перемещения без необходимости скролить.

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

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

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

        Впрочем, какую-то базовую вещь протестировать можно и самостоятельно. Например, когда вы будете только осваивать WAI-ARIA, вы сможете хотя бы проверить, действительно ли сделанный chackbox корректно читается, а его состояние отмеченности и неотмеченности распознаётся. Для таких целей я бы, пожалуй, рекомендовал свободную программу экранного доступа для Windows — NVDA. К тому же она одна из самых популярных, и используемый в ней подход к невизуальному представлению информации наиболее распространённый.

        Но всё-таки чтобы полноценно тестировать невизуальную доступность вам надо либо очень глубоко самому погружаться в тему, отключая монитор и серьёзно осваивая программы экранного доступа, либо привлекать дополнительного специалиста. Однако не всё так страшно, и если просто верстать с применением структуры HTML и корректно подписывая картинки и кнопки, то значительную часть проблем вы решите автоматически.
          0
          Спасибо за развёрнутый ответ. Вообще я сторонник хороших контрастных схем, которые не режут глаз и легко читаются, и линейной подачи информации в формах, так что видимо всё не так уж и сложно адаптируется при желании.
          Осталось ещё как-то разъяснять людям, что доступность — это правильно, ведь обычно она вместе с автоматизированным тестированием отходит на второй план, если вообще об этом хотя бы задумываются.
            0
            К сожалению, главные проблемы лежат в сфере невизуального взаимодействия с интерфейсом, а там очень много подводных камней. То, как воспринимается сайт через screenreader, это совершенно другой мир. Внешне красивые сайты могут быть ужасно неудобными для чтецов экрана, и наоборот. Впрочем, визуальная красота и невизуальная доступность могут сосуществовать, так что это не устойчивая зависимость.

            Accessibility в организационном процессе разработки мне скорей напоминает informational security: также обычные разработчики не понимают, зачем их грузят какими-то непонятными вещами, которые никому не видны и обижаются на тестировщиков, которые находят какие-то непонятные ошибки, плюс об accessibility вспоминают обычно лишь при появлении жалоб пользователей, так же как об informational security — когда происходит инцидент.

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

      Only users with full accounts can post comments. Log in, please.