Что такое aria label
Эффективное использование ARIA в HTML5
ARIA это аббревиатура от Accessible Rich Internet Applications (доступные насыщенные интернет-приложения), использование этого стандарта позволяет сделать сайт более доступным для людей с ограниченными способностями, например, с нарушениями слуха или зрения. Посмотрим, что могут сделать разработчики, чтобы облегчить им жизнь.
Роли ARIA
Роли ARIA добавляются в разметку HTML как атрибуты. Они определяют тип элемента и указывают цель, которой он служит. В следующем примере элемент идентифицируется как баннер:
Еще один пример: здесь роль сообщает сведения о том, что элемент содержит информацию о содержимом страницы.
Оповещение будет выглядеть так:
role=”alert” полноценно работает с элементами, динамически добавляемыми в DOM или при смене отображения, например, с display:none to display:block
Следующая роль одна из моих любимых, ее я использую, когда элемент используется чисто декоративно. Если вы представите человека со скринридером, подумайте об элементах, содержимое которых нет смысла зачитывать. Это могут быть декоративные элементы или пустые элементы, используемые для фона.
Атрибуты ARIA
Атрибуты ARIA немного отличаются от ролей ARIA. Они также добавляются в разметку, но существует уже определенный диапазон атрибутов ARIA. Все атрибуты используют префикс aria- и делятся на две группы: состояния и свойства.
На самом деле использование атрибута ARIA в нативной радио-кнопке излишне, связывание input type=»radio» и aria-checked производится автоматически.
Правила ARIA
Прежде чем бросаться в атаку, запомните, что по нескольким причинам не стоит добавлять ARIA к каждому элементу.
Старайтесь максимально использовать семантические элементы HTML
У элемента может быть только одна роль
У элемента не может быть множественных ролей. Согласно определению, роль это:
Основной индикатор типа. Эта семантическая ассоциация позволяет инструментам отображать и поддерживать взаимодействие с объектам в манере, соответствующей ожиданиям пользователя относительно остальных объектов того же типа.
Не может быть двух ролей у элемента HTML. Все роли семантичны тем или иным способом и в соответствии с определением выше, элемент не может быть двух типов. Может ли у вас быть кнопка-заголовок? Нет, только одно из двух. Выбирайте роль, которая лучше всего описывает функцию элемента.
Не изменяйте нативную семантику
Вы не должны применять роль, не соответствующую семантике элемента, так как добавленная роль переписывает нативную семантику элемента. Например:
Однако второе правило ARIA позволяет в случае необходимости использовать вложение элементов.
Как еще можно сделать разметку более доступной?
Максимально используйте семантические элементы
Вот пример с использованием обоих упомянутых элементов:
Существует еще множество элементов HTML, которые вы, возможно, не учитываете, включая несколько новых, поэтому еще раз рекомендую оценить возможности.
Атрибут alt
Это часто забываемая часть разметки, которая может серьезно сказаться на доступности, особенно в случае скринридеров. Этот атрибут появился в спецификации со времен HTML2 и описывается следующим образом:
текст используемый вместо изображения, если изображение недоступно в силу каких-то ограничений или предпочтений пользователя.
По причине ограничений или предпочтений пользователя. Независимо от причин, по которым не загружается изображение, у пользователей с ослабленным зрением на самом деле нет предпочтений. Они просто испытывают проблемы при просмотре изображения. Хотя спецификация ничего не говорит о термине “доступность”, она предполагает, что изображение не может быть загружено как следует, а у пользователя есть возможность отключить загрузку изображения. Хотя мы живем в мире, в котором второй вариант кажется менее вероятным, мы не можем предугадать, что делает пользователь на другом крае. Поэтому мы должны предлагать пользователям альтернативу.
Люди часто заполняют атрибут alt не информативно, например, пишут текст типа “собака” для фотографии своей собаки, играющей в парке. К сожалению, этот текст не нарисует никакой картины для слабовидящих. Следующий подход более приемлем:
Пример разметки с использованием семантического HTML и ARIA, ориентированный на доступность
Если вы смотрели на примеры в этой статье, то вы ожидаете увидеть в качестве образца следующее:
Заключение
Роли и атрибуты ARIA дают огромный эффект, когда содержимое вашего сайта обрабатывается скрин-ридерами и прочими вспомогательными технологиями. С распространением вспомогательных технологий нам надо рассматривать интеграцию ARIA в наш код как постоянную практику.
Использование атрибута 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-label
The aria-label attribute defines a string value that labels an interactive element.
Description
Sometimes the default accessible name of an element is missing, or does not accurately describe its contents, and there is no content visible in the DOM that can be associated with the object to give it meaning. A common example is a button containing an SVG or icon font (which you shouldn’t be using) without any text.
In cases where an interactive element has no accessible name, or an accessible name that isn’t accurate, and there is no content visible in the DOM that can be referenced via the aria-labelledby attribute, the aria-label attribute can be used to define a string that labels the interactive element on which it is set. This provides the element with its accessible name.
Note: aria-label is intended for use on interactive elements, or elements made to be interactive via other ARIA declarations, when there is no appropriate text visible in the DOM that could be referenced as a label
Most content has an accessible name generated from its immediate wrapping element’s text content. Accessible names can also be created by certain attributes or associated elements.
By default, a button’s accessible name is the content between the opening and closing tags, an image’s accessible name is the content of its alt attribute, and a form input’s accessible name is the content of the associated element.
If none of these options are available, or if the default accessible name is not appropriate, use the aria-label attribute to define the accessible name of an element.
aria-label can be used in cases where text that could label the element is not visible. If there is visible text that labels an element, use aria-labelledby instead.
The aria-label attribute can be used with regular, semantic HTML elements; it is not limited to elements that have an ARIA role assigned.
Note: The aria-label is only «visible» to assistive technologies. If the information is important enough to add for AT users, consider making it visible for all users.
Values
A string of text that will be the accessible name for the object.
ARIAMixin API
The ariaLabel property, part of the Element interface, reflects the value of the aria-label attribute.
The ariaLabel property, part of the ElementInternals interface, reflects the value of the aria-label attribute.
Associated roles
Used in almost all roles except roles that can not be provided an accessible name by the author.
Note: The aria-label attribute is intended for interactive elements only. When placed on non-interactive elements, such as those listed above, it may not be read or may confuse your users as a non interactive element that acts like an interactive one.
Что такое aria-label и как мне его использовать?
Определяет строковое значение, которое маркирует текущий элемент.
Но, по моему мнению, это то, что title атрибут должен был делать. Я посмотрел дальше в Mozilla Developer Network, чтобы получить некоторые примеры и объяснения, но единственное, что я нашел, было
Итак, мой вопрос: зачем мне это aria-label и как мне его использовать?
, когда фактический видимый текст внутри элемента
слишком короткий и не желательно, чтобы полный текст был видимым? В примерах в этой теме можно использовать метку. Но метки не применяются к заголовкам, поэтому я спрашиваю
Это атрибут, разработанный, чтобы помочь вспомогательным технологиям (например, программам чтения с экрана) прикрепить ярлык к анонимному HTML-элементу.
aria-label делает то же самое, но это для тех случаев, когда это не практично или нежелательно иметь label на экране. Возьмите пример MDN :
Большинство людей смогут визуально сделать вывод, что эта кнопка закроет диалог. Слепой человек, использующий вспомогательные технологии, может просто услышать, как «Х» читается вслух, что мало что значит без визуальных подсказок. aria-label явно говорит им, что будет делать кнопка.
В приведенном вами примере вы совершенно правы, вам нужно установить атрибут title.
Если aria-label это инструмент, используемый вспомогательными технологиями (например, программами чтения с экрана), он не поддерживается в браузерах и не оказывает на них никакого влияния. Это не окажет никакой помощи большинству людей, на которых ориентируется WCAG (кроме пользователей программ чтения с экрана), например, людям с ограниченными интеллектуальными возможностями.
Буква «Х» не является достаточной для предоставления информации о действии, выполняемом кнопкой (подумайте о человеке, не имеющем компьютерных знаний). Это может означать «закрыть», «удалить», «отменить», «уменьшить», странный крест, каракули, ничего.
Несмотря на то, что W3C, кажется, продвигает aria-label скорее этот title атрибут здесь: http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/ARIA14 в аналогичном примере, вы можете видеть, что технология поддержка не включает стандартные браузеры: http://www.w3.org/WAI/WCAG20/Techniques/ua-notes/aria#ARIA14
Например, слепые люди не воспринимают всплывающие окна, как у нас с хорошим зрением, это как изменение контекста. «Назад на страницу» будет более удобной альтернативой для программы чтения с экрана, когда «Закрыть» более важно для тех, у кого нет программы чтения с экрана.
Создайте HTML-страницу с кодом ниже
Теперь вам нужен эмулятор чтения с виртуального экрана, который будет запускаться в браузере, чтобы увидеть разницу. Таким образом, хромовые пользователи браузера могут установить ChromeVox расширение и пользователи Mozilla может идти с клыками экраном читателя AddIn
Доступный дизайн компонентов на примерах. Дизайнеру про 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 (на английском языке) — там можно чуть больше погрузиться в тему.