Чеклист доступности веба: WCAG 2.2 для практикующих дизайнеров
Чеклист доступности WCAG 2.2, организованный по месту принятия решений: Figma, браузер, после запуска. Плюс карта ошибок дизайнера с привязкой к критериям.
Большинство чеклистов веб-доступности бесполезны для дизайнеров. Они организованы по номерам критериев успеха WCAG, что соответствует тому, как юрист читает спецификацию, но никак не тому, как создаётся программное обеспечение.
Дизайнеры не открывают Figma, думая о критерии 1.4.3. Они открывают Figma и выбирают цвет текста. Полезный чеклист встречает дизайнера там, где принимается решение, а значит, нужны три отдельных списка: один для файла с макетом, один для браузера, один для периода после запуска. Организуйте его иначе, и он будет проигнорирован.
Что на самом деле требует WCAG 2.2
WCAG 2.2 является актуальным глобальным стандартом на 2026 год и добавляет девять новых критериев успеха поверх WCAG 2.1, в основном сосредоточенных на мобильных устройствах, сенсорных целях, когнитивной нагрузке и аутентификации.
Девять новых критериев, важных для дизайнеров, составляют короткий список. Отображение фокуса становится строже (2.4.11, 2.4.13). Жесты перетаскивания теперь требуют альтернативы без перетаскивания (2.5.7). Сенсорные цели должны иметь минимальный размер 24 на 24 CSS-пикселя, если вокруг них нет достаточного пространства (2.5.8). Требуется единообразное размещение справки на всех страницах (3.2.6). Формы не могут без необходимости запрашивать одну и ту же информацию дважды (3.3.7). Аутентификация не может основываться на когнитивном тесте, например запоминании пароля, без альтернативы (3.3.8, 3.3.9).
AA является уровнем, который требует большинство законов о доступности в мире, включая Европейский акт о доступности ЕС, Section 508 в США и Регламент о доступности для органов государственного сектора в Великобритании. AAA строже и в основном предназначен для государственного управления, здравоохранения и образования.
Чеклист, организованный по номерам разделов WCAG, это спецификация. Чеклист, организованный по месту принятия решений, это инструмент.
Единственный формат чеклиста, который работает
Есть три места, где принимаются решения о доступности. Файл с макетом. Собранный интерфейс в браузере. Производственный сайт после запуска.
Около 70% ошибок доступности — это решения, принятые в Figma, 20% принимаются при разработке, а 10% просачиваются после запуска через изменения контента, сторонние вставки или пользовательский контент. Любой чеклист, который не привязан к этим трём фазам, вынуждает дизайнера переводить с языка спецификаций на язык рабочего процесса, и именно при этом переводе пункты пропускаются.
Остаток этой статьи — три списка по порядку. Выполняйте их по порядку. Всё, что не прошло проверку на этапе проектирования, никогда не должно переходить к этапу разработки. Всё, что не прошло этап разработки, никогда не должно выпускаться.
Чеклист этапа проектирования (что проверять в Figma)
Около 70% ошибок доступности — это решения, принятые в файле с макетом, а значит, их дешевле всего исправить именно там.
| Проверка | Критерий WCAG 2.2 | Как проверить в Figma |
|---|---|---|
| Основной текст имеет контраст не менее 4.5:1 с фоном | 1.4.3 Contrast (Minimum) | Stark, Able или встроенный проверщик контраста Figma |
| Крупный текст (18pt+ или 14pt+ полужирный) имеет контраст 3:1 | 1.4.3 | Те же инструменты |
| Нетекстовые элементы UI (кнопки, рамки, иконки, кольца фокуса) имеют контраст 3:1 | 1.4.11 Non-text Contrast | Вручную проверить пары цветов на холсте |
| Сенсорные цели не менее 24 на 24 CSS-пикселя (рекомендуется 48 на 48) | 2.5.8 Target Size (Minimum) | Измерить размеры фрейма напрямую |
| Информация не передаётся только цветом | 1.4.1 Use of Color | Применить серую шкалу к фрейму (плагин Figma или фильтр скриншота) |
| Каждый фрейм с изображением содержит alt-текст в метаданных слоя | 1.1.1 Non-text Content | Панель доступности Figma или режим разработчика |
| Заголовки используются в логическом порядке (H1, H2, H3, но не H1, H3, H2) | 1.3.1 Info and Relationships | Прочитать дерево заголовков сверху вниз |
| Состояние фокуса разработано для каждого интерактивного элемента | 2.4.7 Focus Visible, 2.4.11 Focus Not Obscured | У каждого интерактивного компонента есть вариант с фокусом |
| Текст ссылки понятен вне контекста | 2.4.4 Link Purpose | Нет меток "нажмите здесь" или "узнать больше" |
| Метки форм видны и не только в виде плейсхолдера | 3.3.2 Labels or Instructions | У каждого поля есть постоянная метка вне поля ввода |
Файл с макетом — это также место, где вы выявляете новые мобильные критерии WCAG 2.2. Сенсорные цели, не соответствующие 2.5.8, почти всегда проваливаются потому, что дизайнер думал в пикселях для десктопа, а цель представляет собой иконку в 16 пикселей без отступов.
Для более детального погружения в тему контраста смотрите правила контраста и APCA. Цветовая работа на этапе проектирования — это место, где большинство сайтов проигрывают аудит до того, как написана хоть одна строка кода.
Чеклист этапа разработки (что проверять в браузере)
Браузер — это место, где решения в области доступности подтверждаются или обнажаются, потому что именно здесь вспомогательные технологии впервые соприкасаются с вашей работой.
| Проверка | Критерий WCAG 2.2 | Как проверить в браузере |
|---|---|---|
| Каждая страница работает только с клавиатурой (tab, shift-tab, enter, пробел, стрелки) | 2.1.1 Keyboard | Отключите мышь и навигируйте по странице |
| Порядок фокуса соответствует визуальному порядку (слева направо, сверху вниз для LTR) | 2.4.3 Focus Order | Пройдите по tab и следите за кольцом фокуса |
| Фокус никогда не скрыт за фиксированными заголовками, баннерами куки или модальными окнами | 2.4.11 Focus Not Obscured (Minimum) | Прокручивайте, нажимая tab, для подтверждения видимости |
| Взаимодействия с перетаскиванием имеют альтернативу через клик или касание | 2.5.7 Dragging Movements | Проверьте слайдеры, сортируемые списки, карусели |
| Ссылка "перейти к содержимому" появляется при первом нажатии tab | 2.4.1 Bypass Blocks | Нажмите tab один раз при загрузке страницы |
| Используются HTML-ориентиры (header, nav, main, footer, aside) | 1.3.1, 4.1.2 | Проверьте структуру DOM |
| Ошибки форм озвучиваются, а не только выделяются цветом | 3.3.1, 3.3.3, 4.1.3 | Отправьте неверную форму с включённым скринридером |
| Скринридер правильно объявляет заголовки, списки и кнопки | 4.1.2 Name, Role, Value | NVDA на Windows, VoiceOver на Mac, TalkBack на Android |
| Атрибуты autocomplete установлены для полей персональных данных | 1.3.5 Identify Input Purpose | Проверьте autocomplete на полях имени, email, адреса |
| У медиа есть субтитры, транскрипты или звуковые описания | 1.2.1 to 1.2.5 | Воспроизведите каждое видео, проверьте дорожки |
Автоматические инструменты выявляют около 30% этих ошибок. Остальное требует живого человека, нажимающего tab и слушающего скринридер. Оба подхода важны, и ни один не заменяет другой.
Лучший набор инструментов для этапа браузера в 2026 году невелик: axe DevTools для автоматического сканирования, Lighthouse для аудита на уровне страниц и настоящий скринридер для ручной проверки. Три инструмента, десять минут на страницу — выявляет почти всё, что обнаружит реальный аудит.
Чеклист после запуска (что проверять в продакшене)
Доступность не заканчивается с запуском, потому что контент, сторонние вставки и пользовательский контент появляются уже после того, как дизайнер поставил свою подпись.
| Проверка | Критерий WCAG 2.2 | Как проверить в продакшене |
|---|---|---|
| Изображения, созданные в CMS, имеют alt-текст, обязательный на уровне редактора | 1.1.1 | Протестируйте CMS: может ли автор опубликовать без alt? |
| Встроенные сторонние виджеты (чат, карты, формы) доступны | Varies | Запустите axe на страницах со вставками |
| Загружаемые PDF и документы размечены и читаемы | 1.1.1, 1.3.1, 2.4.6 | Откройте в проверщике доступности Acrobat |
| Ссылки на справку, поддержку и контакты находятся в одном месте на каждой странице | 3.2.6 Consistent Help (новинка WCAG 2.2) | Визуальный аудит по всем шаблонам |
| Формы не запрашивают избыточную информацию в потоке | 3.3.7 Redundant Entry (новинка WCAG 2.2) | Пройдите через многошаговые формы |
| Аутентификация имеет доступную альтернативу (passkeys, ссылки на email, SSO) | 3.3.8, 3.3.9 Accessible Authentication (новинка WCAG 2.2) | Попробуйте зарегистрироваться и войти с заблокированным менеджером паролей |
| Динамический контент (модальные окна, уведомления, живые регионы) озвучивается | 4.1.3 Status Messages | Вызовите каждый элемент с открытым скринридером |
| Страница продолжает соответствовать правилам контраста и размера целей при масштабировании до 200% | 1.4.4 Resize Text, 1.4.10 Reflow | Увеличьте масштаб браузера до 200% и проверьте |
| Нет автовоспроизведения медиа, или у медиа есть кнопка паузы | 1.4.2 Audio Control, 2.2.2 Pause, Stop, Hide | Загрузите страницу с нуля |
| Баннер с куки не захватывает фокус клавиатуры | 2.1.2 No Keyboard Trap | Перейдите в баннер по tab, затем выйдите из него |
Список после запуска — это место, где большинство команд терпит неудачу. Дизайн был выпущен с соблюдением доступности. Авторы CMS заполняют его неразмеченными PDF, видео с автовоспроизведением и виджетом чата с соотношением контраста 2:1 на его кнопке запуска. Доступность — это свойство системы, а не веха запуска.
Типичные ошибки дизайнеров в привязке к критериям WCAG
Каждая находка аудита доступности восходит к конкретному критерию успеха WCAG, и большинство дизайнеров совершают одни и те же пять ошибок против одних и тех же пяти критериев.
| Ошибка дизайнера | Что это на самом деле | Критерий WCAG 2.2, который она нарушает |
|---|---|---|
| Текст-плейсхолдер как единственная метка | Пользователи теряют метку в момент начала ввода | 3.3.2 Labels or Instructions |
| Кнопки только с иконкой без aria-label или подсказки | Скринридеры объявляют "кнопку" без указания цели | 4.1.2 Name, Role, Value |
| Сообщения об ошибках только с красной рамкой или красным текстом | Пользователи с дальтонизмом не видят ошибки | 1.4.1 Use of Color, 3.3.1 Error Identification |
| Удаление кольца фокуса из эстетических соображений | Пользователи клавиатуры не видят, где они находятся | 2.4.7 Focus Visible |
| Сенсорные цели менее 24 на 24 пикселя без отступов | Пользователи мобильных устройств постоянно промахиваются | 2.5.8 Target Size (Minimum) |
| Низкий контраст в "тонком" UI (текст-плейсхолдер, отключённые состояния, вспомогательный текст) | Читатели на солнечном свету или с нарушениями зрения не могут это прочитать | 1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast |
| Модальное окно, захватывающее фокус, но без закрытия по ESC | Пользователи клавиатуры застревают в модальном окне | 2.1.2 No Keyboard Trap |
| Карусели с навигацией только через перетаскивание | Пользователи с нарушениями моторики не могут перелистывать | 2.5.7 Dragging Movements |
| Фиксированный заголовок, скрывающий сфокусированный элемент при нажатии tab | Пользователи видят прокрутку страницы, но теряют позицию | 2.4.11 Focus Not Obscured |
| Вход только по паролю, без SSO или ссылки на email | Сбой из-за когнитивной нагрузки | 3.3.8 Accessible Authentication |
Те же десять ошибок составляют большинство каждого отчёта об аудите. Исправьте их, и вы пройдёте 80% пути к WCAG 2.2 AA ещё до того, как какой-либо консультант откроет таблицу.
Основы доступности также связаны с остальной частью хорошей визуальной иерархии. Контраст, размер цели и состояния фокуса — это решения иерархии. Дизайн, отточенный в плане иерархии, по умолчанию выполняет большую часть чеклиста доступности, именно поэтому пересечение между хорошей теорией цвета и доступным дизайном практически полное.
Как пройти чеклист без потери недели
Чеклист полезен, только если его прохождение занимает минуты, а не дни, а значит, инструменты должны выполнять большую часть работы.
Рабочий ритм: три прохода, по одному на каждую фазу, каждый выполняется в момент, когда работа достигает этой фазы. Не все три в конце. Не один из них в конце. Три отдельных прохода, каждый недорогой, каждый обеспечивается инструментами там, где это возможно.
- Проход на этапе проектирования: 10 минут на экран. Stark или проверщик контраста Figma для каждой пары текста, применение серой шкалы к фрейму для проверки цветовой информации, измерение каждой сенсорной цели. Делайте это до передачи, а не во время проверки.
- Проход на этапе разработки: 10 минут на шаблон. Сканирование axe DevTools, тест навигации только с клавиатурой, один проход со скринридером на наиболее посещаемых страницах. Интегрируйте axe-core в CI, чтобы новый код не мог быть слит с регрессиями.
- Проход после запуска: ежемесячно, а не при каждом релизе. Полное сканирование сайта через axe или pa11y в продакшене, аудит PDF в любой библиотеке документов, ручной обход форм и потоков аутентификации.
Это полдня работы в месяц на продукт и примерно 15 минут на передачу дизайна. Всё, что занимает больше этого, и команда перестанет это делать. Всё, что меньше, и аудиты возвращаются неисправленными.
FAQ
Является ли WCAG 2.2 обязательным требованием по закону?
Да, в большинстве крупных рынков. Европейский акт о доступности вступил в силу в июне 2025 года и ссылается на WCAG 2.1 как минимум, при этом 2.2 является текущим рабочим стандартом. Section 508 в США ссылается на WCAG 2.0, но контракты на закупки всё чаще требуют 2.2. Канада, Великобритания, Австралия и Япония имеют аналогичные требования, привязанные к WCAG 2.1 или 2.2. Если вы поставляете продукт на любой из этих рынков, WCAG 2.2 AA является безопасной целью.
Какие новые критерии WCAG 2.2 действительно нужно знать?
Четыре из них наиболее важны для дизайнеров. 2.5.7 Dragging Movements требует альтернативы без перетаскивания для drag-взаимодействий. 2.5.8 Target Size (Minimum) требует, чтобы сенсорные цели составляли не менее 24 на 24 CSS-пикселя при достаточном расстоянии между ними. 2.4.11 Focus Not Obscured требует, чтобы сфокусированный элемент оставался видимым при прокрутке и через фиксированные оверлеи. 3.3.8 Accessible Authentication запрещает когнитивные тесты, например запоминание пароля, без альтернативы (SSO, passkey или ссылка на email).
Нужен ли мне отдельный чеклист для мобильных устройств?
Нет. WCAG 2.2 явно написан для охвата мобильных и сенсорных устройств, именно поэтому так много его новых критериев (размер цели, перетаскивание, фокус) учитывают мобильные особенности. Тот же трёхфазный чеклист работает для мобильного веба и адаптивного дизайна. Нативные приложения имеют дополнительные платформенные рекомендации (Apple HIG и Android Accessibility), но правила WCAG по-прежнему применяются.
Каков минимальный размер сенсорной цели в WCAG 2.2?
24 на 24 CSS-пикселя — минимум согласно 2.5.8 Target Size (Minimum), но есть исключения, если вокруг целей достаточно пространства или они встроены в текст. Практическая цель, к которой должно стремиться большинство дизайнеров, — 48 на 48 CSS-пикселей, что соответствует рекомендациям платформ Apple и Google и позволяет избежать граничных случаев в спецификации WCAG.
Запускайте чеклист, а не угадайку
Доступность — это не задача соответствия требованиям. Это свойство дизайна, формируемое в три момента, обеспечиваемое инструментами, проверяемое людьми.
Команды, которые создают доступные сайты без боли, — это не те, у кого лучшие аудиторы. Это те, кто перенёс проверки в фазу проектирования, фазу разработки и фазу запуска и не позволял работе продвигаться дальше ни одной из них при наличии известных ошибок.
Запускайте три списка. Выявляйте десять типичных ошибок до того, как они накапливаются. Автоматизируйте сканирование на этапе браузера в CI. Ежемесячно проверяйте дрейф после запуска. WCAG 2.2 AA перестаёт быть финишной чертой и становится свойством того, как работает команда.
Выберите сегодня один продуктовый экран вашего сайта. Запустите чеклист этапа проектирования для его файла в Figma. Подсчитайте исправления. Это число — цена того, что вы не делали это раньше.
Запускайте чеклист, а не угадайку.
Need a site that passes WCAG 2.2 without a three-month remediation cycle? Brainy ships accessible design from the first Figma frame.
Get Started
