Aria hidden true что это
Правила использования 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-атрибута (подробнее).
Методы скрытия элементов веб-страниц
Веб-разработчикам приходится скрывать элементы веб-страниц по самым разным причинам. Например, есть кнопка, которая должна быть видимой при просмотре сайта на мобильном устройстве, и скрытой — при использовании настольного браузера. Или, например, имеется некий навигационный элемент, который должен быть скрыт в мобильном браузере и отображён в настольном. Элементы, невидимые на странице, могут пребывать в различных состояниях:
HTML5-атрибут hidden
Рассмотрим следующий пример:
В CSS я воспользовался атрибутом hidden для вывода элемента только в том случае, если область просмотра страницы имеет необходимый размер.
Вот CSS-код, который здесь использован:
→ Вот пример этой страницы на CodePen
▍Атрибут hidden и доступность контента
Если рассмотреть атрибут hidden с точки зрения доступности контента, то окажется, что этот атрибут полностью скрывает элемент. В результате с этим элементом не смогут работать средства для чтения с экрана. Не используйте этот атрибут в тех случаях, когда некие элементы страниц нужно делать невидимыми для человека, но не для программ для чтения с экрана.
CSS-свойство display
Представим, что мы хотим скрыть изображение из предыдущего примера и решили воспользоваться следующим CSS-кодом:
При таком подходе изображение будет полностью исключено из документа (из так называемого document flow — «потока документа»), оно будет недоступно программам для чтения с экрана. Возможно, вы не очень хорошо представляете себе понятие «поток документа». Для того чтобы с этим понятием разобраться — взгляните на следующий рисунок.
Синюю книгу убрали из стопки
Вот анимированный вариант примера с книгами, показывающий то, что происходит в том случае, если одну из них убирают из стопки.
Если убрать книгу из стопки — положение других книг в ней изменится
▍Производится ли загрузка ресурсов, скрытых средствами CSS?
Если коротко ответить на этот вопрос — то да, загрузка таких ресурсов производится. Например, если элемент скрыт средствами CSS, и мы показываем этот элемент в некий момент работы со страницей, к этому моменту изображение уже будет загружено. Наличие на странице изображения, даже скрытого средствами CSS, приведёт к выполнению HTTP-запроса на его загрузку.
Исследование страницы, содержащей скрытое изображение
Что такое 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, я рекомендую следующие ресурсы:
Пять правил использования ARIA
Эта статья — вольный перевод оригинала. Я добавляю свои примеры и мысли, пишу как чувствую и ставлю смайлики 🙂 Автор статьи сказал, что ему понравилась моя интерпретация! Джерард занимается доступностью в Twitter и попросил поделиться с вами ссылкой на его курсы по доступности. Курсы лаконичные и очень понятные, я их посмотрела по 10-дневной бесплатной подписке. Итак, к делу!
Опасности, которые таит в себе ARIA Скопировать ссылку
В оригинальной статье введение более содержательное, так что почитайте его хотя бы ради практики английского языка 🙂 Я передам только несколько тезисов — прим. переводчицы.
ARIA — (Accessible Rich Internet Applications) это набор атрибутов, который позволяет сделать наши приложения более доступными, особенно если они написаны на JS. Из моего опыта — это, например, легаси-код, где давно-давно наверстали дивами, а теперь надо как-то добавить доступность, но нет доступа к HTML.
Если вы хотите познакомиться с ARIA — начинайте с официальных спецификаций. Не нужно сразу читать их глубоко и полностью, но парочку секций лучше изучить. Например, самое важное, с чем следует ознакомиться в спеке — это понятие роли.
Роль — это семантика вашего элемента, подсказка для ассистивных технологий, что можно делать с этим элементом, как его обрабатывать, как с ним взаимодействует клавиатура и так далее.
В ассистивные технологии входят скринридеры, брайлевские клавиатуры, голосовые помощники и другие средства доступа к информации, помимо привычных клавиатур, экранов и мышей.
Важно: роли (и вообще любые ARIA-атрибуты) не добавляют элементам никаких стилей и поведения!
У ролей есть классификация. Например, бывают роли для виджетов, для структуры документа, для лайв-областей, которые как-то обновляются на фоне независимо от действий пользователя и о чём-то ему сообщают. Практически для каждой роли есть свой набор обязательных ARIA-атрибутов. Некоторые роли нельзя использовать отдельно от родительских ролей.
Вот и пробежались по введению в статью 🙂 Переходим к правилам!
Пять правил использования ARIA Скопировать ссылку
Если вы уже понимаете, что вынуждены как-то накручивать доступность на ваши интерфейсы, нужно следовать нескольким основным правилам. Это облегчит принятие решений при разработке приложений и конкретно виджетов.
Правило 1 Скопировать ссылку
Не используйте ARIA
Читая это правило, я всегда очень радуюсь — так однозначно и бескомпромиссно оно звучит 🙂 На практике смысл его в том, что сначала вы должны полностью положиться на HTML и использовать его семантику, и только тогда, когда вам не хватило или есть какой-то сложный составной случай (например, аккордеон или вкладки) — тогда подключайте ARIA. Также приходится использовать эти волшебные атрибуты в уже упомянутом мной легаси-коде, где нет доступа к HTML и можно только с помощью JS добавлять что-то к существующим тегам.
Правило 2 Скопировать ссылку
Не изменяйте семантику нативных контролов.
Вы уже начали писать чистый, красивый и семантичный HTML, но поняли, что везде используете таблицы для вывода простых списков. У вас есть возможность явно задать элементу роль, чтобы переопределить его семантику:
Так вот, не переопределяйте дефолтную семантику без острой необходимости! Лучше замените тег: