Команды повсеместно спешат внедрять AI-агентов, и вместе с этим возникает распространенное предположение: будто эти агенты достаточно умны, чтобы сразу обеспечивать доступность. Это не так, и причина очевидна: AI-агенты не живут с инвалидностью. Люди живут.

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

Вот о чем мы поговорим:

Почему AI не может решить проблему доступности Проектирование AI-интерфейсов с учетом различных видов инвалидности Превращение исследований доступности в требования к дизайну Тестирование доступности на трех уровнях Пробелы в доступности — это пробелы в процессах

Почему AI не может решить проблему доступности

AI-агенты обучаются на существующем веб-пространстве, а веб не отличается особой доступностью. Согласно отчету WebAIM за 2026 год по accessibility of the top 1,000,000 home pages, 95% из миллиона протестированных сайтов имеют как минимум одно нарушение руководства по обеспечению доступности веб-контента (WCAG) только на своей главной странице. Автоматизированные инструменты тестирования, на которые большинство команд полагается для выявления этих проблем, обнаруживают лишь около 30–40% сбоев по критериям успешности WCAG.

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

Все это не означает, что AI не может создавать доступные решения. Это значит, что мы должны четко объяснить ему, как выглядит «хорошо». И это должно основываться на том, как на самом деле работают реальные люди.

Наверх

Углубитесь в тему

Проектирование AI-интерфейсов с учетом различных видов инвалидности

Чтобы создавать решения осознанно, мы начинаем не с промпт-инжиниринга. Мы начинаем там, где хороший дизайн начинался всегда: с людей. Наш подход делится на три шага.

1. Расширьте свои персоны с учетом аспектов инвалидности

У вас, скорее всего, уже есть персоны. Расширьте их по трем направлениям:

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

Пример: Джеймс, программный аналитик в федеральном ведомстве, который хочет, чтобы Agentforce помогал ему быстрее обобщать объемные отчеты. Как базовый пользователь, он испытывает типичное разочарование: агентский контент, в котором отсутствует контекст и прозрачность относительно того, как AI использует его инструкции.

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

2. Определите доступные задачи для выполнения (Jobs to be Done)

Стандартная задача для Джеймса может звучать так: «При анализе объемного отчета по программе я хочу, чтобы Agentforce обобщал выводы и заполнял поля аудита, чтобы я мог быстрее завершить оценку». Это хорошее начало, но в нем есть то, что мы называем разрывом с реальностью AI: оно не учитывает, что происходит, когда Джеймс вообще не может воспринять обновление.

Доступная версия сохраняет его цель, но формулирует реальное требование: «Я хочу, чтобы моей программе чтения с экрана предоставлялись краткие сводки о том, что изменилось, чтобы я знал, когда происходят обновления, и чтобы мое положение сохранялось, так я смогу проверять выводы и быстрее отправлять свою оценку, не теряя ориентации». Задача та же. Более четкое и честное определение того, чего требует успех.

3. Тестируйте с реальными пользователями вспомогательных технологий, а не с помощью симуляций

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

Наверх

Превратите исследования доступности в требования к дизайну

Как только вы объединили расширенную персону с доступной задачей, вы можете написать инклюзивные критерии приемки: обычно это от трех до пяти бинарных утверждений об успешности или неудаче, по меньшей мере одно из которых охватывает крайний случай (edge case), структурированные следующим образом:

Дано [человек в контексте]

Когда [совершается действие]

Тогда [происходит ожидаемый результат].

Например:

Пользователи программ чтения с экрана: Дано: пользователь VoiceOver перемещается по динамическому обновлению задачи Agentforce; когда AI заканчивает генерацию ответа, динамическая область сообщает пользователю, что ответ доступен.
Пользователи, использующие только клавиатуру: Дано: пользователь, использующий только клавиатуру, перемещается по рабочему процессу Agentforce; когда в отчете агента появляются элементы действий, все действия доступны в рамках стандартного порядка перехода по клавише Tab с областями касания размером не менее 44×44 пикселей.

Внедряйте эти критерии напрямую в свои промпты и объединяйте их с явным запросом на защитные механизмы Lightning Design System 2 Salesforce. Такая комбинация гарантирует, что модель включает параметры доступности потому, что вы ей об этом сказали, а не потому, что вы надеетесь, будто она вывела их правильно.

AI может ускорить разработку. Он может написать код. Чего он не может делать, так это быть человеком у руля. Эта часть по-прежнему остается за нами.

Наверх

Тестируйте доступность на трех уровнях

Инструменты автоматизированного тестирования — это ваша база, а не предел. Они отлично подходят для выявления синтаксических ошибок и проблем с контрастностью до выпуска кода, но помните, что они тестируют лишь 30–40% существующих сбоев по критериям успешности WCAG. Комплексный подход к тестированию состоит из трех уровней:

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

Наверх

Пробелы в доступности — это пробелы в процессах

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

Проектирование таким образом не просто помогает людям с инвалидностью — оно создает более плавный и интуитивно понятный интерфейс для каждого.

Наверх