Aria label не работает

Правила использования ARIA в HTML

The Web Accessibility Initiative’s Accessible Rich Internet Applications Suite (WAI-ARIA, или просто ARIA) — это набор инструментов и указаний для того, чтобы сделать веб-контент и приложения более доступными.
В частности, он включает в себя набор атрибутов, которые мы можем добавлять к HTML-элементам для придания им семантической информации, которая может быть прочитана с помощью специальных возможностей (assistive technologies).

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

1. Используйте семантический HTML в пользу ARIA

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

Правило номер один — не пытайтесь использовать ARIA, если в этом нет необходимости. HTML5 предоставляет нам широкий спектр семантических элементов.

Поэтому, по возможности, нам стоит использовать семантический HTML-элемент, а не ARIA-атрибут.

Вместо того, чтобы создавать

Нам следует использовать элемент :

2. Не изменяйте значения семантических элементов ARIA-ролями

Не изменяйте нативную семантику элемента, если вам это не необходимо.

Как я уже замечала, многие семантические HTML-элементы имеют свой смысл. Когда мы используем , например, это указывает юзер-агентам, что это — интерактивный элемент (с ним можно взаимодействовать при помощи клика мыши, клавиши Enter или пробела), что вызовет какое-либо действие на странице. С другой стороны, если мы используем элемент , это указывает юзер-агентам, что интерактивное взаимодействие с таким элементом (посредством клика или нажатии клавиши) приведёт к тому, что пользователь будет направлен на другую страницу или в другую часть этой же самой страницы.

Вместо переопределения семантического значения элемента, нам следует использовать соответствующий элемент:

Или, в крайнем случае, мы можем добавить ARIA-роль к элементу, который не несет такого смысла.

3. Интерактивные элементы ARIA должны быть доступны для всех сред

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

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

В руководстве ARIA имеется список возможностей, которые должен иметь каждый элемент. Например, настоящая кнопка должна удовлетворять следующим требованиям:

• Должна быть кликабельной с помощью курсора
• Должна быть кликабельной с помощью клавиши Enter
• Должна быть кликабельной с помощью клавиши пробела

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

4. Используйте соответствующие роли для видимых фокусируемых элементов

Не используйте role=»presentation» или aria-hidden=»true» на видимых фокусируемых элементах.

ARIA-атрибут role=»presentation» подразумевает, что элемент предназначен для визуального взаимодействия и не является интерактивным. Атрибут aria-hidden=»true» говорит о том, что элемент не должен быть видим. Когда мы используем эти атрибуты, нам нужно знать, к каким элементам они применяются и являются ли эти элементы видимыми и интерактивными. Например, обе эти кнопки приведут к тому, что некоторые пользователи будут фокусироваться на элементе, который для них не существует.

Эти атрибуты должны применяться только к элементам, которые не являются интерактивными или являются невидимыми.

5. Интерактивные элементы должны иметь Доступное описание

Все интерактивные элементы должны иметь Доступное описание.

Элементы, с которыми можно взаимодействовать, например кнопки и ссылки, должны иметь «доступное описание».

Доступное описание (accessible name) — имя элемента пользовательского интерфейса.
Очень просто объяснить это на пример кнопки «OK». Текст «OK» — доступное описание (accessible name). (прим. переводчика)

Доступное описание для элемента может быть указано в зависимости от типа этого элемента. Инпуты в форме, как правило, получают свое Доступное описание из соответствующих им лейблов.
(подробнее).

Другие элементы, например кнопки и ссылки, могу получить своё Доступное описание из их контента или label-атрибута (подробнее).

Источник

Атрибут aria-label не читается при навигации с использованием клавиатуры

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

с помощью ChromeVox

Также стоит отметить, что при использовании клавиш со стрелками тег span не получает фокуса. т.е. $(«span»).focus(function())

Можете ли вы уточнить, что вы подразумеваете под «навигацией с помощью клавиатуры»?

Вы используете TAB для доступа к номеру телефона, а затем программа чтения с экрана не читает вашу aria-label ? (У вас нет tabindex=»0″ на вашем поэтому я предполагаю, что вы не используете ключ TAB .)

Или вы используете клавиатуру с помощью клавиш чтения с экрана, например, клавиши вверх/вниз, которые идут по DOM (или, точнее, идут по дереву доступности, аналогичному DOM).

Если вы делаете последнее, то многие браузеры не будут вызывать aria-label элемента в дереве доступности, если этот элемент не имеет роли. элементы не имеют никакого смыслового значения, так что вы должны были бы добавить role атрибута, а также. Является ли это правильным поведением, является спорным, поскольку спецификация aria-label особо не указывает, что роль также должна быть указана.

Есть несколько рекомендаций ARIA о том, как поддерживается aria-label которая объясняет (вроде), почему aria-label может игнорироваться на .

Поэтому, если вы действительно хотите, чтобы aria-label прочитана, вам придется решить, какую роль следует предоставить . Трудно сказать только небольшим фрагментом кода, но также является номером телефона другой информации, например, именем и адресом? Если да, то другая информация (имя, адрес и т.д.) Отображается в списке или таблице или это просто текст?

