Обновлено: .

Базовая доступность не должна требовать включения специального режима. Человек должен иметь возможность найти информацию, понять её и выполнить действие в обычном интерфейсе. Персональные настройки полезны, когда расширяют эту возможность, а не маскируют её отсутствие.

Обсуждая доступность со специалистами по тестированию и сертификации государственных сайтов, я пришёл к простому выводу: оценивать нужно возможность воспользоваться сервисом. Человек должен суметь прочитать условия, заполнить форму и получить результат — без необходимости сначала искать специальную версию сайта.

Удобный для меня — ещё не доступный

Представим запись на консультацию. Крупный текст, выразительные цвета, понятная кнопка. Но дату можно выбрать только перетаскиванием, ошибка помечается одним красным контуром, а подтверждение появляется на две секунды без объявления. Визуально аккуратный экран не позволяет части людей завершить запись.

Доступность касается не только зрения. Важны управление без точной моторики, восприятие без звука, понятные инструкции, возможность читать в своём темпе и использовать вспомогательные технологии. Ситуативные ограничения делают многие из этих решений полезными широкой аудитории. Но это не повод растворять потребности людей с инвалидностью в общей фразе «удобно всем».

Три слоя, которые нельзя подменять друг другом

Основа: содержимое, семантика, управление и обратная связь доступны в основном интерфейсе. Совместимость: сайт сохраняет работу при увеличении, изменении системных цветов и использовании скринридера. Персонализация: человек выбирает комфортное представление — например, тему или плотность текста.

Это наша рабочая модель проектирования, а не новая классификация WCAG. Её смысл прост: переключатель темы не исправляет кнопку, которую невозможно нажать с клавиатуры. И наоборот, корректная кнопка не отменяет пользу индивидуальных настроек.

Основа: смысл, управление, обратная связь. Совместимость: браузер и вспомогательные технологии. Настройки: индивидуальный комфорт.
Три слоя доступного UI. Персонализация дополняет основу, а не заменяет её.

Что не так с «версией для слабовидящих»

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

Но сам факт наличия настроек ничего не доказывает о компетентности команды. Нельзя утверждать, что каждый человек с нарушением цветового зрения уже настроил системные фильтры или что увеличение средствами сайта никому не нужно. Потребности, устройства и навыки различаются. Наша проектная позиция: сначала исправить базовый интерфейс, затем предложить полезную персонализацию.

Не стоит и выдавать эту позицию за буквальный запрет WCAG на альтернативные представления. Стандарт описывает условия для соответствующих альтернативных версий. Это более строгое понятие, чем наличие кнопки переключения темы: нужно проверить эквивалентность информации, функциональности и доступность перехода.

Четыре мифа, которые мешают исправлять продукт

  • «Добавим виджет — получим доступность». Сначала проверим, что изменилось в реальных сценариях. Цветовой фильтр сам по себе не сообщает причину ошибки формы и не задаёт осмысленное имя кнопке.
  • «Нужен только хороший контраст». Читаемая подпись не спасает управление, доступное исключительно мышью.
  • «Чем больше ARIA, тем лучше». Неверная роль может скрыть исходный смысл элемента. Предпочтительнее корректный HTML с необходимыми, а не максимальными дополнениями.
  • «Автотест зелёный — работа закончена». Автоматизация проверяет часть условий. Она не заменяет прохождение сценария человеком.

Последние два ограничения прямо разбирают ARIA Authoring Practices и руководство WAI по инструментам проверки.

WCAG — действительно официальный стандарт?

WCAG выпускает W3C. Статус W3C Recommendation означает зрелую спецификацию, рекомендованную как веб-стандарт. WCAG 2.2 также принят как ISO/IEC 40500:2025; W3C сообщил об этом 21 октября 2025 года. Это не просто совет одного блогера или производителя скринридера.

Однако стандарт и закон — разные вещи. Применимая версия, уровень соответствия, круг организаций и сроки определяются конкретной юрисдикцией, договором или процедурой закупки. Нельзя универсально утверждать «всем сайтам по закону нужен WCAG 2.2 AA».

Для новой разработки разумно зафиксировать WCAG 2.2 AA как инженерную цель, если требования проекта не задают другое. AA включает применимые критерии A и AA; это не средняя оценка и не процент успешных проверок. При этом соответствие стандарту не означает удовлетворение абсолютно всех индивидуальных потребностей.

Как превратить принцип в рабочее решение

Для каждого ключевого действия записывайте четыре вещи: что человек хочет сделать; какой барьер мешает; что меняем; как проверяем результат. Например: «Выбрать дату → календарь работает только мышью → добавить клавиатурное управление и понятный ввод даты → пройти запись без мыши и проверить озвучивание выбранного дня».

Так появляется проверяемое требование вместо декоративного обещания. Начинайте с входа, поиска, заявки, оплаты, отмены и восстановления после ошибки. Успех — не количество специальных кнопок, а возможность самостоятельно пройти весь путь.

Скилл для Codex и Claude Code

По результатам исследования мы создали открытые скиллы для Codex и Claude Code, которые помогают анализировать и улучшать сайты и приложения. Accessible UI направляет агента при проверке семантики, клавиатурного управления, фокуса, форм и контраста; Adaptive Interfaces помогает адаптировать интерфейс к размерам окна, масштабу текста, клавиатуре и складным устройствам. Агент изучает текущий проект, предлагает обоснованные улучшения и проверяет согласованные изменения. Скиллы не заменяют проверку с пользователями и вспомогательными технологиями.

Если вы разрабатываете интерфейсы с ИИ, можно установить скилл Accessible UI из GitHub. В нём собраны практические правила этой серии: семантика, клавиатура, фокус, формы, контраст и проверка результата. Инструкции написаны на английском.

Установка из GitHub: в Codex можно передать эту команду встроенному установщику скиллов:

$skill-installer install https://github.com/wladislaw353/agent-skills/tree/main/skills/accessible-ui

Для Claude Code вся коллекция устанавливается как плагин из этого же репозитория. Инструкция для Claude Code на GitHub содержит команды установки, обновления и вызова каждого скилла. При установке плагином используется имя вида /agent-skills:accessible-ui; при ручной установке отдельного скилла — /accessible-ui.

Для ручной установки склонируйте репозиторий с GitHub. Содержимое папки skills/accessible-ui разместите в каталоге выбранного инструмента:

  • Codex: ~/.agents/skills/accessible-ui/
  • Claude Code: ~/.claude/skills/accessible-ui/

Файл SKILL.md должен находиться непосредственно внутри accessible-ui. После установки откройте новую сессию. Для явного вызова используйте $accessible-ui в Codex CLI или расширении для IDE, либо /accessible-ui в Claude Code.

Источники и статус стандартов проверены 5 ноября 2026 года.