Aria expanded что означает
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-атрибута (подробнее).
Руководство по продвинутым CSS-селекторам. Часть 1
Хочешь знать больше про веб?
Подпишись на наш телеграм-канал TechRocks WEB-разработка?
Перевод статьи «Guide to Advanced CSS Selectors — Part One».
Не важно, пишете вы свой CSS полностью самостоятельно или используете фреймворк. В любом случае понимание селекторов, каскада и специфичности критически важно для работы с CSS и изменения существующих стилевых правил.
Вероятно, вы хорошо знакомы с использованием CSS-селекторов на основе ID, классов и типов элементов. Также вы наверняка часто пользуетесь скромным символом пробела для выбора потомков.
В этой статье я рассмотрю несколько более продвинутых CSS-селекторов и приведу примеры их использования. В частности, мы разберем:
Специфичность и каскад CSS
Чтобы успешно работать с селекторами в CSS, нужно разобраться в некоторых ключевых концепциях. Первая — это специфичность, а вторая — каскад (в «CSS» каскад, собственно, представлен буквой «C»).
«Специфичность представляет собой вес, придаваемый конкретному правилу CSS. Вес правила определяется количеством каждого из типов селекторов в данном правиле. Если у нескольких правил специфичность одинакова, то к элементу применяется последнее по порядку правило CSS. Специфичность имеет значение только в том случае, если один элемент соответствует нескольким правилам. Согласно спецификации CSS, правило для непосредственно соответствующего элемента всегда будет иметь больший приоритет, чем правила, унаследованные от предка», — MDN.
Повышение специфичности происходит в результате отмены наследования из каскада.
.item будет красным, потому что специфичность id-селектора выше, чем у каскада и селектора элемента.
Это не означает, что нужно добавлять #id ко всем вашим элементам и селекторам, но знать об их влиянии на специфичность нужно.
Ключевая идея: чем выше специфичность, тем сложнее перекрыть правило.
В каждом проекте свои нужды по части повторного использования правил. Желание делиться правилами с низкой специфичностью привело к подъему фреймворков, таких как Tailwind и Bulma.
С другой стороны, желание жестко контролировать наследование и специфичность, например в рамках системы проектирования, привело к популярности соглашений о нейминге, таких как БЭМ. В этих системах родительский селектор жестко связан с селекторами-потомками для создания компонентов, пригодных для повторного использования. Эти компоненты образуют собственный пузырь специфичности.
Если вы думаете, что вам не нужно во всем этом разбираться, потому что вы используете фреймворк или систему проектирования, вы заблуждаетесь. Вы искусственно ограничиваете свои возможности использовать CSS на полную мощность.
Красота этого языка проявляется именно в конструировании элегантных селекторов, которые захватывают ровно столько, сколько нужно, и при этом позволяют иметь довольно короткие таблицы стилей.
Универсальный селектор
Универсальный селектор — * — называется так потому, что применим ко всем элементам.
Раньше его не рекомендовали использовать из-за проблем с производительностью, но это больше не актуально. Фактически, это уже больше десяти лет не является проблемой. Чем выбирать CSS-селекторы, ориентируясь на соображения производительности, лучше побеспокоиться о размере JS-пакета и оптимизации изображений.
Но есть более достойная причина использовать этот селектор пореже. Дело в том, что он имеет нулевую специфичность, а значит, может быть перекрыт любым селектором класса, элемента или id-селектором.
Применение универсального селектора на практике
Сброс блочной модели CSS
Чаще всего я использую универсальный селектор в самом первом правиле для сброса CSS:
Вертикальный ритм
Еще один очень полезный вариант применения универсального селектора был предложен Энди Беллом и Хейдоном Пикерингом в их книге и на их сайте Every Layout. Этот способ называется «стек» и в самой простой форме выглядит так:
Если вы хотите быть более избирательным, в определенных обстоятельствах можно использовать этот селектор в качестве потомка:
Это напоминает идею стека, но здесь мы нацеливаемся на элементы заголовков, чтобы оставить немного пространства между разделами контента.
Селекторы атрибутов
Это чрезвычайно мощная категория селекторов, но зачастую их мощь не используют в полной мере.
Знаете ли вы, что с помощью селекторов атрибутов можно добиться результатов сопоставления, как при применении регулярных выражений?
Это исключительно полезно при внесении изменений в системах в стиле БЭМ, где имена классов связаны между собой, но, возможно, нет какого-то одного общего имени класса.
Кроме того, вы можете обеспечить нечувствительность к регистру, добавив i перед закрывающей скобкой селектора атрибута.
Но указывать значение атрибута вообще не обязательно. Вы можете просто проверить, есть ли оно:
Все возможные способы сопоставления со значениями в селекторах атрибутов можно найти в документации MDN.
Применение селекторов атрибутов на практике
Подчистка кода для улучшения доступности
Благодаря этим селекторам можно осуществлять базовый линтинг доступности, например:
Применение к aria для принудительного обеспечения доступности
Например, при реализации аккордеона, где вам нужно включить следующую кнопку независимо от того, переключается ли логическое значение aria при помощи JavaScript:
Теперь aria-expanded можно использовать в CSS в качестве селектора атрибута вместе с соседним родственным комбинатором для стилизации соответствующего контента как закрытого или открытого.
Стилизация не-кнопочных ссылок навигации
При создании навигации вы можете иметь смесь дефолтных ссылок и ссылок, стилизованных как «кнопки». В этом случае для выбора не-кнопочных ссылок будет полезным использовать следующий код:
Удаление стиля списка по умолчанию
Еще один совет от Энди Белла. Можно удалить стилизацию списка, основываясь на наличии атрибута role :
Дочерний комбинатор
«Некоторые селекторы называются комбинаторами, поскольку они соединяют другие селекторы, создавая полезную связь селекторов друг с другом и расположением содержимого в документе», — MDN.
Дочерний комбинатор очень эффективен для небольшого добавления специфичности и уменьшения охвата при применении стилей к элементам-потомкам. Это единственный селектор, который работает с уровнями элементов и может комбинироваться для выбора вложенных элементов.
При применении дочернего комбинатора из элементов, соответствующих второму селектору, будут выбраны только те, которые являются прямыми потомками элементов, соответствующих первому селектору.
Абзац захватывается article > p
Абзац не захватывается article > p
Применение дочернего комбинатора на практике
Многоуровневый список ссылок для навигации
Для визуальной передачи этой иерархии вы скорее всего захотите по-разному стилизовать ссылки разных уровней. Чтобы захватить только ссылки верхнего уровня, можно использовать следующий код:
Вот ссылка на CodePen, где вы можете поэкспериментировать и посмотреть, что будет, если удалить любой из дочерних комбинаторов в этом селекторе.
Определение области видимости для селекторов элементов
Стилизация встроенного (стороннего) контента
Порой у вас нет контроля над именами классов, идентификаторами и даже разметкой. Например, если речь идет о рекламе и прочем контенте, движимом JavaScript.
Примечание. В этом сценарии вам могут помочь и другие селекторы, но только дочерний комбинатор работает с уровнями и может захватывать элементы указанного уровня вложенности.
Общий родственный комбинатор
Общий родственный комбинатор —
— выбирает указанные элементы, расположенные где-нибудь после предыдущего указанного элемента, при том, что все эти элементы имеют одного родителя.
img захватит все изображения, находящиеся где-нибудь после абзаца, если у них с абзацем общий родитель.
Это означает, что здесь изображения будут выбраны:
Скорее всего, вы захотите внести больше конкретики (см. также соседний родственный комбинатор). Поэтому данный селектор чаще используется в творческих упражнениях по написанию кода, таких как моя игра CommitSweeper на чистом CSS.
Применение общего родственного комбинатора на практике
Визуальная передача смены состояния
Допустим, у нас есть чекбокс со следующим HTML:
При помощи общего родственного комбинатора мы можем изменять стиль абзацев соглашения, только если чекбокс был отмечен:
Вариации с низкой специфичностью
Если мы применяем универсальный селектор, мы можем также сгенерировать небольшие вариации, например, в макете с карточками.
Это правило добавляет margin, уменьшает размер шрифта и осветляет цвет текста у любого элемента, который следует за изображением:
Можете поэкспериментировать с применением общего родственного комбинатора в CodePen.
Это правило имеет очень низкую специфичность, так что вы легко его перекроете добавлением какого-нибудь более направленного правила.
Соседний родственный комбинатор
Соседний родственный комбинатор — + — захватывает элементы, идущие сразу за указанным элементом.
Мы уже пользовались этим в примерах с универсальным селектором — * + * — чтобы применить верхний margin только к элементам, следующим за другим элементом. Давайте рассмотрим и другие примеры.
Применение соседнего родственного комбинатора на практике
Полифил для эмуляции gap в навигации
Поддержка gap во Flexbox скоро будет, но на момент написания статьи ее еще нет в Safari.
Применение интервала между метками формы и входными данными
Рассматривая ранее «стек», мы говорили о применении margin только в одном направлении. Используя эту идею в рамках объектов полей формы, мы можем обеспечить достаточный интервал для сохранения визуальной иерархии между типами полей.
В этом случае мы добавляем намного меньший margin между меткой и ее входящими данными, и больший margin между входящими данными и метками:
Примечание. Этот пример работает в ограниченном контексте. Вероятно, вы захотите заключить типы полей в элемент группировки, чтобы обеспечить согласованность между типами полей, а не перечислять все типы полей, кроме полей ввода.
Состояния и свойства объектов — ARIA-атрибуты
Атрибутов спецификации, как нетрудно догадаться, гораздо больше. Их делят на следующие секции.
Эта секция содержит атрибуты, определенные для элементов пользовательского интерфейса, (GUI) веб-документов или интернет-приложений, взаимодействующих с пользователем. Эти атрибуты предназначены для поддержки ролей-виджетов:
— aria-autocomplete — показывает, применяется ли автозаполнение для текстового поля;
— aria-checked — показывает состояние «checked» у чекбоксов или радиокнопок;
— aria-disabled — показывает состояние «disabled» у элементов упражнения;
— aria-expanded — показывает, развернут или свернут текущий элемент;
— aria-hidden — показывает состояние «hidden» у текущего элемента;
— aria-multiline — показывает возможность многострочного ввода у текстового элемента;
— aria-multiselectable — показывает возможность множественного выбора у элементов управления у тега ;
— aria-orientation — показывает положение элемента (горизонтальное или вертикальное);
— aria-readonly — показывает состояние «readonly» у элементов управления;
— aria-required — аналог HTML5 атрибута required;
— aria-selected — показывает состояние «selected» у элементов управления;
— aria-sort — показывает порядок сортировки у строк таблицы или элементов с ролью «grid».
Атрибуты для Live Region
Live Region — это элементы страницы, обновляемые в результате внешнего события, обычно вне пользовательского фокуса. Канонический пример Live Region — информер биржевых сводок.
Задача этих атрибутов — отобразить, какие изменения содержимого могут произойти, когда элемент не в фокусе, и обеспечить вспомогательным технологиям информацию о способе обработки обновления этого содержимого.
— aria-busy — указывает, обновляются ли элемент и его поддерево, в настоящее время.
— aria-live — указывает, что элемент будет обновлен, и описывает типы обновлений браузеру.
Атрибуты перетаскивания (Drag-and-Drop)
Тут все понятно — эти атрибуты обеспечивают эффект drag-and-drop:
— aria-grabbed — указывает, может ли элемент быть захвачен перетаскиванием;
— aria-dropeffect — определяет функции, которые могут быть задействованы в процессе и при завершении перетаскивания.
В этой секции — атрибуты, указывающие на отношения или ассоциации между элементами, которые не могут быть полностью определены структурой документа.
— aria-activedescendant — указывает на элемент, чей контент является активным потомком составного виджета;
— aria-controls — указывает элемент (элементы), чьим содержанием или поведением управляет текущий элемент;
— aria-describedb — указывает элемент (или элементы), описывающие объект;
— aria-owns — определяет положение в иерархии документов по схеме потомок/родитель;
— aria-posinset — определяет позицию элементов наборе;
— aria-setsize — определяет число пунктов в текущем наборе lis-titems или treeitems.
По состоянию на сегодняшний день это почти все, ну а чтобы покончить с этой непростой темой, приведем как пример использования технологии реализацию дерева на html-разметке с применением WAI-ARIA (пример из спецификации):
Инклюзивные компоненты: сворачиваемые секции
Сворачиваемые секции, возможно, самый элементарный паттерн проектирования взаимодействия в вебе. Всё, что они делают — это переключают видимость контента при клике на заголовок. Ничего особенного.
Хотя это простое взаимодействие, оно не имеет нативной и одинаковой реализации в разных браузерах. И это несмотря на то, что есть движение в сторону его стандартизации. Так что это отличный аналог «hello world» для погружения в доступность с точки зрения проектирования взаимодействия с использованием JavaScript и WAI-ARIA.
Почему я говорю об этом только после того, как рассказал про более сложные компоненты? Дело в том, что в этой статье я сосредоточусь на опыте автора и разработчика: мы собираемся сделать наши раскрываемые области веб-компонентами, чтобы они могли легко стать частью более крупных паттернов и быть встроенными в существующий контент.
Как и в случае вкладок, это помогает понять, каким будет наш компонент без улучшения при помощи JavaScript и почему это действительно поможет сделать что-то лучше. В этом случае сворачиваемая секция без JavaScript — просто раздел. То есть это подзаголовок, кратко описывающий какой-то контент: текст, медиа, да что угодно.
Одно из преимуществ _сворачивания _контента заключается в том, что заголовки становятся смежными элементами. Это даёт пользователю возможность изучить доступный контент без необходимости много скроллить и увидеть его полностью, развернув блок.
Другое преимущество — это то, что пользователям клавиатуры не нужно проходить через все элементы страницы, на которых можно сделать фокус, чтобы попасть туда, куда они хотят. На скрытом контенте его установить нельзя.
Адаптивная разметка Скопировать ссылку
Рискованно просто добавлять обработчик клика для заголовков, чтобы связать с ними контент. Это не то взаимодействие, которого ожидают вспомогательные технологии или которого можно добиться при помощи клавиатуры. Вместо этого нам нужно адаптировать разметку, добавив в неё стандартную кнопку.
Примечание: я обернул контент в элемент
Состояние Скопировать ссылку
Наш компонент может находится в одном из двух взаимоисключающих состояний: свёрнутом и развёрнутом. Его состояние может быть отображено визуально, но необходимо также сообщать о нём и программно. Можно сделать это, добавив для кнопки атрибут aria-expanded с начальным значением false (в свёрнутом состоянии). Соответственно, нам нужно скрыть связанный
Некоторые совершают ошибку, добавляя aria-expanded для управляемого элемента вместо контрола. И это понятно, ведь фактически именно у контента переключается состояние. Если подумать, это не принесёт особой пользы: пользователю придётся найти раскрывающийся контент (это возможно только тогда, когда он на самом деле развёрнут!), а потом ещё поискать элемент, который им управляет. Поэтому информация о состоянии сообщается через контрол, который используется для переключения видимости контента.
Примечание. Это всё ARIA-кнопка? Скопировать ссылку
Некоторые добавляют атрибут aria-controls и указывают id для контейнера, в котором хранится контент. Имейте в виду, что атрибут aria-controls работает только в JAWS на момент написания этой статьи (на момент перевода в октябре 2019 года ситуация не изменилась. — прим. переводчика). Пока контент в разделе следует за заголовком или кнопкой в исходном порядке (source order), это не нужно. Пользователь будет сразу же сталкиваться с раскрытым контентом, когда перемещается дальше по странице.
Стилизация кнопки Скопировать ссылку
Мы оказались в ситуации, когда используем кнопку, но при этом она должна выглядеть как улучшенная версия заголовка, внутри которого она находится. Наиболее эффективный способ это сделать — удалить все авторские и браузерные стили для кнопок и наследовать их от их родительского заголовка.
Отлично, однако сейчас кнопка интуитивно не понятна (affordance). Она не выглядит так, будто её можно активировать. Именно здесь обычно добавляется символ плюс или минус. Плюс означает, что раздел может быть развёрнут, а минус, что его можно свернуть.
Теперь возникает такой вопрос: как нам рендерить иконку? Ответ: максимально эффективно и доступно. Простые формы, например, прямоугольники ( ) — это хороший способ создания иконок в SVG, поэтому давайте это сделаем.
Обратите внимание на класс vert для прямоугольника, который представляет собой вертикальную конструкцию. Мы собираемся с помощью CSS показывать и скрывать его в зависимости от состояния, превращая иконку то в плюс, то в минус.
Связывание состояния и его визуального представления — очень хорошая практика. Это гарантия того, что сообщение об изменении состояния совместимо с разными системами. Не слушайте тех, кто выступает за абсолютное разделение HTML-семантики и CSS-стилей. Форма должна следовать за функцией, и такое решение напрямую более надёжно.
Высококонтрастные темы Скопировать ссылку
Чтобы протестировать ваш дизайн в высококонтрастной теме в Windows найдите «Высокая контрастность» и выберете нужную тему в пункте «Выбор темы». Многие высококонтрастные темы инвертируют цвета для уменьшения яркости. Это помогает людям, страдающим мигренью или светобоязнью, а также людям с нарушениями зрения.
Если у нас много сворачиваемых областей на странице, то повторное использование одного и того же содержимого SVG-элемента
при помощи элементов и xlink:href уменьшило бы их избыточность.
Небольшой скрипт Скопировать ссылку
Учитывая простоту такого взаимодействия, а также все элементы с их семантикой, нам нужно только написать очень лаконичный скрипт:
Прогрессивное улучшение Скопировать ссылку
Проблема со скриптом выше заключается в том, что для него требуется вручную адаптировать HTML для работы сворачивающихся секций. Ожидается, что это реализовано инженером как компонент через шаблон или JSX. Однако для статических сайтов, например, блогов, есть две неизбежные проблемы:
Почему это написано на JavaScript? Потому что современные браузеры одинаково поддерживают методы Web API и такой небольшой интерактив не должен зависеть от большой библиотеки.
Прогрессивный веб-компонент Скопировать ссылку
Последний пример показывает, что нам не нужно думать о раскрывающихся секциях во время редактирования. Они появляются автоматически. Но то, что мы приобрели в плане удобства, мы потеряли в контроле. Что, если вместо этого, мы найдём компромисс между лаконичной разметкой и тем, какие разделы будут раскрывающимися и в каком состоянии они будут находиться при загрузке страницы после того, что мы написали?
Веб-компоненты могут стать ответом. Рассмотрим пример ниже:
Фактически, если мы проверяем поддержку элемента с и attachShadow при помощи скрипта, то такой же фолбэк будет отображаться в браузерах, которые эти возможности не поддерживают.
Шаблон Скопировать ссылку
Мы можем добавить элемент шаблона в разметку и ссылаться на него или создать его на лету. Это я собираюсь сделать позже.
Этот шаблон компонента станет поддеревом Shadow DOM.
Когда мы стилизуем сворачиваемую секцию внутри её собственной Shadow DOM, то такие стили не влияют на элементы из Light DOM (стандартной, внешней DOM). Кроме того, они не применяются, если браузер не поддерживает и кастомные элементы.
Определение компонента Скопировать ссылку
Обратите внимание на элемент в HTML-шаблоне. Он — это окно в нашей Light DOM. В него гораздо проще обернуть контент, который предоставил автор, в отличие от предыдущего демо с прогрессивным улучшением.
С помощью этих ссылок можно переместить Light DOM в Shadow DOM. Это означает, что мы можем повторно использовать лейбл
в Light DOM и убрать ставший ненужным элемент. Такие манипуляции с DOM могут выглядеть дико, особенно если вы привыкли использовать простые, декларативные (React) компоненты. Однако это то, что делает веб-компоненты прогрессивными.
Вообще-то мы можем сделать лучше и поддерживать разные начальные уровни заголовков. Вместо того, чтобы управлять заголовками, можно просто получить первый элемент из Light DOM. Убедитесь, что он — заголовок. Это необходимо для его редактирования. Однако, если это не заголовок, мы можем использовать любой элемент. Я покажу как.
Одно из преимуществ использования aria-level заключается в том, что, в нашем случае, атрибут не используется в качестве стилевого хука (styling hook), поэтому внешний вид заголовка или кнопки остаётся неизменным.
Если вы хотите, чтобы заголовки вашей сворачиваемой секции внешне отражали их уровень, вы должны включить что-то вроде CSS-стилей ниже:
Роль region Скопировать ссылку
Пользователи скринридеров больше предпочитают перемещаться по документу по заголовкам, чем по областям, однако у многих скринридеров есть функция шорткатов по областям страницы (region shortcuts). Добавление атрибута role=»region» даёт довольно много:
Привязка open и aria-expanded Скопировать ссылку
Преимущество такого подхода в том, что мы можем переключать состояние, используя скрипт, который просто изменяет значение open за пределами компонента. Чтобы пользователи могли изменить состояние, мы можем просто перебросить open в функцию клика:
Свернуть или развернуть всё Скопировать ссылку
Кажется заманчивым добавить «развернуть или свернуть всё» как два отдельных переключателя. Но мы не знаем, как много разделов будет изначально в другом состоянии. Мы также не знаем, сколько их пользователь открыл или закрыл вручную.
Поэтому нам нужно сгруппировать два альтернативных контрола.
Важно объединить в группу связанные контролы, и списки — это стандартная разметка для того, чтобы это сделать. Кроме того списки ссылок рассматривались в «Меню и кнопки меню» (всё ещё есть перевод на русский. — прим. переводчика). Списки и элементы списков подсказывают пользователям скринридеров о том, что они взаимодействуют со связанными элементами, и количество таких элементов.
Обратите внимание, что при использовании aria-label добавляется только невидимый лейбл. Это допустимо, если назначение кнопок можно определить визуально с помощью других подсказок, по той же раскладке. В этом случае, вероятно, будет достаточно расположить кнопки рядом с разделами, но нужно это протестировать.
Отслеживание URL Скопировать ссылку
Одно последнее улучшение.
Обратите внимание на то, что мы делаем фокус на кнопке внутри заголовка компонента. Это перемещает пользователей клавиатуры к соответствующему компоненту, готовому к взаимодействию. Скринридерами будет объявлен уровень родительского заголовка вместе с названием кнопки.
В дополнение к этому нам нужно обновлять hash каждый раз, когда пользователи открывают последующий раздел. Тогда они могут поделиться определённым URL без необходимости копаться в инструментах разработчика (если они знают как!), чтобы скопировать и вставить id заголовка. Давайте используем pushState для динамичного изменения URL без перезагрузки страницы:
Заключение Скопировать ссылку
Ваша роль как дизайнера и разработчика (да, вы можете быть и тем, и другим одновременно) заключается в том, чтобы удовлетворять потребности людей, которые получают ваш контент и используют предложенный вами функционал. Эти потребности охватывают как потребности «конечных пользователей», так и других контрибьютеров. Продукт должен быть, конечно же, доступным и обладать хорошей производительностью, но поддержка и расширение его возможностей не должны быть завязаны на эзотерических технических знаниях.
Вне зависимости от того, используете ли вы веб-компоненты или нет, прогрессивное улучшение не только гарантирует, что интерфейс хорошо структурирован и надёжен. Как мы здесь увидели, это также может упростить процесс редактирования контента. Это делает разработку приложения и его контент более инклюзивным.
