Aria html что это
Aria html что это
Accessible Rich Internet Applications (ARIA) определяет способ сделать веб контент и веб приложения (особенно те, которые разработаны с помощью Ajax и JavaScript) более доступными для людей с ограниченными возможностями. Например, ARIA делает доступным навигационные маркеры, JavaScript виджеты, подсказки на форме, сообщения об ошибках, автоматические обновления и многое другое.
Поддержка ARIA реализована в большинстве современных браузеров и программах экранного доступа. Конечно, реализации различаются, и старые технологии не поддерживают их полностью (либо вообще не поддерживают). Используйте постепенно деградирующий «щадящий» ARIA, или просите пользователей использовать новые технологии.
Note: Пожалуйста, примите участие в написании и/или переводе статей чтобы сделать ARIA понятнее и доступнее для тех, кто только начинает изучать материал! Не хватает на это времени? Тогда отправьте свои предложения в список рассылки Mozilla по теме accessibility, или на IRC каналс тэгом #accessibility.
Простое улучшение ARIA
ARIA для виджетов на JavaScript.
Дополнительные ресурсы по ARIA
Список рассылки.
Блоги
Обнаружение багов.
Примеры
Стандартизация.
Like the W3C WAI-ARIA specification, the official best practices represents a future ideal — a day when authors can rely on consistent ARIA support across browsers and screen readers. The W3C documents provide an in-depth view of ARIA.
For now, web developers implementing ARIA should maximize compatibility. Use best practices docs and examples based on current implementations.
Open AJAX Accessibility Task Force The Open AJAX effort centers around developing tools, sample files, and automated tests for ARIA. Under Construction: WCAG 2.0 ARIA Techniques The community needs a complete set of WCAG techniques for WAI-ARIA + HTML, so that organizations can be comfortable claiming their ARIA-enabled content is WCAG compliant. This is important when regulations or policies are based on WCAG.
Правила использования 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-ролями
Не изменяйте нативную семантику элемента, если вам это не необходимо.
Вместо переопределения семантического значения элемента, нам следует использовать соответствующий элемент:
Или, в крайнем случае, мы можем добавить ARIA-роль к элементу, который не несет такого смысла.
3. Интерактивные элементы ARIA должны быть доступны для всех сред
Все интерактивные элементы управления ARIA должны быть пригодны для работы с клавиатуры.
Недостаточно использовать ARIA-роль на элементе, чтобы по-настоящему изменить его роль. Если мы попытаемся изменить, например,
В руководстве ARIA имеется список возможностей, которые должен иметь каждый элемент. Например, настоящая кнопка должна удовлетворять следующим требованиям:
При использовании ARIA-ролей нам необходимо учитывать эти требования. Создание элемента похожего на кнопку — не делает его кнопкой. Нам нужно учитывать, как пользователи во всех средах взаимодействуют с элементом.
4. Используйте соответствующие роли для видимых фокусируемых элементов
Не используйте role=»presentation» или aria-hidden=»true» на видимых фокусируемых элементах.
ARIA-атрибут role=»presentation» подразумевает, что элемент предназначен для визуального взаимодействия и не является интерактивным. Атрибут aria-hidden=»true» говорит о том, что элемент не должен быть видим. Когда мы используем эти атрибуты, нам нужно знать, к каким элементам они применяются и являются ли эти элементы видимыми и интерактивными. Например, обе эти кнопки приведут к тому, что некоторые пользователи будут фокусироваться на элементе, который для них не существует.
Эти атрибуты должны применяться только к элементам, которые не являются интерактивными или являются невидимыми.
5. Интерактивные элементы должны иметь Доступное описание
Все интерактивные элементы должны иметь Доступное описание.
Элементы, с которыми можно взаимодействовать, например кнопки и ссылки, должны иметь «доступное описание».
Доступное описание (accessible name) — имя элемента пользовательского интерфейса.
Очень просто объяснить это на пример кнопки «OK». Текст «OK» — доступное описание (accessible name). (прим. переводчика)
Доступное описание для элемента может быть указано в зависимости от типа этого элемента. Инпуты в форме, как правило, получают свое Доступное описание из соответствующих им лейблов.
(подробнее).
Другие элементы, например кнопки и ссылки, могу получить своё Доступное описание из их контента или 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?
Перевод статьи: 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, я рекомендую следующие ресурсы: