accessibility-a11y.js·4 scenarios
Accessibility (a11y) concept page: WCAG 2.2 (POUR principles, A/AA/AAA), semantic HTML first vs ARIA last, keyboard navigation, focus management, screen readers (NVDA/VoiceOver/JAWS), skip links, aria-live regions, prefers-reduced-motion, three-tier audit pipeline (axe/Pa11y/Lighthouse + manual + real users), legal compliance (ADA Dominos v. Robles 2019, EAA 2025). 4 scenarios, 2 ADRs.
Accessibility, или a11y, не отдельная декоративная настройка для небольшой группы пользователей. Это способ сделать интерфейс работоспособным для людей с разным зрением, моторикой, слухом, когнитивной нагрузкой, устройствами ввода и сетапами браузера. Один пользователь читает экран глазами, другой слушает NVDA, третий идет только клавиатурой, четвертый открывает страницу на 200% zoom, пятый включает reduced motion. Для продукта это та же самая пользовательская база, а не отдельный режим.
Инженерная причина проста: доступный UI обычно более надежен. Семантическая кнопка уже умеет focus, Enter, Space, disabled state, участие в форме и понятное имя для screen reader. Корректный label улучшает форму и для автозаполнения, и для тестов, и для голосового управления. Явная иерархия headings помогает не только screen reader, но и SEO, навигации, содержанию страницы. Поэтому a11y нужно проектировать на уровне HTML, состояний, роутинга, дизайна, QA и CI, а не пытаться "добавить ARIA" перед релизом.
Есть и внешние ограничения: WCAG 2.1/2.2 AA часто становится практическим минимумом для коммерческих и государственных сервисов; в США риски идут через ADA, в Европе с 2025 года сильнее влияет European Accessibility Act. Но юридический аргумент вторичен. Главный риск в том, что недоступный интерфейс буквально блокирует покупку, регистрацию, оплату, чтение документа или работу в админке.
Думайте о доступности как о цепочке передачи смысла: продуктовая модель превращается в DOM, DOM превращается в accessibility tree, accessibility tree читается браузером, screen reader, клавиатурой, голосовым управлением и вспомогательными технологиями. Если на одном звене смысл потерян, пользователь получает красивую, но бесполезную поверхность.
Базовая пирамида такая: сначала semantic HTML, затем понятная структура страницы, затем keyboard support и focus management, затем визуальные требования вроде contrast и motion, и только после этого ARIA для тех паттернов, где нативного HTML недостаточно. ARIA не делает плохую разметку хорошей. Она только добавляет роли, состояния и свойства к уже дисциплинированной модели.
WCAG удобно держать в голове через POUR: Perceivable, Operable, Understandable, Robust. Пользователь должен воспринимать информацию, управлять интерфейсом, понимать результат действий и работать через разные технологии сегодня и завтра. Минимум для большинства продуктов - Level AA; AAA полезен как ориентир, но не всегда реалистичен для всего контента.
Диаграмма показывает a11y не как один линтер, а как стек. Слева разные пользователи: sighted mouse user, screen reader user, keyboard-only user, low vision user, cognitive/reduced-motion user. Справа слои frontend: semantic HTML, ARIA augmentation, keyboard handlers, CSS focus/contrast/reduced motion, media alternatives. Ниже расположены реальные assistive technologies: NVDA, VoiceOver, JAWS, browser zoom. Отдельно показан audit pipeline: axe-core, Pa11y, Lighthouse, ручная проверка и тесты с реальными пользователями.
Такой вид полезен тем, что ломает популярную иллюзию "прогоним Lighthouse и закроем a11y". Автоматические инструменты находят missing labels, invalid ARIA, плохой contrast, duplicate id, часть проблем headings и focusability. Но они не понимают, осмыслен ли alt text, удобно ли пройти checkout клавиатурой, не теряется ли focus после закрытия modal, правильно ли screen reader объявляет toast, не мучителен ли flow из 70 Tab presses.
В диаграмме также есть compliance слой: WCAG 2.2 AA, ADA и EAA. Он не стоит наверху как единственная цель, а подключен к проверкам и семантике. Это правильный порядок: сначала пользовательский опыт и техническая модель, затем доказуемое соответствие стандарту.
Первый сценарий сравнивает <button> и <div onClick>. Для sighted mouse user оба варианта выглядят одинаково. Но keyboard-only пользователь не попадает на div через Tab, screen reader не слышит "button", Space прокручивает страницу, disabled behavior приходится реализовывать вручную, form submit не работает. Итог: один нативный элемент заменяет набор хрупких обработчиков. Главный урок: semantic first дешевле, надежнее и переносимее.
Второй сценарий про skip link. На странице с длинной навигацией screen reader user иначе вынужден снова и снова проходить десятки пунктов меню перед основным содержимым. Ссылка Skip to main content, видимая при focus, переводит пользователя сразу к <main>. Это маленькая деталь, но она меняет ежедневную скорость работы. Связанный материал: ::concept{slug="web-perf-core-vitals"}, потому что perceived speed для assistive users тоже является производительностью.
Третий сценарий показывает aria-live. SPA добавляет товар в корзину и рисует toast. Для зрячего пользователя все очевидно, но screen reader молчит, потому что focus остался на кнопке. role="status" или aria-live="polite" сообщает результат без резкого прерывания; role="alert" нужен для критических событий вроде истекшей сессии. Урок: dynamic content обязан иметь канал уведомления, иначе часть пользователей не узнает о результате действия.
Четвертый сценарий про pipeline проверки: axe/Pa11y/Lighthouse в CI, затем ручной проход Tab, VoiceOver/NVDA, zoom 200%, reduced motion, mobile touch targets, затем периодические тесты с реальными пользователями. Это не бюрократия, а разные классы дефектов. Автоматика ловит синтаксис, ручная проверка ловит поведение, реальные пользователи ловят когнитивную цену и неочевидные блокеры.
Первый ADR: semantic HTML first, ARIA last. Выбор не только этический, но и экономический. Нативные элементы дают поведение браузера бесплатно и одинаково работают с keyboard, screen reader, формами, touch, voice control и progressive enhancement. Альтернатива, div плюс role плюс tabindex плюс onKeyDown, кажется гибкой, но переносит на команду ответственность за десятки edge cases. ARIA нужна для сложных виджетов: dialog, combobox, tablist, tree, listbox. Но даже тогда надо реализовывать полный паттерн WAI-ARIA Authoring Practices: roles, states, keyboard map, focus trap, escape handling, aria-controls, aria-activedescendant. Половинчатая ARIA хуже отсутствующей, потому что обещает screen reader один контракт, а поведение дает другое.
Второй ADR: automated audit vs manual and real users. CI обязателен, потому что регрессии должны ломать PR. Но автоматические проверки покрывают только часть WCAG. Поэтому зрелая команда использует три уровня. Tier 1: eslint-plugin-jsx-a11y, axe-core в Playwright/Jest, Storybook addon, Lighthouse CI. Tier 2: ручной QA основных сценариев клавиатурой и screen reader. Tier 3: accessibility research с пользователями, особенно перед крупными релизами checkout, onboarding, редактора, billing или enterprise-функций. Trade-off в стоимости очевиден, но цена поздней переделки выше: недоступный design system размножает дефект по всем страницам.
Отдельный trade-off есть в дизайне. Кастомные компоненты дают визуальную свободу, но дорогие composite widgets вроде date picker, combobox и rich text toolbar лучше строить на проверенных headless libraries: React Aria, Radix UI, Headless UI, Ariakit. Самописный компонент оправдан только если команда готова поддерживать keyboard matrix, screen reader quirks и regression tests.
Государственные сервисы и банки часто требуют WCAG AA как часть приемки. E-commerce страдает от a11y напрямую: если checkout не работает клавиатурой или screen reader не слышит ошибку карты, деньги теряются. Enterprise SaaS получает требования через procurement: VPAT/ACR, accessibility statement, сроки исправления blockers.
В дизайн-системах зрелых компаний a11y встроена в primitives: button, link, dialog, menu, combobox, tooltip, toast. Adobe React Aria полезен как пример системного подхода: hooks дают поведение, а дизайн остается кастомным. GOV.UK Design System полезен как пример простых компонентов, понятных текстов ошибок и progressive enhancement.
Для CloudArch эта тема связана с frontend routing и rich interactive UI. Редактор диаграмм, галерея, concepts pages, формы авторизации и billing должны быть проверяемы не только визуально. Для сложных canvas/diagram interfaces важно иметь keyboard shortcuts, текстовые labels, focusable controls и альтернативные описания состояния. Связанные темы: ::concept{slug="spa-vs-ssr-vs-ssg"}, ::concept{slug="web-perf-core-vitals"}.
div onClick вместо <button> или <a href> - самый частый дефект. Он выглядит безобидно в демо, но ломает keyboard и screen reader. tabindex="1" и любые положительные tabindex ломают естественный порядок. Placeholder вместо label делает форму плохо читаемой и ломает контекст после ввода. Иконка без accessible name превращается в "button, unlabeled".
Плохая ARIA опасна: aria-hidden="true" на контейнере с focusable children, role="button" без keyboard handler, aria-expanded без реального состояния, aria-live на элементе, который монтируется только после сообщения и не объявляется некоторыми screen readers. Еще одна ошибка - modal без focus trap и без возврата focus на кнопку, которая его открыла.
Визуальные ошибки: низкий contrast, focus outline удален ради красоты, meaning передан только цветом, motion не уважает prefers-reduced-motion, изображения без alt или с мусором вроде alt="image", видео без captions. Процессные ошибки: "проверим a11y перед релизом", отсутствие a11y rules в CI, отсутствие ручного screen reader сценария для критических flows.
Не надо использовать ARIA там, где есть нативный HTML. Не надо строить собственный select, если обычный <select> покрывает задачу. Не надо делать сложный combobox ради трех вариантов. Не надо превращать каждую SVG-иконку в отдельный announced element, если она декоративная; используйте aria-hidden="true" для decoration и accessible name на кнопке.
Не стоит гнаться за WCAG AAA для всего продукта, если это мешает выпуску полезного AA-compatible интерфейса. AAA может быть целевым для образовательного, государственного или медицинского контента, но для динамического SaaS чаще разумнее строго держать AA, закрывать blockers и улучшать самые дорогие flows.
Не надо считать canvas-only интерфейс достаточным для всех задач. Если продукт по природе визуальный, часть canvas останется визуальной, но команды управления, список объектов, свойства, ошибки и навигация должны иметь доступные DOM-представления.
Начните с WCAG 2.2 и WAI-ARIA Authoring Practices Guide: они дают критерии и конкретные keyboard patterns. Практически полезны Inclusive Design Patterns Хейдона Пикеринга и Accessibility for Everyone Лоры Калбаг. Для инструментов посмотрите axe-core, Pa11y, Lighthouse CI, eslint-plugin-jsx-a11y, Storybook a11y addon, React Aria и Radix UI.
Внутри курса продолжайте через ::concept{slug="web-perf-core-vitals"}, потому что layout shift, loading state и responsive behavior влияют на доступность, и через ::concept{slug="spa-vs-ssr-vs-ssg"}, потому что SPA route changes требуют focus management и announce strategy.