WCAG у брудній реальності фронтенду: що команди пропускають після аудиту

У продуктових командах дуже часто є один знайомий момент. Аудит доступності вже зробили, по дошці розкладені задачі, хтось сказав, що основні ризики під контролем, і на два-три дні всім стає морально спокійніше. А потім повертається звичайне життя продукту. Маркетинг міняє текст у хедері. Продакт просить щільніший дашборд. У модалку додають ще одну кнопку. Дизайнер затемнює панель, бо так вона "виглядає дорожче". Розробник обгортає стару кнопку кастомним div, бо для анімації так було простіше. Жодна з цих змін не виглядає катастрофою. Жодна не приходить з табличкою: "Я саме та дрібниця, яка тихо зламає клавіатурну навігацію, контраст, порядок фокусу й зрозумілість для скрінрідера наступного четверга".

Саме тому найцікавіша частина WCAG починається не до аудиту, а після нього. Аудит дає знімок. Реальний фронтенд знімком не є. Це рухома система з живим контентом, нервовими пріоритетами й компонентами, які повільно відпливають від тієї акуратної версії, що колись пройшла рев'ю. Доступність майже ніколи не вмирає одним гучним релізом. Вона розсипається в брудній середині процесу, де дрібні компроміси накопичуються тільки тому, що кожен окремо звучить тимчасово і нібито розумно.

Жорстка правда в тому, що більшість команд втрачає доступність не тому, що їм байдуже. Вони втрачають її тому, що швидкість розриває увагу. Один спринт про ship. Наступний про патчі. Потім запуск, розпродаж, редизайн, а після цього пачка "невеликих UI-правок", які насправді зовсім не невеликі. Десь усередині цього потоку доступна поведінка перестає бути продуктовою звичкою і стає спогадом про те, як інтерфейс колись поводився.

Цей спогад небезпечно заспокоює. Дуже багато команд досі мислять категорією "ми вже перевіряли WCAG". Але доступність не схожа на щеплення, яке роблять один раз. Вона набагато ближча до якості верстки чи дисципліни продуктивності. У тебе може бути здоровий базовий стан, а потім регрес після кожної маленької візуальної правки. На практиці найдорожчі accessibility-проблеми рідко виглядають як грубі помилки новачка. Частіше це напівзламані патерни, які здалеку виглядають акуратно, а валяться лише тоді, коли реальна людина пробує пройти інтерфейс без мишки, із збільшеним масштабом, після довгого робочого дня, на посередньому ноутбуці й з контентом, який у макеті ніколи не був таким довгим.

Дмитро Гулак
Founder & CEO of CSS-Zone

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

Ця думка важлива, бо саме так регреси й народжуються в реальності. Команди люблять уявляти accessibility-баг як щось очевидне: відсутній label, зламана форма, жахливий контраст. Такі речі, звісно, бувають. Але значно частіше шкода тихіша. Focus ring замінюють ніжною тінню, яка виглядає елегантно на одному моніторі й майже зникає на іншому. Toast красиво виїжджає на екран, але ніяк не оголошується assistive-технологіям. Заголовок акордеона стає клікабельним лише по тексту, а не по всій зоні, бо під час рефакторингу трохи поміняли markup. "Простий" фільтр-чіп перестає проходитися в логічному порядку, бо flex-перестановка розвела в різні боки візуальну і DOM-ієрархію. Інтерфейс і далі виглядає дорогим. Просто для частини людей він стає ненадійним.

Про це варто говорити довго ще й тому, що доступність набагато емоційніша тема, ніж багатьом інженерам хочеться визнавати. Користувач не переживає WCAG як набір пронумерованих критеріїв. Він переживає її як полегшення або тертя. Полегшення означає, що можна читати без напруження, рухатися без вгадування, виправляти помилки без паніки і довіряти сторінці, що вона не стане раптово ворожою тільки через те, що ти натиснув Tab ще раз. Тертя означає зворотне. Це мікросумніви, поставлені так щільно один до одного, що інтерфейс починає виснажувати, навіть якщо кожна окрема проблема у відриві виглядає дрібницею.

Одна з найкращих ілюстрацій тут - фокус. Команди часто вкладають дивовижно багато уваги в hover-стани і майже нічого у видимість клавіатурного фокусу. Hover видно під час дизайн-рев'ю, бо всі сидять з курсором. Focus майже невидимий у соціальному процесі перевірки, бо мало хто ходить інтерфейсом так, як це роблять клавіатурні користувачі. Через це в прод часто їдуть фокус-стани, які формально є, але практично слабкі. Outline ніби присутній, але тоне у фоні, конфліктує з тінями або губиться на бренд-кольорах саме в той момент, коли людині найбільше потрібна певність.

Виправлення тут рідко буває хитрим. Найчастіше треба просто обрати ясність замість естетичного кокетства і зібрати одну фокус-систему, яка витримає кнопки, лінки, кастомні таби, картки й поля форми.

:root {
  --focus-ring: #2563eb;
  --focus-ring-offset: #f8fafc;
}
.interactive-control:focus {
  outline: none;
}
.interactive-control:focus-visible {
  box-shadow:
    0 0 0 3px var(--focus-ring-offset),
    0 0 0 6px var(--focus-ring);
  border-radius: 12px;
}
.card-link {
  display: block;
  border-radius: 16px;
}
.card-link:focus-visible {
  outline: none;
  box-shadow:
    0 0 0 4px rgba(37, 99, 235, 0.22),
    0 0 0 7px rgba(37, 99, 235, 0.92);
}

Тут справа не в конкретному синьому. Справа в тому, щоб сигнал виживав на різних поверхнях. Коли людина табає pricing-сторінку, налаштування чи moderation-таблицю, вона не повинна домовлятися з інтерфейсом про те, де зараз знаходиться. Для команд, які тестують між іншим, ці переговори майже невидимі. Для користувачів, яким послідовний focus потрібен щодня, вони абсолютно очевидні.

Форми - ще одне місце, де WCAG розсипається вже після аудиту, бо команди недооцінюють, що означає відновлення після помилки під тиском. У стерильному тест-кейсі форма з червоною рамкою і коротким текстом може виглядати повністю нормально. У реальності люди помиляються, гублять з'єднання, відправляють форму занадто швидко, масштабують сторінку, перемикають мову і повертаються до полів, які заповнювали двадцять хвилин тому. Хороша форма не просто показує помилку. Вона допомагає повернути контроль. Пояснює, що саме сталося, де це виправити і чи не зникло вже введене значення.

Саме тут семантична проводка важить більше за будь-який декоративний лиск.

<label for="email">Робочий email</label>
<input
  id="email"
  name="email"
  type="email"
  aria-describedby="email-hint email-error"
  aria-invalid="true"
/>
<p id="email-hint">Вкажіть адресу, яка прив'язана до вашого корпоративного акаунта.</p>
<p id="email-error" role="alert">Введіть коректний робочий email, щоб продовжити.</p>

input[aria-invalid="true"] {
  border-color: #dc2626;
  background: rgba(220, 38, 38, 0.04);
}
#email-error {
  color: #b91c1c;
  font-weight: 600;
}

Це зовсім не той код, який хочеться показувати на конференції, і саме тому він такий важливий. Якість доступності живе в коді, який ніхто не постить у красиві каруселі, але від якого всі залежать у продакшені. Так само це працює зі skip link, landmarks, діалогами, inline-валидацією, описовими заголовками, таблицями та empty state, які пояснюють, а не знизують плечима. У якийсь момент зріла команда просто розуміє: саме в цих "неефектних" шматках або зберігається довіра до продукту, або вона спалюється.

Ще одна типова поломка приходить із візуальних систем, які погано старіють під тиском контенту. Компонент може пройти contrast-перевірку в перший день і все одно стати важким для читання після трьох раундів "невеликих" дизайн-уточнень. Панель зробили темнішою, текст тоншим, акцентний колір моднішим, а disabled-стан ніжнішим, бо хотіли м'якший вигляд. Жодне з цих рішень окремо не виглядає злочином. Разом вони дуже часто дають інтерфейси, які красиво живуть у дрибл-подібних моментах і погано живуть у звичайній роботі.

Якщо команді тут потрібне одне корисне правило, то воно таке: перевіряйте читабельність, коли інтерфейс уже перестав бути "свіжим". Відкрийте дашборд після восьми годин роботи. Збільшіть браузер до 200 відсотків. Почитайте довгу сторінку налаштувань на ноутбуці з неідеальною яскравістю. Пройдіться щільною адмінською таблицею на посередньому трекпаді. Саме тут доступність стає реальною, бо втома реальна. Когнітивне навантаження реальне. WCAG - це не тільки про edge cases. Це ще й про повагу до нормальних людських меж у нормальному робочому дні.

Окремої розмови заслуговують модалки, бо саме в них багато дорогих на вигляд продуктів раптом стає незграбними. "Щаслива" модалка проста. Брудна модалка - це та, де є відкладена валідація, disabled submit, async loading, кнопка закриття, правило для backdrop click і користувач, який уже був роздратований до моменту відкриття. Команди часто правильно збирають картинку і неправильно збирають поведінку. Фокус падає кудись не туди. Escape закриває вікно навіть тоді, коли всередині йде руйнівна дія. Заголовок видно, але для асистивних технологій він не експонований як треба. Після закриття фокус повертається в випадкове місце нагорі сторінки, і людині доводиться заново збирати контекст.

Хороший діалог відчувається як контрольована пауза, а не як телепорт.

<div
  role="dialog"
  aria-modal="true"
  aria-labelledby="delete-title"
  aria-describedby="delete-description"
>
  <h2 id="delete-title">Видалити цей коментар?</h2>
  <p id="delete-description">
    Дія видалить коментар для всіх користувачів і не може бути скасована.
  </p>
  <button type="button">Скасувати</button>
  <button type="button">Видалити</button>
</div>

Але цей markup - лише підлога, а не стеля. Реальна якість починається з того, як ти керуєш фокусом до відкриття, під час взаємодії і після закриття. І все ж більшість регресів стається тому, що команда зупиняється на крок раніше. Вікно вже показали на екрані, отже начебто задача зроблена.

За всім цим є ще тонша організаційна проблема. Accessibility-баги часто мають слабку політичну енергію всередині команди, бо не завжди вибухають в аналітиці так, як просідання перформансу чи баги чекауту. Зламаний порядок фокусу рідко матеріалізується у красиву одну цифру. Виснажлива кольорова система не завжди запускає драматичний графік. Шкода проявляється як вагання, повільніше завершення дій, більше підтримки й тихе виключення частини людей. Саме тому це так легко відкладати, особливо в командах, які вірять тільки тому, що можна миттєво порахувати.

Але будь-хто, хто хоча б кілька років робив реальні продукти, знає: тихе тертя все одно дороге. Воно коштує довіри. Воно коштує завершених сценаріїв. Воно коштує енергії самій команді, бо брудні інтерфейси генерують нескінченні дрібні правки після релізу. У цьому сенсі доступність гранично практична. Це не церемоніальна чеснота. Це технічне обслуговування чесності інтерфейсу. UI не повинен повідомляти "мною легко користуватися", якщо ця правда працює тільки для бадьорого дизайнера з мишкою й ідеальним зором.

Мабуть, саме тому я постійно повертаюся до теми WCAG. Вона нав'язує корисну форму скромності. Нагадує команді, що вона не будує продукт для уявного ідеального користувача, який швидко читає, безпомилково клікає, миттєво розуміє кожен патерн і ніколи не приходить у стресі. Продукт будують для людей у реальному контексті: з перериваннями, втомою, обмеженнями, поспіхом і дратівливістю. Щойно ти це приймаєш, accessibility перестає відчуватися як бюрократія і починає відчуватися як дисциплінована повага.

Ця дисципліна стає значно простішою, коли команда вшиває її в звичайні фронтенд-звички. Коли мерджать новий компонент, хтось має поставити питання, чи не зламалася структура заголовків. Коли міняють палітру, хтось має перегнати контраст там, де реально живе текст, а не лише на бренд-свотчах. Коли з'являється кастомний select або combobox, хтось має пройти його клавіатурою, а не клацнути мишкою один раз і забути. Коли таблицю роблять щільнішою, хтось має спитати, чи не роз'їхався reading order і чи не стали hit area абсурдно дрібними на zoom. Ці питання не додають пафосу. Зате саме вони рятують продукт від повільного зарозуміління.

Іронія в тому, що по-справжньому доступні інтерфейси часто відчуваються дорожчими, а не дешевшими. Вони спокійніші. Читабельніші. Менш нав'язливі. Вони не змушують людину працювати на те, щоб розкодувати стан, знайти потрібну дію або оговтатися після помилки. Багато з того, що люди називають "класним UX", насправді є доступністю, настільки послідовною, що про неї вже не доводиться говорити окремо.

Тому якщо ваша команда вже пройшла аудит і думає, що найважче позаду, то, швидше за все, саме в цей момент треба ставати уважнішими, а не розслаблятися. Найнебезпечніший період починається тоді, коли всім уже достатньо спокійно, щоб робити "невеликі" винятки. Мінус один label тут, м'якший outline там, shortcut у markup, бо спринт горить. Ось це і є схил. І, як майже будь-який продуктовий борг, він не оголошує про себе в момент росту.

Найздоровіша позиція тут нудна і дисциплінована. Перевіряти важливі сценарії ще раз. Перевіряти їх після візуальних правок. Перевіряти, коли росте контент. Перевіряти, коли компоненти починають жити в брудніших контекстах, ніж задумував оригінальний макет. Доступність виживає там, де команда готова бути трохи повторюваною заради того, щоб інтерфейс залишався надійно зручним.

У цьому немає романтики. І це краще за романтику. Це той тип роботи, який тримається і через пів року, коли післярелізний блиск уже давно зник, а людям просто потрібно, щоб продукт працював.