Просмотр веб-страниц агентами — задача, которая до сих пор не имеет идеального решения. Несмотря на прогресс, агенты часто ошибаются даже в простых случаях. Поскольку языковые модели (LLM) изначально работают с текстом, первые подходы сводились к передаче чистого HTML. К удивлению скептиков, это работало — хотя и с ограничениями.

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

Сейчас чемпионом в распознавании интерфейсов считается GPT-5.2 с точностью около 86%. Но средняя точность вводит в заблуждение: агенты легко нажимают на кнопки, но застревают на элементах вроде date picker’ов. Кроме того, анализ изображений требует огромного количества токенов, а отслеживание изменений на экране превращается в технический кошмар.

ARIA — стандарт, родившийся из необходимости

В 2014 году W3C выпустила стандарт WAI-ARIA 1.0. Он появился как ответ на хаос в веб-интерфейсах: сайты стали наполняться кастомными элементами на JavaScript, построенных из <div>, что делало их недоступными для экранных читалок.

ARIA добавляет в HTML три ключевых атрибута:

• roles — определяет тип элемента (кнопка, поле ввода и т.д.);
• names — задаёт читаемое имя;
• states — отражает текущее состояние (выбрано, развернуто, отключено).

Изначально стандарт игнорировали, пока законодатели в Европе не обязали государственные сайты быть доступными. Позже к этому присоединились США и крупные корпорации. Google внедрил полноценную поддержку accessibility tree в Chrome DevTools в 2021 году, что дало надежду на универсальное решение для AI.

Почему ARIA — не панацея

Несмотря на потенциал, ARIA имеет серьёзные ограничения:

1. Кросс-браузерная несовместимость. Работает стабильно в Chrome, но плохо в Firefox и WebKit.
2. Ориентация на людей. Экранные читалки оптимизированы под восприятие человеком, а не под LLM. У моделей другой контекст и способ мышления.
3. Ограниченная поддержка изменений. Сложно отслеживать динамические обновления интерфейса.
4. Зависимость от Google. Playwright, разработанный бывшими сотрудниками Google, перешёл в Microsoft, чтобы избежать привязки к Chrome и Puppeteer.

Playwright и его собственное решение

Разработчики Playwright создали собственный кросс-браузерный механизм, не зависящий от Chrome API. Он внедряет JavaScript в страницу, анализирует DOM и строит ARIA-снэпшот — структурированное представление интерфейса, оптимизированное для LLM.

Результат — YAML-дерево без CSS, лишних классов и визуальной шумихи. Только семантика. Каждый элемент описывается через:

• Роль — возможность взаимодействия (кнопку можно нажать, чекбокс — переключить).
• Имя — человекочитаемый идентификатор, вычисляемый по цепочке: aria-labelledby → aria-label → <label> → текст элемента → title → placeholder.
• Состояние — динамические флаги: [checked], [expanded], [disabled], [selected], [pressed].

Элемент без aria-label и текста остаётся невидимым для агентов. Добавьте aria-label="Save" — и проблема решается.

Уникальные фичи Playwright для AI

Playwright добавляет специальные возможности, недоступные в обычных ARIA-деревьях:

• ref-идентификаторы — каждый элемент получает уникальный ID, который агент использует для взаимодействия. Не нужно гадать с XPath или CSS-селекторами.
• Инкрементальные различия — после первого полного снимка передаются только изменения. Это снижает объём данных на 94%: с ~5 КБ до менее чем 300 байт.

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

Сложности под капотом

Создание семантического снимка — сложнее, чем кажется. Playwright обрабатывает множество краевых случаев:

• <template> и <slot> — отображается финальный результат, а не шаблоны.
• aria-owns — учитывает логические связи между элементами, даже если они разнесены в DOM.
• ::before и ::after — их содержимое включается в снимок, если оно видимо.
• Фильтрация скрытых элементов — display: none, visibility: hidden, aria-hidden="true", элементы с нулевыми размерами не попадают в снимок.

Особенно сложен aria-owns: он требует построения виртуального дерева, не совпадающего с DOM — по сути, графовой структуры. При этом Playwright придерживается строгой позиции: сайты должны соответствовать стандартам, а не браузер подстраиваться под них. Поэтому, например, поля под модальным окном могут оставаться «активными» — хотя в реальности пользователь не сможет до них добраться.

Слепые зоны ARIA

ARIA-снимки не передают:

