AI находит баги в доступности. Но кто решает, как их чинить?

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

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

Состояние дел

ИИ стремительно меняет подход к ремедиации доступности — процессу выявления и исправления нарушений стандартов WCAG (Web Content Accessibility Guidelines). Сегодня модели умеют находить типовые ошибки в интерфейсах, объяснять их природу и даже генерировать патчи. Это работает, и это полезно.

Но «найти нарушение» и «решить, как его исправить» — это разные задачи. И разница между ними не всегда очевидна, потому что ИИ-модель может сгенерировать ответ, который выглядит убедительно, формально корректен и при этом ломает взаимодействие для пользователя вспомогательных технологий. Ошибки такого рода не видны на уровне кода — они проявляются только в контексте реального использования.

Реальный пример: combobox с поиском

Наглядная иллюстрация проблемы — разработка доступного предиктивного поиска для витрины Shopify. Задача типовая: combobox с выпадающим listbox, поддержка скринридеров, навигация с клавиатуры.

На этапе детекции ИИ показал себя хорошо. Модель правильно определила паттерн взаимодействия, нашла реальные баги в JavaScript темы и сделала это быстрее, чем удалось бы вручную:

• навигация стрелками по подсказкам не работала вовсе;
• обработчик Escape полностью стирал введённый пользователем запрос;
• live region переключалась через aria-hidden вместо того, чтобы постоянно присутствовать в DOM, из-за чего разные скринридеры вели себя непредсказуемо.

Всё это — настоящие ошибки, которые нужно исправлять. Детекция сработала.

Где начало ломаться

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

Первый случай. ИИ предложил перенести подсказки поиска в отдельную область, доступную по клавише Tab. На первый взгляд разумно: Tab — стандартный способ перехода между элементами. Но в combobox Tab перемещает фокус за пределы виджита. Пользователь, навигирующий по подсказкам стрелками, не должен «табнуть» в отдельную область, чтобы их увидеть. Модель определила правильный паттерн взаимодействия, а затем предложила исправление, которое этому паттерну противоречит.

Второй случай. Внутри одного listbox оказались два типа элементов с принципиально разным поведением. Одни варианты вели на страницу товара (и отображали изображение и название), другие — перезаписывали поисковый запрос (и содержали только текст запроса). Визуально различие очевидно: зрячий пользователь мгновенно отличает карточку товара от текстовой подсказки. Но модель взаимодействия listbox подразумевает однородные опции. Когда «опции» выполняют фундаментально разные действия, паттерн перестаёт соответствовать реальности. Правильным решением было не «допиливать» текущий listbox до соответствия стандартам, а переосмыслить архитектуру взаимодействия.

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

Почему это опасно

Главная проблема — не в том, что ИИ ошибся. Ошибаются все. Проблема в том, что неверные исправления пришли с точно такой же уверенностью и беглостью, как правильные. Ничто в ответе модели не сигнализировало: «этот вариант, скорее всего, неправильный».

Если бы разработчик, принимающий патч, не понимал, как фокус перемещается внутри combobox, или не задумывался о том, какая информация реально доходит до пользователя скринридера через accessibility tree, оба исправления могли попасть в продакшен. И оба ухудшили бы опыт для людей, для которых доступность — не абстрактное понятие, а единственный способ пользоваться интерфейсом.

Формулирую тезис отдельно, потому что он критически важен: детекция — не суждение. Беглость генерации — не суждение. Модель может точно цитировать WCAG 2.1, знать спецификацию ARIA и генерировать валидный HTML, не обладая при этом способностью проследить, как предложенное исправление повлияет на реального человека с конкретным типом нарушения.

Откуда берётся экспертное суждение

Корректировки в описанном случае пришли не из знания критериев WCAG и не из подглядывания в документацию ARIA. Они пришли из понимания того, как взаимодействие реально работает для человека, использующего вспомогательные технологии.

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

Где место ИИ в процессе

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

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

1. ИИ детектирует — находит нарушения, классифицирует их, объясняет, какие критерии WCAG затронуты.
2. ИИ предлагает — генерирует варианты исправлений, черновики кода.
3. Инженер оценивает — проверяет предложенное решение в контексте реального приложения, анализирует, не противоречит ли патч модели взаимодействия.
4. Пользователи с инвалидностью тестируют — финальная проверка того, что исправление действительно улучшает опыт, а не просто формально соответствует стандарту.

Ни один из этих шагов нельзя исключить без потери качества результата. Первые два ИИ делает быстрее и дешевле человека. Последние два ИИ выполнить принципиально не способен.

Итого

ИИ — мощный инструмент для accessibility-ремедиации. Он ускоряет детекцию, снижает порог входа для разработчиков и помогает не упустить типовые ошибки. Но между «найти нарушение» и «исправить опыт» лежит зона, которая требует суждения, контекста и человеческого опыта. Модель может уверенно предложить исправление, которое формально соответствует стандарту и при этом ломает взаимодействие для конкретного пользователя. Именно поэтому эксперт и конечный пользователь должны оставаться частью процесса — не как бюрократическая надстройка, а как единственный способ убедиться, что результат работает на практике, а не только в терминале.