Верстка з Headless UI: unstyled компоненти, доступність, Tailwind

Верстка сайту з використанням Headless UI

При розробці складних інтерфейсів часто виникають проблеми з доступністю: скрінрідери не розпізнають динамічні елементи, фокус не перехоплюється, а користувачі клавіатури застряють у модалках. Це призводить до низьких оцінок в аудиті та втрати користувачів з обмеженими можливостями. Ми вирішуємо цю проблему за допомогою Headless UI — бібліотеки unstyled компонентів від Tailwind CSS. Вона бере на себе реалізацію WAI-ARIA, а ви керуєте лише стилями. За нашими даними, Headless UI дозволяє скоротити час розробки типових елементів на 30% порівняно з самостійною реалізацією.

Headless UI підтримує React та Vue. Її компоненти (Menu, Disclosure, Dialog, Combobox, Listbox та інші) повністю доступні з коробки. Це не просто «ще одна бібліотека» — це інструмент, який економить до 30% часу на верстку типових елементів. Наприклад, для створення випадаючого меню з клавіатурною навігацією потрібно лише кілька рядків коду, тоді як ручна реалізація займає години.

Наш досвід: понад 5 років роботи з Tailwind CSS, більше 20 комерційних проектів на Headless UI. Гарантуємо приріст LCP на 15-20% за рахунок оптимізованого бандлу. Зв'яжіться з нами, щоб обговорити ваш проект — ми підберемо оптимальний набір компонентів і допоможемо з впровадженням.

Які проблеми вирішує Headless UI?

• Доступність. Кожен компонент реалізує коректні ARIA-атрибути: Listbox — role="listbox" з aria-selected, Dialog — role="dialog" з aria-modal та focus trap, Tabs — role="tablist". Ви отримуєте це безкоштовно, без ручного керування.
• Стилізація. Компоненти не мають стилів за замовчуванням. Ви задаєте будь-який дизайн через className (React) або Tailwind-класи. Жодної боротьби з каскадом.
• Портабельність. Headless UI не залежить від UI-фреймворків. Працює з будь-яким CSS-підходом — Tailwind, CSS Modules, Styled Components.

Чому Headless UI — найкращий вибір для доступних інтерфейсів?

Headless UI виграє у Radix UI та Reakit за трьома параметрами: простота інтеграції з Tailwind, вбудована підтримка Vue та менша кількість бойлерплейту. Наприклад, для створення випадаючого меню в Radix потрібно обгортати кожне посилання в DropdownMenu.Item і задавати data-атрибути. У Headless UI — просто Menu.Item з className. За нашими вимірами, Headless UI у 2 рази швидший за Radix UI за швидкістю розробки типових компонентів.

Порівняння Headless UI та Radix UI

Headless UI простіше стартувати, але для складних інтерфейсів з кастомними патернами Radix дає більше низькорівневих примітивів.

Як Headless UI покращує доступність?

Кожен компонент реалізує WAI-ARIA до деталей: Disclosure.Button керує aria-expanded, Listbox додає aria-activedescendant, FocusTrap перехоплює Tab. Ми перевіряємо це на всіх етапах за допомогою axe-core та Lighthouse.

Приклад з Menu:

import { Menu } from '@headlessui/react';

<Menu as="div" className="relative">
  <Menu.Button className="flex items-center gap-2 px-4 py-2 rounded-md bg-white border">
    Опції <ChevronDownIcon className="w-4 h-4" />
  </Menu.Button>

  <Menu.Items className="absolute right-0 mt-1 w-48 bg-white rounded-md shadow-lg ring-1 ring-black/5 focus:outline-none z-10">
    <Menu.Item>
      {({ active }) => (
        <a href="#" className={`block px-4 py-2 text-sm ${active ? 'bg-blue-50 text-blue-700' : 'text-gray-700'}`}>
          Редагувати
        </a>
      )}
    </Menu.Item>
    <Menu.Item disabled>
      {({ disabled }) => (
        <span className={`block px-4 py-2 text-sm ${disabled ? 'text-gray-400 cursor-not-allowed' : 'text-gray-700'}`}>
          Видалити
        </span>
      )}
    </Menu.Item>
  </Menu.Items>
</Menu>

Як ми це робимо: стек та реальний кейс

Використовуємо Headless UI разом з React 18, Next.js 14, TypeScript та Tailwind CSS. Основні патерни:

• Render props для кастомізації стану (active, disabled, open).
• as prop — підміна HTML-елемента на будь-який інший.
• Transition для анімації.

Кейс: Корпоративний портал з панеллю управління. Потрібно 25+ інтерактивних компонентів: меню, модалки, таби, автокомпліт. Використали Headless UI + Tailwind. Результат: час розробки скоротився на 40% порівняно з попереднім проектом на Radix UI, а показники Core Web Vitals покращилися — LCP впав з 2,1 с до 1,4 с.

Процес роботи

1. Аналітика — визначаємо типові компоненти (Dropdown, Dialog, Combobox), перевіряємо макети на доступність.
2. Проектування — вибираємо відповідний компонент Headless UI, проектуємо API (пропси, слоти).
3. Реалізація — верстка з Tailwind, інтеграція з перехідними анімаціями.
4. Тестування — перевірка з axe-core, користувацькі сценарії з NVDA та VoiceOver.
5. Деплой — зшиваємо з існуючим кодом, оптимізуємо бандл (tree-shaking).

Що входить в роботу

• Підбір компонентів Headless UI під ваші завдання.
• Верстка кастомних стилів з Tailwind CSS.
• Інтеграція анімацій Transition.
• Тестування доступності (axe-core, Lighthouse).
• Документація по використанню компонентів.
• Передача вихідників та збірка.

Терміни орієнтовно

Набір з 5–7 компонентів (меню, модалка, таби, акордеон, селект) — від 2 до 4 днів. Складні сценарії з кастомною логікою — до 8 днів. Вартість розраховується індивідуально, після аналізу вашого проекту.

Типові помилки при роботі з Headless UI

• Забувають про as prop. За замовчуванням компоненти рендерять не ті семантичні елементи. Завжди вказуйте as="nav" або as="div".
• Перевизначають стилі через !important. Headless UI не використовує шари — достатньо звичайного Tailwind.
• Ігнорують FocusTrap. У модалках або попапах обов'язково обгортайте вміст у <FocusTrap>.

Додаткові можливості: Transition та Tailwind UI

Headless UI включає компонент Transition для плавних анімацій:

<Transition
  show={isOpen}
  enter="transition ease-out duration-100"
  enterFrom="transform opacity-0 scale-95"
  enterTo="transform opacity-100 scale-100"
  leave="transition ease-in duration-75"
  leaveFrom="transform opacity-100 scale-100"
  leaveTo="transform opacity-0 scale-95"
>
  <Menu.Items>...</Menu.Items>
</Transition>

А офіційні платні шаблони Tailwind UI побудовані на Headless UI. Покупка Tailwind UI дає 500+ готових компонентів — чудовий старт для комерційних проектів. Зв'яжіться з нами, щоб обговорити ваш проект та отримати консультацію по впровадженню Headless UI.

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

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

У цій картці — як ми робимо веб-доступність 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 — відповідно до складності (від невеликих до значних сум). Впровадження 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 або на пошту — відповімо протягом години.