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

Выберите маршрут, который нельзя потерять

Не начинайте с тысячи страниц и общего score. Возьмите один путь, критичный для пользователя: найти материал и подписаться, выбрать услугу и отправить заявку, войти и изменить профиль. Запишите страницы, шаги и ожидаемый результат. Проверьте desktop и mobile presentation, потому что WCAG рассматривает вариации responsive page как часть полной страницы. Для первого цикла разумно использовать WCAG 2.2 AA как техническую рамку, но не называйте локальный аудит полной conformance-проверкой: она требует всех применимых критериев и полного охвата.

Создайте журнал с колонками «шаг», «ожидание», «наблюдение», «критерий», «влияние», «исправление», «ретест». Скриншот полезен для цвета, но не доказывает порядок focus. Видео показывает interaction, но не заменяет DOM и accessible name. Для каждого дефекта сохраните минимальное воспроизведение: с какой страницы стартовать, какие клавиши нажать и что происходит. Тогда исправление можно проверить независимо, а спор «мне удобно» превращается в тест.

Проверяемый аудит клавиатуры, контраста и структуры

Таблица ниже — не декларация соответствия, а воспроизводимый первый проход. В колонке «PASS» должно быть наблюдаемое условие. Если пункт неприменим, запишите причину вместо автоматического PASS. После изменения повторите маршрут с начала: исправление одного компонента может изменить focus order или скрыть сообщение об ошибке.

Шаг 1. Пройдите всё клавиатурой

Перезагрузите страницу, не кликайте мышью и нажимайте Tab. Записывайте последовательность focus. Shift+Tab должен вести назад. Enter обычно активирует ссылку и кнопку, Space — кнопку или checkbox, стрелки — элементы составных widgets согласно их модели, Esc — закрывает dismissible layer. Не требуйте от каждого control всех клавиш: сверяйтесь с нативной семантикой или подходящим APG pattern. Критерий прост: функция доступна с клавиатуры, а пользователь понимает текущее положение.

Особое внимание уделите modal, dropdown, tabs, autocomplete и бесконечным спискам. При открытии modal focus должен переходить в осмысленное место, оставаться в активном контексте и возвращаться к вызвавшему элементу после закрытия. Нельзя оставлять пользователя на скрытом фоне или создавать keyboard trap. ARIA role сам по себе не добавляет обработку клавиш: если команда строит custom widget, она реализует и тестирует его interaction contract.

Visible focus должен быть различим на всех фонах и не исчезать через мгновение. Не удаляйте browser outline ради визуальной чистоты без эквивалентной замены. Проверьте sticky header, cookie banner и нижнюю панель: они не должны полностью закрывать focused control. Цвет — не единственный сигнал. Для выбранной вкладки или ошибки добавьте форму, текст, icon с accessible name или другое программно определимое состояние.

Шаг 2. Проверьте контраст и цели

Для обычного текста WCAG 2.2 AA задаёт минимум 4,5:1, для large-scale text — 3:1. Large-scale имеет техническое определение; не называйте любой жирный подзаголовок большим. Проверьте текст на обычном, hover, focus, active, disabled и error backgrounds. Логотип и incidental text имеют исключения, но ссылка, placeholder и подпись поля остаются пользовательским интерфейсом. Не оценивайте контраст «на глаз»: сохраните измеренные foreground, background и результат инструмента.

Для pointer target в WCAG 2.2 AA базовый минимум — 24×24 CSS pixels либо достаточное spacing, если применимо исключение. Это нижняя граница, а не рекомендация делать controls крошечными. Пройдите мобильный маршрут пальцем и проверьте соседние иконки, close, pagination и checkbox. Inline links в тексте имеют особый контекст, но отдельная icon-button должна иметь и достаточную цель, и понятное accessible name.

Увеличьте текст до 200 процентов и проверьте reflow на узком viewport. Не должно исчезать содержание, обрезаться action или требоваться одновременно горизонтальный и вертикальный скролл для обычного текста. Zoom иногда меняет breakpoint, поэтому фиксируйте фактический viewport и browser. Если компонент ломается только с длинным русским label, это не косметика: локализованный текст является реальным состоянием интерфейса.

Шаг 3. Прочитайте структуру без визуального слоя

Откройте heading outline. Один h1 обозначает основную тему страницы, последующие уровни отражают вложенность, а не выбранный размер шрифта. Не обязательно запрещать пропуск любого уровня как автоматическую ошибку, но структура должна быть объяснима. Landmarks main, nav, header, footer и aside помогают переходить между областями; если landmarks несколько, им нужны различимые names. Ссылка «к основному содержанию» должна становиться видимой при focus и действительно переносить к main.

Форма начинается не с красной звёздочки, а с понятного label. Свяжите label и control через нативную HTML-модель, добавьте instruction и программную связь error message. После submit focus или live announcement должен помочь найти проблему, не стирая введённое. Placeholder исчезает при наборе и часто имеет слабый контраст, поэтому он не заменяет устойчивую подпись. Группа radios или checkboxes нуждается в общем вопросе, обычно через fieldset и legend.

Для изображения определите функцию в контексте. Фотография, которая добавляет содержание, получает краткий alt с нужной информацией; диаграмме может понадобиться текстовое объяснение рядом. Декоративный орнамент получает пустой alt, чтобы assistive technology могла его пропустить. Functional image описывает действие, а не внешность пиктограммы. Один и тот же asset может требовать разного alt в разных местах, поэтому автоматическое копирование имени файла непригодно.

Шаг 4. Используйте автоматизацию в правильной роли

Checker хорошо обнаруживает часть отсутствующих names, некоторые контрастные пары, дублированные ID и нарушения структуры. Он не знает, выражает ли alt смысл, логичен ли focus order и можно ли понять сообщение об ошибке. Запускайте автоматические правила в разработке и CI, но сохраняйте ручной маршрут. Новый нулевой список ошибок означает лишь, что выбранный инструмент не нашёл известных ему нарушений в проверенном состоянии.

После изменения accessibility-компонента полезно сверить исправления с бюджетом производительности. Нативная семантика обычно проще custom-реализации и часто требует меньше кода. Не удаляйте label или live region ради меньшего DOM; измеряйте фактическое влияние. Если продукт ещё выбирает web, mobile или bot, полезно проверить ограничения выбранного клиентского канала до размножения недоступного паттерна.

Как назначить приоритет

Если один дефект повторяется в menu, modal и form, не создавайте десять независимых косметических задач. Найдите общий primitive, владельца и тест. Такие проблемы стоит оформить системные дефекты как технический долг с последствиями для пользователя, частотой и областью распространения. Исправление базового компонента должно сопровождаться regression tests и ручным ретестом всех состояний.

Ограничения и практический следующий шаг

Этот аудит не является юридической консультацией и не определяет применимое законодательство. WCAG покрывает широкий набор потребностей, но не все сочетания ограничений и контекстов. Screen reader test одним продуктом не представляет всех пользователей. Для важных сервисов привлекайте специалистов и людей из целевой аудитории, проверяйте реальные assistive technologies и публикуйте понятный канал обратной связи.

Практический следующий шаг: выберите один маршрут из трёх–пяти действий и сегодня пройдите его без мыши. Запишите первый блокирующий дефект, его шаг воспроизведения и ожидаемое поведение. Затем измерьте контраст ключевого текста и проверьте heading outline. Исправьте один общий компонент, повторите маршрут с начала и сохраните результат ретеста. Не увеличивайте scope, пока этот цикл не стал воспроизводимым.

Что читать дальше

• сверить исправления с бюджетом производительности

• проверить ограничения выбранного клиентского канала

• оформить системные дефекты как технический долг