A11yn: обучение LLM генерировать доступный веб-код через reward-сигнал из WCAG-аудита

[Один цикл обучения GRPO]

1. ROLLOUT
 Запрос UI → Policy модель генерирует 6 вариантов кода
 
2. REWARD
 Каждый код → Axe-core находит нарушения WCAG
 → Penalty = Σ(количество_узлов × вес_серьёзности)
 → Reward = 2.0 - Penalty (clip to 0)
 
3. UPDATE
 GRPO нормализует rewards внутри группы из 6
 → Advantage = (reward - mean) / std
 → Обновляет веса модели в сторону кода с меньшими нарушениями
 
[Повторить ~6800 раз × 2 эпохи]

Важно: Метод требует fine-tuning инфраструктуры (8× A6000 GPU, vLLM, Axe-core в headless Chrome). Но принципы и список нарушений применимы в промптинге.

Хотя A11yn — это система fine-tuning, из исследования можно извлечь конкретные требования WCAG, которые работают в обычном чате:

1. Region landmarks (894→143 violations)
   • Весь контент страницы должен быть внутри <main>, <nav>, <header>, <footer>
   • Screen readers используют landmarks для быстрой навигации по секциям
2. Color contrast (702→418 violations)
   • Минимум 4.5:1 контраст между текстом и фоном (WCAG 2.0 AA)
   • Критично для слабовидящих пользователей
3. Landmark-one-main (164→17 violations)
   • Ровно один <main> landmark на странице
   • Определяет основной контент для assistive technologies
4. Link names (129→47 violations)
   • Каждая ссылка должна иметь дескриптивный текст
   • ❌ "click here", "read more"
   • ✅ "Скачать отчёт Q3 2024", "Перейти к статье про GRPO"
5. Image alt text (Table 7 rules)
   • Все <img> должны иметь alt="описание"
   • Декоративные изображения: alt="" или role="presentation"

• ARIA attributes: используй правильные роли и атрибуты (Tables 6, 17)
• Forms: каждый <input> с <label> (Table 10)
• Headings: иерархия <h1> → <h2> → <h3> (Table 19)
• Buttons: текст внутри или aria-label (Table 10)

Задача: Создать лендинг для российского EdTech стартапа "Учи.Код" — курсы программирования для школьников

Промпт:

Создай landing page для EdTech стартапа "Учи.Код" — онлайн-курсы Python для школьников 10-14 лет.

Секции: hero с видео, преимущества курса (3 карточки), тарифы (2 опции), отзывы (slider), форма записи, футер.

Соблюдай WCAG 2.0 Level AA:
- Используй семантические landmarks: <header>, <main>, <section>, <footer>
- Только ОДИН <main> на странице
- Контраст текста/фона минимум 4.5:1 (проверь тёмный текст на светлом фоне)
- Alt-текст для всех изображений (описательный, не "image1.jpg")
- Дескриптивные названия ссылок (не "подробнее", а "Посмотреть программу курса Python")
- Каждый <input> с соответствующим <label>
- <button> с понятным текстом внутри
- Heading иерархия: <h1> для заголовка, <h2> для секций, <h3> внутри секций
- Для видео добавь <figcaption> с описанием содержимого

Результат:

Модель сгенерирует HTML с:

