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

Аарон Левенталь
Aaron Leventhal

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

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

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

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

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

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

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

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

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

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

Почему АРИЯ?

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

Допустим, в местном интернет-магазине продаются не все необходимые нам виджеты. Но мы — МакГайвер . Мы можем просто изобретать свои собственные виджеты из других виджетов! Это очень похоже на ситуацию с веб-автором, которому нужно создать строку меню.

Хотя элемент <nav> существует, строки меню часто объединяются с помощью элементов div, изображений, кнопок, обработчиков кликов, дескрипторов нажатия клавиш и ARIA.

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

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

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

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

Все это довольно недоступно, как это обычно бывает со многими вещами в Интернете.

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

Давайте добавим доступность клавиатуры. Для этого требуются только изменения 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" к каждому расширяемому элементу меню, чтобы указать, что есть что-то, что можно расширить, но оно не расширяется. Кроме того, автор должен поместить role="none" в треугольник img , чтобы указать, что это сделано только для красоты. Это не позволит программе чтения с экрана сказать об изображении что-либо лишнее.

Исправить ошибки клавиатуры

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

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

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

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

Ошибки клавиатуры почти всегда являются ошибками веб-контента, особенно HTML и JavaScript, а не 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-версию истины.

Дополнительные ресурсы

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

Что такое API доступности?

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

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

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

,

Аарон Левенталь
Aaron Leventhal

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

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

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

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

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

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

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

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

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

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

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

Почему АРИЯ?

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

Допустим, в местном интернет-магазине продаются не все необходимые нам виджеты. Но мы — МакГайвер . Мы можем просто изобретать свои собственные виджеты из других виджетов! Это очень похоже на ситуацию с веб-автором, которому нужно создать строку меню.

Хотя элемент <nav> существует, строки меню часто объединяются с помощью элементов div, изображений, кнопок, обработчиков кликов, дескрипторов нажатия клавиш и ARIA.

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

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

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

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

Все это довольно недоступно, как это обычно бывает со многими вещами в Интернете.

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

Давайте добавим доступность клавиатуры. Для этого требуются только изменения 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" к каждому расширяемому элементу меню, чтобы указать, что есть что-то, что можно расширить, но оно не расширяется. Кроме того, автор должен поместить role="none" в треугольник img , чтобы указать, что это сделано только для красоты. Это не позволит программе чтения с экрана сказать об изображении что-либо лишнее.

Исправить ошибки клавиатуры

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

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

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

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

Ошибки клавиатуры почти всегда являются ошибками веб-контента, особенно HTML и JavaScript, а не 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-версию истины.

Дополнительные ресурсы

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

Что такое API доступности?

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

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

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