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