• Корректной структурой landmarks (header > main > sections > footer)
• Высоким контрастом (например, #333 текст на #fff фоне = 12.6:1)
• Alt-текстами: <img src="kid-coding.jpg" alt="Школьник 12 лет пишет код на Python в редакторе VS Code">
• Ссылками: Скачать полную программу курса вместо Здесь
• Формой: Имя ребёнка

Не факт, что будет 100% compliance (A11yn с fine-tuning даёт 85% точности), но значительно лучше чем без требований (промптинг даёт примерно 40-50% улучшения vs базовая модель).

Слабость LLM: Модели обучены на триллионах токенов веб-страниц, где 96% сайтов нарушают WCAG. Частотный паттерн "недоступного кода" закодирован в весах. LLM генерирует наиболее вероятный код = репродукция типичных ошибок: <div> вместо <main>, серый текст на белом (2.1:1 контраст), click here, отсутствие alt-текстов.

Сильная сторона LLM: Модели отлично следуют явным инструкциям, особенно когда они конкретные и проверяемые. "Контраст минимум 4.5:1" — чёткое числовое требование. "Используй <main>" — конкретный тег. "Дескриптивные ссылки" — понятный принцип с примерами.

Как метод использует сильную сторону:

1. Fine-tuning (A11yn): Во время обучения Axe-core даёт количественный penalty за каждое нарушение. GRPO сдвигает распределение вероятностей в сторону WCAG-compliant паттернов. После 2 эпох модель "помнит" что <main> лучше <div>, потому что этот паттерн систематически получал выше reward.
2. Промптинг (extractable): Явные требования WCAG в промпте переопределяют частотные паттерны из обучения. Вместо генерации "наиболее вероятного" (недоступного) кода, модель генерирует "соответствующий инструкциям" (доступный) код. Эффект слабее чем fine-tuning (40-50% vs 60%), но работает без инфраструктуры.

Создай {тип_страницы} для {описание_проекта}.

{Опционально: список секций/компонентов}

Соблюдай WCAG 2.0 Level AA:
- Семантические landmarks: <header>, <main>, <section>, <nav>, <footer>
- Ровно ОДИН <main> landmark
- Контраст текста/фона минимум 4.5:1
- Alt-текст для всех <img> (описательный, не filename)
- Дескриптивные названия ссылок (не "click here"/"подробнее")
- Каждый <input> с соответствующим <label>
- <button> с текстом внутри или aria-label
- Heading иерархия: <h1> один на странице, потом <h2>, <h3>...
- Для медиа (<video>, <audio>) добавь описание/субтитры
- Используй HTML5 семантику вместо 
 где возможно

Плейсхолдеры:

• {тип_страницы} — landing page, dashboard, форма, блог, портфолио
• {описание_проекта} — что делает сервис/продукт, для кого, какие функции
• Список секций — опционально, если нужна конкретная структура

Адаптация под задачу:

• Для форм: добавь "валидация с aria-invalid и aria-describedby для ошибок"
• Для SPA: добавь "aria-live регионы для динамического контента"
• Для таблиц: добавь "используй для заголовков"
• Для чатов/комментариев: добавь "role='log' для новых сообщений"

⚠️ Эффективность промптинга ниже fine-tuning: A11yn с GRPO даёт -60% inaccessibility rate, промптинг с WCAG требованиями даёт примерно -40-50%. Frontier модели (GPT-4.1, Claude Sonnet 4) показывают 27-29% inaccessibility rate даже без специальных инструкций — промптинг улучшит, но не до уровня A11yn.

⚠️ Нет автоматической проверки: Промптинг полагается на способность LLM интерпретировать требования. Для гарантии compliance нужен ручной аудит через Axe DevTools, WAVE, Lighthouse или другие инструменты.

⚠️ Сложные ARIA паттерны: Модели часто неправильно используют ARIA для интерактивных компонентов (modals, tabs, accordions). Требуются дополнительные примеры или проверка документации.

⚠️ Промптинг добавляет токены: Шаблон выше ~100 токенов. Для частых генераций UI это может быть накладно. A11yn не требует дополнительных токенов после fine-tuning.

⚠️ Визуальная доступность vs промптинг: Контраст цветов требует точных hex-кодов. LLM может ошибиться в расчётах (сгенерировать #777 на #fff = 4.47:1 вместо требуемых 4.5:1). Для критичных проектов нужна проверка.

Команда из Yonsei University взяла Qwen2.5-Coder-7B-Instruct и обучила через GRPO на 8× NVIDIA A6000. Создали UIReq-6.8K — синтетический датасет из 6800 UI-запросов через GPT-4o-mini, охватывающий 68 категорий (бизнес, здоровье, образование, e-commerce...). Каждый запрос детальный: "Создай community forum для музыкантов с темной темой, sidebar навигацией, постами с комментариями, профилями участников".

Для каждого запроса модель генерировала 6 вариантов кода (temperature 0.7 для разнообразия). Каждый вариант рендерился в headless Chrome → Axe-core сканировал DOM и возвращал нарушения с severity levels. Penalty = сумма взвешенных нарушений (Minor×0.1 + Moderate×0.2 + Serious×0.3 + Critical×0.4). Reward = 2.0 - penalty. GRPO нормализовал rewards внутри группы из 6 → обновлял веса в сторону кода с меньшими penalties.

Почему 2 эпохи дали результат? Axe-core проверяет ~100 правил WCAG. При 6800 запросах × 6 вариантов × 2 эпохи = 81,600 code samples с количественным feedback. Модель быстро научилась паттернам: "используй <main> → меньше penalty", "добавь alt → меньше penalty", "контраст 4.5:1 → меньше penalty". Статистический learning очень эффективен для таких структурных правил.

Оценивали на RealUIReq-300 — 300 запросов из реальных сайтов (вручную кураторовали из публичных веб-страниц, убрали PII). Сравнивали с базовой моделью, Feeda11y (итеративный промптинг), Qwen 14B, GPT-4.1, Claude Sonnet 4.

Неожиданный результат: Frontier модели (GPT-4.1, Claude Sonnet 4) показали ХУЖЕ accessibility чем базовый Qwen 7B + Feeda11y. GPT-4.1: 27% inaccessibility rate, Claude: 29%, Qwen+Feeda11y: 21%. Почему? Frontier модели обучены генерировать визуально привлекательный код, но не специально на accessibility. A11yn с GRPO: 15% inaccessibility rate — на 43% лучше чем лучший baseline.

Ключевой инсайт: Scale (14B parameters, GPT-4.1) НЕ решает accessibility автоматически. Нужен явный feedback signal из WCAG-аудита. Промптинг помогает, но GRPO даёт систематическое улучшение через statistical learning на тысячах примеров.

A11yn: Aligning LLMs for Accessible Web UI Code Generation

Janghan Yoon, Jaegwan Cho, Junhyeok Kim, Jiwan Chung, Jaehyun Jeon, Youngjae Yu

Yonsei University, Seoul National University

arXiv preprint (2025)

Важные отсылки:

• WCAG 2.0 Guidelines: w3.org/WAI/WCAG20/quickref — полный список правил доступности
• Axe DevTools: deque.com/axe/devtools — расширение для браузера, проверяет accessibility
• Feeda11y (2025): итеративный промптинг для accessibility через ReAct feedback loops
• GRPO (DeepSeekMath, 2024): алгоритм policy optimization без critic network