Использование атрибута aria-labelledby
Описание
Атрибут aria-labelledby содержит идентификаторы (атрибут id) меток для таких объектов как элементы ввода (input), виджеты, группы. Атрибут создаёт связь между объектами и их метками. Вспомогательные технологии, такие как средства чтения экрана, используют этот атрибут чтобы собирать все метки в каталог документа, из которого пользователь может перемещаться между ними. Без идентификатора (атрибута id) вспомогательные технологии не могут собрать данные объекты в каталог.
aria-labelledby очень похож на aria-describedby: Метка (label) предоставляет основную информацию об объекте, в то время как описание (description) даёт более полную/детальную информацию которая может понадобится пользователю.
Чтобы повысить совместимость с клиентскими приложениями которые не поддерживают ARIA атрибуты, вы можете использовать aria-labelledby вместе элементом (используя for атрибут)
Этот атрибут может быть использован в любом типичном HTML-элементе формы, он не ограничен элементами которые имеют атрибут ARIA role
Значение
Список идентификаторов (id) разделённых пробелом
Возможные эффекты в клиентских приложениях и вспомогательных технологиях
Примеры
Example 1: Multiple Labels
In the example below, each input field is labelled by both its own individual label and by the label for the group:
Example 2: Associating Headings With Regions
In the example below, header elements are associated with the content they head. Note that the region being referenced is the region that contains the header.
Example 3: Radio Groups
In the example below, the container of a radiogroup is associated with its label using the aria-labelledby attribute:
Example 4: Dialog Label
In the example below, the header element that labels the dialog is referred to by the aria-labelledby attribute:
Example 5: Inline Definition
In the example below, the definition of a term that is described in the natural flow of the narrative is associated with the term itself using the aria-labelledby attribute:
Example 6: Definition Lists
In the example below, the definitions in a formal definition list are associated with the terms they define using the aria-labelledby attribute:
Example 7: Menus
In the example below, a popup menu is associated with its label using the aria-labelledby attribute:
Notes
The most common accessibility API mapping for a label is the accessible name property
Used by ARIA roles
All elements of the base markup
Related ARIA techniques
Compatibility
TBD: Add support information for common UA and AT product combinations
Доступный дизайн компонентов на примерах. Дизайнеру про ARIA-атрибуты, порядок фокуса и другое
Для кого эта статья
Эта информация пригодится вам, если вы создаёте дизайн новых компонентов или тестируете интерфейсы, трудитесь в связке с фронтенд-разработчиком или сами им являетесь, но мало знаете про доступность.
Я расскажу об основных руководствах по доступности и о ключевых моментах, на которые стоит обратить внимание, а именно: о порядке фокуса, о клавиатурном взаимодействии и об ARIA-атрибутах. Я также покажу, как документация помогает нам при разработке доступных (т. е. отвечающих требованиям доступности) компонентов.
Примечание: Под доступностью (accessibility) я подразумеваю соответствие требованиям доступности для пользователей с ограниченными возможностями. Подробнее о том, что это значит, можно прочитать в статье про доступность. Также напомню, что хороший дизайн — это не только про «красивое», но и про «удобное», а accessibility — это часть usability.
Учитываем доступность при разработке компонента
Предположим, вам потребовалось разработать дизайн всплывающей подсказки (тултипа), которая появляется при наведении курсора на информационную иконку. Каждому из наших пользователей, вне зависимости от имеющихся у него ограничений, мы должны обеспечить равный доступ к информации во всплывающей подсказке. Тут можно порекомендовать следующий подход.
Представьте, что ваш пользователь применяет:
только мышь или другое аналогичное устройство ввода с указателем;
экранный увеличитель (лупу);
программу чтения с экрана (скринридер).
Примечание: в некоторых странах соответствие требованиям WCAG закреплено на законодательном уровне. Но если вы будете разрабатывать сайт или приложения для США, то вам придётся изучить Section 508. Эти два стандарта очень похожи, но некоторые отличия всё-таки есть; о них можно почитать здесь.
Мышь. Человек, использующий мышь, может навести курсор на иконку и увидеть подсказку, т.е. здесь проблем не возникает. Не забываем, что размер самой иконки для пользователей мыши должен быть не меньше 24х24 пикселей, а для пользователей сенсорных экранов — 44–48 пикселей.
Клавиатура. У человека, использующего для взаимодействия с сайтом исключительно клавиатуру, уже могут возникнуть сложности — очевидно, что мы не в состоянии навести курсор без мыши. Для такого пользователя мы предусматриваем возможность активировать подсказку с клавиатуры, а именно перейти к иконке клавишей Tab, а когда фокус окажется на ней — показать подсказку. Для этого нужно включить нашу иконку в порядок фокуса. Также нам нужна возможность закрыть подсказку клавишей Esc.
Экранный увеличитель. Для пользователей экранной лупы особенно важны принципы, изложенные в п. 1.4.13 WCAG — ‘Content on Hover or Focus’. Контент, появляющийся при наведении на элемент курсора или при фокусировке элемента, должен соответствовать следующим критериям:
Dismissible (отклоняемость) — контент можно отклонить без перемещения фокуса или курсора. Например, можно предоставить пользователю возможность закрыть подсказку клавишей Esc.
Hoverable (наводимость курсором) — курсор можно перевести с кнопки на появляющийся контент (в нашем случае подсказку), и при этом контент не исчезает. При большом увеличении экрана высока вероятность того, что в определённый момент времени пользователь видит только часть контента — например, кнопку-триггер и начало появившейся подсказки. Чтобы просмотреть всю подсказку, пользователь должен иметь возможность отвести курсор от кнопки и перевести его на всплывшее окно, и при этом подсказка не должна закрываться.
Persistent (постоянство) — появляющийся дополнительный контент остаётся видимым, пока фокус или курсор не убрали с кнопки или дополнительного контента либо пока пользователь не отклонит контент клавишей Esc.
Нарушение критерия ‘hoverable’: в этом примере курсор нельзя перевести с триггера на появившийся контент. 
При большом увеличении экрана часть подсказки может скрываться. Критерий ‘hoverable’ требует предоставить пользователю возможность просмотреть всю подсказку полностью при переводе на неё курсора.
Скринридер. Что насчёт людей, использующих программы чтения с экрана? Наша иконка уже включена в порядок следования фокуса, а значит, невидящий пользователь сможет перейти к ней, используя клавиатуру. При этом нам нужно, чтобы текст подсказки зачитался вслух, и здесь на помощь приходят ARIA-атрибуты (о том, что это такое, — чуть ниже), в данном случае — aria-describedby. При добавлении этого лейбла к HTML-атрибутам иконки содержимое подсказки станет «видимым» — точнее, слышимым — для пользователя программы чтения с экрана. Когда элемент окажется в фокусе, он зачитается примерно следующим образом: «Информационная иконка», «Текст подсказки».
Таким образом, каждый из наших пользователей гарантированно увидит или услышит текст всплывающей подсказки, а значит, наша задача успешно решена.
ARIA-атрибуты
Дело в том, что скринридеры и другие вспомогательные технологии по умолчанию «умеют» взаимодействовать лишь со стандартными элементами HTML — кнопками, полями ввода, заголовками и т.д. А значит, некоторые продвинутые функции и кастомные компоненты вашего сайта могут стать попросту недоступны тем, кто не использует мышь или применяет программу чтения с экрана. В этом случае ARIA-атрибуты незаменимы. Дизайнеру не обязательно знать их все, но понимать, как они работают, — полезно. Рассмотрим несколько примеров.
Aria-label — помогает присвоить компоненту заголовок, который видим исключительно программам чтения с экрана.
Например, вы разместили в интерфейсе кнопку редактирования с иконкой карандаша. Она симпатичная и не занимает много места, а изображение карандаша обычно ассоциируется с действием редактирования. Видящий пользователь быстро считает смысл.
Для пользователя скринридера в этом случае будет полезно добавить пояснительный лейбл, который будет скрыт от глаз, но не от программ чтения с экрана. Применим свойство aria-label=»Редактировать», и при перемещении фокуса на кнопку она зачитается как «Кнопка “Редактировать”».
Атрибут можно использовать в случае, когда вы не хотите перегружать интерфейс визуально, но вам нужно обеспечить ясность восприятия пользователям с ограниченными возможностями.
Aria-labelledby — позволяет сделать отсылку к другому видимому названию или заголовку, например если у вас есть группа радиокнопок с общей подписью.
Aria-describedby — предоставляет дополнительную информацию к имеющемуся видимому заголовку, например если у вас есть поле ввода с названием ‘Password’ и текстовым пояснением требований к длине и составу пароля.
Пример использования свойства aria-describedby из бесплатного курса Web Accessibility от Google (https://classroom.udacity.com/courses/ud891), урок 5 (для просмотра нужна регистрация на сайте Udacity; вводить данные банковской карты при этом не нужно).
Aria-disabled — позволяет включить неактивный (disabled) компонент в порядок следования фокуса (focus order). В норме, при переходе по клавише Tab неактивный компонент будет пропущен, а значит, для пользователя скринридера этот компонент как бы не будет существовать. В целом это правильно, но в некоторых случаях нам нужно, чтобы пользователь с ограниченными возможностями тоже «видел» элемент.
Представим, что у нас есть форма обратной связи и кнопка «Отправить». Кнопка по умолчанию неактивна, но при заполнении полей ввода она становится доступной — довольно распространённый и привычный паттерн. Мы видим, что кнопка, пусть и полупрозрачная, там есть, и мы видим, как в ответ на заполнение полей она активируется. Пользователю скринридера в этом случае также необходимо знать, что кнопка в форме есть, но она неактивна. Это поможет сопоставить состояние кнопки с необходимостью заполнить поля для её активации.
Со всеми ARIA-атрибутами можно ознакомиться на W3.org.
Порядок следования фокуса
Для того чтобы упростить работу людей, пользующихся только клавиатурой, необходимо знать базовые требования к поведению фокуса.
Фокус может находиться только на интерактивных элементах, т.е. кнопках, ссылках, чекбоксах и т.д. Для навигации по тексту, заголовкам и таблицам в программах чтения с экрана есть другие инструменты.
Порядок следования фокуса должен соответствовать визуальному или логическому порядку расположения интерактивных элементов на экране.
Неактивные элементы управления не фокусируются.
Клавиша Tab переносит фокус к следующему компоненту, Shift+Tab — к предыдущему. Внутри компонентов движение фокуса осуществляется чаще всего клавишами стрелок (об этом — в следующем разделе).
На примере ниже правила следования фокуса нарушены, неинтерактивный элемент — текст соглашения, принимаемого нажатием на чекбокс, — фокусируется. Для того чтобы пользователь мог прочитать текст, соотносящийся с чекбоксом ‘I accept these terms’, можно применить уже упоминавшееся свойство aria-describedby.
Текст соглашения не должен включаться в порядок фокуса, вместо этого следует использовать свойство aria-describedby.
Примечание: этот принцип может упростить жизнь даже тем пользователям, у которых нет никаких ограничений — ни постоянных, ни временных. Некоторым людям просто удобнее работать с формой с клавиатуры.
Клавиатурное взаимодействие
Когда пользователь взаимодействует с интерфейсом, он ожидает, что объекты будут реагировать определённым образом на определённые клавиатурные нажатия. Мы привыкли, что галочку можно поставить/снять пробелом, выпадающий список открывается по Alt+стрелка вниз и т.д. Если же элемент управления не взаимодействует с клавиатурой так, как мы ожидаем, то нам легко это увидеть и решить задачу при помощи мыши или тачскрина. Проблемы начинаются, если пользователь не может увидеть элемент интерфейса или нажать на него.
Здесь нам приходит на помощь ещё одно руководство от W3C — WAI-ARIA Authoring Practices. Его цель — показать, как использовать WAI-ARIA при разработке доступных компонентов. В разделе ‘Design Patterns and Widgets’ для каждого компонента описано клавиатурное взаимодействие, а также роли и ARIA-атрибуты, которые полезно использовать при его создании.
Например, для группы радиокнопок будут действовать следующие правила:
Клавиша Tab или Tab+Shift переносит фокус на группу радиокнопок.
Пробел выбирает радиокнопку, если она ещё не выбрана.
Клавиши стрелок вправо и вниз передвигают фокус от одной радиокнопки к другой внутри группы, снимая выбор с предыдущей и выбирая текущую кнопку. И так далее.
Рекомендую сверяться с этим руководством как можно чаще, а также добавлять полезные страницы в закладки.
Использование документации
Напоследок рассмотрим использование документации по доступности на примере разработки модального диалога. Представим, что на экране появляется окно с текстом ошибки. Видящий пользователь заметит его мгновенно, но как оповестить невидящего о том, что на экране что-то изменилось?
Как упоминалось выше, в стандарте WAI-ARIA и руководстве WAI-ARIA прописаны правила поведения всех основных компонентов. В нашем случае нужно использовать роль alertdialog — Alert and Message Dialogs, он же диалог ошибки или окно сообщения.
Здесь пора рассказать об одном из ключевых понятий WAI-ARIA — о ролях.
Роль (обозначается aria-атрибутом role) — это определённый паттерн взаимодействия пользователя с интерфейсом. В стандарте прописан исчерпывающий список ролей, которые мы можем присвоить нашим элементам управления. С их помощью можно обозначить, например, что наш div будет вести себя как чекбокс, и тогда скринридер не только зачитает текст из этого блока, но и сообщит, проставлена ли там галочка, а также проиграет соответствующий звук. Этот звук для невидящего пользователя будет таким же сигналом, как для видящего — квадратик и галочка. Пользователь поймёт, что с элементом можно взаимодействовать — поставить или убрать галочку, нажав на пробел.
При этом важно понимать: когда мы назначаем элементу управления ту или иную роль, мы как бы берём на себя обязательство, что снабдим этот элемент по крайней мере минимально необходимым набором ARIA-атрибутов, которые нужны скринридерам для его правильного озвучивания. Например, для чекбокса нужно указать не только его имя, но и состояние (checked / unchecked). ‘No ARIA is better, than bad ARIA’.
Вернёмся к нашему диалогу. Роль alertdialog позволяет вспомогательным технологиям и браузеру распознать диалог предупреждения или сообщения об ошибке и озвучить его появление специальным образом, например проиграв системный звук предупреждения.
Из пояснения к роли alertdialog в разделе ‘WAI-ARIA Roles, States, and Properties’ мы узнаём, что для элемента с ролью alertdialog мы должны указать значение одного из атрибутов (подробнее о них уже написано выше):
aria-labelledby — указывает на видимый элемент, содержащий заголовок диалога, либо
aria-label — если видимого заголовка нет, и нам нужно указать его только для скринридера.
Кроме того, необходимо указать значение атрибута aria-describedby, если в диалоге есть описательный текст. Как говорилось выше, атрибут aria-labelledby указывает, что элемент поименован неким заголовком. У нас это окно, которое ссылается к собственному названию и при открытии озвучивается примерно следующим образом: «Диалог», «Заголовок диалога» (например, «Подтвердите удаление»), «Текст в диалоге» (например, «Удалённый элемент нельзя будет восстановить»). При этом невидящий пользователь получит чёткое представление о том, какое именно окно появилось на экране.
Далее, WAI-ARIA сообщает нам, что alertdialog является подклассом модального диалога (роль dialog), а значит, мы должны выполнить те требования, которые указаны и для этой роли. Читаем руководство к модальному диалогу:
Фокус переходит на первый активный элемент в диалоге.
После закрытия диалога фокус переходит на предыдущий элемент (кроме случаев, когда логика процесса требует поместить его на элемент, следующий за предыдущим).
Контент под диалогом затемнён и неактивен.
Если эти требования не выполнить, пользователь не сможет взаимодействовать с содержимым диалога.
При появлении окна его заголовок зачитается благодаря атрибуту aria-labelledby, а фокус переместится на первый интерактивный элемент — текстовое поле. При переходе фокуса на поле ‘Special instructions’ дополнительное описание зачитается благодаря свойству aria-describedby.
Таким образом, нам ничего не нужно придумывать самим — все важные моменты уже прописаны в документации.
Примечание: WAI-ARIA не только инструктирует нас по отдельной роли, но и помогает в её выборе. В частности, нам поясняют, что следует отличать роль alertdialog от роли alert — динамического контента (live region), который содержит важную и/или срочную информацию, которую нужно донести до пользователя, не перенося на неё фокус. Динамический контент (live regions) определяется в WAI-ARIA как область веб-страницы, которая меняется в результате внешних событий, в то время как фокус пользователя находится где-то в другой области той же страницы. Примеры таких областей — окно чата, виджет с курсами валют или таймер. Раньше такие области были «невидимы» для ассистивных технологий, теперь же стандарт позволяет обрабатывать их при помощи атрибутов aria-live, aria-relevant, aria-atomic и aria-busy.
Тестирование
После базового знакомства с ARIA-атрибутами, правилами поведения фокуса и правилами клавиатурного взаимодействия вы можете попробовать протестировать интерфейс самостоятельно.
Убедитесь в том, что интерактивные элементы фокусируются, фокус визуально различим и его порядок соответствует расположению элементов на экране.
Проверьте клавиатурное взаимодействие с каждым из интерактивных элементов. Выпадающие списки должны появляться по нажатию Alt+стрелка вниз, элементы списка и радиокнопки — выбираться по клавишам стрелок, кнопки — нажиматься по Enter, чекбоксы — менять своё состояние при нажатии пробела, тултипы — исчезать при нажатии Esc и т.п.
Установите бесплатное расширение для Chrome — Screen Reader от Google. С его помощью можно проверить, корректно ли озвучиваются элементы интерфейса.
Заключение
Как эти знания помогают мне в повседневной работе? Проведение самостоятельного исследования требований доступности и размещение чётких правил поведения компонента экономит время разработчиков, занимающихся интерфейсной частью продукта.
Требования можно заносить в отдельный документ, но мне удобнее делать пометки непосредственно в файле Figma, размещая список параметров соответствия рядом с дизайном компонента.
Напоследок хочу ещё раз напомнить, что доступный дизайн улучшит юзабилити не только для людей с постоянными нарушениями здоровья, но и для обычных пользователей. Все пользователи выиграют, если:
все интерактивные элементы доступны с клавиатуры,
всё внятно и логично подписано.
Для этого мы прежде всего используем обычный HTML/CSS, общие стандарты UX и здравый смысл. А в помощь нам созданы
стандарт WCAG, описывающий принципы доступности,
стандарт WAI-ARIA, благодаря которому нам не нужно выбирать между доступностью сайта или приложения для скринридеров и созданием сложных, динамических дизайнов — мы можем реализовать и то, и другое одновременно,
руководство WAI-ARIA Authoring Practices, подробно описывающий, как сделать доступным тот или иной элемент управления.
Примечание: если вам стало интересно, то есть также бесплатный курс от Google на Udacity (на английском языке) — там можно чуть больше погрузиться в тему.
Что такое ARIA?
Перевод статьи: Ben Myers — What Is ARIA?
Введение
Не секрет, что сегодняшние сайты становятся все более сложными. Веб-страницы теперь больше напоминают динамические, живые приложения. Разработчики комбинируют и оформляют элементы HTML для создания новых пользовательских интерфейсов. Однако пользователям с ограниченными возможностями может быть непросто разобраться в этом новом мире.
Одним из инструментов, разработанных для решения этой проблемы, является ARIA. Сокращенно от Accessible Rich Internet Applications (Доступные многофункциональные интернет-приложений), ARIA — это подмножество атрибутов HTML (обычно с префиксом aria-), которые изменяют то, как вспомогательные программы, такие как программы чтения с экрана, распознают ваши страницы.
К сожалению, разработчики часто неправильно понимают ARIA и применяют ее неправильно, что ведет к ухудшению работы пользователей с ограниченными возможностями. В 2017 году ресурс веб-доступности WebAIM сообщил:
Когда WebAIM оценивает веб-сайты клиентов на предмет доступности, мы часто тратим больше времени на оценку и составление отчетов об использовании ARIA, чем на любую другую проблему. Почти каждый отчет, который мы создаем, содержит раздел, предупреждающий о злоупотреблении ARIA и описывающий использование ARIA, которые необходимо исправить или, чаще всего, удалить.
Самый сильный индикатор того, что страница будет иметь множество ошибок доступности, — это наличие ARIA. Страницы с ARIA имеют на 65% больше проблем, чем без него. И это становится все хуже. Это ОЧЕНЬ тревожно!
Отчет WebAIM показывает нам, что более сложные страницы и использование библиотек и структур могут привести как к большему количеству ситуаций, требующих ARIA, так и к большему количеству ошибок. Таким образом, кажется, что у разработчиков нет понимания того, что такое ARIA и как ее следует использовать.
Это может быть связано с тем, что существует множество атрибутов ARIA, каждый из которых имеет свои (правда, иногда нишевые) варианты использования. Это так же делать ARIA сложным для понимания.
Кроме того, ARIA не всегда полноценно описывается в документацию по веб-разработке. Кажется что его часто используют для того чтобы сделать элемент «более доступным». Мой друг признался, что скопировал ARIA из примера кода, потому что пример из документации включал его. Но не понимая что именно делает ARIA, разработчики вполне разумно могут предположить, что больше ARIA означает лучшую доступность.
В этой статье я хочу рассказать что такое ARIA, что она делает, почему вы должны ее использовать ее, и когда ее не нужно использовать.
Пересмотр дерева доступности
В моем последнем посте я представил дерево доступности: альтернативный DOM, который браузеры создают специально для вспомогательных программ. Эти деревья доступности описывают страницу в терминах доступных объектов: структуры данных, предоставляемые операционной системой, которые представляют различные виды элементов пользовательского интерфейса и элементы управления, такие как текстовые узлы, checkbox или кнопки.
Доступные объекты описывают элементы пользовательского интерфейса как наборы свойств. Например, свойства, которые могут описывать checkbox, включают:
Мы можем разбить эти атрибуты на четыре типа:
Эти качества охватывают все, что пользователь может захотеть узнать о функции элемента, в то же время пропуская все что связано с внешним видом элемента.
Хорошая разметка означает хорошие деревья
Тем не менее, возможности семантики не без граничны. Иногда нам нужны новые, более сложные операции, которые семантические элементы просто еще не поддерживают, такие как:
Что делать в этих случаях? По-прежнему важно спроектировать весь функционал так, чтобы вспомогательные программы могли все это понять. Во-первых, мы должны реализовать как можно больше с помощью семантической разметки. Затем мы используем атрибуты ARIA, чтобы настроить/подкорректировать дерево доступности.
ARIA не изменяет DOM и не добавляет новую функциональность к элементам. Она никак не изменит поведение элементов. ARIA исключительно управляет представлением элементов в дереве доступности. Другими словами, ARIA используется для изменения роли, имени, состояния и свойств элемента для вспомогательных технологий.
Это прекрасно в теории, но как это работает на практике?
Рассмотрим переключатель
Давай те рассмотрим как работает Aria на примере переключателя (switch):
Если вы нажмете на переключатель, вы активируете темный режим. Нажмите на него еще раз, и вы вернетесь в светлый режим. Переключение должно работать даже с клавиатуры — вы можете перейти к нему и вызвать его, нажав пробел.
Но у этого переключателя есть небольшая проблема. Если вы перейдете к нему с помощью программы чтения с экрана, вы услышите что-то вроде этого:
VoiceOver, просто прочитает «group»
Пользователи программы чтения с экрана не будут знать, что это за элемент, для чего он нужен, и даже то, что он кликабелен. Пользователи других вспомогательных технологий будут также разочарованы. Это то, что в бизнесе называется «проблемой». К счастью, мы можем попытаться исправить это с помощью ARIA. Мы рассмотрим, как ARIA изменяет имена, роли, состояния и свойства, добавляя атрибуты ARIA к этому переключателю.
Если вы хотите использовать код локально, чтобы следовать по нему, вы можете клонировать его из GitHub. Если у вас нет программы для чтения с экрана, выполните следующие действия, чтобы просмотреть дерево доступности вашего браузера.
Прежде всего, как мы можем убедиться, что вспомогательные технологии могут понять, что наш элемент — это переключатель, а не проста группа элементов?
Браузер на самом деле не знает, что делать с нашим переключателем или как лучше всего использовать его для вспомогательных программ. Поскольку наш переключатель — это просто с другим внутри него, лучшим предположением браузера является то, что это общая группа элементов. К сожалению, это не помогает пользователям вспомогательных программ понять, что это за элемент или как им следует взаимодействовать с ним.
Мы можем помочь браузеру, предоставив нашему переключателю атрибут role. role может принимать множество возможных значений, таких как button, link, slider или table. Некоторые из этих значений имеют соответствующие семантические элементы HTML, но некоторые нет.
Мы хотим выбрать роль, которая лучше всего описывает наш элемент как переключатель. В нашем случае есть две роли, которые описывают элементы, которые чередуются между двумя противоположными состояниями: checkbox и switch. Эти роли функционально очень похожи, за исключением того, что состояния checkbox checked и unchecked, а switch использует on и off. Роль switch также имеет более слабую поддержку, чем checkbox. Мы будем использовать switch, но вы можете использовать checkbox самостоятельно.
Теперь, когда мы перейдем к нашему переключателю с помощью программы чтения с экрана, мы получим более точное описание этого элемента:
VoiceOver прочитает «off, switch»
Когда я немного задержался на этом элементе с активным VoiceOver, VoiceOver сказал мне, как я могу взаимодействовать с элементом с помощью клавиши пробела:
Вспомогательные технологии теперь могут использовать эти роли для предоставления дополнительных функций, облегчающих навигацию по странице для пользователей с ограниченными возможностями. Например, когда пользователь вводит голосовую команду «click button», программа распознавания речи Dragon NaturallySpeaking подсвечивает все кнопки на странице. Программы чтения с экрана часто предоставляют ярлыки для навигации между различными элементами одной и той же роли — JAWS предоставляет горячие клавиши, а VoiceOver предоставляет Rotor для этой цели.
Важно отметить, что роль — это обещание. Вы обещаете пользователям, что они могут взаимодействовать с элементами определенным образом и будут вести себя предсказуемо. Например, пользователи ожидают от переключателей switches следующее:
Указание role для элемента не приведет к автоматическому добавлению каких-либо ожидаемых функций. Это не сделает наш элемент фокусируемым или добавит ключевые события. Разработчик должен выполнить это обещание. В случае с нашим переключателем я уже обработал это с помощью tabindex и добавил прослушиватель событий keydown.
Хорошо, что пользователи и вспомогательные технологии знают, что наш элемент — это switch. Теперь, однако, они могли бы спросить себя для чего этот переключатель?
Иногда доступное имя по умолчанию недостаточно. В некоторых случаях, оправданна ручная установка доступного имени. Например когда:
ARIA предлагает два атрибута для изменения имени элемента: aria-label и aria-labelledby.
Когда вы указываете aria-label для элемента, вы переопределяете любое имя, которое имело этот элемент, и заменяете его содержимым этого атрибута aria-label. Возьмите кнопку со значком увеличительного стекла. Мы могли бы использовать aria-label, чтобы программы чтения с экрана перезаписывали содержимое кнопки и объявляли ее как «Search»:
Давайте добавим aria-label к нашему переключателю:
Если вы перейдете к переключателю с помощью программы чтения с экрана, вы услышите что-то вроде этого:
VoiceOver прочитает переключатель как «Use dark mode, off, switch«
aria-label лучше всего использовать, когда на странице еще нет видимой текстовой метки. В качестве альтернативы, если у нас уже есть ярлык на странице, мы могли бы использовать aria-labelledby. aria-labelledby берет идентификатор текстовой метки и использует содержимое этой метки в качестве доступного имени.
Например, мы могли бы использовать aria-labelledby, чтобы использовать заголовок в качестве метки для раздела оглавления.
использует идентификатор id, чтобы указать, какой элемент должен служить его меткой. В результате весь раздел оглавления называется Table of Contents (Оглавление).
Этот подход очень похож на использование элемента для атрибута, за исключением того, что он работает для всех элементов, а не только для полей формы.
Вот как будет выглядеть наш пример переключателя, если мы используем aria-labelledby вместо aria-label:
Примечание: во время написания этой статьи я узнал, что программы чтения с экрана могут игнорировать aria-label и aria-labelledby для статических элементов. Если ваши ярлыки не работают, убедитесь, что у вашего элемента есть landmark role или роль, которая подразумевает интерактивность.
Состояние (State)
Когда я перехожу к нашему переключателю с помощью программы чтения с экрана, она говорит мне, что он находится в выключенном состоянии. Тем не менее, когда я запускаю тумблер … он все равно говорит, что он выключен. Нам нужен способ, чтобы вспомогательные программы знали, когда состояние переключателя изменилось.
Атрибуты состояния ARIA описывают свойства элемента, которые могут изменяться способами, которые актуальны для пользователя. Они динамичны. Например, складные разделы (collapsible sections) позволяют пользователям нажимать кнопку, чтобы развернуть или свернуть содержимое. Когда пользователь программы чтения с экрана фокусируется на этой кнопке, вероятно, было бы полезно, если бы они знали, было ли содержимое в настоящее время развернуто или свернуто. Мы могли бы установить aria-extended=»false» на кнопку, а затем динамически изменять значение при каждом нажатии кнопки.
Еще один заслуживающий упоминания атрибут ARIA — aria-hidden. Всякий раз, когда элемент имеет aria-hidden=»true», он и любой его дочерний элемент немедленно удаляются из дерева доступности. Вспомогательные программы, использующие дерево, не будут знать, что этот элемент существует. Это полезно для презентационных элементов, которые украшают страницу, но создают беспорядочные возможности чтения с экрана. aria-hidden также может быть динамически переключен, например, чтобы скрыть содержимое страницы от программ чтения с экрана, когда открыто модальное окно.
Возвращаясь к нашему переключателю, элементы, для которых заданы role=»checkbox» или role=»switch», ожидают, что элемент будет иметь атрибут состояния, aria-checked, и будет меняться между «true» и «false» всякий раз, когда переключение срабатывает.
Следующий пример демонстрирует, как мы можем использовать JavaScript для изменения aria-checked:
Попробуйте перейти к переключателю с помощью программы чтения с экрана. Нажмите на переключатель, чтобы включить темный режим. Теперь переключатель фактически объявляет, когда он включен:
VoiceOver прочитает текст «on, Use dark mode, switch»
Свойства
Свойства ARIA — это атрибуты, которые описывают дополнительный контекст об элементе, который было бы полезно знать пользователю, и который не подвержен изменениям, таким как состояние. Примеры свойств:
Некоторые свойства ARIA устанавливают отношения между элементами. Например, вы можете использовать aria-describedby, чтобы связать элемент с другим элементом, который предоставляет более длинное описание:
Используйте меньше ARIA.
Спецификации ARIA Консорциума World Wide Web предоставляют пять правил использования ARIA. Первое правило можно прочитать как «не используйте ARIA», как это сделали некоторые, но это не совсем так. Правило звучит так:
Если вы можете использовать встроенный HTML-элемент с семантикой и поведением, которые вам требуются, вместо использования ARIA элементов (роли, состояния или свойства), чтобы сделать его доступным, то сделайте это.
Другими словами, ARIA должна быть инструментом в вашем арсенале, но она не должна быть первым инструментом, к которому вы обращаетесь. Вместо этого используйте семантику элементов, где это возможно. В нашем примере с переключателем это может выглядеть следующим образом (мы можем использовать встроенный checkbox и вообще не использовать ARIA):
Почему мы должны использовать семантическую разметку вместо ARIA? Вот несколько причин:
Мне действительно нравится, как выразилась Кэтлин МакМэхон. Если веб-разработка похожа на приготовление пищи, то семантические элементы — это ваши высококачественные ингредиенты. Атрибуты ARIA — это ваши приправы. Готовьте с ними, во что бы то ни стало, но вам нужно только небольшое их количество.
Дальнейшее чтение
Если вы хотите узнать больше об ARIA, я рекомендую следующие ресурсы:
