Доступный 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 теперь — центр управления. Аудит контраста, симуляция цветовой слепоты, токены, варианты и плагины доступности — всё это уже там, используйте их до того, как дизайнер возьмётся за спецификацию.
- Тестируйте с живыми людьми. Автоматика ловит ∼30–57% проблем. Остальное требует, чтобы в цикле тестирования каждого крупного релиза были оплачиваемый пользователь скринридера, пользователь только с клавиатурой и пользователь с когнитивными особенностями.
Почему Фора Софт можно доверить доступный UI/UX-дизайн
Фора Софт выпускает программные продукты с 2005 года — более 200 веб- и мобильных продуктов, разработанных с нуля, в health-tech, e-learning, видеостриминге, финтехе и e-commerce для клиентов в США, ЕС, Великобритании и на Ближнем Востоке. Доступность для нас — обязательная точка ревью на каждом продукте, а не уборка после релиза. Наша платформа BrainCert обработала более 500 миллионов минут живого видео в учебных классах, и это значит, что у нас есть продакшен-данные о том, как стилизация субтитров, цветовой контраст и дизайн фокусных состояний ведут себя в руках реальных пользователей с ассистивными технологиями. Мы входим в Clutch Top 1000 Global и в Top 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 для UI-компонентов и графических объектов (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 или когда работаете в регулируемых рынках (ЕС/EAA, госсектор США, здравоохранение, финансы).
Беритесь за токен-ориентированный контраст, когда: ваша дизайн-система живёт в Figma Tokens или Style Dictionary — кодификация правил 4,5:1 и 3:1 на уровне токенов ловит 90% регрессий по контрасту ещё до QA.
Принцип 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-index или порядок слоёв, если не указать иначе. Используйте плагин 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 мс должны иметь фолбэк со сниженным движением (cross-fade или мгновенный переход). Автозапуск видео по умолчанию выключен или имеет кнопку паузы, до которой можно дойти не более чем за два таба. Зацикленные анимации имеют кнопку остановки. Параллакс отключается под `prefers-reduced-motion`. Мигающий контент никогда не превышает 3 вспышки в секунду (WCAG 2.3.1).
Что закладывать: фолбэк под `prefers-reduced-motion` для каждого токена анимации, отключение автозапуска при сниженном движении или Low Power Mode, кнопки паузы на каруселях и зацикленном видео, не более 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 года. Указательный ввод не должен менять состояние только по hover — hover показывает, клик подтверждает (WCAG 2.5.3 Label in Name).
Что закладывать: минимальные тап-зоны 24×24 CSS-пикселя (44×44 pt на нативном мобильном), кнопочные альтернативы для каждого жеста, отсутствие изменений состояния только по hover, единообразное соответствие «длинное нажатие → меню переполнения». Бюджет — 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, линт уровня чтения для текстов интерфейса, паттерн «лейбл над полем» во всех формах, индикаторы прогресса на сценариях длиннее 2 шагов, единообразные навигационные паттерны. Бюджет — 1–2 недели на выравнивание дизайн-системы.
Беритесь за когнитивную доступность в первую очередь, когда продукт нацелен на массовую аудиторию, на health-tech, финансы, госсектор или образование, либо обслуживает людей, для которых ваш основной язык не родной.
Принцип 7. Формы, ошибки и восстановление
Формы — место, где доступность ломается сильнее всего и где отказ напрямую отражается на выручке. Каждому полю нужен: видимый постоянный лейбл (не только плейсхолдер), программно связанная подсказка, `autocomplete`/`textContentType`, чтобы браузер или ОС могли подставить значения, и состояние ошибки, которое озвучивается скринридером и программно связано с полем (WCAG 3.3.1, 1.3.5).
Дизайн-правила 2026 года: валидируйте на blur (когда пользователь покидает поле), а не на каждом нажатии — посимвольная валидация только зашумляет вывод скринридера. Сообщения об ошибках живут под полем, красным цветом, с иконкой и понятным текстом, объясняющим, как исправить. Используйте регионы `aria-live="polite"` для асинхронных смен состояния (сохраняем… сохранено) в вебе, `UIAccessibility.post(.announcement, ...)` в iOS, `sendAccessibilityEvent` в Android. CAPTCHA без доступной альтернативы нарушает 1.1.1 — берите вместо неё невидимые Turnstile/reCAPTCHA v3 или Apple Private Access Tokens.
Что закладывать: паттерн «лейбл над полем», программную связку «ошибка–поле», валидацию на blur, асинхронные объявления статуса, доступные альтернативы CAPTCHA, сохранение черновика формы в многошаговых сценариях. Бюджет — 1 неделя на крупную форму.
Беритесь за доступность форм в первую очередь, когда продукт включает регистрацию, онбординг, оформление заказа, запись на приём или любой многошаговый сценарий. Формы — место, где доступность напрямую конвертируется в выручку.
Беритесь за отдельное ревью форм, когда: конверсия любой формы регистрации, оформления заказа или онбординга ниже среднего по вертикали — паттерны доступных форм (лейблы, восстановление после ошибок, автозаполнение полей) сильно коррелируют с долей завершения.
Сравнительная матрица: 7 принципов UI/UX-доступности на одной странице
Фреймворк решения: доработать, переделать или отложить
Не каждому продукту нужна полная перестройка дизайн-системы ради доступности. Действуйте по этой лесенке:
Дорабатывайте на месте, когда у вас компонентная дизайн-система, есть токены, а аудит дал менее ∼60 проблем. Большинство команд со зрелой библиотекой Figma попадают сюда. Ожидаемый бюджет: 4–8 недель дизайна + 2 недели инженерии на каждый продуктовый поверхностный слой.
Переделывайте дизайн-систему, когда ваша палитра «как сложилось», отступы выставлены на глаз, компоненты копипастятся, или аудит даёт больше 100 проблем, сконцентрированных в базовых примитивах. Сначала перестраивайте токены и примитивы, потом мигрируйте экраны. Ожидаемый бюджет: 8–16 недель.
Откладывайте (осторожно), когда продукт ещё до PMF, рынок один и B2B вне регуляторного охвата ЕС, а в роадмапе есть чёткая веха по доступности через 6 месяцев. Каждый месяц отсрочки прибавляет примерно 1 неделю будущих доработок и 10–20% к счёту за исправления, когда наконец придёт регулятор, клиент или иск.
Никогда не откладывайте, когда вы продаёте B2C-потребителям в ЕС (EAA), госсектору США (Section 508 и правило DOJ 2024 года под Title II), здравоохранению, финансам или любой энтерпрайз-сделке, где закупки проходят через анкету по доступности.
Не уверены, нужна вам доработка или редизайн?
Лиды дизайна Фора Софт проверят вашу библиотеку Figma и топ-5 пользовательских сценариев по WCAG 2.2 AA за 5-дневный engagement и дадут письменный вердикт.
Мини-кейс: как доработка доступности выглядит на практике
Один наш 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 закона о ФТК.
Оверлеи к тому же активно ломают ассистивные технологии. Пользователи скринридеров сообщают, что подмешанные оверлеями ARIA-атрибуты конфликтуют с нативной ARIA и приводят к дублирующемуся, перемешанному по порядку или «безмолвному» контенту. «Памятка по оверлеям» 2021 года, подписанная более чем 700 специалистами по доступности, остаётся канонической формулировкой: оверлеи — это не соответствие требованиям, не исправление и не замена дизайна.
Правильный ответ в 2026 году — вложить 4–16 недель в реальную доработку дизайна и инженерии, а не 225 тыс. ₽ в год в подписку на оверлей. Математика каждый раз на стороне доработки.
EAA, ADA и другие регулирования в 2026 году
Европейский акт о доступности (EAA, Директива 2019/882): действует с 28 июня 2025 года. Покрывает большинство B2C-цифровых продуктов, продающихся в ЕС, — e-commerce, банкинг, транспорт, электронные книги и другое. Практическая цель соответствия — 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. Доступность, пойманная в QA, обходится в 5–10 раз дороже, чем заложенная в дизайн. Добавляйте критерии приёмки по доступности в каждую дизайн-задачу.
3. Полагаться на оверлей. См. выше. Оверлеи — это магнит для исков и сломанный пользовательский опыт. Деньги лучше потратить на доработку дизайн-системы.
4. Пропускать тестирование на живых пользователях. Автоматика ловит ∼57% проблем. Остальное — корявые формулировки VoiceOver, запутанный порядок фокуса, плохой когнитивный поток — всплывает только с платными тестировщиками, использующими ассистивные технологии. Закладывайте бюджет на каждый релиз.
5. Делать аудит «один раз и забыть». Доступность регрессирует с каждым спринтом. Включите проверку WCAG в ревью пулреквестов, гоняйте Lighthouse Accessibility или axe-CI на каждой сборке и раз в квартал проводите полный аудит.
KPI: что измерять после выхода доступности в прод
Доступности нужен такой же спринт-за-спринтом мониторинг, как производительности или uptime. Когда семь принципов на месте, эти KPI покажут, держится ли система — и получают ли пользователи реальную пользу.
KPI дизайн-системы. (1) Соответствие контраста токенов в каждой паре палитры — цель 100% по WCAG AA. (2) Покрытие доступности компонентов в библиотеке Figma — цель 100% компонентов с вариантами focus, hover, disabled, error и dark-mode. (3) Доля экранов, проходящих автоматические аудиты axe/Lighthouse, — цель ≥95% экранов с оценкой Lighthouse Accessibility ≥95.
Продуктовые KPI. (1) Завершаемость задач для пользователей только с клавиатуры против пользователей с мышью на топ-3 сценариях — цель: разрыв в пределах 10%. (2) Завершаемость задач для пользователей скринридера — цель: разрыв в пределах 15%. (3) Обращения в поддержку, связанные с доступностью, на 10 000 MAU — стремимся к нулю. (4) Разница NPS между пользователями, заявляющими о себе как о пользующихся ассистивными технологиями, и общей когортой — цель: паритет.
KPI по соответствию. (1) Доля прохождения аудита WCAG 2.2 AA, ежеквартально, внешним аудитором — цель 100% закрытия must-fix-пунктов на релиз. (2) Свежесть Accessibility Statement — обновляется каждый пользовательский релиз. (3) Время до устранения проблем по доступности, заявленных пользователями, — цель <30 дней.
Подводя итог
Доступный UI/UX в 2026 году — это задача дизайн-системы, которая решается токенами, стеком инструментов вокруг Figma и циклом тестирования, в который входят живые люди с ассистивными технологиями. Команды, выпускающие инклюзивные продукты, делают это потому, что закладывают семь принципов — контраст, типографику, фокус, движение, гибкость ввода, ясность контента и формы — в каждый компонент ещё до того, как инженер напишет код. Автоматика ловит ∼57% проблем; остальное требует людей. Оверлеи — это пассив, а не решение. Вложите 4–16 недель в реальную доработку, добавьте критерии приёмки по доступности в дизайн-задачи — и вы будете выпускать продукты, которые работают для 100% потенциальных пользователей, держатся в регулируемых рынках и не порождают ровный поток исков по доступности.
Готовы выпустить дизайн-систему, проходящую 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 и пришлём приоритизированный бэклог.
