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

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

Ключевые выводы

Зафиксируйте версию сайта, целевой уровень WCAG, браузеры, размеры окна, вспомогательные технологии и границы проверки.

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

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

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

Никогда не превращайте сводку ИИ или балл одного сканера в заявление о соответствии.

Что действительно устанавливает проверка доступности?

WCAG 2.2 определяет проверяемые критерии успеха, сгруппированные по принципам воспринимаемости, управляемости, понятности и надёжности.［1］ Проверка может собрать доказательства того, выполняет ли продукт в выборке применимые критерии в протестированных условиях. Её вывод ограничен версией, областью, выборкой, методами тестирования и использованными технологиями.

Методология W3C WCAG-EM задаёт структурированный подход: определить область, изучить объект, выбрать репрезентативную выборку, проверить её и сообщить о результатах.［2］ Она не делает небольшое автоматическое сканирование равноценным полной оценке.

Используйте такой заголовок проверки:

Поле	Что фиксировать
ID и версия проверки	Устойчивая идентичность и история изменений
Граница продукта	Домены, приложение, области с аутентификацией и исключённые системы
Идентичность сборки	Коммит, релиз, развёртывание, снимок контента и дата проверки
Цель	Версия WCAG, уровень соответствия и дополнительные требования политики
Технологии	HTML, CSS, JavaScript, документы, медиа и сторонние компоненты
Среды	Браузер, ОС, размер окна, масштаб, способ ввода и вспомогательные технологии
Выборка	Шаблоны, страницы, состояния, сценарии, компоненты и случайно выбранные страницы
Проверяющие	Автоматический инструмент, ручной проверяющий, специалист и участники-пользователи
Ограничения	Недоступные среды, заблокированные состояния и непроверенные интеграции

Не начинайте с просьбы к ИИ «проверить этот сайт». Без зафиксированной границы ответ не сможет отличить отдельное наблюдение от полной оценки.

Шаг 1. Определите цель и заморозьте продукт

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

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

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

Шаг 2. Создайте репрезентативный перечень

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

Составьте выборку, которая охватывает:

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

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

Если диаграммы занимают центральное место, согласуйте работу с процессом визуализации данных. Альтернативные описания, таблицы данных, кодирование без опоры только на цвет, взаимодействие с клавиатуры и поведение фокуса требуют доказательств дизайна и реализации, а не одной подписи, созданной ИИ.

Шаг 3. Используйте автоматические проверки только для поиска кандидатов

Автоматические инструменты полезны для детерминированных шаблонов: отсутствующих доступных имён, неверных связей, части ошибок контраста, дублирующихся ID, некорректной структуры и выявляемых ошибок ARIA. W3C прямо отмечает, что инструменты помогают, но не могут сами определить доступность: нужно человеческое суждение.［3］

Для каждого запуска сохраняйте инструмент и его версию, конфигурацию, набор правил, URL или компонент, среду, метку времени, исходный результат и сборку продукта. Убирайте дубли только после сохранения исходных доказательств. Одно и то же правило на 200 страницах может означать один дефект общего компонента или множество независимых дефектов контента.

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

Автоматические проверки дают и ложноположительные, и ложноотрицательные результаты. У кнопки может быть программное имя, но оно может оставаться неоднозначным. Диалог может использовать корректный ARIA и при этом удерживать фокус. Страница может пройти все правила сканера, но инструкции на ней останутся непонятными.

Шаг 4. Вручную проверьте клавиатуру, фокус, масштаб и формы

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

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

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

Записывайте доказательства так, чтобы другой проверяющий мог их воспроизвести:

