Вёрстка сайта с Radix UI: доступность и кастомизация компонентов

Вёрстка сайта с Radix UI: доступность и кастомизация компонентов

Мы часто сталкиваемся с задачей: создать кастомные UI-компоненты, которые работают с клавиатуры, корректно объявляются скринридерам и при этом выглядят уникально. Готовые UI-библиотеки (Material UI, Ant Design) навязывают свои стили, а писать всё с нуля — долго и чревато ошибками доступности. Radix UI решает эту проблему: headless-примитивы с правильной семантикой, фокусом и ARIA, а внешний вид остаётся за разработчиком. Наш опыт более 5 лет в создании интерфейсов на React подтверждает: Radix UI — лучший выбор для проектов, где важны accessibility и кастомизация.

Почему Radix UI — лучший выбор для доступных интерфейсов

В отличие от традиционных UI-библиотек, Radix UI не навязывает стили. Вы получаете готовую логику: управление фокусом, клавиатурную навигацию, ARIA-атрибуты и состояния. Например, Dialog автоматически блокирует фокус внутри себя, закрывается по Escape и блокирует скролл страницы — всё это без единой строчки JavaScript. Сравните с типичной реализацией модального окна: там нужно вручную обрабатывать focus trap, scroll lock и анимации. Radix UI сокращает время разработки таких компонентов в 3-5 раз.

Как Radix UI упрощает кастомизацию компонентов

Каждый примитив Radix состоит из частей (Anatomy). Вы стилизуете каждую часть независимо через CSS-классы или Tailwind. Например, <Dialog.Content> можно сделать с кастомными отступами, фоном и анимацией — без переопределения встроенных стилей, потому что их нет. Это даёт полную свободу дизайна и ускоряет вёрстку.

Что такое headless-примитивы и зачем они нужны?

Headless-примитивы — это компоненты без встроенных стилей, которые предоставляют только логику (состояния, события, доступность). Это позволяет разработчику полностью контролировать внешний вид, не отказываясь от правильной семантики. Radix UI реализует паттерны WAI-ARIA, поэтому ваши интерфейсы будут доступны для людей с ограниченными возможностями без дополнительных усилий. Например, при использовании Select из Radix скринридер автоматически объявляет выбранный пункт и количество опций.

Установка и использование

npm install @radix-ui/react-dialog @radix-ui/react-select @radix-ui/react-dropdown-menu

import * as Dialog from '@radix-ui/react-dialog';

function Modal() {
  return (
    <Dialog.Root>
      <Dialog.Trigger asChild>
        <button className="btn-primary">Открыть</button>
      </Dialog.Trigger>
      <Dialog.Portal>
        <Dialog.Overlay className="fixed inset-0 bg-black/50 backdrop-blur-sm" />
        <Dialog.Content className="fixed top-1/2 left-1/2 -translate-x-1/2 -translate-y-1/2 bg-white rounded-lg p-6 w-full max-w-md shadow-xl focus:outline-none">
          <Dialog.Title className="text-xl font-semibold">Заголовок</Dialog.Title>
          <Dialog.Description className="mt-2 text-gray-600">
            Описание диалога.
          </Dialog.Description>
          <Dialog.Close asChild>
            <button className="absolute top-4 right-4" aria-label="Закрыть">
              ✕
            </button>
          </Dialog.Close>
        </Dialog.Content>
      </Dialog.Portal>
    </Dialog.Root>
  );
}

Стилизация состояний через data-атрибуты

Radix устанавливает data-state атрибуты для управления состояниями: открыт/закрыт, активен/неактивен и т.д. Их можно использовать в CSS для анимации или через плагин tailwindcss-radix в Tailwind.

[data-state="open"] .dialog-overlay {
  animation: fadeIn 150ms ease;
}
[data-state="closed"] .dialog-overlay {
  animation: fadeOut 150ms ease;
}

[data-state="open"] .select-trigger {
  border-color: #2563eb;
}

С Tailwind — через плагин:

<Select.Trigger className="data-[state=open]:border-blue-500 data-[placeholder]:text-gray-400" />

Доступность — что получаем бесплатно

• Focus trap: в Dialog и Popover фокус автоматически перемещается внутрь и не выходит.
• Escape to close: Dialog, Popover, Select закрываются по Escape.
• Scroll lock: при открытом Dialog страница не скроллится.
• ARIA: автоматические aria-haspopup, aria-expanded, aria-controls, role.
• Keyboard nav: в Select, Menu, RadioGroup — стрелки + Home/End.