• Визуальный дизайн — цвета, отступы, иконки. Красное сообщение об ошибке и зелёное уведомление о успехе выглядят одинаково.
• Пространственные отношения — «кнопка под формой» или «рядом»? Дерево не хранит информацию о расположении. Некоторые агенты экспериментируют с bounding-box, но это не стандарт.
• Canvas / WebGL — игры, графики, визуализации остаются невидимыми, если разработчик не добавил ARIA-атрибуты.
• Неявная визуальная семантика — выделенная строка через CSS не будет распознана, если не задана как ARIA-состояние.

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

Сравнение агентов

• Claude (MCP) — использует Playwright ARIA-снимки + инкрементальные различия.
• GitHub Copilot — с 2026 года перешёл на Playwright + ARIA.
• ChatGPT Browsing — анализирует DOM напрямую.
• Anthropic Computer Use — полагается на скриншоты, не специализирован под веб.
• Другие агенты — комбинируют анализ HTML и скриншоты.

Практически все могут использовать скриншоты как fallback. Главная тенденция — миграция на Playwright и ARIA-снимки.

Кумулятивный эффект стандартизации

Playwright сделал ARIA-снимки каноническим форматом для агентов. Это создаёт положительный цикл:

Агенты стандартизируются на ARIA → разработчики улучшают доступность → ARIA-снимки становятся точнее → агенты работают надёжнее → больше агентов принимают стандарт.

Сообщество инклюзивности 20 лет убеждало разработчиков писать семантический HTML. Экономика AI может добиться того же за два года.

Что это значит

Дерево доступности больше не просто требование к соответствию стандартам. Оно становится де-факто API для взаимодействия с вебом.

• Для AI-инженеров: если агент полагается на визуальные данные, вы теряете деньги и производительность. Лучшая архитектура — «семантика в первую очередь, визуал как fallback».
• Для веб-разработчиков: ваш следующий «пользователь» — робот. Кнопка с иконкой без aria-label — это баг сразу в двух измерениях: для людей и для AI.
• Для индустрии: ARIA-снимки обеспечивают совместимость. Одна и та же страница работает одинаково для Claude, Copilot, Browser-Use и будущих агентов. Это редкое единство в разрозненной индустрии.
• Для тестирования: можно писать семантические тесты, устойчивые к редизайну. Например: «На странице должен быть отмеченный чекбокс с меткой “Email notifications”» — это и проверка, и спецификация одновременно.

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

Эта простая задача до сих пор не имеет 100% надёжного решения  - и агенты часто спотыкаются на совсем простых и очевидных вещах.Так как типичная LLM обучена работать с  текстом, первые попытки были просто давать модели чистый HTML. И как не странно, это даже работало, причём надёжнее, чем ожидалось скептиками. Можно придумать 1000+ доказательств ущербности этого подхода, но это достаточно для 90% задач, когда надо просто прочитать текст, например новости или пост. Сразу же появились различной степени эффективности фильтры, убирающие «лишнее» в этой простыне.В случае факапа АИ переключалась на модели, заточенные на распознавание скриншотов.Я не нашёл ни одной production-ready web-ориентированной системы,  опирающейся исключительно на  скриншоты. Это остаётся уделом  систем для работы с desktiop-приложениями. Спойлер: там тоже не всё хорошо, чемпион сейчас GPT-5.2 cо средней 86% точностью. Но точность на то и средняя, что в кнопки АИшка попадает обычно  первого раза, зато потом долго тупит на date picker‘ах. Расход токенов тоже не радует, а отслеживание изменений на экране открывает портал в ад, настолько там много подводных камней.

Одновременно в параллельной вселенной существовали E2E тесты, которые имитировали живых юзеров, нажимали на кнопки и заполняли поля. И этим тестам тоже как-то надо было отслеживать изменения на экране. Например, чтобы понять, что разработчик Вася переделал форму и не сообщил тестерам. Сравнение скиншотов оказалось крайне не надёжным методом. Тут разработчики Playwright – это известный open source фреймворк для E2E тестов, под крылом Microsoft - вспомнили про  ARIA и экранные читалки.

ARIA – случайный успех

В далёком 2014 W3C опубликовала первый стандарт WAI-ARIA 1.0. В то время все хотели WEB 2.0 но мало кто знал как его делать правильно. В результате интернет наводнили сайты с кастомными реализациями выпадающих меню, панелей и прочего JavaScript - UI. Внутри был винегрет из