llmdocsсправочник разработчика

Веб-доступность (a11y)

Материал из llmdocs — справочник разработчика
Портал: Веб: HTML, CSS, JS, HTTP
Веб-доступность (a11y)
Сокращениеa11y (a + 11 букв + y)
Основной стандартWCAG 2.2 (W3C, октябрь 2023)
Принципывоспринимаемость, управляемость, понятность, надёжность (POUR)
Уровни соответствияA, AA, AAA
Спецификация ARIAWAI-ARIA 1.2
СкринридерыNVDA, JAWS, VoiceOver, TalkBack, Orca
Инструменты проверкиaxe, Lighthouse, WAVE

Веб-доступность (англ. web accessibility, сокращённо a11y) — свойство сайта или веб-приложения, при котором им могут полноценно пользоваться люди с ограничениями: незрячие и слабовидящие, глухие, люди с нарушениями моторики, когнитивными особенностями, а также все, кто оказался в «ситуативных» ограничениях — с одной свободной рукой, на ярком солнце или с медленным интернетом. Доступность достигается в основном правильным использованием HTML, продуманным дизайном и проверкой с клавиатуры и экранным диктором.

Зачем

По оценке ВОЗ, около 16% людей в мире живут с той или иной формой инвалидности.[2] Для многих из них доступный интерфейс — единственный способ получить госуслуги, купить продукты или работать. Во многих странах требования доступности закреплены законом: в США — ADA и Section 508, в Евросоюзе — European Accessibility Act (обязателен для многих частных сервисов с июня 2025 года). Доступность полезна и бизнесу: семантическая разметка лучше индексируется поисковиками и понятнее языковым моделям, а субтитры и чёткая структура удобны всем.

WCAG

Основной стандарт — Web Content Accessibility Guidelines консорциума W3C; актуальная версия — WCAG 2.2 (2023).[1] Он построен на четырёх принципах (POUR):

Принцип Смысл Примеры требований
Воспринимаемость информацию можно воспринять любым органом чувств альтернативный текст изображений, субтитры, контраст
Управляемость интерфейсом можно управлять разными способами всё доступно с клавиатуры, видимый фокус, достаточно времени
Понятность содержание и поведение предсказуемы язык страницы, понятные ошибки форм
Надёжность совместимость с вспомогательными технологиями корректная разметка, имена и роли элементов

Каждый критерий имеет уровень A, AA или AAA. Законы и корпоративные политики обычно требуют уровня AA. Например, контраст обычного текста — не менее 4,5:1, крупного — 3:1; размер цели для нажатия — не меньше 24×24 CSS-пикселя (новое в 2.2).

Семантический HTML

Большая часть доступности достаётся бесплатно, если использовать элементы по назначению:[5]

<!-- плохо: div не фокусируется и не объявляется как кнопка -->
<div class="btn" onclick="save()">Сохранить</div>

<!-- хорошо: клавиатура, фокус и роль работают сами -->
<button type="button" onclick="save()">Сохранить</button>

Основные правила:

  • Структура заголовков h1–h6 без пропусков уровней; ориентиры header, nav, main, footer — по ним скринридер перемещается по странице.
  • У каждого информативного изображения — alt с описанием смысла; у декоративного — пустой alt="".
  • У каждого поля формы — связанная <label>; ошибки описаны текстом, а не только красным цветом.
  • Ссылки с осмысленным текстом: «Скачать отчёт за 2025 год», а не «здесь».
  • Атрибут lang у <html> — чтобы синтезатор речи выбрал правильный язык.
  • Таблицы данных — с <th> и scope, а не вёрстка таблицами.

Клавиатура и фокус

Всё, что можно сделать мышью, должно быть доступно с клавиатуры: Tab и Shift+Tab переходят по интерактивным элементам, Enter и пробел активируют их, Esc закрывает диалоги. Фокус должен быть видимым — нельзя писать outline: none без замены; в CSS для этого есть :focus-visible. Порядок перехода совпадает с визуальным, модальные окна удерживают фокус внутри себя и возвращают его на место после закрытия. Ссылка «Перейти к содержимому» в начале страницы избавляет от прохода по всему меню.

ARIA

WAI-ARIA — набор атрибутов, сообщающих вспомогательным технологиям роли, состояния и свойства нестандартных виджетов: role="tab", aria-expanded="true", aria-live="polite" для динамических уведомлений.[3] Главное правило ARIA — не использовать ARIA, если есть подходящий HTML-элемент: неправильная ARIA ухудшает доступность. Шаблоны доступных компонентов (вкладки, комбобоксы, меню, деревья) с нужными ролями и клавишами описаны в ARIA Authoring Practices Guide.[4] Во многих случаях вместо самодельных компонентов лучше использовать нативные <dialog>, <details> и <select> или проверенные библиотеки (Radix, React Aria).

Проверка

Автоматические инструменты — axe (расширение и библиотека для тестов), Lighthouse в Chrome DevTools, WAVE — находят около трети проблем: контраст, отсутствие alt и подписей, неверные ARIA-атрибуты. По ежегодному исследованию WebAIM, на главных страницах миллиона популярных сайтов в среднем находится более 50 автоматически обнаруживаемых ошибок, а самые частые из них — низкий контраст и изображения без alt.[6] Остальное требует ручной проверки:

  1. пройти основные сценарии только с клавиатуры;
  2. включить скринридер (VoiceOver на macOS — Cmd+F5, NVDA на Windows) и послушать страницу;
  3. увеличить масштаб до 200–400% и проверить, что ничего не обрезается;
  4. проверить режим prefers-reduced-motion и тёмную тему.

Проверки axe можно встроить в тесты и CI/CD, чтобы ошибки не возвращались.

См. также

Источники

  1. W3C — Web Content Accessibility Guidelines (WCAG) 2.2
  2. W3C WAI — Introduction to Web Accessibility
  3. W3C — WAI-ARIA 1.2
  4. W3C WAI — ARIA Authoring Practices Guide
  5. MDN — Accessibility
  6. WebAIM — The WebAIM Million
Категории: