Доступность сайта по WCAG 2.2: практический чек-лист для бизнеса

Доступный сайт позволяет людям с разными особенностями зрения, слуха, моторики и восприятия понимать контент и выполнять важные действия. Это не отдельная «версия для людей с инвалидностью» и не панель, которая мгновенно исправляет интерфейс. Доступность закладывается в структуру, дизайн, тексты, компоненты и код.

Для бизнеса это означает меньше барьеров в заявках и покупках, понятный интерфейс для более широкой аудитории и меньшую стоимость последующих доработок. Если требования включить в UI/UX-дизайн или редизайн, контраст, фокус, формы и поведение компонентов можно решить системно до запуска.

Этот материал не является сертификатом соответствия или юридической консультацией для конкретной страны. Он помогает подготовить продукт к глубокому аудиту и расставить приоритеты среди распространенных проблем.

Что такое WCAG 2.2

Web Content Accessibility Guidelines разработаны в рамках W3C Web Accessibility Initiative. WCAG 2.2 объединяет проверяемые критерии вокруг четырех принципов:

1. Воспринимаемость — информация доступна не только одним способом.
2. Управляемость — интерфейс работает с разными методами ввода.
3. Понятность — содержание и поведение элементов предсказуемы.
4. Надежность — разметка корректно взаимодействует с браузерами и вспомогательными технологиями.

Критерии имеют уровни A, AA и AAA. Уровни A и AA часто используют как практический ориентир, но целевой уровень определяется договором, аудиторией, рисками продукта и актуальными правилами конкретной юрисдикции.

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

Кому помогает доступный дизайн

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

Многие решения полезны всем:

• субтитры позволяют смотреть видео без звука;
• высокий контраст улучшает чтение на улице;
• содержательные заголовки ускоряют просмотр;
• видимый фокус показывает текущую позицию;
• понятные ошибки помогают завершить форму;
• крупные цели уменьшают случайные нажатия;
• семантический HTML упрощает поддержку.

Определите объем до начала исправлений

Не начинайте со случайной замены цвета. Составьте список шаблонов и критических маршрутов:

• главная;
• услуга или категория;
• статья;
• поиск и фильтры;
• карточка товара;
• корзина и checkout;
• форма обращения;
• вход, регистрация и восстановление пароля;
• политики и документы;
• 404 и системные состояния.

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

Для большого продукта начните со структурированного UX-аудита сайта и добавьте доступность как отдельное направление. Это не позволит исправлять одну кнопку, когда ошибка повторяется во всей библиотеке компонентов.

1. Проверьте структуру документа

Заголовки должны описывать логику материала, а не просто создавать крупный текст. Странице нужен понятный основной заголовок и последовательные подразделы. Не выбирайте H3 из-за размера шрифта — визуальное оформление задается CSS.

Проверьте:

• описывает ли <title> содержание страницы;
• правильно ли указана основная языковая версия;
• есть ли четкий главный заголовок;
• соответствуют ли уровни логике контента;
• осмысленно ли используются header, nav, main, aside, footer;
• размечены ли списки, таблицы и цитаты подходящими элементами;
• совпадает ли порядок чтения DOM с визуальной последовательностью.

Отключите CSS или изучите дерево доступности. Если смысл разрушается, визуальная сетка скрывает структурную проблему.

2. Добавьте полезные текстовые альтернативы

Alt-текст передает функцию или информацию значимого изображения. Он не должен копировать имя файла или механически начинаться со слов «изображение». Формулировка зависит от контекста.

Примеры:

• товар: Бежевое льняное кресло с деревянными ножками;
• график: передайте вывод и добавьте данные рядом;
• кнопка-иконка: доступное название «Открыть поиск»;
• декоративная текстура: пустой alt="", чтобы скринридер ее пропустил.

Не повторяйте без необходимости одинаковую информацию в alt, подписи и соседнем абзаце. Сложному графику нужен содержательный текстовый эквивалент, а не только «график продаж».

3. Измерьте контраст и не полагайтесь только на цвет

На уровне AA WCAG 2.2 обычному тексту, как правило, нужен контраст не менее 4,5:1, крупному — 3:1. Важные границы контролов, иконки и графические элементы также должны оставаться различимыми согласно применимому критерию.

Не оценивайте контраст на глаз. Измеряйте сочетания в состояниях normal, hover, focus, disabled и error. Текст поверх фотографии должен быть читаемым в самой слабой области или иметь стабильную подложку.

Цвет не может быть единственным сигналом. Красная рамка без текста «Введите номер телефона» не объясняет ошибку. Зеленый и красный статусы дополняйте подписью, формой, иконкой или паттерном.

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