Однако, как примечание, когда вы указываете aria-label с целью заставить считыватель экрана читать текст определенным образом, что обычно не рекомендуется. Услышать номер телефона, считанный как реальный номер, а не как отдельные цифры, конечно, не идеальны для пользователя с экрана, но они привыкли к нему и могут перемещаться по цифрам за раз, если они этого захотят. В какой-то момент, когда атрибут autocomplete более широко поддерживается читателями экрана, мы надеемся, что эта проблема будет решена. Тем временем, когда вы форсируете текст для устройства чтения с экрана, это может иметь пагубные последствия для пользователей Брайля. В вашем примере телефона, как пользователь Брайля, мое устройство Брайля покажет мне «девять пробелов четыре пространства девять пространство пространства пространства пять пробел пять пробел пять пространство [и т.д.]». Это много символов Брайля для космического персонажа, с которым мне приходится пробираться.

Источник

aria-labelledby не работает с NVDA / Firefox

Мне нужна помощь, чтобы программа чтения с экрана NVDA прочитала собственное описание математического выражения, которое я написал в своем index.html. Математическое выражение находится внутри предложения. Так что это выглядит примерно так:

Проблема в том, что программы чтения с экрана не читают ни верхние индексы, ни символы минус.

Чтобы исправить эту проблему, я добавил aria-labelledby для добавления пользовательского описания:

Это частично решило проблему (только Voice Over / MacOS). Но Windows / NVDA / Firefox не работает. Это просто игнорировать.

Я пытался использовать aria-label и aria-describedby , но, похоже, это не работает. Заранее спасибо.

2 ответа

Комбинация браузера / программы чтения с экрана должна игнорировать aria-label и / или aria-labelledby в . Вы можете узнать немного больше о том, какие элементы с этими атрибутами поддерживаются в каких комбинациях, здесь: ARIA поддержка пользовательским агентом

Вместо этого, ваша лучшая ставка, скорее всего, будет использовать закадровый прием. Сначала CSS, чтобы визуально скрыть вещь, но все же оставить ее на странице для программ чтения с экрана:

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

Это должно сделать это для вас.

Лучшим подходом здесь было бы написать уравнения в MathML, встроенные в ваш HTML, который может быть прочитан в последних версиях как NVDA, так и JAWS с использованием MathPlayer, и изначально VoiceOver. Учитывая ваши простые уравнения, ни у одного из них не возникнет проблем с их правильным чтением, и даже их ручное кодирование в презентации MathML будет быстрым. Я бы порекомендовал вам ознакомиться с некоторыми из множества редакторов, чтобы сделать ваш MathML как можно более полным.

Кроме того, я хотел уточнить или исправить это утверждение @aardrian:

Комбинация браузера / программы чтения с экрана должна игнорировать aria-label и / или aria-labelledby в .

Это неправда. Атрибуты aria-label и aria-labelledby действительны для любого элемента в ARIA 1.0 spec. Без тестирования, я предполагаю, что NVDA был сбит с толку при вычислении доступного имени, потому что элемент содержал текст и / или рассматриваемый код использует недопустимо. Я успешно использовал оба на .

Источник

Кнопка со значком, помеченным aria-label, по-прежнему является ошибкой «Пустая кнопка»

Кнопка с aria-label :

По-прежнему определяется как ошибка специальных возможностей («Пустая кнопка») WAVE. Любые идеи?

4 ответа

Старые программы чтения с экрана / браузеры не используют ARIA. Использование визуально скрытого текста — более надежный метод, как в ссылке CBroe, оставленной в комментарии выше.

Вы можете использовать это так

aria-label — это очень широко поддерживаемый способ добавления доступного имени к кнопке, у которой уже есть видимая метка для программ чтения с экрана. Немного более широко поддерживаемый метод — использование атрибута title вместо aria-label . Это, естественно, обеспечит совместимость с Dragon, который очень хорошо поддерживает title. ПРИМЕЧАНИЕ: это предполагает наличие видимой метки — это важно (и часто упускается из виду) для таких вещей, как поля ввода.

Если вам нужна более современная программа проверки доступности, используйте расширения ax от компании, в которой я работаю (Deque Systems). Вот расширение Chrome ax и Расширение Firefox ax

Вы можете добавить атрибут title одновременно с атрибутом aria-label .

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

Не удаляйте атрибут aria-label , потому что атрибут title не всегда читается программами чтения с экрана.

Но это может показаться немного наивным, но вы можете написать полный текст, не скрывая его.

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

Источник

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

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

В принципе, дополнительная разметка для обеспечения accessibility реализуется через отдельную технологию WAI-ARIA, однако и стандартные семантические структуры HTML5 современными браузерами и современными программами экранного доступа воспринимаются как соответствующие атрибуты ARIA для вспомогательных технологий. Проще говоря, это означает, что в теории следующие два варианта вёрстки с точки зрения программ чтения экрана аналогичны::

