АРИЯ: яд или противоядие?

Как ложь программам чтения с экрана лечит доступность, если она не втирает в нее соль!

Aaron Leventhal

Что такое АРИЯ?

ARIA позволяет веб-авторам создавать альтернативную реальность, видимую только программам чтения с экрана 🤥

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

Всякий раз, когда существует волшебная заметка, она либо отвергает наше представление о том, что представляет собой каждый инструмент, либо что-то об этом инструменте. Пример: «Вот эта штука — клеевой пистолет!». Хотя на самом деле это по-прежнему пустая синяя коробка, стоящая на верстаке, волшебная наклейка заставит нас понять, что это клеевой пистолет. Мы также можем добавить: «и он заполнен на 30%!». Программа чтения с экрана сообщит, что клеевой пистолет заполнен на 30%.

Веб-эквивалент этого состоит в том, чтобы взять простой элемент блока (div) с изображением внутри него и использовать ARIA, чтобы указать, что это ползунок со значением 30 из 100.

Что не такое АРИЯ?

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

Вы правильно прочитали: ARIA на самом деле ничего не делает с фокусом клавиатуры или порядком табуляции. Все это сделано в HTML, иногда с добавлением JavaScript.

Как работает АРИЯ?

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

Почему АРИЯ?

Зачем нам вообще лгать нашим пользователям!?

Допустим, в местном интернет-магазине продаются не все необходимые нам виджеты. Но, черт возьми, мы МакГайвер . Мы можем просто изобретать свои собственные виджеты из других виджетов! Кстати, семь наиболее часто используемых вещей МакГайвера — это швейцарские армейские ножи, жевательная резинка, шнурки для обуви, спички, скрепки, праздничные свечи и клейкая лента. Он использует их для изготовления бомб и других вещей, которые не валяются просто так. Это очень похоже на ситуацию с веб-автором, которому нужно создать строку меню. Строки меню настолько полезны, что можно подумать, что они являются частью HTML, но это не так. Ну что ж! Вы же не думали, что авторам понравятся ссылки и кнопки? Поэтому автор соберет его, используя свои любимые инструменты: элементы div, изображения, стиль, обработчики кликов, обработчики нажатия клавиш, Spit и ARIA.

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

Пример строки меню

Поддержка любителей кликеров мышью

Давайте вместе сделаем строку меню. Мы показываем множество элементов в общих элементах блока, называемых div. Каждый раз, когда наш пользователь нажимает на элемент div, он выполняет соответствующую команду. Круто, это работает для тех, кто кликает мышью!

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

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

Конечно, все это довольно недоступно, как это обычно бывает со многими вещами в Интернете, во многом потому, что мастера стандартов HTML не добавили все, что нужно веб-автору. И даже если бы они это сделали, веб-авторы все равно всегда хотели бы изобрести свою собственную специальную версию.

Делаем нашу клавиатуру в строке меню доступной

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

Точно так же, как веб-страница может реагировать на мышь, она также может реагировать на клавиатуру. Наш JavaScript будет прослушивать все нажатия клавиш и решать, полезно ли нажатие клавиши. Если нет, он выбрасывает его обратно на страницу, как рыбу, которую невозможно съесть. Наши правила примерно такие:

• Если пользователь нажимает клавишу со стрелкой, давайте посмотрим на наши собственные схемы внутренней строки меню и решим, каким должен быть новый активный пункт меню. Мы удалим все текущие выделения и выделим новый пункт меню, чтобы зрячий пользователь визуально знал, где он находится. Затем веб-страница должна вызвать event.preventDefault() , чтобы запретить браузеру выполнять обычное действие (в данном случае прокрутку страницы).
• Если пользователь нажимает клавишу Enter , мы можем рассматривать это как щелчок и выполнить соответствующее действие (или даже открыть другое меню).
• Если пользователь нажимает клавишу, которая должна сделать что-то еще, не ешьте это! Верните его обратно на страницу, как задумано природой. Например, нашей строке меню не нужна клавиша Tab , так что бросьте ее! Это трудно понять правильно, и авторы часто путают это. Например, для строки меню нужны клавиши со стрелками, а не Alt + Arrow или Command + Arrow. Это ярлыки для перехода к предыдущей/следующей странице в истории веб-поиска на вкладке браузера. Если автор не будет осторожен, строка меню съест их. Подобные ошибки случаются часто, а мы еще даже не начали работать с ARIA!

Доступ к программе чтения с экрана к нашей строке меню

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

Но это несправедливо! Строка меню отлично подходит для зрячего пользователя.

АРИЯ спешит на помощь. ARIA позволяет нам представить программе чтения с экрана, что фокус находится в строке меню. Если автор все сделает правильно, наша пользовательская строка меню будет выглядеть для программы чтения с экрана так же, как строка меню в настольном приложении.

Наша первая, кхм, ложь ARIA — использовать атрибут aria-activedescendant и установить для него идентификатор текущего активного пункта меню, стараясь обновлять его при каждом изменении. Например, aria-activedescendant="settings-menuitem" . Эта маленькая невинная ложь заставляет программу чтения с экрана рассматривать наш активный элемент ARIA как фокус, который читается вслух или отображается на дисплее Брайля.

Вернёмся к aria-activedescendant . Используя его для указания из выделенной строки меню на определенный пункт меню, программа чтения с экрана теперь знает, куда переместился пользователь, но ничего больше об объекте. Что это вообще за div? Вот тут-то и появляется атрибут role. Мы используем role="menubar" для содержащего элемента для всего объекта, затем мы используем role="menu" для групп элементов и role="menuitem" для... барабанной дроби... отдельного меню. предметы.

А что, если элемент меню может вести к дочернему меню? Пользователь должен это знать, верно? Для зрячего пользователя в конце меню может быть небольшая картинка в виде треугольника, но программа чтения с экрана не умеет автоматически считывать изображения, по крайней мере, на данном этапе. Мы можем добавить aria-expanded="false" к каждому расширяемому элементу меню, чтобы указать, что 1) есть что-то, что можно расширить, и 2) в настоящее время оно не расширено. В качестве дополнительного штриха автор должен поместить role="none" в треугольник img, чтобы указать, что это сделано только для целей украшения. Это не позволяет программе чтения с экрана сказать об изображении что-либо, что в лучшем случае было бы избыточным и, возможно, раздражающим.

Работа с ошибками

Ошибки клавиатуры (HTML!)

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

Примеры ошибок:

• Флажок использует пробел для переключения, но автор забыл вызвать preventDefault() . Теперь клавиша пробела будет переключать флажок и страницу вниз, что является поведением браузера по умолчанию для клавиши пробела.
• Модальный диалог ARIA хочет захватить внутри себя навигацию по вкладкам, а автор забывает специально разрешить переход Control + Tab в браузер. Теперь Control + Tab просто перемещается по диалоговому окну и не переключает вкладки в браузере, как должно. Фу.
• Автор создает список выбора и реализует вверх/вниз, но не реализует навигацию домой/конец/вверх/вниз или навигацию по первым буквам.

Авторы должны следовать известным закономерностям. Посетите раздел «Ресурсы» для получения дополнительной информации.

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

Ошибки клавиатуры почти всегда являются ошибками веб-контента, особенно HTML и JavaScript, а не ARIA.

Баги ARIA: почему их так много?

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

В конце концов, если автор не является опытным пользователем программы чтения с экрана, в ARIA что-то пойдет не так. В нашем примере со строкой меню автор мог подумать, что роль «option» должна использоваться, когда «menuitem» правильный. Они могли забыть использовать aria-expanded , забыть установить и очистить aria-activedescendant в нужное время или забыть иметь строку меню, содержащую другие меню. А как насчет количества пунктов меню? Обычно пункты меню представляются программами чтения с экрана чем-то вроде «пункт 3 из 5», чтобы пользователь знал, где они находятся. Обычно это рассчитывается браузером автоматически, но в некоторых случаях и в некоторых комбинациях браузера и программы чтения с экрана могут быть вычислены неверные числа, и автору придется переопределить эти числа с помощью aria-posinset и aria-setsize .

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

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

Краткое содержание

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

ARIA — это простой уровень разметки, переопределяющий истину. Когда программа чтения с экрана спрашивает, что происходит, если ARIA существует, они получают ARIA-версию истины вместо реальной базовой истины.

Приложение 1: Дополнительные ресурсы

Гибридный справочник с информацией о клавиатуре и примерами кода.

• Практика разработки ARIA W3C : документирует важные характеристики навигации с помощью клавиатуры в каждом примере и предоставляет рабочий код JS/CSS/ARIA. Примеры сосредоточены на том, что работает сегодня, и не касаются мобильных устройств.

Приложение 2: Для чего чаще всего используется ARIA?

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

Вот некоторые распространенные варианты использования ARIA.

• Специальные виджеты, которых нет в HTML, например строка меню, автозаполнение, дерево или электронная таблица.
• Виджеты, которые существуют в HTML, но автор все равно изобрел свои собственные, возможно, потому, что им нужно было настроить поведение или внешний вид обычного виджета. Например, элемент HTML <input type="range"> по сути представляет собой слайдер, но авторы хотят, чтобы он выглядел по-другому. Для большинства вещей можно использовать CSS, но для input type="range" CSS неудобен. Автор может создать свой собственный слайдер и использовать на нем role="slider" с aria-valuenow чтобы указать текущее значение.
• Живые регионы сообщают программам чтения с экрана, что «в этой области страницы обо всем, что меняется, стоит рассказать пользователю».
• Ориентиры (теперь у HTML есть эквиваленты). Они чем-то похожи на заголовки, поскольку помогают пользователям программ чтения с экрана быстрее находить то, что им нужно. Однако они отличаются тем, что содержат всю связанную область. Например, «этот контейнер — основная область страницы» и «этот контейнер — панель навигации».

Приложение 3. Что такое API специальных возможностей?

API доступности — это то, как программа чтения с экрана или другой AT узнает, что находится на странице и что происходит прямо сейчас. Примеры включают MSAA, IA2 и UIA. И это только Windows! API доступности состоит из двух частей:

• «Дерево» объектов, представляющее иерархию контейнеров. Это как русские матрешки, но каждая кукла может содержать несколько других кукол. Например, документ может содержать несколько абзацев, а абзац может содержать текст, изображения, ссылки, жирный шрифт и т. д. Каждый элемент в дереве объектов может иметь такие свойства, как роль (что я такое?), имя/метка. , введенное пользователем значение, описание, а также логические состояния, такие как фокусируемый, сфокусированный, обязательный, проверенный. ARIA может переопределить любое из этих свойств. Программа чтения с экрана использует дерево, чтобы помочь пользователю перемещаться в режиме виртуального буфера, например «перейдите к следующему заголовку, пожалуйста».
• Происходит серия событий, описывающих изменения в дереве, например «фокус здесь!». Программа чтения с экрана использует события, чтобы сообщить пользователю, что только что произошло. Когда меняется важная разметка HTML или ARIA, генерируется событие, сообщающее программе чтения с экрана, что что-то изменилось.

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