4. Пройдите сайт только с клавиатурой

Отложите мышь и используйте Tab, Shift+Tab, Enter, Space, стрелки и Escape. Каждый интерактивный элемент должен получать фокус, следовать логичному порядку и не создавать ловушку.

Проверьте:

• меню, ссылки и кнопки;
• вкладки и аккордеоны;
• слайдеры и модальные окна;
• подсказки и кастомные select;
• календари, фильтры и автодополнение;
• загрузку файлов;
• медиаплеер;
• корзину и оплату;
• cookie-баннер.

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

5. Сохраните видимый фокус

outline: none без качественной замены делает клавиатурную навигацию почти невидимой. Фокус должен отличаться от обычного и hover-состояния, не обрезаться контейнером и не скрываться под sticky header, cookie-баннером или плавающей кнопкой.

Проектируйте focus-состояния для всех компонентов в дизайн-системе. После динамической операции проверяйте, переходит ли фокус к важному сообщению или следующему логичному шагу.

6. Сделайте ссылки и кнопки понятными

«Нажмите здесь» теряет смысл вне абзаца. Лучше: «Скачать прайс в PDF», «Посмотреть кейсы» или «Прочитать условия доставки». Пользователь скринридера может просматривать список ссылок отдельно.

Кнопка выполняет действие, ссылка переводит в другое место. Не стилизуйте <div> под кнопку, когда нативный <button> уже имеет ожидаемую семантику и клавиатурное поведение.

Иконке без текста нужно доступное название. Декоративную иконку внутри кнопки с понятной подписью не следует озвучивать повторно.

7. Обеспечьте удобный размер целей

В WCAG 2.2 есть критерий минимальной цели 24×24 CSS-пикселя с исключениями, включая достаточное расстояние. В мобильных сценариях важные кнопки часто стоит делать крупнее, особенно в меню, checkout и формах.

Оценивайте активную область, а не только видимую иконку. Padding может увеличить цель. Проверьте крестики, пагинацию, варианты товара, стрелки и элементы количества.

В руководстве по адаптивному дизайну и мобильному UX подробнее разобраны breakpoints, экранная клавиатура, ориентация и реальные touch-сценарии.

8. Разрешите масштабирование и изменение текста

Не блокируйте pinch-to-zoom через viewport. Проверьте страницу при масштабе 200% и узкой ширине. Основной контент и функции не должны исчезать, накладываться или требовать горизонтального скролла, кроме обоснованных исключений вроде широкой таблицы.

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

9. Создайте доступные формы

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

Проверьте:

• логичный порядок;
• типы email, tel и number;
• autocomplete;
• обязательность, обозначенную не только цветом;
• подсказку о формате до ошибки;
• сообщение рядом с полем;
• сводку ошибок для длинной формы;
• сохранение правильных данных;
• переход фокуса к важной ошибке;
• доступный статус успеха;
• достаточное время при ограниченной сессии.

Не заставляйте пользователя угадывать формат. Покажите пример и принимайте привычный ввод, где это возможно. Формы сторонних плагинов проверяйте в итоговом HTML, а не только в редакторе.

10. Добавьте субтитры, транскрипты и управление медиа

Предварительно записанному видео со звуком нужны синхронизированные субтитры согласно применимым критериям. Важная визуальная информация может требовать аудиоописания или текстовой альтернативы. Аудиоматериалу полезен транскрипт.

Автоматические субтитры необходимо вычитать: названия, числа и термины часто распознаются неверно. Плеер должен работать с клавиатуры, иметь доступные названия элементов и не запускать звук неожиданно.

Избегайте опасного мигания. Интерфейс с активной анимацией должен учитывать prefers-reduced-motion, особенно для параллакса, крупных переходов и автоматических каруселей.

11. Пишите понятный контент

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

Полезные правила:

• ставьте главное в начало;
• используйте короткие абзацы и описательные подзаголовки;
• расшифровывайте редкие сокращения;
• конкретно называйте следующий шаг;
• не опирайтесь только на направление или цвет;
• показывайте условия до действия;
• объясняйте способ исправить ошибку;
• сохраняйте одинаковые названия в меню, заголовке и кнопке.

Понятный язык поддерживает и SEO-продвижение: страница точнее отвечает на запрос, а структура упрощает навигацию людям и поисковым системам.

12. Используйте ARIA осторожно

ARIA описывает сложные компоненты, но не исправляет плохую основу. Сначала выбирайте нативный HTML. <button> надежнее, чем <div role="button">, для которого приходится вручную создавать фокус, клавиши и состояния.

Проверьте:

