Как сделать сайт доступным: стартовое руководство по WCAG 2.2

Чтобы сделать сайт доступным, создайте его так, чтобы им могли пользоваться с клавиатуры, программой чтения с экрана, при масштабировании или с переключающим устройством, а не только мышью: используйте настоящие HTML-элементы для кнопок, ссылок, заголовков и подписей полей, давайте изображениям осмысленный alt-текст, сохраняйте высокий контраст текста и делайте фокус видимым. Ориентир — WCAG 2.2 уровня AA. Автоматические проверки находят часть проблем; десятиминутный тест с клавиатурой и программой чтения с экрана находит много из остального.

Что означает «доступный» на практике

Доступность — про людей: слепой пользователь с программой чтения с экрана, человек с тремором, который навигирует с клавиатуры, человек с плохим зрением, который увеличивает страницу до 200%, человек, читающий на ярком солнце, или тот, у кого временно сломана рука. Хорошая доступность обычно делает сайт лучше для всех: понятная структура, читаемый текст, формы, которые объясняют свои ошибки.

Эталонный стандарт — Web Content Accessibility Guidelines (WCAG) от W3C. По состоянию на сентябрь 2026 года текущая версия — WCAG 2.2 (опубликована в октябре 2023 года, обновлена в декабре 2024); WCAG 3 — ранний черновик. WCAG строится вокруг четырёх принципов — контент должен быть воспринимаемым, управляемым, понятным и надёжным — и имеет три уровня соответствия:

Законы в нескольких странах ссылаются на WCAG — например, Европейский акт о доступности, который с июня 2025 года применяется ко многим цифровым сервисам для потребителей в ЕС. Какие правила применяются к вам, зависит от того, где вы работаете и что продаёте; если не уверены, проконсультируйтесь со специалистом. Это руководство описывает практическую работу.

Варианты: как к этому прийти

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

Исправления, которые важнее всего

Используйте правильные HTML-элементы

Большая часть доступности достаётся бесплатно при правильном HTML. <button> можно фокусировать, он работает с Enter и пробелом и объявляется как кнопка. <div> с обработчиком клика не делает ничего из этого. Код, сгенерированный ИИ, иногда использует стилизованные div для всего; просите семантические элементы:

• <button> для действий, <a href> для навигации
• Один <h1> на страницу, затем <h2>, <h3> по порядку — пользователи программ чтения с экрана перемещаются между заголовками
• Ориентиры: <header>, <nav>, <main>, <footer>
• <label>, связанный с каждым полем формы
• Язык страницы в <html lang="ru">

Используйте атрибуты ARIA только тогда, когда нативный элемент не подходит — например, для собственного набора вкладок или комбобокса. Неправильный ARIA хуже его отсутствия.

Доступ с клавиатуры и видимый фокус

Всё, что можно сделать мышью, должно работать только с клавиатуры (WCAG 2.1.1). Нажмите Tab по странице: каждая ссылка, кнопка и поле должны быть доступны в логичном порядке, и вы всегда должны видеть, где фокус (2.4.7 Focus Visible). В WCAG 2.2 добавлено, что сфокусированный элемент не должен полностью скрываться за липкими заголовками или баннерами cookie (2.4.11, уровень AA).

Частые ошибки: меню, которые открываются только при наведении, модальные окна, которые не удерживают фокус или не закрываются по Escape, и outline: none в CSS без замены.

Текстовые альтернативы

Каждому значимому изображению нужен alt-текст, который описывает, что на нём показано в контексте («Шеф сервирует дегустационное меню», а не «image1.jpg»). Декоративные изображения получают пустой alt="", чтобы программы чтения их пропускали. Кнопкам только с иконкой нужно доступное имя («Закрыть», «Поиск»). Видео нуждаются в субтитрах; аудио — в расшифровке.

Цвет и контраст

WCAG 2.2 AA требует соотношения контраста не меньше 4,5:1 для обычного текста и 3:1 для крупного (1.4.3), а также 3:1 для элементов интерфейса, таких как рамки полей и значимые иконки (1.4.11). Типичные провалы — светло-серый текст в плейсхолдерах и бледные кнопки. Также никогда не передавайте смысл только цветом: красная рамка у неверного поля требует и текста ошибки.

Масштабирование и перекомпоновка

Текст должен оставаться пригодным при увеличении до 200% (1.4.4), а контент должен работать при ширине 320 CSS-пикселей без горизонтальной прокрутки (1.4.10). Правильно выполненная адаптивная вёрстка решает большую часть этого.

Размер целей, формы и ошибки

