Недоступный сайт не всегда выглядит сломанным. Кнопки могут быть аккуратными, но текст на цветной плашке не читается, фокус клавиатуры исчезает, а сообщение об ошибке формы видно только по красной рамке. Для посетителя, который пользуется клавиатурой, экранным диктором, увеличением или телефоном при ярком свете, такой сайт превращается в набор препятствий. И исправлять их после запуска обычно дороже: решение затрагивает дизайн-систему, шаблоны и компоненты форм.
Доступность стоит включать в требования как проверяемые свойства интерфейса. Не абстрактное «удобство для всех», а конкретные правила: контраст текста, видимое состояние фокуса, логическая последовательность табуляции, подписи полей, текстовые ошибки, альтернативы для нетекстового контента и проверка на реальных устройствах.
Начните с дизайн-системы
Цвет не должен быть единственным носителем смысла. Если обязательное поле отмечено только красным, часть пользователей не поймёт различия; если статус передан только иконкой без подписи, экранный диктор может не сообщить его вовсе. Компоненту нужны текст, форма или иной дополнительный сигнал.
В макетах проверяют контраст обычного текста, ссылок, подписей, кнопок и состояний. Оценивать его на глаз по одному монитору нельзя: оттенок может казаться различимым дизайнеру и исчезать на другом экране. В палитре лучше заранее хранить допустимые пары фона и текста, чтобы результат можно было повторить, а не подбирать цвет для каждого баннера вручную.
Состояние элемента важно не меньше его обычного вида. Кнопка, ссылка и поле существуют не только в покое — у них есть hover, focus, active, disabled, ошибка, загрузка и успешное завершение. Если этих состояний нет на макете, разработчик вынужден додумывать логику, а приёмка видит её уже в коде.
Проверьте сценарий с клавиатуры
Человек должен пройти по сайту без мыши: открыть меню, перейти к основному содержимому, открыть диалог, заполнить форму, закрыть модальное окно и вернуться в предсказуемое место. Порядок фокуса должен совпадать с визуальным порядком и смыслом страницы. Фокус нельзя прятать под декоративный слой или отправлять в фон за открытым окном.
Интерактивный элемент должен быть настоящим элементом управления, а не стилизованным контейнером с обработчиком клика. Нативная кнопка и ссылка уже несут большую часть ожидаемого поведения. Нестандартному компоненту придётся отдельно реализовывать роли, клавиши, состояния и объявления для вспомогательных технологий — это дольше и хрупче.
Формы: подпись, ошибка, подтверждение
У каждого поля должна быть программно связанная видимая подпись. Placeholder её не заменяет: текст исчезает при вводе, может иметь слабый контраст и не всегда правильно объявляется вспомогательными технологиями. Если поле требует формат или пример, подсказку размещают рядом и связывают с элементом формы.
Ошибку нужно сформулировать словами: «Введите номер в указанном формате» полезнее, чем красная граница без пояснения. После отправки фокус переводят к сообщению об ошибке или первому проблемному полю, но не теряют введённые данные. При успехе пользователь должен получить подтверждение, доступное не только визуально, — и параллельно стоит проверить, что заявка действительно создана на стороне сервера.
Контент и медиа
Изображение с информацией требует осмысленного альтернативного текста. Декоративные детали дублировать не нужно, но схему, график или кнопку, которая существует только в виде картинки, без объяснения оставлять нельзя. Видео нуждается в доступной альтернативе для речи и ключевой визуальной информации, если это необходимо для понимания действия.
Редакторам нужны правила, иначе доступность теряется после первой публикации. В шаблоне статьи можно ограничить уровни заголовков, подсказать alt-текст, предупредить о пустой ссылке и не дать вставить таблицу без заголовков. Автоматические проверки полезны, но они не определят, понятен ли смысл изображения и логична ли подпись.
Ошибки, которые находят на приёмке
- Проверяют только цветовую палитру. Контраст важен, но без клавиатурной навигации, подписей и корректных сообщений об ошибке сайт всё равно недоступен для части посетителей.
- Ставят tabindex как способ исправить порядок. Ручная нумерация фокуса быстро ломается после изменения страницы. Сначала выстраивают логический DOM-порядок и нативные элементы, исключения тестируют отдельно.
- Используют placeholder вместо label. После ввода человек теряет подсказку о назначении поля. Видимая подпись остаётся ориентиром и помогает вспомогательным технологиям правильно назвать элемент.
- Считают автопроверку полной приёмкой. Инструмент найдёт часть технических нарушений, но не оценит реальный сценарий, текст ошибки и последовательность действий. Нужна ручная проверка клавиатурой и с разными размерами экрана.
С чего начать со старым сайтом
Переделывать всё сразу не нужно. Разумный порядок: новые компоненты, формы и ключевые сценарии — сразу с требованиями доступности, для существующих разделов — план исправлений. Главное — не добавлять новые нарушения в процессе развития сайта.
Ответственность за доступность распределена между владельцем продукта, дизайнером, разработчиком, редактором и тестировщиком. В требованиях нужно назначить владельцев компонентов и критерии приёмки, иначе задача останется ничьей.
Доступность — это набор решений в компонентах и сценариях, а не финальный декоративный чек-лист. Когда контраст, фокус, формы и контент проверяют до релиза, сайт становится понятнее всем посетителям и проще в поддержке.
Top comments (0)