Сравнение AI-сгенерированного DatePicker и доработанного до WCAG: визуально одинаковы, но невидимая часть (ARIA, фокус) требу

Claude DatePicker: 3 дня доработок для WCAG-доступности

ИИ-инструменты 30 июня 2026 г.

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

Источник: Habr

Если ваша команда рассматривает AI-генерацию UI-компонентов с требованиями доступности, этот кейс покажет, на что реально уходит время и где AI пока не справляется.

Что произошло: эксперимент с Claude и DatePicker

Технический директор студии «Исходный код» Илья и его команда последние полгода занимались улучшением доступности React-компонентов. Для медицинского проекта, где пациентам нужно записываться на прием, потребовался DatePicker — компонент выбора даты.

Вместо того чтобы использовать готовую библиотеку вроде @react-aria/datepicker от Adobe, команда решила написать собственный компонент. Причины: нестандартный макет с горизонтальной прокруткой месяцев, строгие требования дизайн-системы клиента и желание не тянуть 25KB библиотеки с лишними абстракциями ради одного компонента.

Тогда родилась гипотеза: пусть Claude напишет основу — структуру, логику календаря, типы TypeScript и базовое состояние. Команда рассчитывала, что AI закроет 70% работы, а оставшиеся 30% — ARIA-атрибуты, управление фокусом и тестирование со screen reader'ами — они доделают сами.

Claude получил детальный промпт с требованиями паттерна WAI-ARIA APG «Date Picker Dialog» и сгенерировал компонент за несколько минут. Визуально и функционально в Storybook всё работало: календарь открывался, даты выбирались, состояние обновлялось.

Почему «готовый» компонент провалил тест с реальным пользователем

Как только команда запустила screen reader NVDA и попробовала пройти по компоненту клавишей Tab, фокус выскочил за пределы диалогового окна. Для человека, который пользуется только клавиатурой или голосовым чтением экрана, компонент стал непригодным.

Автор кейса формулирует это так: «Claude не подвел в видимых 70%, но подвел в невидимой части, где на самом деле и скрывается доступность». AI сгенерировал корректную структуру React, но не понял пользовательского опыта, скрытого за aria-атрибутами, поведением клавиатуры и управлением фокусом.

Именно этот разрыв между «компонент работает в изоляции» и «компонент работает для реального пользователя» стоил команде трех дней доработок.

Что именно пришлось переделывать: три дня ручной работы

Доработки затронули три ключевые области, которые AI не смог корректно реализовать:

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

ARIA-атрибуты. Сгенерированные атрибуты не соответствовали реальному поведению компонента. Screen reader не мог правильно интерпретировать, какая дата выбрана, какой месяц отображается и какие действия доступны.

Клавиатурная навигация. Claude не реализовал полный набор клавиатурных команд, требуемых паттерном WAI-ARIA APG: стрелки для перемещения между днями, Enter для выбора, Escape для закрытия календаря.

Команда сохранила большую часть кода, сгенерированного Claude — структуру компонента, логику календаря и типы. Но вся «невидимая» часть, отвечающая за доступность, была переписана вручную.

Что это значит для вашей команды: практические выводы

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

Аспект Что сделал Claude Что пришлось дорабатывать
Структура React Хороший каркас Не требовалось
Логика календаря Рабочая Не требовалось
Типы TypeScript Базовые Не требовалось
ARIA-атрибуты Формально присутствовали Полная переработка
Управление фокусом Отсутствовало Реализовано с нуля
Клавиатурная навигация Частичная Полная доработка
Тестирование со screen reader Не проводилось Проведено вручную

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

Где AI пока не справляется: что проверить до внедрения

На основе этого кейса можно составить чек-лист для проверки AI-сгенерированных компонентов:

  • [ ] Проверьте управление фокусом с помощью клавиши Tab — фокус не должен покидать пределы компонента
  • [ ] Протестируйте компонент с реальным screen reader'ом (NVDA, JAWS, VoiceOver)
  • [ ] Проверьте все клавиатурные команды, описанные в паттерне WAI-ARIA APG
  • [ ] Убедитесь, что ARIA-атрибуты соответствуют фактическому состоянию компонента
  • [ ] Проверьте, что все визуальные состояния (выбрано, недоступно, сфокусировано) корректно озвучиваются
  • [ ] Протестируйте компонент в разных браузерах и с разными screen reader'ами

Без этих проверок компонент, который выглядит рабочим в Storybook, может оказаться непригодным для пользователей с ограниченными возможностями.

Что делать на этой неделе: план действий

Если ваша команда рассматривает AI-генерацию UI-компонентов:

  1. Определите критичные для доступности компоненты. DatePicker, модальные окна, формы, навигационные меню — для них AI-генерация требует наибольших доработок.
  2. Заложите бюджет на доработку. Исходя из этого кейса, планируйте 2-3 дня на доведение одного сложного компонента до WCAG-доступности.
  3. Не полагайтесь на визуальную проверку. Компонент может выглядеть идеально, но быть непригодным для пользователей screen reader'ов.
  4. Используйте AI для шаблонного кода. Структура, типы, базовая логика — здесь AI действительно экономит время. ARIA, фокус и клавиатурная навигация требуют ручной работы.
  5. Проверяйте с реальными инструментами. Storybook и визуальные тесты не показывают проблемы доступности. NVDA или другой screen reader — обязательный инструмент проверки.

Источники

Генерация изображения

  • Модель: flux-schnell
  • Провайдер: replicate

Темы журнала

Что почитать дальше

Теги