Доступный дизайн в 2026: 7 принципов, стандарты WCAG 2.2 AA и почему оверлеи — плохая идея
Доступный UI/UX-дизайн в 2026 году — это задача дизайн-системы, а не оверлея. Европейский акт о доступности (European Accessibility Act) вступил в силу 28 июня 2025 года; аудит WebAIM за 2025 год показал, что у 94,8% главных страниц из миллиона крупнейших сайтов есть хотя бы одно нарушение WCAG (в среднем 51 ошибка на страницу), а поставщики оверлеев, обещавших автоматическое соответствие требованиям, теперь фигурируют в качестве ответчиков примерно в 25% американских судебных исков по цифровой доступности. Команды, которые выпускают инклюзивные продукты в 2026 году, на этапе дизайна решают семь ключевых задач — контраст, типографика, фокус, движение, гибкость ввода, ясность контента и восстановление после ошибок — и закладывают каждую из них в дизайн-токены, библиотеки Figma и Storybook. Этот гайд — наш рабочий плейбук для любого UI/UX-проекта: семь принципов дизайна, привязанных к WCAG 2.2 AA, стек инструментов вокруг Figma и дизайн-системы, фреймворк выбора «доработать или переделать», реальный кейс, пять типичных ошибок, которые сбивают команды с пути, и KPI, которые действительно стоит отслеживать. Все рекомендации проверены на продуктах, которые наша команда создавала для клиентов в США, ЕС, Великобритании и на Ближнем Востоке.
КЛЮЧЕВЫЕ ВЫВОДЫ
- 1,3 млрд человек в мире живут с инвалидностью (∼16% населения по данным ВОЗ). Игнорировать их в продукте — это одновременно упущенная выручка и этическая ошибка.
- Оверлеи — это не решение проблемы доступности. Исследование Deque 2024 года показало, что автоматические инструменты выявляют около 57% проблем; оверлеи находят ещё меньше и стали причиной примерно 25% судебных исков по ADA в США с 2023 года.
- Семь принципов дизайна решают 95% реальных проблем: контраст и цвет, типографика и Dynamic Type, фокус и клавиатура, движение и анимация, гибкость ввода и жестов, ясность контента, формы и ошибки.
- Стоимость растёт нелинейно со временем. Доступность, заложенная в дизайн-систему, занимает менее 5% от общего времени на дизайн; доработка после релиза — 15–30%.
- Figma теперь — центр управления. Аудит контраста, симуляция цветовой слепоты, токены, варианты и плагины доступности — всё это уже есть в Figma. Используйте их до того, как дизайнер начнёт писать спецификацию.
- Тестируйте с живыми людьми. Автоматизация находит около 30–57% проблем. Остальное можно выявить только с помощью реальных пользователей: в цикле тестирования каждого крупного релиза должны участвовать человек, пользующийся скринридером, человек, работающий только с клавиатурой, и человек с когнитивными особенностями.
Почему Фора Софт можно доверить доступный UI/UX-дизайн
Фора Софт выпускает программные продукты с 2005 года — более 200 веб- и мобильных решений, созданных с нуля, в сферах health-tech, e-learning, видеостриминга, финтеха и e-commerce для клиентов из США, стран ЕС, Великобритании и Ближнего Востока. Доступность — обязательный этап проверки на каждом проекте, а не задача после релиза. Наша платформа BrainCert обработала более 500 миллионов минут живого видео в учебных классах, что даёт нам реальные данные о том, как стилизация субтитров, цветовой контраст и дизайн фокусных состояний работают у пользователей с ассистивными технологиями. Мы входим в Clutch Top 1000 Global и находимся на 3-м месте по рейтингу Clutch в разработке видео. Плейбук ниже — это живой инструмент, которым наши лиды дизайна пользуются в 2026 году, а не просто пересказ стандартов WCAG.
Нужен аудит доступности вашей дизайн-системы в Figma?
Наши лиды по дизайну проверят токены, компоненты и живые прототипы на соответствие WCAG 2.2 AA и за 5 рабочих дней подготовят приоритизированный бэклог.
Ландшафт UI/UX-доступности в 2026 году кратко
Три силы меняют подход к доступности UI/UX в 2026 году. Во-первых, регулирование уже не абстракция: Европейский акт о доступности вступил в силу (с 28 июня 2025 года), число исков по ADA Title III в США против мобильных и веб-продуктов превысило 4000 в 2024 году (по данным трекера Seyfarth), а новое правило DOJ 2024 года под Title II прямо распространило требования WCAG 2.1 AA на цифровые сервисы органов власти штатов и местных администраций. Британский Equality Act, канадский ACA, австралийский DDA, ACT Онтарио AODA и израильский закон о равных правах людей с инвалидностью — все они опираются на стандарты WCAG 2.1 или 2.2 AA. Теперь B2C-продукты по умолчанию попадают под действие нормативных требований.
Во-вторых, дизайн-инструменты подтянулись. В Figma теперь есть проверка контраста, симуляция цветовой слепоты, auto-layout, который учитывает масштабирование текста, и растущая экосистема плагинов доступности (Stark, A11y Annotation Kit, Contrast, Able). Дизайн-токены для цвета, типографики и отступов позволяют заложить правила контраста прямо в систему — и выявлять нарушения ещё до того, как инженер напишет код.
В-третьих, ИИ одновременно ускоряет процессы и создаёт риски. Stark AI, Microsoft Accessibility Insights, Google Lookout и Deque axe DevTools генерируют черновики аудитов, alt-тексты и исправленные фрагменты кода на Tailwind или SwiftUI. Но поставщики оверлеев — те, кто обещает соответствие стандартам одной строкой JavaScript, — столкнулись с волной исков и жалоб на удобство использования. Правило 2026 года: используйте ИИ как помощника, а не как защиту.
Принцип 1. Цвет, контраст и дизайн-токены
Контраст — самое частое нарушение доступности: WebAIM в 2025 году обнаружил, что 79,1% главных страниц не соответствуют WCAG по контрасту хотя бы раз. WCAG 2.2 AA требует соотношения 4,5:1 для обычного текста, 3:1 для крупного текста (от 18pt или от 14pt полужирным) и 3:1 для элементов интерфейса и графических объектов (1.4.11). Решение — дизайн-токены: каждый цвет в палитре имеет заранее проверенную по контрасту роль (body-on-surface, body-on-primary, accent-on-surface и т.д.), и линтер прерывает сборку, если какая-либо пара токенов не соответствует стандарту AA.
Подводные камни 2026 года: полупрозрачные оверлеи (модальные окна, тултипы, подписи hero-блоков) оценивают контраст относительно изображения-фона, а не относительно swatch в макете — проверяйте на самом сложном фрагменте картинки. Градиентные фоны — классическая ошибка: текст поверх градиента должен соответствовать соотношению 4,5:1 в самой тёмной или светлой точке градиента. Не используйте только цвет для передачи состояния (ошибки, обязательные поля, статус-метки) — дополняйте иконкой или текстом (1.4.1).
Что закладывать: дизайн-токены с проверенным контрастом, линт контраста Figma в CI, парность «паттерн + иконка» на всех состояниях с цветовой кодировкой, явные варианты Dark Mode и High Contrast в Tailwind или вашей дизайн-системе. Бюджет — 1 неделя на доработку, если токены уже есть; 3–4 недели, если палитра «как сложилось».
Беритесь за дизайн контраста на основе токенов, когда в вашей дизайн-системе больше 10 переиспользуемых цветов, когда вы внедряете Dark Mode или работаете в регулируемых отраслях — ЕС/ЕАА, госсектор США, здравоохранение, финансы.
Беритесь за токен-ориентированный контраст, когда: ваша дизайн-система работает с Figma Tokens или Style Dictionary — если закодировать правила 4,5:1 и 3:1 на уровне токенов, вы поймаете 90% проблем с контрастом ещё до этапа тестирования.
Принцип 2. Типографика, порядок чтения и масштабируемый текст
Примерно 30% пользователей увеличивают системный размер текста выше стандартного; люди со слабым зрением часто ставят 200% и больше. Требования WCAG 1.4.4 (Resize Text), 1.4.10 (Reflow) и 1.4.12 (Text Spacing) означают, что контент должен оставаться удобным для использования при любых настройках. Что это значит на этапе дизайна: никогда не используйте фиксированные пиксельные размеры шрифта; применяйте `rem`/`em` в вебе, SwiftUI Dynamic Type в iOS, единицы `sp` с масштабированием `TextAppearance` в Android. Избегайте коротких контейнеров фиксированной ширины для пользовательского контента — пусть текст свободно переносится.
Порядок чтения в Figma тоже важен. Стандартный порядок в DOM (или порядок в VoiceOver на нативных платформах) следует за z-индексом или порядком слоёв, если не задать иначе. Используйте плагин Reading Order в Figma или явно указывайте `aria-label`/`accessibilityLabel` при передаче макета в разработку. Длина строки тоже имеет значение — 45–75 символов, как рекомендует WCAG 2.2 AAA, это удобно и для пользователей с когнитивными особенностями.
Что закладывать: масштабируемую типографскую шкалу, токены межсимвольных и межстрочных интервалов (line-height ≥1,5, letter-spacing ≥0,12em, word-spacing ≥0,16em), адаптивные ограничения длины строки, чёткие указания порядка чтения для передачи в разработку. Бюджет — 1–2 недели.
Беритесь за типографику в первую очередь, когда продукт текстоёмкий (новости, документация, e-learning, юридическая сфера), ориентирован на старшую аудиторию или работает с международной аудиторией, где разные языки по-разному нагружают вашу типографическую шкалу.
Принцип 3. Порядок фокуса, видимость фокуса и работа с клавиатурой
До каждого интерактивного элемента должно быть можно добраться с клавиатуры (WCAG 2.1.1), у каждого должен быть заметный индикатор фокуса (2.4.7, 2.4.11 Focus Not Obscured), а порядок перехода между элементами — логичным (2.4.3). Что это значит на этапе дизайна в 2026 году: фокусные состояния нельзя скрывать «ради чистоты». Каждая кнопка, ссылка, поле формы и кастомный виджет должны иметь обводку фокуса с контрастом не ниже 3:1 по отношению к фону (новый критерий WCAG 2.2 — 2.4.13 Focus Appearance).
Skip-ссылки, регионы-ориентиры (`<main>`, `<nav>`, `<aside>`) и иерархия заголовков (h1→h2→h3 без пропусков уровней) — по-прежнему самые быстрые победы по доступности в вебе. Управление фокусом в модальных окнах и оверлеях — поймать фокус внутри модалки, вернуть его на триггер при закрытии — это то место, где сыпется большинство команд. Проектируйте модалки с явной кнопкой закрытия, биндингом на `Escape` и целью начального фокуса, прописанной в спецификации.
Что закладывать: видимые обводки фокуса на каждом интерактивном элементе, ссылку «Перейти к основному контенту», единообразную структуру навигационных регионов, фокус-ловушки на всех модалках, диалогах и шторках, тестирование с клавиатуры на каждом прототипе. Бюджет — 1–2 недели.
Беритесь за дизайн «клавиатура+фокус первым», когда ваш продукт — софт для продуктивности, у него сложные сценарии работы, его покупают энтерпрайз-клиенты или это SaaS с большим объёмом ввода данных. Выигрывают и продвинутые пользователи, и пользователи ассистивных технологий.
Беритесь за явное тестирование порядка фокуса, когда: на странице есть липкие заголовки, стеки модалок или drag- and- drop — на эти три паттерна приходится большинство нарушений WCAG 2.4.3, доезжающих до продакшена.
Принцип 4. Движение, анимация и вестибулярная безопасность
WCAG 2.3.3 (Animation from Interactions) и CSS-свойство `prefers-reduced-motion` требуют уважать настройку «уменьшить движение». Полноэкранные переходы, параллакс, автозапуск видео и длинные анимации могут вызывать тошноту, головокружение и мигрень у людей с вестибулярными расстройствами (∼1 из 20 взрослых, по данным Vestibular Disorders Association). В прототипах Figma и при передаче в разработку предусматривайте варианты со сниженной анимацией рядом с каждой анимацией.
Лучшие практики на 2026 год: анимации длительностью более 300 мс должны иметь альтернативный вариант с минимальным движением (например, плавный переход или мгновенная смена). Автозапуск видео по умолчанию отключён или сопровождается кнопкой паузы, до которой можно добраться не более чем за два нажатия клавиши Tab. Зацикленные анимации обязательно имеют кнопку остановки. Эффект параллакса отключается при настройке `prefers-reduced-motion`. Мигающий контент не должен превышать три вспышки в секунду (требование WCAG 2.3.1).
Что закладывать: фолбэк под `prefers-reduced-motion` для каждого токена анимации, отключение автозапуска при сниженном движении или режиме энергосбережения, кнопки паузы на каруселях и зацикленном видео, не более 3 Гц мигания нигде. Бюджет — 1 неделя.
Беритесь за дизайн с безопасным движением, когда в продукте много анимаций (игры, соцсети, AR/VR, онбординг) или когда пользователи жалуются, что «голова кружится», «тошнит» или «слишком много движения».
Принцип 5. Гибкость ввода, жесты и размеры тап-зон
Тап-зоны должны быть не меньше 24×24 CSS-пикселей (WCAG 2.2 AA, 2.5.8 Target Size Minimum), а на мобильных устройствах — идеально 44×44 pt. Для каждого кастомного жеста — свайпа на удаление, долгого нажатия, перетаскивания для сортировки, щипка для зума — должен быть альтернативный способ управления: кнопка, меню или клавиатурный шорткат (WCAG 2.5.7 Dragging Movements, новый в 2.2). Пользователи Voice Control и Switch Control не могут выполнять жесты — им нужна доступная замена, работающая по тапу.
Что это значит на этапе дизайна: каждому жесту в спецификации должна соответствовать кнопка, видимая в покое или появляющаяся при фокусе, выполняющая ту же функцию. Меню переполнения («…») в строках списка — стандартный паттерн 2026 года. Указательный ввод не должен изменять состояние только при наведении — наведение показывает, клик подтверждает (WCAG 2.5.3 Label in Name).
Что закладывать: минимальные тап-зоны — 24×24 CSS-пикселя (44×44 pt на нативном мобильном), альтернативы кнопкам для каждого жеста, отсутствие изменений состояния только при наведении, единообразное соответствие «длинное нажатие → меню переполнения». Бюджет — 1 неделя.
Беритесь за гибкий ввод, когда в продукте сложные взаимодействия (редакторы с drag-and-drop, креативные инструменты на жестах, картографические интерфейсы, видеоредакторы). Если вы выходите на любой B2C-рынок ЕС — это вообще без вариантов.
Беритесь за аудит тап-зон 44×44pt, когда: продукт выходит на планшеты или ТВ и полагается на тач или указательный ввод — у любой другой категории тап-зон (телефон, десктоп, часы) дефолты уже известны, а планшет и ТВ часто ломают сразу обе.
Принцип 6. Ясность контента, простой язык и когнитивная нагрузка
Когнитивная доступность — это то, где большинство продуктов слабы. WCAG 3.1.5 (Reading Level) рекомендует писать на уровне неполного среднего образования; рекомендации по простому языку от ЕС (Clear Writing for Europe) и США (plainlanguage.gov) поддерживают эту идею. Лучшая практика 2026 года: основной контент — на уровне 9 класса, предложения не длиннее 20 слов, активный залог, конкретные существительные, без идиом.
Что делает дизайн: лейблы вместо плейсхолдеров («Адрес электронной почты» над полем, а не внутри), конкретные глаголы в CTA («Создать аккаунт», а не «Продолжить»), понятные сообщения об ошибках, которые объясняют, что делать («Пароль должен содержать минимум 8 символов», а не «Некорректный ввод»), индикаторы прогресса в многошаговых сценариях (1 из 4), единообразные навигационные паттерны (одна и та же навигация на одном и том же месте на каждом экране — WCAG 3.2.3). ИИ-инструменты вроде ReadEasy.ai или оценки читаемости в Microsoft Copilot могут помочь упростить формулировки; финальную правку всегда делает человек-редактор.
Что закладывать: правила простого языка в CMS, линт уровня читаемости для текстов интерфейса, паттерн «лейбл над полем» во всех формах, индикаторы прогресса на сценариях из трёх и более шагов, единые навигационные паттерны. Бюджет — 1–2 недели на выравнивание дизайн-системы.
Беритесь за когнитивную доступность в первую очередь, когда продукт рассчитан на широкую аудиторию, связан с здравоохранением, финансами, госуслугами или образованием, либо используется людьми, для которых основной язык не родной.
Принцип 7. Формы, ошибки и восстановление
Формы — место, где доступность чаще всего нарушается, и где проблемы напрямую влияют на выручку. Каждому полю нужно: видимый и постоянный ярлык (а не только плейсхолдер), программно связанная подсказка, `autocomplete`/`textContentType`, чтобы браузер или ОС могли автоматически подставлять значения, и состояние ошибки, которое скринридер озвучивает и которое программно связано с полем (WCAG 3.3.1, 1.3.5).
Дизайн-правила 2026 года: проверяйте данные при потере фокуса (когда пользователь покидает поле), а не при каждом нажатии — посимвольная валидация только мешает скринридерам. Сообщения об ошибках размещайте под полем: красным цветом, с иконкой и понятным текстом, объясняющим, как исправить проблему. Для асинхронных изменений состояния (например, «сохраняем…», «сохранено») в вебе используйте регионы `aria-live="polite"`, в iOS — `UIAccessibility.post(.announcement, ...)`, в Android — `sendAccessibilityEvent`. CAPTCHA без доступной альтернативы нарушает требование 1.1.1 — используйте вместо неё невидимые решения, такие как Turnstile, reCAPTCHA v3 или Apple Private Access Tokens.
Что закладывать: паттерн «лейбл над полем», программную связь «ошибка–поле», валидацию при потере фокуса, асинхронные уведомления о статусе, доступные альтернативы CAPTCHA, сохранение черновика формы в многошаговых сценариях. Бюджет — 1 неделя на крупную форму.
Начинайте с доступности форм, если продукт включает регистрацию, онбординг, оформление заказа, запись на приём или любой многошаговый сценарий. Формы — это место, где доступность напрямую влияет на выручку.
Беритесь за отдельное ревью форм, когда: конверсия любой формы регистрации, оформления заказа или онбординга ниже средней по отрасли — паттерны оформления форм (подписи к полям, работа с ошибками, автозаполнение) сильно влияют на долю завершённых действий.
Сравнительная матрица: 7 принципов доступности интерфейса на одной странице
Фреймворк решения: доработать, переделать или отложить
Не каждому продукту нужна полная перестройка дизайн-системы ради доступности. Действуйте по этой лестнице:
Дорабатывайте на месте, когда у вас есть компонентная дизайн-система, токены, а аудит выявил менее 60 проблем. Большинство команд с зрелой библиотекой Figma попадают в эту категорию. Ожидаемый бюджет: 4–8 недель на дизайн и 2 недели на инженерию для каждого продуктового поверхностного слоя.
Переделывайте дизайн-систему, когда ваша палитра «как получилось», отступы ставятся на глаз, компоненты копипастятся или аудит выявляет более 100 проблем, сосредоточенных в базовых элементах. Сначала обновляйте токены и примитивы, потом мигрируйте экраны. Ожидаемый бюджет — 8–16 недель.
Откладывайте (осторожно), когда продукт ещё не достиг PMF, рынок один, а B2B находится вне регуляторного охвата ЕС, и в роадмапе есть чёткая веха по доступности через 6 месяцев. Каждый месяц отсрочки добавляет примерно одну неделю будущих доработок и 10–20% к стоимости исправлений, когда наконец придёт регулятор, клиент или иск.
Никогда не откладывайте, когда вы продаёте B2C-пользователям в ЕС (EAA), государственным структурам США (Section 508 и правило DOJ 2024 года по Title II), в здравоохранении, финансах или в любой сделке с крупным бизнесом, где закупки проходят через анкету по доступности.
Не уверены, нужна ли доработка или редизайн?
Лиды дизайна Фора Софт проверят вашу библиотеку Figma и пять ключевых пользовательских сценариев на соответствие стандартам WCAG 2.2 AA в течение 5 дней и предоставят письменный вердикт.
Мини-кейс: как доработка доступности выглядит на практике
Один наш SaaS-клиент запустил B2B-дашборд аналитики, который за три года вырос с 4 до 40 экранов. Аудит доступности 2025 года выявил 118 нарушений WCAG 2.2 AA — 42 по контрасту, 27 по фокусу, 18 по формам, 13 по движению, 10 по тап-зонам, 8 по ясности контента. Корневые причины: палитра, которую «занесло», ad-hoc-стилизация фокуса, паттерн «плейсхолдер как лейбл». Мы провели 10-недельную доработку: на 1–3 неделях перестроили дизайн-токены (цвет, типографика, отступы, обводки фокуса) и внедрили их в Tailwind и Figma; на 4–6 неделях отрефакторили 12 главных экранов под новые токены; на 7–8 неделях починили формы и асинхронные объявления статуса; на 9–10 неделях разобрались с движением, тап-зонами и текстами. Аудит после доработки: 7 остаточных мелких проблем (все косметические). Измеримый эффект: завершаемость задачи в основном сценарии «создать отчёт» выросла с 71% до 89% для пользователей, работающих только с клавиатурой; NPS на когорте аудита поднялся с 32 до 51 за 90 дней; обращения в поддержку с фразами «не вижу», «не читается» или «не получается перейти табом» снизились на 78%.
Стек инструментов доступного дизайна на 2026 год
В Figma: Stark (проверка контраста, симуляция цветовой слепоты, фокус, аннотации — самый популярный плагин в 2026 году), Able (быстрая проверка контраста), Contrast от WillowTree, A11y Annotation Kit для подготовки спецификаций разработки, плагин Reading Order. Используйте Figma Variables для управления токенами цвета, типографики и отступов с режимами light, dark и high-contrast.
Для аудитов и постоянного мониторинга: Deque axe DevTools Browser + Mobile (выдаёт исправленные сниппеты Tailwind и SwiftUI через axe AI), Microsoft Accessibility Insights для Web/Windows/Android, Siteimprove для постоянного мониторинга, WAVE для быстрых бесплатных аудитов, оценка Lighthouse Accessibility для CI.
Для тестирования с живыми пользователями: Assistiv Labs (удалённые сессии со скринридерами), Fable (платные тестировщики с инвалидностью), UserTesting с сегментами по доступности. Заложите 2–4 сессии на крупный релиз с платными участниками, которые ежедневно используют ассистивные технологии.
ИИ-ассистенты: Stark AI для аннотированных спецификаций в Figma, Microsoft Copilot Readability, ReadEasy.ai для упрощения текста, Google Lookout Dev Kit для описаний изображений, axe DevTools AI для сгенерированных правок. Любой результат ИИ — это черновик; проверка человеком обязательна.
Почему оверлеи — неправильный ответ в 2026 году
«Оверлеи доступности» в одну строчку JavaScript — AccessiBe, виджеты UserWay, EqualWeb, accessiBle, Max Access — обещают соответствие требованиям через тег-скрипт, который подмешивает ARIA-атрибуты, переключает контраст и показывает виджет с настройками. На практике автоматические инструменты ловят только ∼57% проблем (по данным исследования Deque 2024 года), а оверлеи зачастую справляются ещё хуже, потому что работают с неизвестной им семантической структурой.
Юридическая ситуация сегодня вполне ясна. Отчёт UsableNet о защите по делам о доступности за 2024 год показал, что за последние 24 месяца более 1000 исков по ADA были поданы против сайтов, использующих оверлеи доступности — это около 25% всех цифровых дел по ADA. Несколько судов сочли установку оверлеев фактором, усиливающим небрежность, а не защищающим от неё. Федеральная торговая комиссия предупредила, что маркетинговые заявления поставщиков оверлеев могут быть признаны вводящими в заблуждение в соответствии с разделом 5 закона FTC.
Оверлеи также мешают работе ассистивных технологий. Пользователи скринридеров сообщают, что ARIA-атрибуты, добавляемые оверлеями, конфликтуют с нативной ARIA и приводят к дублированию контента, его перемешиванию или полной «немоте». «Памятка по оверлеям» 2021 года, подписанная более чем 700 специалистами по доступности, остаётся каноническим документом: оверлеи — это не соответствие требованиям, не исправление и не замена дизайна.
Правильный ответ в 2026 году — потратить 4–16 недель на реальную доработку дизайна и инженерии, а не 225 тыс. ₽ в год на подписку на оверлей. Математика всегда на стороне доработки.
EAA, ADA и другие регулирования в 2026 году
Европейский акт о доступности (EAA, Директива 2019/882): вступает в силу 28 июня 2025 года. Охватывает большинство цифровых продуктов для конечных пользователей, продаваемых в ЕС — интернет-магазины, банковские сервисы, транспорт, электронные книги и другие. На практике соответствие означает выполнение стандартов WCAG 2.2 AA / EN 301 549. Штрафы могут достигать 1 млн евро (размер зависит от страны), а в некоторых юрисдикциях возможен и принудительный вывод продукта с рынка.
ADA в США: финальное правило Департамента юстиции (DOJ) от апреля 2024 года по Title II прямо распространяет стандарты WCAG 2.1 AA на сайты и мобильные приложения штатов и муниципалитетов (сроки соответствия — 2026–2027). Title III регулирует частные «места общественного пользования», и судебная практика расширяет его действие на цифровые платформы; в 2024 году было подано более 4000 исков, большинство из которых урегулировано на сумму от 375 тысяч до 3,7 миллиона рублей.
Section 508: базовый уровень соответствия стандартам WCAG 2.0 AA для любого цифрового продукта, продаваемого федеральным агентствам США. Многие штаты приняли эти требования или даже ужесточили их.
Прочее: Equality Act 2010 в Великобритании + Public Sector Bodies Accessibility Regulations 2018 (WCAG 2.1 AA), канадский ACA (федеральный) + AODA (Онтарио, B2C с выручкой >10 млн канадских долларов), австралийский DDA + DTA Digital Service Standard, израильские Equal Rights for Persons with Disabilities Regulations (2013/2017).
Пять ошибок, которые сбивают проекты по доступности
1. Проектировать без токенов. Если палитра, типографская шкала и отступы не вынесены в токены, каждый новый экран — новый риск для доступности. Сначала — токены, потом — редизайн.
2. Считать доступность этапом QA. Если проблемы с доступностью находят на этапе тестирования, их исправление обходится в 5–10 раз дороже, чем если учесть их ещё на этапе дизайна. Добавляйте критерии доступности в каждую задачу по дизайну.
3. Полагаться на оверлей. См. выше. Оверлеи привлекают юридические риски и портят пользовательский опыт. Деньги лучше потратить на доработку дизайн-системы.
4. Пропускать тестирование на живых пользователях. Автоматизация ловит около 57% проблем. Остальное — непонятные формулировки в VoiceOver, запутанный порядок фокуса, плохой когнитивный поток — выявляется только при работе с платными тестировщиками, использующими ассистивные технологии. Закладывайте бюджет на каждый релиз.
5. Делать аудит «один раз и забыть». Доступность ухудшается с каждым спринтом. Включите проверку WCAG в ревью пулреквестов, запускайте Lighthouse Accessibility или axe-CI на каждой сборке и раз в квартал проводите полный аудит.
KPI: что измерять после выхода доступности в прод
Доступности нужен такой же спринт-за-спринтом мониторинг, как и производительности или uptime. Когда семь принципов соблюдены, эти KPI покажут, работает ли система стабильно — и действительно ли пользователи получают от неё пользу.
KPI дизайн-системы. (1) Соответствие контраста цветов в каждой паре палитры — цель 100% по стандарту WCAG AA. (2) Покрытие доступности компонентов в библиотеке Figma — цель 100% компонентов с вариантами состояния: фокус, наведение, отключено, ошибка и тёмная тема. (3) Доля экранов, проходящих автоматические проверки axe и Lighthouse, — цель не менее 95% экранов с оценкой доступности в Lighthouse ≥95.
Продуктовые KPI. (1) Завершаемость задач у пользователей, использующих только клавиатуру, по сравнению с пользователями мыши на трёх главных сценариях — цель: разница не более 10%. (2) Завершаемость задач у пользователей скринридеров — цель: разница не более 15%. (3) Количество обращений в поддержку по вопросам доступности на 10 000 активных пользователей в месяц — стремимся к нулю. (4) Разница в NPS между пользователями, применяющими ассистивные технологии, и общей группой — цель: равенство показателей.
KPI по соответствию. (1) Доля прохождения аудита WCAG 2.2 AA, ежеквартально, внешним аудитором — цель 100% закрытия must-fix-пунктов к релизу. (2) Актуальность Accessibility Statement — обновляется с каждым пользовательским релизом. (3) Время устранения проблем по доступности, сообщённых пользователями, — цель менее 30 дней.
Подводя итог
Доступный UI/UX в 2026 году — задача дизайн-системы, которую решают с помощью токенов, стека инструментов вокруг Figma и цикла тестирования с участием реальных людей, использующих ассистивные технологии. Команды, создающие инклюзивные продукты, закладывают семь ключевых принципов — контраст, типографику, фокус, движение, гибкость ввода, ясность контента и формы — в каждый компонент ещё до написания кода. Автоматизация ловит около 57% проблем; остальное требует участия людей. Оверлеи — это не решение, а временная мера. Вложите 4–16 недель в реальную доработку, добавьте критерии доступности в дизайн-задачи — и сможете выпускать продукты, которые работают для всех потенциальных пользователей, соответствуют требованиям регулируемых рынков и не вызывают постоянных исков по доступности.
Готовы выпустить дизайн-систему, соответствующую WCAG 2.2 AA?
Дизайнеры Фора Софт закладывают доступность в каждый спринт. Свяжитесь с нами — мы предложим план доработки под ваш продукт.
Часто задаваемые вопросы
WCAG 2.2 AA — правильная цель на 2026 год, или стоит метить в AAA?
WCAG 2.2 AA — общепринятая регуляторная цель: EU EN 301 549, US Section 508, правило DOJ 2024 года под Title II, Equality Act в Великобритании и практически все корпоративные чек-листы закупок. Уровень AAA — ориентир для отдельных типов контента (например, контраст 7:1 или уровень читаемости), но не реалистичная цель для всего продукта. Выпускайте продукт на уровне AA, а на критических сценариях, где сосредоточены пользователи с более выраженными нарушениями, проверяйте соответствие AAA.
Сколько стоит UI/UX-аудит с фокусом на доступность?
Лёгкий автоматический аудит продукта среднего размера (10–25 экранов) обойдётся в 150–375 тыс. ₽. Полный ручной аудит — проверка библиотеки Figma, автоматические сканирования, тестирование с клавиатуры и скринридерами, 3–5 платных сессий с реальными пользователями — стоит 750 тыс. – 2,2 млн ₽. Самостоятельное исправление ошибок обычно обходится в 3–10 раз дороже аудита и зависит от того, насколько глубоко придётся менять дизайн-систему.
Может ли ИИ заменить человека при аудите доступности?
Нет. Исследование Deque 2024 года подтвердило, что автоматические инструменты находят около 57% нарушений WCAG; остальное — порядок фокуса, формулировки для скринридеров, когнитивная ясность, реальные проблемы в пользовательских сценариях — требует ручного тестирования и участия людей с реальным опытом использования ассистивных технологий. ИИ — это инструмент для черновика; продукт выпускают люди.
Бывают ли случаи, когда оверлеи доступности допустимы?
Только как краткосрочная мера, пока идёт настоящая доработка, и даже тогда — с публичным Accessibility Statement, в котором честно перечислены остающиеся пробелы. Не позиционируйте оверлей как соответствие требованиям: ФТК предупреждала, что такие заявления могут быть признаны вводящими в заблуждение, и около 25% американских исков по цифровому ADA поданы против сайтов с оверлеями. Настоящие правки в дизайн-системе в долгосрочной перспективе обходятся дешевле.
Помогают ли дизайн-системы с доступностью на самом деле?
Да — грамотно построенная дизайн-система — самое «рычажное» вложение в доступность из возможных. Исправили контраст, фокус, типографику и паттерны ошибок один раз в токенах и примитивах — и каждый новый экран автоматически получает эти настройки. Наши данные по более чем 200 продуктам: команды с токенизированными дизайн-системами тратят на доступность менее 5% времени дизайна; без них — 15–30%.
Какая самая быстрая победа по доступности, которую можно реализовать в этом спринте?
Проверьте цветовые токены на соответствие стандарту WCAG AA и исправьте худшую пару. Проблемы с контрастом — самая распространённая ошибка в соблюдении WCAG (79,1% страниц по данным WebAIM 2025) и одна из самых простых для исправления, если цветовые токены являются основным источником. Выпустите палитру с проверенным контрастом в этом спринте — и вы устраните около 40% типичных замечаний при аудите.
Как делать доступность в dark mode и при работе с темами?
Dark mode сам по себе не гарантирует доступность — контраст всё равно нужно проверять, а цветовые токены должны поддерживать варианты light, dark и high-contrast. SwiftUI, UIKit, Tailwind, CSS custom properties и Figma Variables отлично справляются с этим. Для каждого семантического цветового токена (body-on-surface, accent, border и так далее) выпускайте все три варианта и запускайте линтер контраста на каждой паре.
Читать дальше
Остались вопросы по доступному UX?
Свяжитесь с нами — обсудим их на вашей реальной библиотеке Figma и пришлём приоритизированный бэклог.