• доступное название;
• роль;
• состояния expanded, selected, checked, invalid;
• связь поля с подсказкой и ошибкой;
• озвучивание динамических статусов;
• соответствие видимого текста доступному имени.

Неверное или избыточное ARIA ухудшает интерфейс. Изучайте дерево доступности и результат в скринридере.

13. Тестируйте динамические компоненты

Фильтры, корзина, SPA и диалоги обновляют экран без полной перезагрузки. Зрячий пользователь видит изменение, а вспомогательная технология может не получить уведомление.

После действия проверьте:

• озвучивается ли количество результатов;
• подтверждается ли добавление товара;
• сохраняется ли осмысленный фокус;
• можно ли закрыть диалог;
• есть ли текстовый статус загрузки;
• объясняет ли ошибка API следующий шаг;
• есть ли альтернатива бесконечному скроллу;
• можно ли выполнить drag-and-drop другим способом.

При разработке сайта эти состояния нужно включать в требования к компонентам и приемочные критерии, а не обнаруживать случайно перед релизом.

14. Включите документы и внешние сервисы

Доступный сайт может вести на недоступный PDF, оплату, карту, чат или бронирование. Включите сторонние сервисы в сквозной сценарий, даже если команда не контролирует их код.

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

Запросите у поставщика сведения о клавиатуре, скринридерах, отчете доступности и известных ограничениях. Фразы «соответствует WCAG» без версии, уровня и области проверки недостаточно.

15. Совмещайте автоматическую и ручную проверку

Сканер полезен для поиска отсутствующих alt, неверных ролей, части проблем контраста, пустых контролов, повторяющихся id и базовых ошибок структуры. Он не определит качество alt, логичность фокуса, понятность инструкции и удобство диалога.

Практический цикл:

1. просканируйте репрезентативные шаблоны;
2. пройдите критические сценарии только клавиатурой;
3. проверьте масштаб 200% и узкую ширину;
4. измерьте визуальные состояния;
5. изучите дерево доступности;
6. протестируйте основные маршруты скринридером;
7. привлеките пользователей с разными потребностями, если масштаб и риск это оправдывают;
8. повторите тест после исправлений.

Коды ответа, редиректы и общую техническую диагностику можно дополнительно проверить через инструменты BB STUDIO, но они не заменяют аудит доступности.

Расставьте приоритеты по влиянию

Не создавайте плоский список из ста одинаково срочных замечаний. Оценивайте влияние, частоту, охват и стоимость исправления.

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

После запуска включите регрессионные проверки в техническую поддержку сайта. Новый баннер, плагин или материал может вернуть устраненные барьеры.

Чек-лист перед запуском

Контент и структура

• Язык и title страниц указаны правильно.
• Заголовки образуют логичную иерархию.
• Списки, таблицы и области семантически размечены.
• Значимые изображения имеют подходящие альтернативы.
• Декоративные изображения не создают шум.
• Ссылки понятны самостоятельно.

Визуальный дизайн

• Контраст текста и компонентов измерен.
• Цвет не является единственным сигналом.
• Фокус виден на интерактивных элементах.
• Контент сохраняется при масштабе 200%.
• Нет необоснованного горизонтального скролла.
• Touch-цели достаточно крупные и разнесены.

Взаимодействие

• Критические сценарии работают с клавиатуры.
• Ловушки фокуса отсутствуют.
• Диалоги правильно управляют фокусом.
• Динамические статусы озвучиваются.
• Движение можно уменьшить.
• Ограничение времени можно продлить там, где требуется.

Формы и медиа

• Поля имеют постоянные label и инструкции.
• Ошибки объясняют проблему и исправление.
• Статус отправки доступен без визуальной догадки.
• У видео есть необходимые субтитры и альтернативы.
• Плеер работает с клавиатуры.
• Документы доступны или имеют HTML-альтернативу.

Процесс

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

Когда достаточно исправлений, а когда нужен редизайн

Точечные правки подходят, если структура логична, компоненты последовательны, а проблемы сосредоточены в цветах, названиях, фокусе и разметке. Редизайн эффективнее при хаотичной иерархии, зависимости важных сценариев от hover или drag-and-drop, отсутствии дизайн-системы и разном поведении каждого шаблона.

Посмотрите портфолио BB STUDIO, чтобы оценить подход к структуре и адаптивным сценариям. Для плана исправлений конкретного продукта отправьте сайт на предварительную оценку вместе со списком приоритетных страниц и задач.

Вывод

Доступность — качество всего продукта, а не отдельная панель. Она начинается с логичного контента, продолжается в дизайн-системе и реализации, подтверждается ручным тестированием и поддерживается после каждого релиза.

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