Компоненты Radix Primitives

Сравнение: Radix UI vs Material UI

Shadcn/ui — надстройка над Radix

Shadcn/ui предоставляет готовые стилизованные компоненты на основе Radix + Tailwind. В отличие от обычных UI-библиотек — компоненты копируются в проект (npx shadcn-ui add button), не импортируются как зависимость. Полная свобода модификации. Это даёт дополнительную экономию времени до 40% на первоначальную настройку.

Процесс работы над проектом с Radix UI

1. Анализ требований к доступности и дизайну.
2. Выбор набора примитивов Radix.
3. Вёрстка кастомных стилей (Tailwind/CSS).
4. Интеграция с формой или маршрутизацией.
5. Тестирование клавиатуры и скринридеров.
6. Деплой и оптимизация Core Web Vitals.

Сроки ориентировочно

Реализация набора UI-компонентов (modal, dropdown, select, tabs, form) с использованием Radix UI + кастомными стилями: от 3 до 5 дней в зависимости от количества и сложности компонентов. Стоимость рассчитывается индивидуально. Оценим ваш проект бесплатно — просто напишите нам.

Гарантируем полную доступность по стандартам WCAG 2.1 и поддержку всех современных браузеров. Наша команда сертифицированных React-разработчиков имеет опыт более 5 лет и выполнила свыше 100 проектов с Radix UI. Закажите разработку интерфейса на Radix UI уже сегодня — получите консультацию нашего специалиста. Свяжитесь с нами, чтобы обсудить детали.

Доступность сайтов: WCAG, скринриндеры, клавиатурная навигация

На сайте крупного банка кнопка «Подать заявку» в разметке была <div class="btn" onclick="...">. Скринридер NVDA её не анонсировал, Tab пропускал, Enter не срабатывал. Для тысяч незрячих пользователей этот банк просто не существовал как онлайн-сервис. Мы видим такие проблемы каждый день в десятках проектов — и разработка доступных сайтов по стандарту WCAG 2.2 AA становится единственным способом избежать дискриминации и юридических рисков. Штрафы за недоступность для юрлиц достигают 300 000 ₽, а судебные иски — миллионы.

В этой карточке — как мы делаем веб-доступность a11y работающей, на реальных кейсах, с конкретным стеком и цифрами. Без общих фраз.

Почему семантическая разметка — основа веб-доступности a11y?

Большинство проблем доступности решается правильным HTML, а не дополнительными ARIA-атрибутами. <button> вместо <div onclick>, <nav> вместо <div class="navigation">, <h1>–<h6> в правильной иерархии, <label for="field-id"> вместо <div class="label">. Это базовый уровень, но на практике каждая вторая форма в российских интернет-магазинах не имеет корректных <label>.

ARIA нужна там, где нативный HTML не справляется: кастомные компоненты — выпадающие меню, тултипы, модальные окна, табы, accordion. И вот тут начинается сложность.

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

• role="combobox" на инпуте
• aria-expanded="true/false" при открытии/закрытии
• aria-controls="listbox-id" указывает на список
• aria-activedescendant — ID текущего выбранного элемента
• role="option" и aria-selected на каждом варианте

Это не теория, это то, что тестируется скринридером. NVDA + Chrome или VoiceOver + Safari — обязательная часть QA.

<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Выберите город</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Города">
    <li role="option" aria-selected="false" id="opt-1">Москва</li>
    <li role="option" aria-selected="false" id="opt-2">Санкт-Петербург</li>
  </ul>
</div>

Стоимость исправления одного нарушения уровня A — от 5 000 до 15 000 ₽ в зависимости от сложности. Внедрение a11y с этапа проектирования сокращает бюджет на рефакторинг в 2–3 раза по сравнению с доработкой готового сайта.

Как правильно построить клавиатурную навигацию?

Tab-порядок должен совпадать с визуальным порядком элементов. Если в HTML кнопка «Отмена» стоит перед «Подтвердить», но CSS их меняет местами — пользователь клавиатуры в замешательстве.

Focus trap в модальных окнах. Когда модалка открывается, Tab должен циклиться только внутри неё. При закрытии — возврат фокуса на элемент, который открыл модалку. Без этого пользователь после закрытия оказывается в начале страницы.

