Состояния и свойства объектов — 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 (пример из спецификации):
Компоненты
Более десятка повторно используемых компонентов построены так, чтобы обеспечить кнопки, выпадающие меню, группы ввода, навигации, оповещения, и многое другое.
Выпадающие меню
Раскрывающиеся списки переключаемой, контекстная накладки для отображения списков ссылок и более. Они сделаны интерактивными с включенным Bootstrap выпадающего JavaScript плагин. Они переключаются нажатием, не парит; это преднамеренное дизайнерское решение.
Содержание
Примеры
Одиночная кнопка выпадающего меню
Самое приятное, что вы можете сделать это с любым вариантом кнопки:
Split кнопка с выпадающим меню
Изменение размера
Кнопка меню работы с кнопками всех размеров, в том числе по умолчанию и секущихся выпадающих кнопок.
Вариант списка сверху
Пункты меню
Исторически выпадающем меню had чтобы быть одной, но это уже не в случае с v4. Теперь при необходимости можно использовать элементы в раскрывающихся списках, а не просто ы.
Выравнивание меню
Внимание! меню расположены только с CSS и может потребоваться некоторые дополнительные стили для точного выравнивания.
Заголовки меню
Добавьте заголовок чтобы маркировать участки в любом выпадающего меню.
Dropdown header
Делители меню
Отдельные группы связанных элементов меню с делителем.
Заблокированы части меню
Использование
Примечание: data-toggle=»dropdown» атрибут является основанием для закрытия выпадающего меню на уровне приложения, так что это хорошая идея, чтобы всегда использовать его.
С помощью данных атрибутов
Добавить data-toggle=»dropdown» на ссылку или кнопку для переключения в меню.
Через JavaScript
Вызвать меню через JavaScript:
data-toggle=»dropdown» еще требуется
Независимо от того, вызываете ли вы свой выпадающий список через JavaScript или вместо этого используете data-api, data-toggle=»dropdown» всегда должно присутствовать на спусковом элементе раскрывающегося меню.
Варианты
Методы
| Способ | Описание |
|---|---|
| $().dropdown(‘toggle’) | Переключает меню данной панели навигации и вкладок навигации. |
События
| Событие | Описание |
|---|---|
| show.bs.dropdown | Это событие немедленно срабатывает при вызове метода экземпляра-шоу называется. |
| shown.bs.dropdown | Это событие запускается, когда выпадающее меню становится видимым для пользователя (будет ждать CSS переходы для завершения). |
| hide.bs.dropdown | Это событие немедленно уволили, когда скрывать метод экземпляра называется. |
| hidden.bs.dropdown | Это событие запускается, когда в списке есть, который скрыт от пользователя (будет ждать CSS переходы для завершения). |
Спроектированы и построены со всей любовью в мире @mdo и @fat. Поддерживается основной командой с помощью наших спонсоров.
Сейчас v4.0.0-alpha.4. Код лицензии MIT, документы CC BY 3.0.
Инклюзивные компоненты: меню и кнопки меню
Классифицировать сложно. Например, возьмём крабов. Раки-отшельники, веерные крабы и подковообразные крабы, с точки зрения таксономии, не настоящие крабы, но это не мешает использовать в их названиях слово «краб». Всё становится ещё запутаннее, когда через какое-то время благодаря процессу, называемому канцеризацией, ненастоящие крабы эволюционируют, чтобы больше походить на настоящих. Это то, что произошло с королевскими крабами, которые в прошлом были раками-отшельниками. Представьте размеры их раковин!
В дизайне мы часто совершаем такую же ошибку, когда называем разные вещи одинаковыми именами. Они кажутся похожими, но внешность может быть обманчивой. Это плохо сказывается на прозрачности вашей библиотеки компонентов. С точки зрения инклюзивности это может привести к тому, что вы измените нужную семантику и поведение компонента на совершенно противоположные. Пользователи будут ожидать одного поведения, а получат другое.
Выпадающие списки, которые состоят из нескольких пунктов, часто называют «меню». Об этом я и хочу поговорить в этой статье. Мы будем делать настоящее меню, но по пути обсудим их не совсем настоящие реализации.
Давайте начнём с вопроса: является ли блок ссылок с картинки, выпадающий вниз из панели навигации, меню?
Правильный ответ: нет, это не настоящее меню.
То, что навигационная схема состоит из списков или ссылок — давнее соглашение. Оно почти так же давно предписывает, что дополнительная навигация (sub-navigation) должна быть вложенными списками со ссылками. Если бы я удалил стили для компонента, показанного выше, я бы увидел что-то вроде этого списка ссылок, только с Times New Roman и синего цвета.
С точки зрения семантики вложенные списки со ссылками в этом контексте корректны. Системы навигации на самом деле оглавления: именно так они устроены. Единственное, что действительно заставляет думать, что перед нами меню — это стилизация вложенных списков и способ их отображения при наведении курсора или при фокусе.
Относительно второго пункта: при перемещении по области навигации в подменю ожидаешь, что каждое подменю будет появляться при наведении или при фокусе на ссылке верхнего уровня (например, «Магазин» из примера выше). Это одновременно показывает подменю и размещает ссылки в нём в порядке получения фокуса. С помощью JavaScript можно управлять событиями фокуса (focus) и его потери (blur) и сохранить внешний вид подменю пока это необходимо. При этом те, кто использует для навигации клавиатуру, должны иметь возможность переходить по очереди от одной ссылки каждого уровня к другой.
Проблема с навигационными подменю Скопировать ссылку
Навигационные подменю (или для кого-то «выпадающие списки») отлично работают с мышью или с клавиатуры, но не так хороши для касаний. Когда вы в первый раз нажимаете на ссылку верхнего уровня «Магазин» из примера, то сообщаете, что надо открыть подменю и перейти по ссылке.
Здесь есть два возможных варианта решения проблемы:
Первое решение не самое хорошее. Я ранее замечал, что этот тип семантики и поведения нежелателен в данном контексте, где ссылки — это управляемые контролы (subject controls). Кроме того пользователи больше не смогут переходить на страницу верхнего уровня, если она есть.
Какие устройства — сенсорные? Скопировать ссылку
Заманчиво думать: «Это не самое хорошее решение, но я применю его только для сенсорных интерфейсов». Проблема в том, как определить, есть ли у устройства сенсорный экран?
Вам точно не стоит относить любой «маленький экран» к разряду «экранов с сенсорным управлением». Работая в одном офисе с людьми, разрабатывающими сенсорные дисплеи для музеев, я могу заверить вас, что самые большие экраны — сенсорные. Не забывайте о ноутбуках с клавиатурой и сенсорным дисплеем.
К тому же многие, но далеко не все устройства небольшого размера являются сенсорными. В инклюзивном дизайне вы не можете позволить себе предполагать.
Второе решение более инклюзивное и надёжное. Это «фолбэк» для пользователей всех устройств. Но я специально взял в кавычки это слово, потому что думаю, что на самом деле постраничные оглавления — это лучший способ обеспечения навигации.
Похоже, получившая премию команда Government Digital Services с этим согласится. Вы также могли видеть такие оглавления в Wikipedia.
Оглавление Скопировать ссылку
Примечания Скопировать ссылку
Всё на одной странице Скопировать ссылку
Примечание: в некоторых браузерах фокус плохо переносится на отдельные фрагменты страницы. Добавление tabindex=»-1″ к нужному фрагменту исправляет это.
В случае, если на сайте много контента, лучше тщательно продумывать информационную архитектуру с оглавлениями меню, чем делать ненадёжную и громоздкую систему выпадающих меню. Так будет легче сделать адаптивную версию страницы с меньшим количеством кода, а также это упростит восприятие её структуры. Там, где системы выпадающих меню скрывают структуру, оглавления обнажают её.
На некоторых сайтах, включая правительственный цифровой сервис gov.uk, есть страницы с указателями (или «темами»), которые представляют собой просто оглавления. Это настолько мощная концепция, что популярный генератор статических сайтов Hugo создаёт такие страницы по умолчанию.
Информационная архитектура — это важная часть инклюзивности. Плохо организованный сайт может соответствовать нужным вам техническим требованиям, но при этом будет отталкивать многих пользователей. Особенно это касается тех, у кого есть когнитивные нарушения или у кого мало времени на то, чтобы с чем-то долго разбираться.
Кнопки навигационного меню Скопировать ссылку
Пока мы обсуждаем тему фальшивых навигационных меню, было бы упущением с моей стороны не поговорить про кнопки меню. Вы наверняка видели состоящую из трёх линий иконку-гамбургер или «navicon».
Даже с упрощённой информационной архитектурой и одним уровнем навигационных ссылок пространство на маленьких экранах на вес золота. Скрытие навигации за кнопкой означает, что во вьюпорте будет больше места для основного контента.
Кнопка навигации больше всего из того, что мы изучали, похожа на настоящую кнопку меню. Так как она открывает меню по клику, то она должна:
Прогрессивное улучшение Скопировать ссылку
Давайте не будем забегать вперёд. Мы должны помнить о прогрессивном улучшении и подумать, как это будет работать без JavaScript.
В изначальном HTML-файле мало что можно сделать с помощью кнопок (кроме кнопок для отправки данных, но они даже близко не связаны с тем, что нам нужно сделать). Может быть, вместо этого, нам следует начать с простой ссылки, которая приведёт нас к навигации?
Нет особой необходимости использовать ссылку, если между ней и навигацией нет большого количества контента. Так как навигация сайта в большинстве случаев должна размещаться наверху страницы, то в этом решении нет необходимости. Так что, действительно, навигационное меню без JavaScript должно быть просто… навигацией.
Вы улучшите его, добавив кнопку, которая в исходном состоянии скрывает навигацию с помощью атрибута hidden :
Делать всё возможное для поддержки старого программного обеспечения — это, конечно, часть инклюзивного дизайна. Некоторый софт невозможно обновить или его разработчики не хотят этого делать.
Расположение Скопировать ссылку
Многие неправильно размещают кнопку за пределами области (навигации). Это может привести к тому, что пользователи скринридеров, которые перемещаются по с помощью горячих клавиш, решат, что область пустая, что не особо им поможет. Со списком, скрытым от скринридеров, они просто столкнулись бы с этим:
Вот как мы можем переключить состояние:
ARIA-controls Скопировать ссылку
Без хорошего метода перемещения между элементами, вам нужно убедиться в том, что одно из следующего верно:
Использование aria-controls на самом деле не приносит большого вреда, за исключением того, что делает объявления в скринридере более подробным. Однако некоторым пользователям JAWS это может быть нужно. Вот как будет использоваться атрибут вместе с id для списка:
Меню и роли menuitem Скопировать ссылку
Настоящее меню (с точки зрения WAI-ARIA) должно себя идентифицировать с помощью роли menu (для контейнера) и, обычно, роли menuitem для дочерних элементов (или других ролей для подобных элементов). Эти роли для родителей и детей работают сообща и предоставляют вспомогательным технологиям нужную информацию. Вот как можно расширить список, добавив для него семантику меню:
Краткий ответ — нет. Более подробный ответ: нет, потому что наши элементы списка содержат ссылки, а элементы menuitem не могут иметь интерактивных потомков. То есть они являются контролами в меню.
Мы хотим, чтобы пользователи знали, что они используют ссылку и могут ожидать от неё поведения ссылки, так что пример выше не очень хороший. Как я уже сказал, настоящие меню предназначены для (написанных на JavaScript) приложений.
Примечание. Элемент Скопировать ссылку
Если вы давно знакомы с адаптивным дизайном, то можете вспомнить паттерн, в котором навигация была свёрнута в элемент в небольших вьюпортах.
Как и в случае с переключателями на основе чекбоксов, которые мы обсуждали (см. в переводе — прим. переводчика), использование нативного элемента, который ведёт себя не так, как задумано, без дополнительного скрипта — хороший выбор. Особенно с точки зрения эффективности и производительности в случае мобильных устройств. Элементы — это своего рода меню, с семантикой, аналогичной меню, открывающееся кнопкой, которую мы скоро будем создавать.
Однако, так же как и с переключателем, основанном на чекбоксе, мы используем элемент, связанный со вводом данных, а не просто делаем выбор. Это может запутать многих пользователей, тем более, что этот шаблон использует JavaScript, чтобы выбранный элемент вёл себя как ссылка. Неожиданное изменение контекста, которое это вызывает, считается ошибкой согласно критерию 3.2.2 On Input (Level A).
Настоящие меню Скопировать ссылку
Теперь, когда мы обсудили ненастоящие меню и квази-меню, пришло время создать настоящее меню, которое открывается и закрывается настоящей кнопкой меню. С этого момента я буду называть вместе кнопку и меню — «кнопкой меню».
Но в каком случае наша кнопка меню может считаться настоящей? Что ж, это будет компонент меню, предназначенный для выбора параметров в приложении, который предусматривает всю нужную семантику и стандартное поведение для такого инструмента.
Как я уже упоминал, эти соглашения пришли из дизайна десктопных приложений. ARIA-атрибуты и управление фокусом с помощью JavaScript необходимы для их полной имитации. Одна из целей ARIA — помочь веб-разработчикам создавать сложные веб-интерфейсы и не нарушать при этом устоявшие паттерны взаимодействия, пришедшие из реального мира.
В этом примере мы представим, что наше приложение — это какая-то игра или викторина. Наша кнопка меню даёт пользователю выбрать уровень сложности. С учётом всей семантики меню выглядит следующим образом:
Примечания Скопировать ссылку
Клавиатура и поведение при фокусе Скопировать ссылку
Есть намного больше способов взаимодействовать с кнопкой с клавиатуры. Вот краткий обзор поведения при фокусе с клавиатуры, которое мы будем реализовывать на основе WAI-ARIA Authoring Practices 1.1:
Преимущество перемещения фокуса между пунктами меню с помощью клавиш со стрелками состоит в том, что за Tab сохраняется функция выхода из меню. На практике это означает, что пользователям не нужно проходить через каждый пункт меню, чтобы выйти из меню. Это значительно улучшает юзабилити, особенно в меню, где много пунктов.
Метод open Скопировать ссылку
Мы можем создать методы для обработки различных событий как часть продуманного дизайна API.
Мы можем исполнить этот метод, когда пользователь нажимает клавишу вниз на кнопке меню, на которой сделан фокус:
Кроме того, разработчик, использующий этот скрипт, сможет теперь программно открывать меню:
Примечание. Хак с чекбоксом Скопировать ссылку
Если вам не нужен JavaScript, то лучше не использовать его настолько, насколько это возможно. Использование третьей технологии поверх HTML и CSS всегда усложняет систему и приводит к появлению в ней слабых мест. Однако не все компоненты можно создать без использования JavaScript.
В случае с кнопками меню желание сделать их «работающими без JavaScript» привело к появлению так называемого хака с чекбоксом. В нём состояние checked (или unchecked ) скрытого чекбокса используется для переключения видимости элемента меню с помощью CSS.
Для пользователей скринридеров роль чекбокса и состояние checked бессмысленны в этом контексте. Это можно частично исправить, добавив role=»button» для чекбокса.
Это разумное решение, но работа над нашей кнопкой меню всё ещё не закончена. Ожидаемое поведение фокуса, которое мы обсудили, просто не может быть реализовано без JavaScript.
Такое поведение принято и предсказуемо, оно делает кнопку более удобной. Однако, если вам действительно нужно сделать кнопку меню без JavaScript, то это самый подходящий вариант. Учитывая то, что урезанная кнопка навигационного меню, которую я рассмотрел ранее, предлагает контент меню, который не зависит от самого JavaScript (то есть ссылки), этот подход может быть подходящим вариантом.
Примечание: меню открывает только пробел.
Событие choose Скопировать ссылку
Есть много всего, что мы можем сделать с помощью этого механизма. Возможно, у нас есть live region с id со значением menuFeedback :
Теперь мы можем настроить обработчик событий и заполнить live region информацией, скрытой внутри события:
При выборе пункта меню пользователь скринридера услышит: «Вы выбрали [название пункта меню]». Изменения контента live region (которому задан здесь атрибут role=»alert» ) объявляются скринридерами при каждом его обновлении. Live region не является обязательным, но это пример того, что может произойти в интерфейсе, когда пользователь сделал выбор в меню.
Сохранение выбора Скопировать ссылку
Не все пункты меню нужны для выбора сохранения настроек. Многие из них ведут себя как стандартные кнопки, которые при нажатии приводят к тому, что что-то происходит в интерфейсе. Однако, в случае с нашей кнопкой меню со сложностью, мы хотели бы указать текущую настройку сложности. То есть ту, которая выбрана последней.
В нативных меню на многих платформах выбранные элементы отмечаются с помощью галочек. Мы можем это без проблем сделать, используя чуть больше CSS:
При перемещении по меню с запущенным скринридером при фокусе на этом выбранном элементе он объявит что-то вроде: «Галочка, средний, пункт меню, выбрано».
Поведение при открытии меню с выбранным menuitemradio немного отличается. Вместо того, чтобы сделать фокус на первом (включённом) элементе в меню, фокус устанавливается на выбранном элементе.
Какая польза от такого поведения? Пользователь (любой) помнит о своём предыдущем выборе. В меню с многочисленными параметрами (например, с масштабом), люди, работающие на клавиатуре, находятся в оптимальном положении для изменения настроек.
Использование кнопки меню с помощью скринридера Скопировать ссылку
Расшифровка Скопировать ссылку
Хейдон: Это кнопка меню со сложностью и я собираюсь протестировать её на VoiceOver в Chrome. Для начала я сделаю фокус на самой кнопке.
VoiceOver: Сложность, всплывающая кнопка.
VoiceOver: Галочка, очень сложно, пункт меню, выбран, меню, пять пунктов.
VoiceOver: Очень высокая, пункт меню.
VoiceOver: Сложность, всплывающая кнопка.
Хейдон: Это закрывает меню и перемещает фокус на саму кнопку меню «Сложность». Итак, вы вернулись туда, откуда начали.
Инклюзивная кнопка меню на Github Скопировать ссылку
Я и Хьюго Жирадель вместе работали над созданием компонента кнопки меню с фичами API, которые я описал, и ещё многим другим. Вы должны поблагодарить Хьюго за многие из этих фич, так как они основывались на работе над a11y-dialog — доступным модальным окном. Он есть на Гитхабе и в npm.
Кроме того, Хьюго сделал специально для вас версию кнопки на React.
Инклюзивные компоненты: сворачиваемые секции
Сворачиваемые секции, возможно, самый элементарный паттерн проектирования взаимодействия в вебе. Всё, что они делают — это переключают видимость контента при клике на заголовок. Ничего особенного.
Хотя это простое взаимодействие, оно не имеет нативной и одинаковой реализации в разных браузерах. И это несмотря на то, что есть движение в сторону его стандартизации. Так что это отличный аналог «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 без перезагрузки страницы:
Заключение Скопировать ссылку
Ваша роль как дизайнера и разработчика (да, вы можете быть и тем, и другим одновременно) заключается в том, чтобы удовлетворять потребности людей, которые получают ваш контент и используют предложенный вами функционал. Эти потребности охватывают как потребности «конечных пользователей», так и других контрибьютеров. Продукт должен быть, конечно же, доступным и обладать хорошей производительностью, но поддержка и расширение его возможностей не должны быть завязаны на эзотерических технических знаниях.
Вне зависимости от того, используете ли вы веб-компоненты или нет, прогрессивное улучшение не только гарантирует, что интерфейс хорошо структурирован и надёжен. Как мы здесь увидели, это также может упростить процесс редактирования контента. Это делает разработку приложения и его контент более инклюзивным.