Поле записи	Содержание
ID проблемы	Устойчивый идентификатор
Страница или компонент	Каноническое расположение и версия компонента
Среда	Браузер, ОС, размер окна, способ ввода и вспомогательные технологии
Критерий	Применимый критерий успеха WCAG и целевой уровень
Шаги	Минимальный путь к наблюдаемому поведению
Ожидаемое	Доступное поведение, наблюдаемое пользователем
Фактическое	Что произошло, без догадок о причине
Влияние на пользователя	Задача и затронутое взаимодействие, а не только дефект кода
Доказательства	Одобренные снимок экрана, запись, фрагмент DOM или результат инструмента
Область	Один случай, шаблон, компонент или неизвестно
Приоритет	Обоснование по влиянию, частоте, охвату и обходному пути
Владелец и статус	Ответственная команда и состояние процесса
Повторная проверка	Сборка, среда, результат, проверяющий и дата

Шаг 5. Тестируйте со вспомогательными технологиями

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

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

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

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

Шаг 6. Привлекайте пользователей, не перекладывая ответственность

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

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

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

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

Шаг 7. Проверка веб-доступности с помощью ИИ требует ограниченной задачи

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

Упорядочь предоставленные наблюдения о доступности по обязательным полям записи о проблеме.
Сохрани ID страниц, среды, шаги, ссылки на доказательства и заметки проверяющих.
Не заявляй соответствие WCAG, не назначай критерий без подтверждения проверяющего,
не придумывай влияние на пользователя, не делай выводов об инвалидности и не меняй результаты проверки.
Неуверенные сопоставления помечай [REVIEW], возможные дубли — [POSSIBLE DUPLICATE].
Прежде чем писать рекомендации по исправлению, перечисли недостающие доказательства и противоречия.

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

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

Шаг 8. Приоритизируйте по влиянию на пользователя и системному охвату

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

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

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

Шаг 9. Проведите ретест и укажите ограничения

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

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

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

Что делает проверку обоснованной?

Итоги

Определите стандарт, продукт, выборку и среды до тестирования.
Сочетайте автоматический поиск с ручной оценкой и оценкой со вспомогательными технологиями.
Привлекайте пользователей с инвалидностью, не выдавая одно исследование за сертификацию.
Используйте ИИ для упорядочивания очищенных доказательств, а не для создания влияния или соответствия; проверяйте его результат под явной ответственностью человека.［5］
Приоритизируйте воспроизводимые препятствия и системный охват.
Проверяйте повторно всю задачу и честно сообщайте об ограничениях.

Часто задаваемые вопросы (FAQ)

Может ли ИИ выполнить полный аудит доступности?

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

Доказывает ли высокий автоматический балл соответствие WCAG?

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

Какие страницы включать в выборку?

Все основные шаблоны и критические сценарии, общие компоненты, формы и ошибки, адаптивные состояния, медиа или документы, сторонние интеграции и случайно выбранные обычные страницы. Записывайте исключённые или недоступные области.

Какие вспомогательные технологии тестировать?

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

Может ли ИИ сопоставлять находки с критериями WCAG?

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

Как обрабатывать дублирующиеся находки сканера?

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

Заменяет ли тестирование с пользователями проверку по стандарту?

Нет. Оценка пользователями выявляет реальные препятствия и стратегии, а проверка по стандарту даёт систематическое покрытие критериев. Эти методы дополняют друг друга.

Что нужно, чтобы закрыть проблему?

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

Материал носит общий характер и не является юридической консультацией или сертификацией доступности. Применимые обязательства и формальные заявления о соответствии требуют квалифицированной проверки с учётом юрисдикции.

Источники

W3C, Web Content Accessibility Guidelines (WCAG) 2.2 — https://www.w3.org/TR/WCAG22/
W3C, Website Accessibility Conformance Evaluation Methodology — https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/
W3C, Web Accessibility Evaluation Tools Overview — https://www.w3.org/WAI/test-evaluate/tools/
W3C, Involving Users in Web Accessibility Evaluation — https://www.w3.org/WAI/test-evaluate/involving-users/
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 4 сентября 2026 г.

Проверка веб-доступности с помощью ИИ: выборка и ретест