Не заменяйте визуальные метки атрибутом ‘aria-label’

Перевод подготовила Ольга Кудрявцева.

Атрибут aria-label (прим. 1) может быть чрезвычайно полезным при правильном использовании. При неверном употреблении он приводит к путанице в случае, если пользователь использует речевой ввод. Эту ошибку достаточно легко сделать – к счастью, ее также легко и исправить!

Атрибут aria-label – что это?

В соответствии со стандартом WAI ARIA 1.2 (прим. 2), атрибут aria-label«определяет строковое значение, которое создает метку текущего элемента». У него такая же цель, как и у атрибута aria-labelledby, который делает отсылку к другому элементу, создающему метку текущего элемента. Цель обоих атрибутов – обеспечить текущему элементу название, доступное с помощью ассистивных технологий.

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

Доступное имя – это часть того, что используют программы экранного доступа для описания элементов пользователю, когда эти элементы активны. Кнопка, у которой нет атрибута aria-label, а между открывающим и закрывающим тегами расположен обычный текст, получит доступное имя, совпадающее с этим текстом. Точно такая же кнопка может получить совершенно другое доступное имя, измененное с помощью атрибута aria-label.

Пример 1: кнопка без атрибута aria-label

Код:

<button>OK</button> Вывод: OK

Что скажет скринридер на примере NVDA: «ОК, кнопка».

Пример 2: кнопка с атрибутом aria-label

Код:

<button aria-label="Подтвердить выбор">OK</button>
 Вывод: OK

Что скажет NVDA: «Подтвердить выбор, кнопка».

Почему атрибут aria-label должен совпадать с визуальной меткой?

Во-первых, атрибут aria-label должен совпадать с визуальной меткой элемента, потому что в Руководстве по обеспечению доступности веб-контента (WCAG) есть критерий успеха 2.5.3 «Метки в названии» (уровень А), который говорит:

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

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

Если вы похожи на меня, возможно, вам понадобится чуть больше пояснений для следования правилам, чем простое объяснение: так указано в стандартах. Многим людям не нравится, когда им говорят, что делать, и это прекрасно!

Итак, почему необходимо следовать критерию 2.5.3? Частично это связано с технологией распознавания речи. Оказывается, Доступное имя для элементов используется пользователями, употребляющими речевой ввод, для взаимодействия с элементами на веб-странице.

Давайте вернемся к двум нашим предыдущим примерам:

• Пользователь, использующий речевой ввод, может активировать кнопку из Примера 1, сказав «Нажми ОК». Потому что Доступное имя для этой кнопки – «ОК».
• Пользователь не сможет активировать кнопку из Примера 2 таким же образом. Потому что Доступное имя для этой кнопки – «Подтвердите выбор». То есть если пользователь, использующий речевой ввод, хочет активировать эту кнопку, он должен сказать «Нажми Подтвердите выбор».

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

Что случается, когда атрибут aria-label не совпадает с визуальной меткой?

Параллельно с написанием данной статьи я начала изучать особенности использования Голосового контроля на Мак. Я хотела узнать, смогу ли я найти реальный пример нарушения навигации с помощью речевого ввода из-за несовпадения визуальных меток и Доступных имен. И пару примеров я нашла прямо на домашней странице Twitter.

К сожалению, более половины основных навигационных ссылок имеют Доступные имена, которые не совпадают с визуальными метками. Даже в тех случаях, когда атрибут aria-label ссылки начинался с текста визуальной метки, мне не удалось активировать данные ссылки с помощью технологии голосового ввода. Я совершила бесчисленное количество попыток.

• Домашняя страница: Атрибут aria-label для этой ссылки – динамический. Если в пользовательской ленте есть непрочитанные твиты, тогда атрибут aria-label нужно читать как «Домашняя страница (Новые непрочитанные твиты)». Команда «Нажми на Домашнюю страницу» активирует данную ссылку только, если у пользователя нет непрочитанных твитов.
• Изучить: Атрибут aria-label для этой ссылки – «Найти и изучить». Голосовая команда «Нажми Изучить» не приведет к активации данной ссылки.
• Уведомления: Атрибут aria-label для этой ссылки – динамический. Если у пользователя есть, например, 2 уведомления, тогда атрибут aria-label нужно читать как «Уведомления (Два непрочитанных уведомления)». Команда «Нажми на уведомления» активирует данную ссылку только, если у пользователя нет непрочитанных уведомлений.
• Сообщения: Атрибут aria-label для этой ссылки – динамический. Если, к примеру, у пользователя есть непрочитанные сообщения от другого пользователя, атрибут aria-label нужно читать как «Сообщения в директ (Один непрочитанный диалог)». Если непрочитанных сообщений нет, атрибут aria-label – «Сообщения в директ». Команда «Нажми на сообщения» никогда не срабатывает.

Вот короткая демонстрация того, как я пытаюсь активировать ссылку «Сообщения» на главной странице Twitter:

Есть ли другие пользователи, которым важно совпадение атрибута aria-label и визуальной метки?

Данная статья в основном описывает опыт зрячих пользователей, использующих речевой ввод, но есть и другие группы пользователей, для которых описываемые вопросы крайне важны. Представьте себе зрячего пользователя программы экранного доступа, который доходит до кнопки из Примера 2. Скрин ридер произнесет «Подтвердите выбор, кнопка», а на самой кнопке будет написано ОК.

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

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

Как можно исправить несовпадение атрибутов aria-label и визуальных меток?

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

— Есть ли повторяющиеся визуальные метки?

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

— Является ли контент элемента обычным текстом? В этом случае не указывайте атрибут aria-label. Сгенерированное доступное имя для элемента будет состоять из этого текста.

—  Является ли элемент кнопкой переключения? В соответствии с рекомендациями по обеспечению доступности в данном случае лучше использовать атрибут ‘aria-pressed’, а не динамический aria-label.

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

Примечания переводчика:

1. ↑ Атрибут aria-label создает текстовую метку текущего элемента в случае отсутствия видимого текста описания элемента.
2. ↑ WAI ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications (Инициатива по веб-доступности – Доступные интернет-приложения)) – техническая спецификация, которая определяет особенности применения aria-разметки.

Оригинал статьи: Don’t Overwrite Visual Labels With `aria-label`

Об авторе:

Эшли М. Бойер (Ashlee M Boye) — программист с disability (ограниченными возможностями здоровья) и специалист по веб-доступности, которая в основном работает с фронтендом и React. В своем блоге она пишет о доступности и других темах веб-разработки. Ее цель в обучении доступности — показать другим разработчикам, что это не так сложно, как кажется, и просто требует времени и практики, как и любая структура, технология или алгоритм, изученные разработчиками.