Колірний контраст в інтерфейсі: основні принципи

Колірний контраст — один із тих елементів, через які ми, дизайнери, можемо реально впливати на доступність. Звісно, доступність — це щось більше, ніж просто кольори. Але саме контраст — один із найпростіших параметрів, які можна виміряти, перевірити й покращити.

Гайдлайн WCAG доволі об’ємний і складний, що може налякати тих, хто тільки починає знайомитись із темою. Щоб полегшити вам старт, я підготував кілька наочних прикладів, які покажуть, як саме працює колірний контраст в UI-дизайні та як з ним ефективно взаємодіяти.

У цій статті розглянемо основні принципи та приклади того, як ефективно працювати з контрастом у дизайні, а також дамо відповіді на питання:

• Що таке коефіцієнт контрастності і як він вимірюється?
• Які вимоги існують для різних елементів?
• Як виконувати ці вимоги практично.

Основи

Колір — один із найскладніших інструментів у дизайні. Щоб зрозуміти, як він працює, потрібно трохи розбиратись у людському сприйнятті, колірних моделях, а іноді навіть у математиці та історії.

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

Коли ви знайомі з HSL-моделлю (Hue — відтінок, Saturation — насиченість, Lightness — яскравість), усе стає набагато логічніше. Наприклад, кольори з однаковими відтінком і насиченістю, але різним рівнем яскравості, виглядають зовсім по-різному — світлішими або темнішими.

Коефіцієнт контрастності

У гайдлайні WCAG коефіцієнт контрастності (contrast ratio) — це показник, який описує співвідношення яскравості двох кольорів, як їх сприймає людське око. Його значення може коливатись від 1:1 (мінімальний контраст) до 21:1 (максимальний контраст).

Найвищий коефіцієнт контрасту — це комбінація чорного тексту на білому фоні (або навпаки). І важливий момент: порядок кольорів у розрахунку не має значення — результат завжди буде той самий.

У дизайні ми зазвичай вимірюємо контрастність між елементом на передньому плані та його фоном. Найчастіше це стосується саме тексту. Але WCAG також згадує про «суміжні» або сусідні кольори — наприклад, у випадку з кнопками чи формами, де треба враховувати й контраст меж, і колір фону, і самих елементів управління.

Буває, що навіть для одного єдиного компонента потрібно перевірити кілька різних коефіцієнтів контрастності.

До речі, хоча офіційне значення виглядає як 3.5:1, у цій статті ми іноді скорочуватимемо його до 3.5 — бо частина ":1" завжди залишається незмінною й зрозуміла з контексту.

Рівні відповідності

У WCAG 2.2 є три рівні відповідності: A, AA та AAA. Вони працюють як орієнтири, що допомагають зрозуміти, наскільки наш дизайн дійсно доступний для користувачів.

Усі елементи інтерфейсу в рекомендаціях поділяються на текстові та нетекстові. До нетекстових належать дві основні категорії: UI-компоненти — тобто кнопки, чекбокси, перемикачі та інші елементи керування та графічні об’єкти — наприклад, іконки, декоративні елементи чи ілюстрації.

Кожен тип елементів має свої власні вимоги, які потрібно виконати, щоб отримати відповідність на рівні AA або AAA. Нижче — кілька типових прикладів, які покажуть, як це працює на практиці.

Текст

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

• Звичайний текст — це все, що має 24px і менше. Якщо текст жирний — тоді межа зменшується до 19px і менше.
• Великий текст — від 24px і більше, або 19px+, якщо текст жирний.

Які коефіцієнти контрастності потрібні для відповідності стандартам:

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

Текст на зображені

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

Тут є кілька лайфхаків:

• Напівпрозорий шар між текстом і зображенням.
  Це найпростіший спосіб зробити текст читабельним. Просто додаєш напівпрозорий чорний чи інший кольоровий шар поверх картинки — і все: текст видно, картинку видно.
• Тінь навколо тексту — “ореол”.
  Така тінь створює буферну зону, яка контрастує з будь-яким фоном. Навіть якщо підпис стоїть прямо на снігу — він все одно залишиться читабельним.

Текст на градієнтах

