Доступность (accessibility) сайта: как сделать его удобным для всех и сохранить стиль

Доступность (accessibility) - это набор проектных и технических решений, благодаря которым сайт остаётся понятным и управляемым для людей с разными возможностями, устройствами и условиями. Чтобы сделать сайт удобным для всех и не потерять стиль, внедряйте WCAG-практики: семантический HTML, управление фокусом, достаточный контраст, альтернативы контента и регулярный аудит доступности сайта.

Опорные принципы доступного сайта

• Доступность закладывается в дизайн-систему: компоненты сразу имеют состояния фокуса, ошибки и альтернативные представления.
• Семантика важнее визуала: правильные теги и лэндмарки делают интерфейс читаемым для скринридеров и предсказуемым для клавиатуры.
• Клавиатура - обязательный путь: всё интерактивное должно работать без мыши, с видимым фокусом и без ловушек.
• Контент не должен зависеть от одного канала: цвет, звук и анимация всегда дублируются текстом/структурой.
• Тестирование - это процесс: сочетайте авто-проверки, ручные сценарии и периодический accessibility аудит сайта.

Зачем доступность: влияние на бизнес, UX и правовую ответственность

• Шире охват и устойчивый UX. Доступный интерфейс лучше переживает плохой интернет, маленькие экраны, яркое солнце, временные ограничения (сломанная мышь/травма).
• Меньше затрат на поддержку. Предсказуемые формы, понятные ошибки, корректная навигация снижают число обращений и отказов.
• Проще масштабировать дизайн. Когда компоненты изначально доступны, дальнейшая разработка доступного сайта идёт быстрее и стабильнее.
• Снижение рисков. Для ряда организаций и контрактов требования по доступности могут быть обязательными - проверяйте юридический контекст проекта заранее.

Кому подходит. Практически любому публичному сайту, продукту с формами/оплатой/личным кабинетом, сервису с регулярными обновлениями UI.

Когда не стоит делать "идеально" сразу. Если у вас прототип для проверки гипотезы на 1-2 недели - делайте минимум: семантика, фокус, читаемые ошибки, базовый контраст. Полную адаптацию сайта для людей с ограниченными возможностями планируйте итеративно.

Нормативы и критерии оценки: как применять WCAG в реальном проекте

WCAG удобно применять как список проверяемых критериев, привязанный к вашим пользовательским потокам (регистрация, поиск, оплата, настройка профиля). Цель - не "галочки", а отсутствие блокирующих барьеров.

• Определите целевой уровень и охват. Зафиксируйте, какие страницы/функции входят в аудит доступности сайта и какие исключения допустимы (например, сторонний виджет).
• Соберите доступы и артефакты. Нужны дизайн-макеты (Figma), репозиторий/стенд, список ключевых сценариев, доступ к аналитике ошибок (Sentry/Logs), если есть.
• Подготовьте инструменты проверки. Browser DevTools, Lighthouse, axe DevTools, WAVE, Accessibility Tree/Inspector, скринридеры (NVDA/JAWS на Windows, VoiceOver на macOS/iOS), линтеры (eslint-plugin-jsx-a11y), Storybook a11y addon.
• Согласуйте формат результата. Дефекты фиксируйте как: критерий WCAG → шаги воспроизведения → ожидаемое/фактическое → влияние → рекомендация → ссылка на компонент/страницу.
• Решите, что делать руками. Авто-сканеры ловят лишь часть проблем; ручной accessibility аудит сайта обязателен для клавиатуры, фокуса, форм, модалок, каруселей, динамического контента.

Семантика и структура: правильный HTML, лэндармки и компоненты

1. Постройте документный каркас и заголовки. Используйте один главный смысловой заголовок страницы (внутри контента), далее иерархию H2/H3 без пропусков уровней. Это делает навигацию по странице быстрой в скринридерах.
   • Не используйте заголовки ради размера шрифта - размер решает CSS.
   • Проверяйте outline в DevTools/плагинах для структуры.
