Гайды

Accessibility & Vibe: яркий интерфейс без нарушений WCAG

13 августа 2025 · 3 минуты чтения

Проверка фактов

Юлия Найпак

Методист по автоматизации. Сверяет паспорт инструмента с документацией вендора.

Автор Р

Редакция

Коллектив авторов, редакторов и иллюстраторов статей на сайте блога онлайн-университета «Зерокодер». Пишем…

Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.

В солнечный полдень дизайнер влюбляется в неоновые градиенты, а вечером на production-сборке баг-репорты: «Кнопку невозможно прочитать в режиме тёмной темы!». Слишком знакомо? За пять минут мы соберём правила, которые уберегут ваш яркий интерфейс от жалоб на контраст и приведут его к строгим числам WCAG — без выцветания ощущения «вау».

• Контраст ≠ унылый серый: управляем палитрой математикой, а не запретами.
• WCAG 2.2 допускает цветовые ходы, если учитывать состояние, толщину и размер шрифта.
• Токенизация и CSS custom properties — быстрый лифт для построения адаптивной темы.
• Автотесты в CI ловят ошибки доступности раньше, чем дизайнер скажет «Done».

Зачем WCAG не враг цвету?

Яркий интерфейс быстро создаёт эмоциональную связь с продуктом, но эйфория заканчивается, когда первые пользователи с дальтонизмом включают режим «высокой контрастности». Вместо того чтобы обесцвечивать бренд-цвета, мы введём цифры: контраст 4,5:1 для текста, 3:1 для крупных заголовков и 1,5:1 для декоративных элементов. Числа — рамки, внутри которых можно рисовать хоть кислотными оттенками, если правильно подбирать фон и размер.

Шаги:

1. Замерьте контраст пары «цвет — фон» с помощью `@storybook/addon-a11y`.
2. Если ниже порога, увеличьте размер шрифта или толщину символа.
3. Используйте слой белого/чёрного с альфой 0.1–0.2 для выравнивания контраста.
4. Зафиксируйте цифры в дизайн-токенах.

/* цвета объявлены как CSS custom properties, легко проверять и менять */
:root {
 --brand-pink: #FF277E;      /* яркий фирменный */
 --surface-dark: #141414;    /* фон в dark-теме */
 --on-pink: #FFFFFF;         /* текст на розовом */
}
.button-primary {
 background: var(--brand-pink);
 color: var(--on-pink);
 font-weight: 600;           /* добавляем толщину — контраст растёт */
}

Как выстроить контраст и не ослепить?

Глаз воспринимает относительную яркость: при тёмной теме даже умеренный контраст воспринимается слишком резким. Поэтому вместо фиксированного коэффициента используйте логарифмическую формулу APCA (Advanced Perceptual Contrast Algorithm). Она точнее отражает реальное восприятие и входит в черновик WCAG 3.0.

Алгоритм внедрения:

1. Включите библиотеку `@wcag-tools/apca` во фронтенд-репозиторий.
2. Создайте JS-утилиту `checkContrast(foreground, background)`.
3. Поднимите порог до Lc 60 (APCA) для интерактивных элементов.
4. Подсветите ошибки в Storybook с помощью badge-компонента.
5. Сообщите дизайнеру прямо в Figma через плагин «A11y — Color».

Мини-вывод: APCA убирает «слепые зоны» классического контраста и даёт вам научную оптику вместо гадания на глаз.

> Попробуйте проверить свой самый яркий компонент через APCA-калькулятор прямо сейчас — результат удивит.

Проверяем доступность на лету — автоматизация или хаос?

Вручную просматривать контраст каждой кнопки скучно, а пропущенный дефект становится дорогим. CI-проверка с `axe-core` или `pa11y` выполняется за секунды и генерирует отчёт в формате JUnit — его же читает ваша Jira. Вставьте шаг в GitHub Actions, и PR не сольётся, пока не отрегулирован контраст.

CI-чек-лист:

1. Установите `npm i —save-dev axe-playwright`.
2. Добавьте спец-тест `axe.checkPage()` к smoke-suite.
3. Сохраните отчёт XML как build-артефакт.
4. Настройте «must-pass» правило по числу violations = 0.
5. Уведомляйте в Slack канал #a11y-alerts.

# .github/workflows/a11y.yml
name: a11y-guard
on: pull_request
jobs:
 axe:
   runs-on: ubuntu-latest
   steps:
     — uses: actions/checkout@v4
     — name: Install deps
       run: npm ci
     — name: Playwright + Axe
       run: npx playwright test —config=axe.conf.ts

Мини-вывод: автоматический «красный свет» в CI дешевле оправданий на ретроспективе.

Финальный чек-лист «яркий интерфейс без нарушений WCAG»