Листинг 1:

Поскольку в рамках всей статьи нас интересует только то, что происходит в контейнере body, то далее договоримся, что в последующих листингах будет приводиться только вёрстка из body, а всё остальное будет подразумеваться как в листинге 1.)

Итак, листинг 1 свёрстан с использованием стандартных семантических возможностей HTML5, а листинг 2 использует старую добрую блочную вёрстку через div, но с добавлением разметки WAI-ARIA. По задумке разработчиков стандартов доступности, браузеров и вспомогательных технологий предполагается, что эти две страницы должны обрабатываться программами экранного доступа одинаково, однако тут мы и сталкиваемся с прозой жизни.

Возьмём две наиболее популярные программы экранного доступа: JAWS (версии 15.0) и NVDA (версии 2014.3), а также два наиболее популярных у их пользователей браузера: Internet Explorer (версии 11) и Firefox (версии 32). После этого протестируем все возможные конфигурации на предмет обработки семантических областей из листинга 1. В итоге, получим следующие результаты:

Поддержка семантических тегов HTML5

Теги	JAWS Internet Explorer	JAWS Firefox	NVDA Internet Explorer	NVDA Firefox
aside	Да	Да	Нет	Да
footer	Нет	Да	Нет	Да
header	Нет	Да	Нет	Да
main	Да	Да	Нет	Да
nav	Да	Да	Нет	Да

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

Разумеется, поскольку финальный вариант WAI-ARIA принят совсем недавно, а руководство по его поддержки со стороны User Agent вообще до сих пор не существует в завершённом виде, то в будущем, когда всё утрясётся, можно надеется, что и такие вещи также унифицируются. Однако проекты разрабатываются и сдаются уже здесь и сейчас, да и graceful degradation тоже никто ещё не отменял. Поэтому имеет смысл верстать так, чтобы с одной стороны использовать семантические новинки HTML5, а с другой — не обижать вспомогательные технологии при любых раскладах.

Достигнуть этого можно путём одновременного использования и семантики HTML5, и разметки WAI-ARIA. То есть к этим тегам надо будет добавлять соответствующие роли WAI-ARIA, как бы подстраховывая семантические области HTML5 через Accessible Rich Internet Applications.

Здесь следует сразу предупредить, что атрибуты разметки WAI-ARIA имеют более высокий приоритет, чем стандартные семантические структуры HTML5, поэтому если, например, для тега main прописать атрибут role со значением contentinfo, то программы экранного доступа будут называть его так, как будто это footer. Так что отсутствие WAI-ARIA лучше, чем наличие её некорректного применения. Иными словами: «Не умеешь, не берись», но эта статья как раз и призвана научить этому не сложному приёму вёрстки.

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

Соответствие базовых семантических тегов HTML5 и значений атрибута role из WAI-ARIA

Тег HTML5	Роль WAI-ARIA
footer	contentinfo
header	banner
main	main
nav	navigation

Кстати, что касается роли banner, специально оговоримся, что она предназначена для оборачивания именно всей шапки страницы, а не рекламного баннера. То есть она, действительно, прямой аналог тега header. Как показывает практика, некоторых слово «banner» вводит в заблуждение, и они начинают это значение присваивать именно рекламным баннерам, но это неправильно.

Вышеприведённые соответствия позволят корректно разметить в WAI-ARIA базовые семантические области HTML5. Однако заметно, что там упомянуты далеко не все из них. Дело в том, что во-первых, некоторые семантические структуры HTML5 не имеют прямых аналогов WAI-ARIA, например, это касается тега article, а во-вторых, с некоторыми из них всё не так просто, главным образом, речь, конечно, об aside.

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

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

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

Использование таких приёмов вёрстки требует уже несколько большего понимания логики невизуальных интерфейсов, поэтому рубить с плеча тут не стоит. Можно только посоветовать всё-таки использовать роль complementary, а более сложные интерфейсные ходы применять только если вы в достаточной степени уверены, что это уместно. Если бы в листинге 3 вместо note была использована complementary, то это было бы лучше, чем наоборот.

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

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

То есть атрибут aria-label позволяет задать дополнительную текстовую метку, которая будет пояснять назначение данного блока. Причём важно понимать, что aria-label именно дополняет role, поэтому не надо в её тексте дублировать информацию о семантическом назначении блока, например, совсем не нужно для nav писать, что это «Область навигации по разделам», достаточно просто написать «Разделы». Ну а для тега main вообще нет необходимости прописывать aria-label, так как он в принципе должен быть на странице лишь в единственном экземпляре и его назначение итак понятно. А вот для aside, footer, header или nav поясняющую метку следует добавлять по обстоятельствам. Как правило, это имеет смысл, если на странице несколько таких элементов одного типа, что с теми же footer или header бывает не так часто.

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

Напоследок две ссылки, по которым можно более подробно ознакомиться с семантическими возможностями HTML5 и WAI-ARIA:

Источник