2. Добавьте лэндмарки (landmarks) и "пропуск к контенту". Обозначьте области страницы через семантические теги/ARIA: header, nav, main, footer; добавьте ссылку "Перейти к содержимому" в начале DOM, видимую на фокусе.
   • Если лэндмарков несколько (например, два nav), задайте различимые aria-label.
3. Используйте нативные элементы вместо дивов. Кнопка должна быть button, ссылка - a, поле - input/textarea, список - ul/ol. Нативные элементы сразу дают клавиатуру, роли и состояния.
   • Избегайте role="button" на div: это почти всегда источник багов фокуса и событий.
4. Сделайте формы самодостаточными. Каждое поле имеет понятную подпись (label или связанный текст), подсказку (если нужно) и сообщение об ошибке, привязанное к полю через aria-describedby.
   • Не используйте placeholder как единственную подпись: он исчезает и плохо читается.
   • Ошибку формулируйте как действие: "Введите email в формате ...", а не "Неверно".
5. Опишите динамику и статусы. Для уведомлений, загрузок и смены состояния используйте aria-live там, где это оправдано, и не "спамьте" озвучкой. Для модалок задавайте role="dialog", aria-modal="true" и заголовок диалога.
   • Для открывающихся/закрывающихся контролов применяйте aria-expanded и aria-controls.

Быстрый режим

1. Переведите интерактив на нативные элементы (button/a/input) и вычистите div-кнопки.
2. Выстройте заголовки и лэндмарки (header/nav/main/footer) + добавьте "Перейти к содержимому".
3. Пройдите ключевые сценарии только клавиатурой и исправьте фокус/ловушки.
4. Проверьте формы: label, связанная ошибка, понятные сообщения.
5. Запустите авто-проверку (axe/Lighthouse) и закройте критичные замечания.

Клавиатурная навигация и управление фокусом: правила и распространённые ошибки

• Весь интерактив доступен с клавиатуры: Tab/Shift+Tab перемещают фокус по логичному порядку, Enter/Space активируют элементы.
• Фокус всегда видим: не отключайте outline без равнозначной замены; состояние фокуса отличается от hover.
• Нет "ловушек" фокуса: из модалки/меню можно выйти, а при закрытии фокус возвращается в место открытия.
• Порядок фокуса соответствует визуальному порядку (без хаотичных tabindex > 0).
• Скрытые элементы не получают фокус (display:none/hidden/aria-hidden корректны для невидимого контента).
• Раскрывающиеся элементы (select-подобные, аккордеоны) управляются предсказуемо и отражают состояние (aria-expanded).
• После динамических действий (добавили товар, применили фильтр) фокус не "прыгает" в начало страницы без причины.
• Горячие клавиши не конфликтуют с системными и имеют выключатель/настройку, если они глобальные.

Визуальная и аудиальная адаптация: контраст, типографика, альтернативы контента

• Недостаточный контраст текста/иконок/состояний. Проверяйте контраст в Figma-плагинах и DevTools; учитывайте disabled/placeholder/secondary.
• Информация передаётся только цветом. Добавляйте текст, иконку, паттерн, подпись или изменение формы (например, ошибка поля: текст + рамка + сообщение).
• Мелкий кегль и плотные межстрочные интервалы. Держите комфортную читаемость: нормальная высота строки, адекватные отступы, ограничение длины строки в текстовых блоках.
• Потеря структуры при масштабировании. Проверяйте zoom в браузере; избегайте фиксированных высот для контейнеров с текстом.
• Анимации без контроля. Уважайте prefers-reduced-motion; не делайте мигания и агрессивные автопереходы.
• Медиа без альтернатив. У изображений - осмысленный alt (или пустой alt для декоративных), у видео - субтитры/текстовая расшифровка, у аудио - транскрипт.
• Иконки без подписи. Для кнопок-иконок добавляйте aria-label или видимый текст; "лупа" должна быть "Поиск".
• Ссылки неотличимы от текста. Ссылка должна иметь устойчивый признак, не зависящий только от цвета (например, подчёркивание).

