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

Среди миллиона страниц было обнаружено 50 960 288 различных ошибок доступности - в среднем 51 ошибка на страницу. Источник

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

Чтобы исправить эти проблемы, стоит “научить” свою IDE генерировать доступные интерфейсы, при помощи нескольких шагов:

  1. Использовать библиотеки UI компонентов, которые доступны “из коробки”;
  2. Добавить правила для агента, чтобы он верстал с учетом требований;
  3. Тестировать сгенерированные интерфейсы.

Выбор UI библиотеки

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

React/Next

  1. Radix и ShadCN - Мой персональный топ. Компоненты красивые, собирать и использовать удобно;
  2. Spectrum - К Adobe предъявляются завышенные требования по качеству интерфейсов, по этому эти ребята знают как делать их доступными;
  3. MUI - Production-ready компоненты от Google.

Vue/Nuxt

  1. Radix и ShadCN для Vue - компонентов и возможностей theme’инга меньше, но вайбкодится отлично;
  2. NuxtUI - Стилизованный набор компонентов для Nuxt приложений, рекомендую использовать MCP для поиска по компонентам, иногда галлюцинирует;
  3. Reka UI - Тоже самое, только без стилей, как Radix.

Svelte/SvelteKit

  1. Radix и ShadCN - Все тоже самое, по мне самый удобный вариант.
  2. Melt UI - В отличии от других библиотек, эта не предоставляет готовые компоненты, но набор функций для построения компонентов из нативных HTML элементов;
  3. Bits UI - Целый конструктор доступных компонентов, по сути похоже на Radix.

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

Рекомендую использовать ShadCN и TailwindCSS, это лучшее сочетание для LLM – меньше галлюцинаций, при этом не нужно описывать специальные правила для этого набора.

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

Про правила

В популярных AI IDE есть правила, которые вы можете настраивать глобально и локально для своего проекта:

  1. Cursor: ./cursor/rules/{rule_name}.mdc, можно так же настроить в разделе “Rules & Memory”, Cursor Settings;
  2. Windsurf: ./.windsurfrules;
  3. Claude Code: CLAUDE.md.

Минимально, вы можете добавить всего пару строчек в существующие правила, чтобы IDE учитывала, что не стоит абы как собирать интерфейс:

Accessibility
- Ensure interfaces are keyboard navigable.
- Implement proper ARIA labels and roles for components.
- Ensure color contrast ratios meet WCAG standards for readability.

Этого должно хватить чтобы избежать «диватоза», но бывает надо собрать сложный компонент, комбинируя компоненты из UI библиотеки, с нативными тегами, чтобы сделать что-то сложное.

Я создал правила для Cursor, которое должно учитывать любой фреймворк и компонентную библиотеку, там собраны примеры и более точные требования: Правила для курсора (.mdc), но для вашего приложения, рекомендую создать эти правила самостоятельно, учитывая ваш стек, фреймворк, компоненты, архитектурные паттерны и прочее, для этого можно воспользоваться промптом для Claude, он поможет сгенерировать правила для Cursor, вам нужно только заполнить детали вашего стека – Промпт для генерации правил.

Для других IDE, используйте те же подходы.

Тестирование

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

Дополнительные ресурсы и инструменты

  • В случае, если «семантика», «доступность», «WCAG» и «W3C» понятия для вас новые, рекомендую посмотреть доклад Вадима Макеева, на тему «людоедских интерфейсов» - YouTube | Людоедский интерфейс, Вадим Макеев, Eng Ver;
  • Готовые правила для курсора, от комьюнити и официальные - cursor.directory;
  • Статья на Веб-стандартах «аудит доступности»;
  • Плагин-тул для браузера для проверки ваших веб страниц - WAVE (Web Accessibility Evaluation Tool);
  • Обзор основ доступности от W3C (может быть полезно для более точных промптов) - Accessibility Fundamentals Overview
  • Что такое “скринридер” и какие они бывают – Статья на Доке;
  • Набор инструментов, методик и решений для поддержания доступности на всех этапах разработки и работы с продуктами (AXE Devtools, AXE For VS Code, и другие) - Сайт Deque.

Что дальше?

Попробуйте внедрить в свой пайплайн новые правила, начните тестировать интерфейсы.

Можете написать мне, я с радостью помогу настроить ваш IDE, подскажу как протестировать и расскажу как донести важность до стейкхолдеров – danila@katokdoes.art.