Доступность: в каких сценариях не будет анонсировано описание арии? - PullRequest
2 голосов
/ 05 июня 2019

Я работаю над созданием доступного текста справки для элементов управления моей формы. Я планирую использовать aria-describedby, чтобы прикрепить доступное описание к полю. Этот подход обсуждается здесь

Хотя при тестировании с расширением ChromeVox и программой чтения с экрана Windows 10 я обнаружил, что aria-describedby не объявлено, , но оно довольно хорошо поддерживается во всех браузерах и программах чтения с экрана , поэтому я планирую использовать этот подход.

Также это предполагает, что в некоторых случаях aria-describedby будет игнорироваться или работать не так, как ожидалось, но эти случаи довольно специфичны, и я в целом согласен с этим.

содержание, описанное в арии, не всегда может быть объявлено пользователям, в зависимости от их чтения с экрана и метода навигации. Атрибут хорошо поддерживается, но это не значит, что знать: содержание, описанное в арии, может быть объявлено не всеми средства чтения с экрана при переходе к кнопке, ссылке или элементу управления с помощью виртуальный курсор. В частности, JAWS не может анонсировать элемент описание при использовании горячих клавиш для перехода к определенным элементам. когда Навигация по посещаемым ссылкам, описание не будет объявлено. Однако JAWS должен объявлять описания при навигации по форме управления. JAWS 17 + IE не будет анонсировать содержание, описанное в арии, когда переход по ссылке (более новая версия JAWS исправила это). IE11 не будет объявить доступное имя или описание элемента управления формы, если title атрибут используется в тандеме с описанным арией, а пользователь перемещается с помощью виртуального курсора или горячей клавиши управления формой (F). И то и другое будет объявлено при использовании клавиши Tab. (IE11 имел гораздо большие проблемы с арией, описанной в прошлом.) TalkBack + Android Chrome не будет объявлять любые арии, описанные содержимым модального диалога, когда автофокусировка элемента в этом диалоге. Если пользователь имеет описания или подсказки отключены, любое связанное содержимое не будет объявил. Поэтому очень важно, чтобы любой контент, который необходимо, чтобы понимание пользовательского интерфейса было доступно с помощью других чем просто ария, описанная.

Я хотел бы понять, бывают ли случаи, когда aria-describedby не будет объявлено автоматически? Предыдущая фраза ссылки, похоже, предполагает, что она будет объявлена ​​только по запросу:

Используя aria-описанный byby для ссылки на формат поля, этот информация предоставляется пользователям по запросу. То есть не отображается автоматически или читать вслух. Это имеет смысл, если Пользователь был проинформирован о формате раньше или когда есть много поля ввода с таким же форматом, например.

Я не понимаю, что значит "по запросу". Я полагаю, что стандартное поведение заключается в объявлении текста, описанного в арии, после объявления метки и типа ввода.

1 Ответ

1 голос
/ 06 июня 2019

Поведение aria-describedby (например, aria-label и aria-labeledby) глубоко зависит от роли элемента, в котором они появляются.

Как вы, возможно, знаете, программы чтения с экрана обычно имеют два «режима» , и это в основном определяется ролью (или семантикой по умолчанию) содержимого.

У меня наверняка были проблемы с объявлением неинтерактивных элементов, если они появляются в интерактивном ("режиме форм") контенте.

У меня были хорошие результаты при использовании aria-describedby с модальным контентом. (Поместите атрибут на модальное поле и укажите на текстовые элементы, внутри которых вы хотите объявить, когда модальное окно открывается.) Но я полагаю, это потому, что существует очевидный момент, когда программа чтения с экрана должна делать эти объявления: момент, когда модал открывается.

В случае, когда форма (или другой контейнер "режима форм") всегда присутствует на странице, вы обычно можете читать неинтерактивный контент, используя комбинации клавиш режима обзора, такие как "следующий заголовок" ("Н") на NVDA и JAWS) или «следующий абзац» («P»). Проверьте, достаточно ли этих «запросов» для решения.

Вы также можете поэкспериментировать со стандартными элементами HTML fieldset и legend, целью которых является предоставление текстового описания для групп интерактивных элементов.

Также подумайте о том, чтобы рассматривать «форму» (или панель инструментов или что-то еще) как одну точку табуляции и использовать клавиши со стрелками для навигации по компонентам внутри. Таким образом, когда вы сосредотачиваетесь на контейнере, вы должны получить объявление о том, что aria-describedby (или действительно aria-labeledby / aria-label)

Если это не работает для вас, есть пара хаков, которые вы можете попробовать в крайнем случае:

  • Поместите tabindex="-1" на элемент, окружающий текст, который вы хотите объявил, а затем позвоните focus() на этот элемент в соответствующем момент.
  • Скопируйте текст в текстовое содержимое области aria-live с javaScript в соответствующий момент.

Ни один из этих хаков не хорош и может не подойти вам, если нет «подходящего момента». (Нет эквивалента onfocus для режима просмотра). Но с небольшой осторожностью их можно заставить работать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...