Контрастність WCAG: де інтерфейс перестає читатися
Низька контрастність інтерфейсу майже ніколи не видна в макеті — вона проявляється на реальних екранах і за реального освітлення.
Типові місця ті самі: сірі підписи під полями введення, текст тонкого накреслення дрібним кеглем, напівпрозорі підкладки поверх фотографій, неактивні й наведені стани кнопок, підказки та повідомлення про помилки у формах.
Формально контрастність WCAG вимірюється відношенням яскравості тексту та фону: для звичайного тексту потрібно 4,5:1, для великого — 3:1, для меж полів і іконок в елементах керування — теж 3:1.
Складність у тому, що перевірка контрасту тексту за статичним макетом бреше: якщо під написом лежить зображення, градієнт або напівпрозорий шар, фон під конкретними символами виявляється світлішим, ніж у середньому по блоку.
Далі вмикається наслідок. Нечитабельний текст на сайті — це не питання естетики: користувач не розуміє, що вводити в поле, не бачить, де саме помилка, не знаходить посилання на відновлення доступу.
Він або йде, або пише в підтримку, і зворотний зв'язок перетворюється на потік однотипних питань замість даних про продукт. На мобільному, на сонці, за слабкого зору або зниженої яскравості екрана запас читабельності витрачається першим.
Доступність інтерфейсу тут — не галочка у звіті, а вимога до системи стилів: токени кольору, стани компонентів, правила перевизначення під конкретних споживачів.
Розбираємо, де саме інтерфейс перестає читатися і як це закривається так, щоб правило працювало на всіх нових екранах, а не правилася вручну в кожному.
Читабельність, масштабування тексту й охоплення аудиторії
Контраст основного тексту нижче порога 4.5:1 — це не питання смаку. За такого співвідношення підписи полів, підказки й повідомлення про помилку зливаються з фоном для людей з послабленим зором і для тих, хто читає з телефона в яскравому приміщенні.
Приведення пар «текст — фон» до 4.5:1, а великого тексту й елементів керування до 3:1 прибирає цілий клас відмов, за якого людина фізично не може завершити сценарій.
Масштабування шрифту — друга половина завдання. Макет на відносних одиницях витримує системне збільшення до 200% без горизонтального прокручування, обрізаних підписів і блоків, що наїжджають один на одного.
Абсолютні значення в пікселях такої перевірки не проходять, і користувач, якому потрібен великий текст, іде, хоча прийшов у справі.
На формах ефект помітний найшвидше. Коли підписи контрастні, межі полів розрізнювані, а помилку показано не лише кольором, а й текстом поруч із полем, частка покинутих заявок падає: людина бачить, що від неї вимагається і що заповнено неправильно.
Звернення в підтримку на кшталт «не бачу кнопку», «текст зливається» зникають як клас — причина була не в логіці, а в читабельності. Час, що звільнився, команда витрачає на розвиток сценаріїв, а не на підказки, де знаходиться кнопка оплати.
Окремий виграш — охоплення аудиторії. Читабельний інтерфейс однаково працює для користувачів із порушеннями зору, для тих, хто заходить з телефона на вулиці, і для старшої вікової групи, яка збільшує шрифт у браузері.
Способи привести контрастність і типографіку до норми
Аудит починається з інвентаризації пар «текст — фон» і розмірів шрифту за екранами. Поріг для основного тексту — 4.5:1, для великого кегля та графічних елементів — 3:1, плюс вимога зберігати читабельність під час масштабування інтерфейсу до 200%.
За WCAG порушення майже завжди групуються в кілька шаблонів — від цього залежить, який спосіб виправлення спрацює.
Підходи не замінюють один одного: налаштування стилів, переробку компонентів і ручне доопрацювання застосовують у різному порядку.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Правка загальних стилів: палітра у змінних, шкала розмірів і міжрядкових інтервалів | порушення типові — сірий текст на світлих підкладках, дрібний кегль у підписах | не закриває текст поверх зображень, градієнтів і напівпрозорих шарів |
| Переробка бібліотеки компонентів: кнопки, поля, таблиці, сповіщення | один елемент повторюється на десятках екранів | змінює верстку — потрібна регресія за всіма місцями використання компонента |
| Ручне доопрацювання проблемних екранів | унікальні блоки: банери, картки з фонами, калькулятори | погано масштабується, перевірку повторюють після кожної правки контенту |
На практиці починають із налаштування стилів: палітра та шкала у змінних закривають більшість типових порушень одразу на всіх екранах. Потім переробляють компоненти, щоб виправлення не відкочувалося під час наступної збірки. Ручне доопрацювання залишається для унікальних блоків.
Обмеження підходу: перевірки ловлять контраст, але не читабельність — довжину рядка, міжлітерні відстані та переповнення під час перекладу іншою мовою, тому типографіку інтерфейсу все одно проходить інженер. Пороги фіксуємо в правилах перевірки, щоб регресії не поверталися.
Як відбувається впровадження: від аудиту до передавання
Впровадження доступності — не разова правка палітри, а послідовність кроків із перевірюваним результатом на кожному. Мета — не лише підняти контрастність WCAG до потрібного рівня, а й закріпити правила, щоб нові екрани не повторювали ті самі порушення.
- Інвентаризація інтерфейсу. Збираємо перелік шаблонів, компонентів та їхніх станів — наведення, фокус, вимкнений елемент, помилка. Для кожного фіксуємо текстові стилі та фони: без цього списку заміри втрачають повноту.
- Аудит і замір. Рахуємо фактичний коефіцієнт контрасту для всіх пар «текст — фон» окремо для дрібного й великого тексту, елементів керування та графіки. Позначаємо все нижче потрібних 4.5:1 і 3:1.
- Розбір спірних місць. Текст поверх зображень, градієнти, напівпрозорі шари та стани фокусу автоматика рахує некоректно — їх перевіряємо вручну, на реальному контенті.
- План правок. Для кожної групи вирішуємо: змінити відтінок у палітрі, додати підкладку або обведення, обмежити фон під текстом. Правки вносимо в токени дизайн-системи, а не в окремі компоненти, — одна зміна розходиться по всіх екранах.
- Налаштування й перевірка. Правимо палітру, типографіку та токени, задаємо мінімальні розміри шрифтів і міжрядковий інтервал, прибираємо фіксовані висоти блоків. Потім повторюємо заміри й проганяємо регресію за всіма шаблонами, темною темою та режимом високої контрастності системи.
- Передавання документації. Віддаємо правила контрасту й типографіки, чек-ліст для нових компонентів та опис перевірок в автотестах, щоб під час наступного релізу доступність не відкотилася.
Що замовник отримує на руки: правила, стилі, регламент
Правка поточних екранів — лише половина результату робіт із доступності. Друга половина — матеріали, за якими команда замовника сама перевіряє нові сторінки й не втрачає контрастність через два релізи. Передаємо їх разом із кодом, а не окремим документом «для звітності».
- Змінні теми. Кольори й розміри шрифтів винесено в набір змінних: фон, основний і другорядний текст, межі, стани наведення й фокусу. Зміна брендового відтінку в одному місці більше не ламає сусідні екрани.
- Правила контрасту. Таблиця припустимих поєднань із порогами для основного тексту, великих заголовків, елементів керування та піктограм. Окремо позначено, де контраст можна знизити, а де ні.
- Приведені стилі. Кнопки, поля введення, посилання, підказки й повідомлення про помилки переведено на змінні теми та перевірено в усіх станах — включно з фокусом, наведенням і неактивним виглядом.
- Регламент перевірки. Покроковий порядок: які екрани дивитися, чим вимірювати, що вважати блокувальним порушенням, а що — припустимим винятком і як його оформити.
- Інструкція для дизайнерів. Як вибирати пару «фон — текст» і розміри шрифтів ще в макеті, щоб верстку не переробляти. З прикладами припустимих і заборонених поєднань.
- Пам’ятка для редакторів. Обмеження за довжиною рядка й розміром шрифту плюс заборона на колір як єдиний носій смислу: посилання всередині абзацу має відрізнятися не лише відтінком.
- Масштабування шрифтів. Поведінка верстки під час збільшення тексту: що переноситься, що обрізається, де потрібна інша розкладка і як це перевірити перед випуском.
Розбір проєкту: як прибрали провали з доступності
Клієнт — сервіс подання заявок з особистим кабінетом: близько 240 екранів, частина на успадкованих шаблонах. Прогін на контрастність за Настановою з доступності веб-контенту (WCAG) показав, що 68 екранів не проходять перевірку, а 31 набрано кеглем нижче базового. Сканер видав 210 критичних зауважень — і це лише за ключовими сценаріями, які потрапили у вибірку.
Що змінили в реалізації
Контраст винесли в токени теми: замість колірних кодів усередині компонентів — пари «текст/фон», перевірені на відношення 4.5:1 для основного тексту й 3:1 для великого, з окремими значеннями для наведення й неактивного стану.
Шкалу типографіки звели до шести розмірів із кроком від базового та заборонили локальні перевизначення кегля в розмітці — інакше наступний розробник знову ламає те, що вже полагодили.
Що показали заміри
Частка екранів, що проходять автоматичну перевірку, зросла з 72% до 100%: критичних зауважень нуль, залишилися поодинокі попередження на перекладах.
Частка завершених форм піднялася з 61% до 84% — люди перестали покидати заповнення на кроці, де підписи полів були сірими на сірому. Звернення в підтримку з формулюванням «не бачу текст» скоротилися втричі за той самий період.
Чим відрізняються рівні AA і AAA в WCAG і який вибирати?
Рівні WCAG — це не «якість вищого ґатунку», а формальні пороги: A — базовий мінімум, AA — галузевий стандарт, на який посилаються у вимогах і тендерах, AAA — розширений. Різниця між ними вимірювана і насамперед стосується вимог до контрастності тексту та елементів інтерфейсу.
| Рівень | Вимоги до контрасту | Кому потрібен | Обсяг правок |
|---|---|---|---|
| A | великий текст і елементи керування 3:1 | мінімальна відповідність | зазвичай уже виконаний |
| AA | звичайний текст 4.5:1, великий 3:1, контраст меж і станів | більшість сайтів і сервісів | токени палітри та стани компонентів |
| AAA | звичайний текст 7:1, великий 4.5:1 | держсервіси, банки, медицина, навчання | переробка дизайн-системи |
Рівень A закривається майже автоматично. AA вимагає перезібрати стани інтерфейсу: плейсхолдери, вимкнені кнопки, посилання всередині тексту, межі полів введення — їх найчастіше задають сірими «на око», і на перевірці вони поріг не проходять.
AAA піднімає планку до 7:1: фірмовий акцент майже ніколи не проходить як колір тексту, його залишають для фонів і великих заголовків.
На весь сайт такий рівень беруть рідко, бо він звужує палітру до кількох перевірених пар; вибірково — для довгих текстів, форм і розділів, де аудиторія читає довго.
Який рівень вибрати: базово — AA, він покриває юридичні вимоги й не ламає візуальний стиль. AAA вмикають точково — там, де є регулятор або аудиторія з порушеннями зору.
Перевірка контрасту автоматизується краще за інші критерії, але стани наведення й фокусу доводиться звіряти вручну — саме там залишаються пропуски.
Технічні сумніви щодо доступності та розмірів шрифту
Питання щодо доступності майже завжди впираються в одне й те саме: як виконати вимоги контрастності WCAG, не розходячись із брендом, і не переписувати заново те, що вже працює. Нижче — відповіді на те, що найчастіше випливає на етапі перевірки інтерфейсу.
Фірмові кольори не проходять за контрастом — міняти палітру?
Заміняти не потрібно. Ми розширюємо палітру похідними тонами: для тексту беремо затемнений варіант бренд-кольору, для підкладок — освітлений, а сам вихідний колір залишаємо в логотипі, великих заливках і декорі, де вимоги до контрасту м’якші.
Отримані відтінки фіксуємо як іменовані значення палітри, щоб дизайнер не підбирав їх заново в кожному макеті.
У нас уже впроваджено набір компонентів — усе переробляти?
Ні. Правки йдуть у базові рівні: типографіку, кнопки, поля введення, посилання, стани наведення й фокусу. Інші компоненти успадковують ці значення, тому зміна доходить до них без ручної правки. Фактично змінюються кілька десятків рядків у загальних стилях, а не весь інтерфейс.
Шрифт бренду тонкий і на дрібних розмірах «розсипається». Що робити?
Дивимося метрики накреслення: висоту рядкових, міжлітерний просвіт, насиченість. Для тонких варіантів піднімаємо мінімальний розмір і вагу, додаємо запас за міжрядковим інтервалом.
Текст перестає злипатися за збільшеного масштабу, а характер шрифту зберігається на заголовках, де він працює як задумано.
Як ви перевіряєте результат?
Ручний прохід за ключовими екранами плюс автоматичну перевірку у збірці: вона ловить контраст і розміри шрифту на нових елементах і не дає відхиленням повернутися.
Додатково дивимося інтерфейс за збільшення масштабу та на вузьких екранах — так видно, де верстка ламається, а не лише де бракує контрасту.
Обговоримо завдання і повернемося з оцінкою та планом
Щоб оцінка робіт була точною, а не приблизною, на старті потрібен мінімальний набір вихідних даних. Чим повніший склад, тим менше припущень у плані впровадження і тим рідше обсяг правок змінюється в середині проєкту.
- Перелік сторінок і розділів, де контраст тексту та розміри шрифтів викликають питання, — включно з кнопками, полями введення й повідомленнями про помилки.
- Чинні значення кольорів і типографіки: макет, тема оформлення або таблиця стилів зі змінними.
- Цільовий рівень відповідності та вимоги вашого боку або зовнішньої перевірки, якщо вони вже сформульовані.
- Звіти та скриншоти минулих замірів — за ними видно, які зауваження вже закривалися.
- Доступ до репозиторію або тестового стенда: перевіряємо контраст і масштабування тексту на живих сторінках, а не на копії макета.
- Список підтримуваних браузерів і пристроїв, включно з мобільними, та налаштування масштабування, які потрібно врахувати.
- Обмеження щодо дизайну: фірмові кольори й накреслення, які не можна змінювати, — під них підбираємо найближчі припустимі відтінки.
Далі ми звіримо дані, уточнимо кілька деталей і повернемося з оцінкою робіт, планом впровадження за етапами та складом змін у стилях і компонентах. Обговоримо завдання: розберемо пріоритети, назвемо порядок робіт і покажемо, що саме ви отримаєте на виході.