Хоча WCAG не дає чітких інструкцій щодо тексту на градієнтах, тут варто включити логіку. Я раджу перевіряти контрастність не тільки з основним кольором, а з усіма кольорами градієнта. Бо текст буде “плавати” на різних відтінках — і важливо, щоб усюди залишався читабельним.

Наприклад, білий текст на фіолетовому — ідеально. А ось той самий білий на світлому синьому — вже виглядає не дуже. Якщо не проходить перевірку — є два варіанти:

• зробити синій темнішим;
• або збільшити розмір шрифту, щоб потрапити у лояльнішу категорію великого тексту.

Текстові посилання

Тут мова про посилання всередині абзаців, не про великі кнопки. Якщо єдиний спосіб їх виділити — це колір, то цього замало. Посилання має:

• контрастувати з фоном,
• і водночас бути помітним серед звичайного тексту.

На прикладі нижче видно, скільки контрастів треба враховувати (особливо якщо текст великий).

Щоб не мучитись — завжди додавай підкреслення. Це однозначно вказує користувачу: “тут посилання”. Якщо робиш підкреслення на ховер — це ок, але краще, щоб воно було завжди. І тоді контраст з іншим текстом уже не обов’язковий. Бо вже видно, що це інший елемент. Наприклад, посилання може бути тим самим кольором, що й основний текст — якщо він підкреслений.

Декоративний текст

Виняток із правил — декоративний текст, який не виконує жодної важливої ​​функції. Суперечливий сценарій — вимкнений текст (наприклад, якщо елемент заблокований), який також не повинен відповідати жодним критеріям.

UI-компоненти

З текстом розібралися. Тепер давай подивимось, як поводитися з іншими елементами інтерфейсу.

Будь-який UI — це набір компонентів. Одні з них просто інформують, інші — чекають взаємодії. І саме для інтерактивних треба подбати про зрозумілість і доступність.

Що це означає? Наприклад:

• обведення полів,
• стрілки в дропдаунах,
• будь-які візуальні підказки, що допомагають зрозуміти: “тут можна клікнути”.

Усі ці компоненти мають мати контраст щонайменше 3:1, якщо це основний спосіб показати, що елемент інтерактивний. Але це не означає, що кожен елемент має мати жирне чорне обведення. Якщо обведення компонента відіграє суто декоративну роль, вимоги контрастності не використовуються.

Кнопки

Тут теж все просто. Не обов’язково малювати рамку або тінь, щоб дати зрозуміти, що це кнопка. За умови, що її добре видно завдяки тексту, розташуванню чи загальному контексту. Контраст самої кнопки з фоном не є обов’язковим. Але якщо всередині є текст — правила застосовуються стандартно.

Обидві кнопки на зображенні вище відповідають вимогам. Однак ту, що праворуч, ідентифікувати простіше завдяки більш темному обведенню.

Поля введення та елементи керування формами

Коли мова про форми — всякі інпут-філди, чекбокси й радіокнопки — видимі межі реально важливі. Саме вони часто допомагають юзеру зрозуміти, де можна щось ввести або вибрати.

У прикладі нижче обведення є основним способом ідентифікації поля введення з білою заливкою, розташованого на світлому тлі, тому вона повинна мати мінімальний коефіцієнт контрастності 3:1.

Якщо прибрати обведення, єдиним індикатором компонента залишиться заливка.

Є ще компоненти з кількома частинами — наприклад, тогли. Там важливо не просто зробити красиво, а грамотно підібрати кольори для кожного елементу:

• іконки,
• ручки перемикача,
• заливки самого тогла,
• фону сторінки.

І ось тут вже треба стежити за контрастом між кожною парою:

• іконка ↔ ручка,
• ручка ↔ сам тогл,
• тогл ↔ фон.

Для всіх пар — мінімум 3:1.

Стану

Компоненти повинні відповідати вимогам контрастності у будь-якому стані.

Стан фокусу

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

Однак, якщо ви плануєте розробити власний кастомний фокус-стан, варто подбати про належний контраст кольору обведення як із заливкою самого компонента, так і з фоном сторінки.

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

Відключений стан

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

Інші графічні елементи

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

Не всі іконки мають відповідати вимогам контрастності. Це стає критичним лише тоді, коли іконка несе змістовне навантаження і супроводжується текстовим підписом.

