Как проверить доступность страницы с помощью ИИ

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

Что даёт итоговый документ и где его границы

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

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

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

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

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

Сбор и проверка исходных данных

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

Порядок сбора:

1. Откройте страницу в браузере и найдите нужный компонент.
2. Скопируйте разметку компонента из инструментов разработчика.
3. Убедитесь, что фрагмент самодостаточен: видны теги формы, поля, подписи, кнопки.
4. Сохраните фрагмент в текстовый файл, чтобы правки было видно построчно.
5. Отдельно выпишите, какие стили и скрипты к компоненту применяются, если они влияют на поведение.

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

Документация MDN по HTML и доступности подчёркивает: значительная часть контента становится доступной за счёт использования правильных элементов HTML по их прямому назначению. Этот принцип задаёт направление разбора — искать места, где элемент выбран не по смыслу.

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

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

Готовый заполненный учебный артефакт

Ниже — учебный пример. Все условия вымышлены; измерения на странице и проверка соответствия стандартам не выполнялись.

Исходная разметка формы:

<form>
  <div>Email</div>
  <input id="email" type="email">
  <div onclick="send()">Отправить</div>
</form>

Разбор даёт два обоснованных замечания. Первое: подпись не связана с полем через label, поэтому программная связь между текстом «Email» и полем ввода отсутствует. Второе: div не имеет нативной семантики кнопки, у него нет роли кнопки и встроенной клавиатурной активации.

Исправленная основа:

<form>
  <label for="email">Email</label>
  <input id="email" name="email" type="email">
  <button type="submit">Отправить</button>
</form>

Что изменилось по существу. Текст подписи связан с полем через атрибут for и идентификатор. Кнопка отправки стала элементом button, который браузеры наделяют встроенной клавиатурной доступностью. Появился атрибут name у поля — он нужен для отправки значения формы. Показана семантическая основа компонента. Исходный вызов send() в ней не воспроизведён: перед применением разработчик должен подключить существующую логику отправки к форме и отдельно проверить её поведение. Полного кода обработчика во входе нет.

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

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

Ручной план проверки для этого примера: клавиша Tab переводит фокус с поля на кнопку; кнопка активируется с клавиатуры; сообщение об ошибке понятно и связано с полем. Фактический результат этих проверок в учебном примере не получен — его получают на реальной странице.

Копируемый промпт с указанными входами

Промпт, чтобы получить первичный разбор переданного HTML и список ручных проверок:

Ты помогаешь подготовить первичный разбор доступности одного фрагмента HTML.

Вход:
- Фрагмент HTML: [вставьте разметку компонента]
- Контекст: [название компонента, страница, назначение]
- Известные ограничения: [что вы не передаёте — CSS, скрипты, данные о пользователях]

Задача:
1. Найди замечания, которые подтверждаются только переданным фрагментом.
2. Для каждого замечания укажи: фрагмент разметки, основание, минимальную правку, ручную проверку.
3. Отдельным списком перечисли, что по этому фрагменту проверить нельзя.
4. Не оценивай контраст без CSS.
5. Не выставляй статус соответствия WCAG.
6. Не делай выводов о всей странице или сайте.

Формат ответа:
- Замечания: таблица с колонками «Фрагмент», «Основание», «Минимальная правка», «Ручная проверка».
- Неизвестные данные: маркированный список.
- Итог: одна фраза о том, что разбор охватывает только переданный фрагмент.

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

Вариации той же задачи:

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

Отрицательный пример и неизвестные данные

Отрицательный пример — вывод «сайт полностью доступен после двух правок». Такой вывод отводится. Две правки касаются одного фрагмента и не покрывают ни контраст, ни фокус, ни порядок страницы, ни работу скринридера.

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

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

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

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

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

Ручная проверка результата по исходнику

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

Порядок ручной проверки:

1. Сравните исходный и исправленный фрагменты построчно.
2. Убедитесь, что подпись связана с полем через label и атрибут for.
3. Убедитесь, что интерактивный элемент имеет нативную семантику кнопки.
4. Откройте страницу в браузере и пройдите компонент клавишей Tab.
5. Проверьте активацию кнопки с клавиатуры.
6. Проверьте, что сообщение об ошибке понятно и связано с полем.
7. Проверьте контраст по стилям страницы.
8. Проверьте компонент скринридером.

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

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

Чек-лист WebAIM по WCAG различает требования по типу медиа и уровню. Для прямых трансляций со звуком он указывает синхронизированные субтитры. Для записанного видео на уровне A он описывает альтернативу: описательная расшифровка или аудиоописание, если значимая визуальная информация отсутствует в звуке. На уровне AA аудиоописание проверяют отдельно; описательная расшифровка в дополнение к нему рекомендована WebAIM. Для таблиц данных проверяют связь ячеек с заголовками.

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

Сохранение и согласование результата

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

Форма фиксации:

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

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

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

Частые вопросы

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

Какие данные нужно передать модели?
Передайте разметку одного компонента, его назначение и список ограничений. Укажите, что CSS и скрипты не приложены. Так модель не станет оценивать контраст и поведение ошибок по догадке.

Почему ИИ не может оценить контраст по фрагменту HTML?
Цвета текста, фона и интерактивных элементов приходят из стилей. В переданной разметке их нет, поэтому суждение о контрасте опирается на предположение. Контраст проверяют по стилям страницы.

Что делать с выводом «сайт полностью доступен»?
Отвести такой вывод. Он выходит за рамки переданного фрагмента. В задании заранее запретите статус соответствия WCAG и выводы о сайте целиком.

Как сохранить результат разбора?
Соберите три части: замечания по фрагменту, список неизвестных данных, журнал ручных проверок. Храните исходный и исправленный фрагменты рядом с журналом, чтобы правки оставались объяснимыми.