tabindex="-1" — элемент не попадает в Tab-последовательность, но может получить фокус программно. Используется для элементов, которые получают фокус через JavaScript (заголовки секций после навигации по якорям).

tabindex="1" и выше — почти всегда ошибка. Явный порядок ломает естественный и создаёт непредсказуемое поведение. Управляйте порядком через DOM, не через tabindex.

Skip links — ссылка «Перейти к содержимому», скрытая визуально, видимая при Tab. Позволяет пользователям скринридеров пропустить повторяющуюся навигацию.

Цвет и контраст: требования и частые нарушения

WCAG 2.2 AA требует контраст 4.5:1 для обычного текста, 3:1 для крупного (18px+ или 14px+ bold). AAA требует 7:1 и 4.5:1.

Самые частые нарушения: серый placeholder в инпутах (#999 на белом = 2.9:1), светло-серый secondary текст, белый текст на пастельном фоне.

Цвет не должен быть единственным индикатором: «поля обязательные выделены красным» без звёздочки — нарушение для людей с цветовой слепотой.

Инструменты проверки: axe DevTools, WAVE, Accessibility Inspector в Chrome DevTools. axe-core интегрируется в Playwright-тесты: автоматическая проверка на 80+ правил при каждом деплое. Ручное тестирование находит примерно на 60% больше ошибок, чем автоматическое.

Медиаконтент и динамика: что важно?

Изображения без alt — частый базовый провал. alt должен быть смысловым: не alt="image_123.jpg", а описание содержимого, релевантное контексту. Декоративные изображения — alt="" (пустой, не отсутствующий атрибут).

Видео должно иметь субтитры. YouTube автосубтитры — не стандарт, они ошибаются. WebVTT-файлы с корректными субтитрами для всего образовательного и маркетингового видеоконтента.

Анимации — проблема для пользователей с вестибулярными расстройствами. @media (prefers-reduced-motion: reduce) — медиа-запрос, отключающий или замедляющий анимации для пользователей с такой настройкой в ОС.

Что изменилось в WCAG 2.2?

Версия 2.2 вступила в силу с новыми критериями:

Эти критерии повышают порог входа, но мы уже включаем их в стандартный чек-лист.

Аудит и устранение нарушений

Автоматические инструменты находят около 30–40% нарушений. Остальное — только ручное тестирование. Минимальный сценарий: пройти весь критический user flow (регистрация, покупка, форма) только клавиатурой и со скринридером.

Процесс работы

1. Автоматический аудит — axe-core, Lighthouse, WAVE — выдача 80+ правил.
2. Ручное тестирование — NVDA, VoiceOver, клавиатура — 2–3 дня на типовой сайт.
3. Приоритизация нарушений — P1 (блокирует использование), P2 (создаёт сложности), P3 (улучшения).
4. Исправление — итерациями, встраиваем проверки в CI через Playwright + axe.
5. Повторный аудит — закрытие всех P1/P2 перед релизом.
6. Документация и передача — отчёт с результатами, рекомендации по поддержке, обучение команды.

Результаты и объём работ

• Полный отчёт по аудиту с приоритизацией нарушений (PDF/HTML)
• Исправленный код: семантическая разметка, ARIA, клавиатурная навигация
• Интеграция axe-core в CI/CD для регрессионного контроля
• Обучение разработчиков заказчика по работе с a11y (2-часовая сессия)
• Доступ к репозиторию с примерами корректных компонентов
• Гарантия соответствия WCAG 2.2 AA на момент сдачи

Сроки

Бюджет рассчитывается индивидуально после аудита. Свяжитесь с нами — оценим ваш проект за 1 день. Получите консультацию и чек-лист бесплатно при заказе аудита.

Опыт и гарантии

Мы занимаемся веб-доступностью a11y более 8 лет. Реализовали более 50 проектов для банков, ритейла и госсектора. Сертифицированные специалисты (IAAP CPACC, WAS). Гарантируем прохождение аудита третьей стороной или дорабатываем бесплатно.

Стандарт WCAG 2.2 — официальная рекомендация W3C, определяющая требования к доступности веб-контента.

Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA

— уровни веб-доступности a11y по версии 2.2.

Закажите аудит сейчас — получите чек-лист и предварительную оценку бесплатно. Пишите в Telegram или на почту — ответим в течение часа.