Был у меня однажды такой опыт, простая задача: по клику на кнопку в элементе списка показать модалку с запросом дополнительной информации, сабмитом и отменой. Мы сразу решили подумать о хорошем UX, и тут начались вопросы.

По дизайну форма должна была появляться в месте клика. Это попап? Или диалог? Нужен ли бекдроп? Должно ли окно закрываться по Esc? А что делать с кнопкой "назад" на Android — закрывать только модалку или уходить со страницы целиком? В следующем спринте планировались нотификации по сокетам, и там тоже была масса вопросов к всплывающим уведомляшкам.

Это был тот редкий случай, когда мы решили не брать готовую библиотеку компонентов, а сделать всё сами. Вопросов накопилось много и я решил покопать спеку WAI-ARIA.

И я рекомендую делать это каждому разработчику интерфейсов!. Тем более, что у нее есть более дружелюбное представление: https://www.w3.org/WAI/ARIA/apg/.

Открытие: доступность — это архитектура

В процессе погружения в особенности доступности я обнаружил нечто неожиданное: выверенную систему описания интерфейса с точки зрения его функций, а не визуального представления.

ARIA APG — это не просто гайдлайны о том, как делать интерфейсы доступными для людей с ограниченными возможностями. Это целостная архитектурная система, которая помогает правильно структурировать компоненты и их взаимодействие. Там учтены практически все краевые случаи, без обработки которых мы рискуем оставить пользователя в неприятной ситуации. И это очень полезно для непосредственной разработки!

Термины

К сожалению, далеко не все дизайн-системы и npm-пакеты следуют выработанным стандартам. Многие термины в нашем сообществе используются неправильно — такое вот наследие. А не знание терминов или их не правильное использование ухудшает наши коммуникации и понимание друг друга. По моему опыту, и сам иногда не знаешь точно что имеешь в виду, используя термины интуитивно, а не изучив их заранее. Вот что я выяснил:

Modal, toast, snackbar, drawer — это неверные названия для dialog, alert, alertdialog, status, log, marquee (см. Live Region Roles и Window Roles).

Роль dialog представляет контент без обязательного взаимодействия. Например: карточка товара, просмотр фото с комментариями. Требования: бекдроп, автофокус и focus lock, aria-describedby или aria-labelledby, aria-modal.
Роль alert — это важная информация, требующая внимания пользователя, но не требующая реакции. Визуально исчезает сама. Например: срабатывание таймера, уведомление об ошибке.
Роль alertdialog предоставляет информацию, по которой требуется реакция пользователя. Требования как у диалога. Например: подтверждение удаления файла, ошибка с вариантами обработки.
Роли status/log/marquee похожи на alert, но не требуют обязательного внимания. Например: новое сообщение в чате, статус обработки заказа.

Понимая это и начиная разработку и проектирование кода с этих функций, составление конечных компонентов становится намного очевиднее и проще!

Work in progress

Но есть и пробелы в спецификации. Как должно модальное окно реагировать на кнопку "назад" управления историей навигации? Должна ли системная кнопка "назад" на Android закрывать открытую модалку или полностью уходить со страницы? В гайдах на этот счёт прямых указаний нет. На просторах интернета все еще идут споры. Но это нормально.

Из интересного по теме, можно обратить внимание на эту статью: https://baymard.com/blog/back-button-expectations

Важно понимать, что WAI-ARIA — это живой стандарт. В нём может чего-то не быть, а что-то может даже оказаться неточным (например, есть открытые вопросы по Menu and Menubar navigation). Но это всё равно лучшая доступная база, с которой стоит начинать проектирование компонентов.

Headless UI

Изучая доступность, я понял, почему такие библиотеки как Ariakit и React Spectrum разделяют состояния и представление. Когда мы отделяем логику и поведение компонента от его визуального отображения, опираясь на семантику WAI-ARIA, мы получаем:

Структуру — пирамиду из спецификации, имплементации логики, дизайна и компонентов отображения
Гибкость — не нужно думать над тем как добавлять новую фичу в компонент, все решает композиция

Когда мы организовываем код, опираясь на паттерны доступности, разрабатывать и использовать конечные визуальные компоненты становится намного проще. Проще разговаривать с дизайнерами и определять фичи и поведение компонентов. WAI-ARIA даёт вам готовую архитектуру — остаётся только следовать ей.

Доступность помогает всем

Стоит помнить, что хорошие практики доступности нужны намного более широкому кругу пользователей, чем может казаться с первого взгляда, есть множество людей с временно ограниченными способностями:

Одна рука занята сумкой / ребёнком / в гипсе
Экран не видно из-за солнца или низкой яркости
Мышка сломалась, трекпад неудобный
Усталость глаз после долгого рабочего дня или плохое самочувствие

В таких ситуациях пользователь особенно нуждается в нашей заботе.

Доступность — это не про особые потребности меньшинства. Это про качественную архитектуру приложения, которая делает интерфейс удобным для всех.

Выводы

Использование WAI-ARIA как основы архитектуры UI-компонентов даёт неожиданные преимущества:

Ускоряет разработку — у вас есть готовые паттерны для большинства случаев
Упрощает рефакторинг — чёткая структура кода позволяет легко вносить изменения
Улучшает коммуникацию — единая терминология помогает в общении с дизайнерами
Повышает качество — вы не забудете про важные детали вроде focus management
Повышает конкурентноспособность - продукт не столкнется с государственным или иным регулированием

Доступность — это не дополнительная фича, которую можно отложить на потом. Это фундамент хорошей архитектуры, который помогает создавать качественные интерфейсы быстрее и эффективнее. WAI-ARIA - это не догма, но база, которая нужна каждому веб разработчику.

Практические ресурсы

Базовые паттерны компонентов с понятными объяснениями, обязательно скиньте своим дизайнерам!
Большой список примеров с черновым кодом реализации
Примеры реализации с детальным описанием поведения
Спецификация WAI-ARIA для глубокого погружения
Issues для поиска того над чем еще думают

А если бы вы были подписаны на мой канал в телеграме, то прочитали бы пост по теме еще в 2022: https://t.me/artalog/151.

Доступность как архитектура UI