У прикладі ліворуч іконка виконує декоративну функцію — вона доповнює зміст, але не є основним джерелом інформації, оскільки її значення пояснюється текстом. У такому випадку контрастність не є обов’язковою. Якщо ж підпису немає (приклад – праворуч), іконка повинна відповідати мінімальному контрасту 3:1.

У деяких випадках іконки є ключовими для взаємодії з інтерфейсом. Наприклад, стрілки у спадних списках вказують на наявність додаткового контенту або напрямок дії. У подібних випадках дотримання вимог до контрастності (мінімум 3:1) є обов’язковим.

Інструменти для перевірки контрасту

Щоб перевірити контраст між кольорами, зручно використовувати спеціалізовані інструменти, такі як WebAIM. Також є безліч плагінів для Figma — наприклад, Contrast Checker, який легко вбудовується у звичний робочий процес.

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

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

Наприклад, якщо пара кольорів $color-text-primary і $color-background-default відповідає вимогам контрастності, ми можемо безпечно застосовувати її для різних компонентів інтерфейсу. Це скорочує кількість рутинної роботи та знижує ймовірність помилок.

Хоча в цій статті основна увага приділена саме кольоровому контрасту, в окремих випадках не варто покладатися виключно на колір, якщо мета — створити інтерфейс, зручний та доступний для всіх користувачів.

Статус

Зверніть увагу на приклад нижче. У цьому календарі колір — єдиний візуальний індикатор, який сигналізує про вартість у певні дні. Користувачі з дальтонізмом, які не розрізняють зелений і червоний, не зможуть помітити різницю та ризикують втратити важливу інформацію, що впливає на ухвалення рішення.

Схожа ситуація — коли статус компонента позначено лише кольором. Оптимальне рішення — додати текстові підказки або плашки зі статусом, щоб забезпечити альтернативне сприйняття.

Інший поширений приклад — повідомлення про помилку в полях введення. Одного лише червоного кольору недостатньо: більш ефективно поєднувати його з іконкою або пояснювальним текстом.

Діаграми

Діаграми — окрема категорія графіки. Навіть за умови достатнього контрасту між кожним кольором і фоном, складно гарантувати, що всі суміжні кольори матимуть належний контраст один відносно одного.

Щоб покращити сприйняття, варто використовувати додаткові засоби: збільшити відступи між сегментами (негативний простір), додати текстури або пояснювальні підписи. Такі підходи дозволяють зробити інформацію зрозумілішою, навіть якщо колірне кодування відіграє другорядну роль.

Майбутнє

Посібник WCAG — крута точка старту для створення доступних інтерфейсів. Але іноді трапляються нюанси: деякі кольорові пари, які візуально виглядають ок, не проходять перевірку, а ті, що виглядають суперчитабельно, можуть не вписуватись у вимоги.

Наразі готується нове покоління стандартів — WCAG 3.0, і з ним з’являється нова модель розрахунку контрасту — APCA. Вона точніше відображає, як ми реально бачимо кольори на екранах, і використовує зовсім інший принцип оцінювання, ніж звична нам формула. Це може стати новим стандартом у найближчому майбутньому.

Альтернативні колірні моделі

Поки чекаємо на повноцінний запуск APCA, можна використовувати інші підходи для створення більш передбачуваних і зрозумілих колірних пар.

Один з таких — HSLuv. Це модифікована версія знайомої HSL, яка набагато краще відображає те, як люди насправді сприймають яскравість кольору.

У HSL, наприклад, жовтий із L=70 виглядає набагато яскравішим, ніж синій із тим самим L. Але в HSLuv ці кольори виглядають більш збалансовано. Тобто, якщо взяти кольори з однаковою яскравістю (наприклад, L=50), ми можемо передбачити, що їхній контраст із L=95 буде стабільно ~8.2, незалежно від відтінку.

🎨 У Figma для цього існує зручний плагін — HSLuv Figma Plugin, який допоможе конвертувати кольори у потрібну модель.

Висновок

Колірний контраст — не просто формальність. Це реальний інструмент, що робить інтерфейси зручнішими для всіх. І хоча універсального рішення немає, дотримання стандартів WCAG або тестування через APCA — це вклад у якість, яку відчують користувачі.

Світ інтерфейсів стає доступнішим — і це наша спільна заслуга.