• Размер цели: WCAG 2.2 AA требует, чтобы цели для указателя были не меньше 24 на 24 CSS-пикселей либо имели достаточный отступ вокруг меньших (2.5.8). Чем крупнее, тем удобнее на телефонах.
• Формы: видимые подписи (не только плейсхолдер), понятные инструкции и тексты ошибок, которые говорят, что не так и как исправить, рядом с полем.
• Вход: не заставляйте людей решать головоломку или переписывать код без альтернативы; разрешайте менеджеры паролей и вставку (3.3.8 Accessible Authentication).

Промпты, которые работают

Построй этот сайт в соответствии с WCAG 2.2 уровня AA: семантические ориентиры HTML, один h1 на страницу с заголовками по порядку, настоящие элементы button и link, подписи у каждого поля формы, видимые стили фокуса, контраст текста не ниже 4,5:1, alt-текст у значимых изображений и alt="" у декоративных, а также html lang.

Проверь страницы /signup и /checkout на доступность. Проверь использование только с клавиатуры, порядок фокуса, видимый фокус, подписи, тексты ошибок, контраст и имена для программ чтения у кнопок-иконок. Перечисли каждую проблему с критерием WCAG, затем исправь их, не меняя визуальный дизайн больше, чем необходимо.

Мобильное меню нельзя использовать с клавиатуры. Сделай его кнопкой с aria-expanded, переноси фокус в меню при открытии, закрывай по Escape и возвращай фокус на кнопку.

Пошагово

1. Запустите автоматическую проверку. Раздел Accessibility в Lighthouse в Chrome DevTools или расширение axe для браузера на каждой основной странице. Исправьте всё, что они сообщают.
2. Отключите мышь. Пройдите Tab по каждой странице и выполните все ключевые задачи — регистрацию, поиск, оформление. Отметьте всё, до чего не можете дотянуться, где не видите фокус или из чего не можете выйти.
3. Увеличьте до 200% и сузьте окно до ширины телефона. Ничего не должно обрезаться или требовать горизонтальной прокрутки.
4. Попробуйте программу чтения с экрана минут десять: VoiceOver на Mac и iPhone, TalkBack на Android или NVDA на Windows (бесплатно). Послушайте заголовки, ссылки и поля формы. «Кнопка» без имени или «ссылка, нажмите здесь» — это работа, которую нужно сделать.
5. Проверьте контраст текста, кнопок и полей инструментом проверки контраста.
6. Исправьте и перепроверьте те же задачи.
7. Опубликуйте заявление о доступности с указанием стандарта, на который вы ориентируетесь, и способом сообщить о проблемах — и отвечайте на такие сообщения.

Частые ошибки

• Полагаться на виджет-оверлей вместо исправления кода.
• Убирать контуры фокуса, потому что они выглядят неаккуратно, без замены.
• Плейсхолдер как единственная подпись. Он исчезает, когда человек начинает печатать, и часто имеет низкий контраст.
• Ссылки «Нажмите здесь» и «Читать далее». Вне контекста пользователь программы чтения слышит список одинаковых ссылок.
• Alt-текст, набитый ключевыми словами. Alt-текст нужен людям; описывайте изображение.
• Проверка один раз. Каждая новая функция может сломать доступ с клавиатуры. Добавьте проход с клавиатурой в свою предзапусковую проверку.

Чек-лист доступности

• Автоматическая проверка (Lighthouse или axe) чистая на основных страницах
• Каждую задачу можно выполнить только с клавиатуры
• Фокус всегда виден и никогда не скрыт липкими элементами
• Семантические заголовки, ориентиры, кнопки и ссылки; задан lang
• Значимый alt-текст; декоративные изображения с alt=""; субтитры у видео
• Контраст текста ≥ 4,5:1 (крупный текст ≥ 3:1); элементы интерфейса ≥ 3:1
• Работает при масштабе 200% и ширине 320 px
• У каждого поля формы видимая подпись и понятные тексты ошибок
• Заявление о доступности со способом сообщить о проблемах

О концепциях, лежащих в основе, читайте что такое веб-доступность. Доступный и хороший дизайн во многом пересекаются; как сделать красивое приложение с ИИ описывает визуальную сторону.

Доступность на Mythex

Mythex строит с тем стандартом, который вы попросите, поэтому укажите «WCAG 2.2 AA» в первом промпте и в последующих. Вы можете использовать рамку превью под размер телефона, чтобы проверить маленькие экраны (Preview and Code), но тесты с клавиатурой, масштабированием и программой чтения лучше всего проводить на опубликованном адресе или превью, открытом в отдельной вкладке. Попросите агента проверить страницу, исправить найденное, а затем протестируйте исправления сами — автоматическая проверка — это начало, а не окончательное подтверждение.

Вопросы