Design System Accessibility Audit (WCAG 2.2 AA)

Design System Accessibility Audit (WCAG 2.2 AA)

Обзор

Компания: Piano Analytics — аналитическая платформа для крупнейших мировых издательств и медиакомпаний.

Продукт: Дизайн-система — общая библиотека компонентов, используемая во всех продуктах Piano.

Роль: Единственный дизайнер на аудите. Ранее построил большую часть компонентов, сам вызвался провести аудит при появлении новых требований.

Сроки: ~2 месяца (параллельно с основными задачами).

Задача

Стало известно о новых требованиях WCAG 2.2. Поскольку я строил большую часть дизайн-системы с нуля, я взял эту задачу на себя — провести полный аудит и привести компоненты к уровню AA.

Главный вызов: сделать систему доступной не сломав существующий визуальный язык.

Ключевой инсайт — Boundaries Clause

Я ожидал масштабных изменений — у нас были проблемы с контрастом фонов кнопок, инпутов, чекбоксов. Но при глубоком изучении стандарта нашёл SC 1.4.11 (Non-text Contrast): элемент не обязан иметь контраст 3:1 сам по себе, если его границы — не единственный индикатор присутствия.

Это значит: светлые кнопки, тонкие бордеры инпутов и чекбоксов можно оставить — пока есть лейбл, плейсхолдер, иконка или структура лейаута, которые делают элемент различимым.

Этот инсайт сохранил визуальный стиль продукта и сократил объём изменений в разы.

Что проверил и исправил

Полный аудит: кнопки, инпуты, чекбоксы, радио, тогглы, алерты, иконки, сообщения, вся типографика.

Основные проблемы и решения:

  • Контраст текста и иконок: плейсхолдеры и иконки на альфа-цветах давали ~2.7:1. Поднял opacity с 40% до 50–65% — минимальное визуальное изменение, полное соответствие
  • Кликабельные зоны: чекбоксы, радио, тогглы и иконочные кнопки были меньше 24px. Увеличил hit area через padding, сохранив визуальный размер
  • Фокус-состояния: старый фокус имел контраст ~1.5:1. Ввёл единый высококонтрастный focus ring для keyboard navigation через :focus-visible
  • Обработка ошибок: WCAG требует текстовое описание ошибки, не только цвет. Предложил команде три варианта, выбрали оптимальный для нашего UI

Компоненты до и после аудита

Примеры компонентов до и после — минимальные визуальные изменения, полное соответствие AA

Процесс

  • Провёл аудит всех компонентов по WCAG 2.2 AA
  • Подготовил документацию с проблемами, решениями и обоснованиями
  • Составил сводные таблицы требований для кнопок, полей и контролов
  • Провёл встречу с командой — представил результаты, обсудил открытые вопросы, собрал решения
  • Рекомендации приняты, внедрение в прод

Решения и компромиссы

  • Уровень AA, не AAA: реалистичный баланс между доступностью и объёмом изменений для существующего продукта.

  • Boundaries clause вместо слепого повышения контраста: сохранил визуальный язык, не нарушив стандарт.

  • :focus-visible вместо :focus: фокус виден только при навигации клавиатурой — нет визуального шума для пользователей мыши.

  • Увеличение hit area через padding: соответствие 24px минимуму без изменения визуального размера компонентов.

Рефлексия

Главный урок: accessibility — это не чеклист, а стратегия. Слепое следование каждому пункту WCAG привело бы к переделке всего UI. Глубокое изучение стандарта позволило найти подход, который и соответствует требованиям, и сохраняет продукт.

Что бы сделал иначе: заложил бы accessibility-требования в дизайн-систему с самого начала — тогда аудит был бы проверкой, а не исправлением.