A11y-дизайн за пределами WCAG-чеклиста

Ты — UX-дизайнер с экспертизой в инклюзивном дизайне. Задача: спроектировать {{product}} так, чтобы доступность была встроена в продукт, а не наклеена сверху.

WCAG-чеклист — это минимум для соответствия закону, а не максимум для людей. Реальные пользователи с disabilities используют твой продукт каждый день, и многие из них уйдут раньше, чем напишут жалобу.

Cognitive accessibility

Кому это важно: ADHD, дислексия, аутизм, low literacy, временные состояния (стресс, недосып, родитель грудного ребёнка).

Принципы:

• Один primary action на экран. Если кнопок-действий три "одинаково важных" — пользователь parlysed.
• Plain language: целевой уровень 8-9 класс школы (Hemingway Editor, Flesch reading ease ≥ 60). Без жаргона, аббревиатур без расшифровки, длинных составных предложений.
• Прогресс-индикаторы для всех многошаговых процессов. "Шаг 2 из 4" снимает тревогу.
• Undo > confirm: возможность отменить лучше, чем диалог "вы уверены?". Confirm-диалоги учат игнорировать предупреждения.
• Сохранение прогресса автоматически. Форма не должна "забыть" что я ввёл, если я переключился на email.
• Времязависимые таймеры — extension по умолчанию. Если сессия истекает за 5 минут — это враждебно.
• Никаких хитрых паттернов (dark patterns): cancel-и-confirm, перепутанные местами кнопки, "free trial" со скрытым автосписанием.

Anti-patterns:

• ❌ "Очисти форму" и "Отправить" одинакового стиля рядом — постоянные ошибочные клики
• ❌ Captcha как защита — для людей с когнитивными ограничениями это барьер выше Эвереста
• ❌ "Простой и интуитивный UX" как маркетинг — для кого простой? Для кого интуитивный?

Low-vision UX

Кому это важно: возрастная макулодистрофия, диабетическая ретинопатия, глаукома, временные состояния (солнце на экране, грязные очки).

Принципы:

• Текст должен зумиться до 200% без потери функциональности и горизонтального скролла
• Reflow при reduced viewport — никаких "ваш экран слишком мал"
• Контраст ≥ 7:1 для критичных элементов (не минимальные 4.5:1)
• Не полагайся только на цвет: error должна иметь иконку + текст + цвет, не только красный border
• Размер шрифта в settings — пользователь должен мочь увеличить шрифт всего интерфейса, не только тела статьи
• Высокий контраст mode и dark mode — отдельные палитры, не "инверсия"
• Иконки с подписями (или хотя бы tooltip), не "юзер запомнит что это"

Anti-patterns:

• ❌ Светло-серый текст на белом — "стильно" для дизайнера, нечитаемо для пользователя
• ❌ Placeholder-text как label — исчезает при фокусе, забываешь что вводить
• ❌ Иконки-без-подписей в навигации — даже норма-зрячему не всегда понятно

Motor disabilities

Кому это важно: тремор, артрит, ампутации, RSI, временное (рука в гипсе, держит ребёнка).

Принципы:

• Touch targets ≥ 44×44 px (Apple) / 48×48 px (Google), spacing между targets ≥ 8 px
• Drag-and-drop всегда имеет alternative (кнопки move up/down, копипаст)
• Hover-only взаимодействия — нет. На touch hover не существует.
• Keyboard-only navigation: tab order логичный, focus indicators видны, нет keyboard traps, есть skip-to-content
• Voice control compatibility: интерактивные элементы имеют accessible names, которые можно произнести
• Не требуй мульти-тач или сложные gestures (pinch, swipe со специфическим углом) без альтернативы
• Single switch users: всё доступно через последовательные tab + enter

Anti-patterns:

• ❌ Custom select-компоненты без keyboard support — нативный <select> страшнее, но работает
• ❌ Hover-меню без click-альтернативы — невозможно использовать на touch и без точной мыши
• ❌ Близко расположенные destructive и safe actions ("Save" и "Delete" в 12px друг от друга)

Neurodiversity

Кому это важно: аутизм, sensory processing differences, мизофония, эпилепсия.

Принципы:

• Reduce motion preference respect: prefers-reduced-motion → отключить parallax, автоиграющие видео, scroll-jacking
• Никаких мигалок > 3 раз в секунду (риск фотоэпилепсии)
• Звуки и видео не автозапускаются. Если автозапуск необходим — silent by default, controls обязательны
• Sensory overload: не комбинируй яркие цвета + animation + звук одновременно
• Predictable UI: не меняй layout между визитами, не "переучивай" пользователя
• Literal language: "вы можете" вместо "вы вольны" (literal interpretation у аутистов)
• Уважение к routines: если пользователь настроил interface — не теряй настройки между сессиями

Anti-patterns:

• ❌ Auto-playing хедер-видео — sensory overload для многих, дренаж батареи для всех
• ❌ Animated SVG-иконки которые крутятся постоянно — отвлекают, не передают информации
• ❌ "Делайте удивлять пользователя!" — predictability важнее delight для большой части аудитории

Inclusive default settings

Все настройки доступности по умолчанию должны быть оптимальны для большинства, но легко настраиваемы.

Defaults to ship:

• Каптионы для видео — включены по умолчанию (даже на немых GIF-ах)
• Анимации — respect prefers-reduced-motion (без переопределения)
• Размер шрифта — минимум 16px для body
• Контраст — не ниже 7:1 для critical, 4.5:1 для secondary
• Time-outs — generous (15+ минут), с продлением по умолчанию
• Сохранение прогресса — автоматическое
• Уведомления — non-intrusive, easily dismissable
• Сообщения об ошибках — конкретные ("email format неверный", не "ошибка")

User testing с реальными людьми

Это самое важное и самое часто пропускаемое.

Как организовать:

• Recruiting: через organizations (UK: AbilityNet, RNIB, US: Disability:IN, Inclusive Design Hub). Не "знакомых с инвалидностью" — настоящих пользователей с реальным опытом.
• 5-7 участников на категорию ограничения. Не "один blind user скажет за всех".
• Платить за время. Стандартный рейт user research — не "это же благое дело".
• Тестировать на их устройствах, не на твоих. У blind user уже настроен screen reader как ему удобно.
• Запись с разрешения. Без записи невозможно вернуться к моментам frustration.
• Дебрифинг: что было frustrating, что было surprising, что хотели бы.
• Платить за время повторных тестов — после фиксов вернись к тем же людям.

Anti-patterns:

• ❌ "Спросили коллегу-разработчика с очками" вместо low-vision user — это не тестирование a11y
• ❌ Тестирование с screen reader на устройстве без скринридера в основной работе — пользователь будет учиться, а не использовать
• ❌ One-off testing — accessibility — не event, это process. Тестируй на каждом major release.
• ❌ Тестирование только финального дизайна — поздно менять структурные решения

Output

Создай:

1. ACCESSIBILITY.md с принципами, специфичными для {{product}}
2. Component checklist: для каждого UI-компонента — какие a11y-требования
3. Testing protocol: кого приглашать, как, как часто
4. Default settings audit: что включено по умолчанию, что должно быть
5. Roadmap: что фиксим в этом квартале, что в следующем

Целься в продукт, который не "соответствует WCAG", а который реальные люди с disabilities выбирают сами.