Внедрение и тестирование: приоритеты, чек‑лист и инструменты для команды

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

Вариант 1: точечный аудит и закрытие критичных барьеров

• Уместно, если релиз близко и нужны быстрые улучшения без рефакторинга дизайн-системы.
• Пакет: аудит доступности сайта по ключевым сценариям + задачи в трекере с приоритетом P0/P1.
• Инструменты: axe DevTools, Lighthouse, NVDA/VoiceOver, чек-листы клавиатуры, запись воспроизведения (видео) для багрепортов.

Вариант 2: встроить доступность в дизайн-систему и библиотеку компонентов

• Уместно, если много страниц/фич и есть повторяемые компоненты (модалки, меню, табы, формы).
• Действия: "золотые" компоненты с a11y-спеками, примерами использования, тестами и токенами (цвет/фокус/состояния).
• Инструменты: Storybook + a11y addon, unit/интеграционные тесты (Testing Library), eslint-plugin-jsx-a11y.

Вариант 3: регулярный процесс и внешняя экспертиза

• Уместно, если нужна независимая проверка, отчёты для заказчика или вы рассматриваете услуги по доступности сайта.
• Формат: периодический accessibility аудит сайта (например, перед крупными релизами) + обучение команды + ревью макетов.
• Результат: регламент, DoD для задач, шаблоны компонентов, библиотека типовых решений.

Приоритетный чек‑лист для команды (безопасные шаги)

1. Закрыть блокеры: недоступные кнопки/ссылки, модалки без фокус-ловушки, формы без label, отсутствие видимого фокуса.
2. Привести семантику: заголовки, списки, таблицы (где нужно), landmarks, корректные aria-* только по необходимости.
3. Нормализовать состояния компонентов: hover/focus/active/disabled/error, чтобы стиль сохранялся и был предсказуем.
4. Добавить альтернативы: alt для изображений, подписи иконок, субтитры/транскрипты для медиа.
5. Поставить "ворота качества": линтер a11y, быстрый прогон axe, ручная проверка клавиатурой на PR/релиз.

Разбор типичных сложностей и рабочих решений

Как понять, с чего начать, если сайт большой?

Начните с ключевых пользовательских сценариев и шаблонов страниц, затем масштабируйте решения через компоненты. Практика: сначала аудит доступности сайта на 5-10 самых посещаемых/доходных маршрутах.

Можно ли сохранить фирменный стиль и при этом улучшить доступность?

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

Когда нужен внешний accessibility аудит сайта, а когда достаточно внутренних проверок?

Внешняя проверка полезна перед юридически/репутационно значимыми релизами и для независимого отчёта. Внутренние проверки обязательны постоянно: линтеры, Storybook и ручные сценарии клавиатуры.

Что чаще всего ломает доступность в SPA/React/Vue?

Неправильное управление фокусом при роутинге, "див-кнопки", модалки без возврата фокуса и динамические обновления без понятного уведомления. Лечится нативными элементами, едиными компонентами и явными правилами фокуса.

Как корректно подписывать поля, если дизайн без лейблов?

Не прячьте смысл: используйте видимые подписи или "плавающий" label, связанный с input. Placeholder может быть подсказкой, но не заменой label.

Как делать адаптацию сайта для людей с ограниченными возможностями, если есть сторонние виджеты?

Сначала изолируйте риски: оборачивайте виджет понятным контекстом, обеспечьте доступ к альтернативному каналу (например, форма/контакты). Параллельно требуйте a11y-совместимость от поставщика или выбирайте альтернативу.

Что включить в договор/ТЗ на разработку доступного сайта?

Зафиксируйте целевой уровень WCAG, перечень сценариев, требования к клавиатуре/фокусу/формам/модалкам и формат приёмки. Отдельно пропишите ответственность за сторонние компоненты и порядок регресса.