С чего начать проверку доступности сайта для людей с ограничениями зрения?

Начинайте с быстрых, но показательных проверок: контраст текста и элементов управления, полноценная навигация с клавиатуры (видимый фокус и логичный порядок), корректные alt-тексты у изображений и семантическая структура заголовков (H1–H6 без «скачков»). Эти четыре блока закрывают большую часть проблем для пользователей со слабым зрением и со скринридерами и дают понятный бэклог на доработку.

Как я бы проверял это по шагам (логика и что именно смотреть)

1) Контраст (текст, кнопки, ссылки, состояния)

Что важно: контраст влияет и на слабое зрение, и на чтение на мобильных/при ярком свете. Проверять нужно не только «основной текст», но и все состояния интерфейса.

• Текст к фону: основной текст, вторичный текст, плейсхолдеры, подписи, ошибки/подсказки.
• Интерактивные элементы: кнопки, ссылки, элементы меню, табы, чекбоксы/радиокнопки, иконки (если несут смысл).
• Состояния: hover/active/disabled/focus. Частая проблема — хороший контраст в обычном состоянии и «провал» в hover или disabled.
• Не полагаться только на цвет: например, ошибка должна быть видна не только красным, но и текстом/иконкой/подчёркиванием/рамкой.

Ориентиры по WCAG: для обычного текста — контраст не ниже 4.5:1, для крупного текста (примерно 18pt или 14pt жирным) — 3:1. Для графических объектов и компонентов интерфейса (границы полей, иконки, контролы) обычно целятся минимум в 3:1.

2) Клавиатура и фокус (самая быстрая проверка, даёт много находок)

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

1. Tab по странице: пройти шапку → меню → поиск → контент → формы → подвал. Нельзя «застревать» в компонентах и нельзя «прыгать» хаотично.
2. Видимый фокус: у каждого фокусируемого элемента должен быть чёткий outline/подсветка. Нельзя просто отключать outline без замены на свой стиль.
3. Логичный порядок фокуса: он должен соответствовать визуальному и смысловому порядку (обычно DOM-порядок). Частая проблема — элементы визуально слева направо, а фокус идёт «змейкой» из‑за перестроения блоков CSS.
4. Управление компонентами: выпадающие меню, модальные окна, слайдеры, табы — должны открываться/закрываться с клавиатуры, а фокус должен переводиться внутрь модалки и возвращаться назад после закрытия.
5. Skip link: ссылка «Перейти к содержимому» в начале страницы сильно ускоряет навигацию со скринридером и клавиатуры.

Риск: кастомные компоненты (select, dropdown, datepicker) чаще всего ломают клавиатуру и фокус. Их надо проверять отдельно и не «допиливать по месту», а приводить к устойчивому паттерну.

3) Alt-тексты и изображения (разделяем декоративное и смысловое)

Что важно: alt — это не SEO-описание картинки, а смысл для тех, кто её не видит. Правильный alt снижает шум в скринридере и помогает понять контент.

• Смысловые изображения: alt должен кратко передавать смысл (что пользователь должен понять). Пример: не «картинка товара», а «Кроссовки модель X, чёрные».
• Декоративные изображения: alt должен быть пустым (alt=""), чтобы скринридер их пропускал.
• Иконки-кнопки: если кнопка без текста (например, лупа), ей нужен доступный текст через aria-label/текст внутри, а не alt у фоновой иконки.
• Изображения-ссылки: alt должен описывать действие/назначение ссылки, а не просто картинку.
• Сложные изображения (графики): нужен текстовый эквивалент рядом (описание выводов/таблица), одного alt обычно недостаточно.

4) Заголовки и структура (читаемость и навигация для скринридера)

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

• Один H1 на страницу: отражает основной смысл страницы.
• Иерархия без скачков: H2 внутри страницы, H3 как подраздел H2 и т. д. (не переходить H2 → H4 без причины).
• Не использовать заголовки ради размера шрифта: визуальный стиль делается CSS, а H-теги — только для структуры.
• Секции и однотипные блоки: карточки, списки услуг, FAQ — должны иметь логичные подзаголовки, чтобы по ним можно было ориентироваться.

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

1. Выберите 5–7 ключевых шаблонов страниц: главная, каталог/листинг, карточка товара/услуги, статья, страница с формой (регистрация/оплата/заявка), личный кабинет, поиск/результаты.
2. На каждом шаблоне прогоните 4 проверки: контраст → Tab-навигация и фокус → изображения/alt → заголовки.
3. Соберите бэклог в формате «проблема → где → риск → как проверить после фикса»: так разработчикам проще внедрять и не ломать снова.
4. Закрепите правила в дизайн-системе/компонентах: один раз на уровне компонентов (кнопки, поля, модалки) — и дальше масштабируется на весь сайт.

Типичные ошибки, которые я вижу чаще всего

• Контраст проверили только для текста, но забыли про кнопки, бордеры полей, плейсхолдеры и фокус-состояния.
• Спрятали outline, потому что «некрасиво», и не сделали альтернативный видимый фокус.
• Alt пишут всем подряд, включая декоративные картинки, из‑за чего скринридер начинает «болтать лишнее».
• Заголовки используют для дизайна, ломая иерархию (несколько H1, скачки уровней).
• Кастомные селекты/модалки без корректного фокуса — пользователь не может закрыть окно или теряет место на странице.

Если хотите, я могу предложить короткий чек-лист на один лист для вашей команды (дизайн + фронт) и минимальный набор критериев приёмки задач по доступности, чтобы это стало частью процесса, а не разовой проверкой.