Контрастность WCAG: где интерфейс перестаёт читаться
Низкая контрастность интерфейса почти никогда не видна в макете — она проявляется на реальных экранах и при реальном освещении. Типовые места одни и те же: серые подписи под полями ввода, текст тонкого начертания мелким кеглем, полупрозрачные подложки поверх фотографий, неактивные и наведённые состояния кнопок, подсказки и сообщения об ошибках в формах.
Формально контрастность WCAG измеряется отношением яркости текста и фона: для обычного текста нужно 4,5:1, для крупного — 3:1, для границ полей и иконок в элементах управления — тоже 3:1. Сложность в том, что проверка контраста текста по статичному макету врёт: если под надписью лежит изображение, градиент или полупрозрачный слой, фон под конкретными символами оказывается светлее, чем в среднем по блоку.
Дальше включается цена. Нечитаемый текст на сайте — это не вопрос эстетики: пользователь не понимает, что вводить в поле, не видит, где именно ошибка, не находит ссылку на восстановление доступа. Он либо уходит, либо пишет в поддержку, и обратная связь превращается в поток однотипных вопросов вместо данных о продукте. На мобильном, на солнце, при слабом зрении или сниженной яркости экрана запас читаемости расходуется первым.
Доступность интерфейса здесь — не галочка в отчёте, а требование к системе стилей: токены цвета, состояния компонентов, правила переопределения под конкретных потребителей. Разбираем, где именно интерфейс перестаёт читаться и как это закрывается так, чтобы правило работало на всех новых экранах, а не правилось вручную в каждом.
Читаемость, масштабирование текста и охват аудитории
Контраст основного текста ниже порога 4.5:1 — это не вопрос вкуса. При таком соотношении подписи полей, подсказки и сообщения об ошибке сливаются с фоном для людей с ослабленным зрением и для тех, кто читает с телефона в ярком помещении. Приведение пар «текст — фон» к 4.5:1, а крупного текста и элементов управления к 3:1 убирает целый класс отказов, при котором человек физически не может завершить сценарий.
Масштабирование шрифта — вторая половина задачи. Макет на относительных единицах выдерживает системное увеличение до 200% без горизонтальной прокрутки, обрезанных подписей и наезжающих друг на друга блоков. Абсолютные значения в пикселях такую проверку не проходят, и пользователь, которому нужен крупный текст, уходит, хотя пришёл по делу.
На формах эффект заметен быстрее всего. Когда подписи контрастны, границы полей различимы, а ошибка показана не только цветом, но и текстом рядом с полем, доля брошенных заявок падает: человек видит, что от него требуется и что заполнено неверно.
Обращения в поддержку вида «не вижу кнопку», «текст сливается» уходят как класс — причина была не в логике, а в читаемости. Освободившееся время команда тратит на развитие сценариев, а не на подсказки, где находится кнопка оплаты.
Отдельный выигрыш — охват аудитории. Читаемый интерфейс одинаково работает для пользователей с нарушениями зрения, для тех, кто заходит с телефона на улице, и для старшей возрастной группы, которая увеличивает шрифт в браузере.
Способы привести контрастность и типографику в норму
Аудит начинается с инвентаризации пар «текст — фон» и размеров шрифта по экранам. Порог для основного текста — 4.5:1, для крупного кегля и графических элементов — 3:1, плюс требование сохранять читаемость при масштабировании интерфейса до 200%. По WCAG нарушения почти всегда группируются в несколько шаблонов — от этого зависит, какой способ исправления сработает.
Подходы не заменяют друг друга: настройку стилей, переработку компонентов и ручную доводку применяют в разном порядке.
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Правка общих стилей: палитра в переменных, шкала размеров и межстрочных интервалов | нарушения типовые — серый текст на светлых подложках, мелкий кегль в подписях | не закрывает текст поверх изображений, градиентов и полупрозрачных слоёв |
| Переработка библиотеки компонентов: кнопки, поля, таблицы, уведомления | один элемент повторяется на десятках экранов | меняет вёрстку — нужна регрессия по всем местам использования компонента |
| Ручная доводка проблемных экранов | уникальные блоки: баннеры, карточки с фонами, калькуляторы | плохо масштабируется, проверку повторяют после каждой правки контента |
На практике начинают с настройки стилей: палитра и шкала в переменных закрывают большинство типовых нарушений сразу на всех экранах. Затем перерабатывают компоненты, чтобы исправление не откатывалось при следующей сборке. Ручная доводка остаётся для уникальных блоков. Ограничение подхода: проверки ловят контраст, но не читаемость — длину строки, межбуквенные расстояния и переполнение при переводе на другой язык, поэтому типографику интерфейса всё равно проходит инженер. Пороги фиксируем в правилах проверки, чтобы регрессии не возвращались.
Как проходит внедрение: от аудита до передачи
Внедрение доступности — не разовая правка палитры, а последовательность шагов с проверяемым результатом на каждом. Цель — не только поднять контрастность WCAG до требуемого уровня, но и закрепить правила, чтобы новые экраны не повторяли те же нарушения.
- Инвентаризация интерфейса. Собираем перечень шаблонов, компонентов и их состояний — наведение, фокус, отключённый элемент, ошибка. Для каждого фиксируем текстовые стили и фоны: без этого списка замеры теряют полноту.
- Аудит и замер. Считаем фактический коэффициент контраста для всех пар «текст — фон» отдельно для мелкого и крупного текста, элементов управления и графики. Отмечаем всё ниже требуемых 4.5:1 и 3:1.
- Разбор спорных мест. Текст поверх изображений, градиенты, полупрозрачные слои и состояния фокуса автоматика считает некорректно — их проверяем вручную, на реальном контенте.
- План правок. По каждой группе решаем: менять оттенок в палитре, добавить подложку или обводку, ограничить фон под текстом. Правки вносим в токены дизайн-системы, а не в отдельные компоненты, — одно изменение расходится по всем экранам.
- Настройка и проверка. Правим палитру, типографику и токены, задаём минимальные размеры шрифтов и межстрочный интервал, убираем фиксированные высоты блоков. Затем повторяем замеры и прогоняем регрессию по всем шаблонам, тёмной теме и режиму высокой контрастности системы.
- Передача документации. Отдаём правила контраста и типографики, чек-лист для новых компонентов и описание проверок в автотестах, чтобы при следующем релизе доступность не откатилась.
Что заказчик получает на руки: правила, стили, регламент
Правка текущих экранов — только половина результата работ по доступности. Вторая половина — материалы, по которым команда заказчика сама проверяет новые страницы и не теряет контрастность через два релиза. Передаём их вместе с кодом, а не отдельным документом «для отчётности».
- Переменные темы. Цвета и размеры шрифтов вынесены в набор переменных: фон, основной и второстепенный текст, границы, состояния наведения и фокуса. Смена брендового оттенка в одном месте больше не ломает соседние экраны.
- Правила контраста. Таблица допустимых сочетаний с порогами для основного текста, крупных заголовков, элементов управления и пиктограмм. Отдельно помечено, где контраст можно понизить, а где нет.
- Приведённые стили. Кнопки, поля ввода, ссылки, подсказки и сообщения об ошибках переведены на переменные темы и проверены во всех состояниях — включая фокус, наведение и неактивный вид.
- Регламент проверки. Пошаговый порядок: какие экраны смотреть, чем измерять, что считать блокирующим нарушением, а что — допустимым исключением и как его оформить.
- Инструкция для дизайнеров. Как выбирать пару «фон — текст» и размеры шрифтов ещё в макете, чтобы вёрстку не переделывать. С примерами допустимых и запрещённых сочетаний.
- Памятка для редакторов. Ограничения по длине строки и размеру шрифта плюс запрет на цвет как единственный носитель смысла: ссылка внутри абзаца должна отличаться не только оттенком.
- Масштабирование шрифтов. Поведение вёрстки при увеличении текста: что переносится, что обрезается, где нужна другая раскладка и как это проверить перед выпуском.
Разбор проекта: как убрали провалы по доступности
Клиент — сервис подачи заявок с личным кабинетом: около 240 экранов, часть на унаследованных шаблонах. Прогон на контрастность по Руководству по доступности веб-контента (WCAG) показал, что 68 экранов не проходят проверку, а 31 набран кеглем ниже базового. Сканер выдал 210 критичных замечаний — и это только по ключевым сценариям, которые попали в выборку.
Что изменили в реализации
Контраст вынесли в токены темы: вместо цветовых кодов внутри компонентов — пары «текст/фон», проверенные на отношение 4.5:1 для основного текста и 3:1 для крупного, с отдельными значениями для наведения и неактивного состояния. Шкалу типографики свели к шести размерам с шагом от базового и запретили локальные переопределения кегля в разметке — иначе следующий разработчик снова ломает то, что уже починили.
Что показали замеры
Доля экранов, проходящих автоматическую проверку, выросла с 72% до 100%: критичных замечаний ноль, остались единичные предупреждения на переводах. Доля завершённых форм поднялась с 61% до 84% — люди перестали бросать заполнение на шаге, где подписи полей были серыми на сером. Обращения в поддержку с формулировкой «не вижу текст» сократились втрое за тот же период.
Чем отличаются уровни AA и AAA в WCAG и какой выбирать?
Уровни WCAG — это не «качество подороже», а формальные пороги: A — базовый минимум, AA — отраслевой стандарт, на который ссылаются в требованиях и тендерах, AAA — расширенный. Разница между ними измерима и в первую очередь касается требований к контрастности текста и элементов интерфейса.
| Уровень | Требования к контрасту | Кому нужен | Объём правок |
|---|---|---|---|
| A | крупный текст и элементы управления 3:1 | минимальное соответствие | обычно уже выполнен |
| AA | обычный текст 4.5:1, крупный 3:1, контраст границ и состояний | большинство сайтов и сервисов | токены палитры и состояния компонентов |
| AAA | обычный текст 7:1, крупный 4.5:1 | госсервисы, банки, медицина, обучение | переработка дизайн-системы |
Уровень A закрывается почти автоматически. AA требует пересобрать состояния интерфейса: плейсхолдеры, отключённые кнопки, ссылки внутри текста, границы полей ввода — их чаще всего задают серыми «на глаз», и на проверке они порог не проходят.
AAA поднимает планку до 7:1: фирменный акцент почти никогда не проходит как цвет текста, его оставляют для фонов и крупных заголовков. На весь сайт такой уровень берут редко, потому что он сужает палитру до нескольких проверенных пар; выборочно — для длинных текстов, форм и разделов, где аудитория читает подолгу.
Какой уровень выбрать: базово — AA, он покрывает юридические требования и не ломает визуальный стиль. AAA включают точечно — там, где есть регулятор или аудитория с нарушениями зрения. Проверка контраста автоматизируется лучше остальных критериев, но состояния наведения и фокуса приходится сверять вручную — именно там остаются пропуски.
Технические сомнения по доступности и размерам шрифта
Вопросы по доступности почти всегда упираются в одно и то же: как выполнить требования контрастности WCAG, не расходясь с брендом, и не переписывать заново то, что уже работает. Ниже — ответы на то, что чаще всего всплывает на этапе проверки интерфейса.
Фирменные цвета не проходят по контрасту — менять палитру?
Заменять не нужно. Мы расширяем палитру производными тонами: для текста берём затемнённый вариант бренд-цвета, для подложек — осветлённый, а сам исходный цвет оставляем в логотипе, крупных заливках и декоре, где требования к контрасту мягче. Полученные оттенки фиксируем как именованные значения палитры, чтобы дизайнер не подбирал их заново в каждом макете.
У нас уже внедрён набор компонентов — всё переделывать?
Нет. Правки идут в базовые уровни: типографику, кнопки, поля ввода, ссылки, состояния наведения и фокуса. Остальные компоненты наследуют эти значения, поэтому изменение доходит до них без ручной правки. Фактически меняются несколько десятков строк в общих стилях, а не весь интерфейс.
Шрифт бренда тонкий и на мелких размерах «рассыпается». Что делать?
Смотрим метрики начертания: высоту строчных, межбуквенный просвет, насыщенность. Для тонких вариантов поднимаем минимальный размер и вес, добавляем запас по межстрочному интервалу. Текст перестаёт слипаться при увеличенном масштабе, а характер шрифта сохраняется на заголовках, где он работает как задумано.
Как вы проверяете результат?
Ручной проход по ключевым экранам плюс автоматическую проверку в сборке: она ловит контраст и размеры шрифта на новых элементах и не даёт отклонениям вернуться. Дополнительно смотрим интерфейс при увеличении масштаба и на узких экранах — так видно, где вёрстка ломается, а не только где не хватает контраста.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы оценка работ была точной, а не приблизительной, на старте нужен минимальный набор исходных данных. Чем полнее состав, тем меньше допущений в плане внедрения и тем реже объём правок меняется в середине проекта.
- Перечень страниц и разделов, где контраст текста и размеры шрифтов вызывают вопросы, — включая кнопки, поля ввода и сообщения об ошибках.
- Действующие значения цветов и типографики: макет, тема оформления или таблица стилей с переменными.
- Целевой уровень соответствия и требования вашей стороны или внешней проверки, если они уже сформулированы.
- Отчёты и скриншоты прошлых замеров — по ним видно, какие замечания уже закрывались.
- Доступ к репозиторию или тестовому стенду: проверяем контраст и масштабирование текста на живых страницах, а не на копии макета.
- Список поддерживаемых браузеров и устройств, включая мобильные, и настройки масштабирования, которые нужно учесть.
- Ограничения по дизайну: фирменные цвета и начертания, которые нельзя менять, — под них подбираем ближайшие допустимые оттенки.
Дальше мы сверим данные, уточним пару деталей и вернёмся с оценкой работ, планом внедрения по этапам и составом изменений в стилях и компонентах. Обсудим задачу: разберём приоритеты, назовём порядок работ и покажем, что именно вы получите на выходе.
