Як перевірити колірний контраст без встановлення будь-чого

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

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

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

Правила контрасту, які вам справді потрібні

Для більшості вебзавдань контраст за WCAG зводиться до кількох порогів:

• Звичайний текст: щонайменше 4.5:1 контрасту відносно фону.
• Великий текст: щонайменше 3:1. WCAG визначає це приблизно як 24 CSS-пікселі або близько 18.66 CSS-пікселя, якщо текст жирний.
• Компоненти інтерфейсу та графічні об’єкти: щонайменше 3:1 для значущих меж, іконок, станів і частин діаграм, потрібних для розуміння інтерфейсу.
• Підвищений контраст: 7:1 для звичайного тексту та 4.5:1 для великого тексту, якщо ви прагнете перевищити базовий рівень.

Є винятки, наприклад неактивні елементи керування, декоративні елементи та логотипи. Використовуйте ці винятки помірковано. «Це частина бренду» — не виняток; це дизайн-обмеження.

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

Починайте з відрендереної сторінки, а не з дизайн-файлу

Дизайн-файли корисні, але вони не враховують усіх реальних змінних: CSS-перевизначення, прозорість, стани наведення, рендеринг шрифтів у браузері, масштаб користувача, темний режим, успадковані стилі, CMS-контент і маркетингові вставки.

Перевіряйте сторінку такою, якою її отримують користувачі.

Відкрийте сторінку в сучасному настільному браузері. Chrome, Edge, Firefox і Safari мають корисні інструменти інспектування. Точні назви відрізняються, але робочий процес однаковий:

1. Клацніть правою кнопкою миші текст або елемент інтерфейсу.
2. Виберіть Inspect.
3. Знайдіть обчислені color і background-color.
4. Використайте колірний зразок браузера або панель доступності, щоб прочитати коефіцієнт контрасту.
5. Зафіксуйте проходження, провал і невизначеність.

У браузерах на базі Chromium піпетка/вибір кольору часто показує коефіцієнт контрасту та підказки pass/fail за WCAG для тексту. Firefox DevTools також надає інформацію про доступність і колірні інструменти. Safari Web Inspector може показувати обчислені стилі та інформацію про доступність, хоча робочий процес трохи інший.

Ключове — не конкретний браузер. Ключове — читати обчислений результат, а не значення, яке, на чиюсь думку, використовує компонент.

Спершу складіть короткий список для аудиту

Не інспектуйте випадковий текст, доки не втомитеся. Складіть короткий перелік патернів:

• Основний текст на головному фоні сторінки.
• Приглушений текст, підписи, метадані та плейсхолдери.
• Посилання у звичайному стані, при наведенні, відвідані та у фокусі.
• Основні, вторинні та деструктивні кнопки.
• Мітки форм, допоміжний текст, помилки та повідомлення про успіх.
• Елементи навігації, «хлібні крихти» та вкладки.
• Картки, бейджі, pills і теги.
• Іконки, що передають значення.
• Діаграми, карти, індикатори прогресу та статусні кольори.
• Текст поверх зображень, відео, градієнтів або напівпрозорих накладень.

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

Якщо ваш аудит включає кнопки, поєднайте перевірку контрасту з базовими пунктами з нашого чекліста доступних вебкнопок. Проблеми контрасту кнопок часто розташовані поруч із відсутніми станами фокуса, нечіткими підписами або зламаною поведінкою з клавіатури.

Перевіряйте контраст тексту в DevTools

Для простого тексту на суцільному фоні браузер зазвичай може обчислити контраст за вас.

Інспектуйте елемент і знайдіть властивість color. Відкрийте вибір кольору зі зразка. Якщо браузер може визначити фон, він покаже коефіцієнт контрасту. Деякі інструменти також малюють лінію у виборі кольору, яка показує, де колір проходив би 3:1, 4.5:1 або 7:1.

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

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

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

Перевіряйте реальний фон, включно з прозорістю

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

Поширені пастки:

• Текст усередині напівпрозорої картки.
• Текст на батьківському елементі із застосованим opacity.
• Накладення, що використовують rgba() або color-mix().
• Градієнти за заголовками.
• Фонові зображення, які змінюються по всій ділянці тексту.
• Змінні теми, що змінюються в темному режимі.

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

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

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

Не забувайте про стани

Статичні скриншоти пропускають багато проблем контрасту. Перевіряйте стани взаємодії безпосередньо в браузері.

У DevTools примусово вмикайте псевдокласи, такі як:

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

Потім знову інспектуйте обчислені кольори.

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

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

Використовуйте Lighthouse, але не передавайте йому своє судження

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

Автоматизовані перевірки добре знаходять текстові вузли з очевидними провалами обчисленого контрасту. Вони слабші в таких випадках:

• Текст, вбудований у зображення.
• Мітки, відрендерені в canvas.
• Крайові випадки SVG.
• Проблеми, що проявляються лише при наведенні.
• Якість індикатора фокуса.
• Діаграми, де колірні зв’язки передають значення.
• Компоненти, приховані за автентифікацією, меню або кроками форми.

Якщо звіт зелений, вам усе одно потрібно інспектувати репрезентативні компоненти. Якщо звіт червоний, не панікуйте й відсортуйте проблеми за впливом на користувача. Той самий принцип загалом стосується звітів про продуктивність і доступність: читайте результат інструмента як доказ, а не як вирок. Ми використовуємо такий підхід у нашому посібнику з читання звіту Lighthouse без паніки, і тут він добре працює.

Перевіряйте також нетекстовий контраст

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

Перевірте принаймні ці випадки:

• Межі полів вводу відносно фону сторінки.
• Контури checkbox і radio.
• Стани перемикачів.
• Кнопки лише з іконкою.
• Іконки помилок і попереджувальні символи.
• Лінії, стовпчики та підписи діаграм.
• Індикатори прогресу.
• Індикатори вибраної вкладки або активної навігації.

Ціль зазвичай становить 3:1 відносно суміжних кольорів. Наприклад, світло-сіра межа поля вводу на білому фоні може бути майже невидимою. Діаграма з п’ятьма пастельними лініями може виглядати елегантно й водночас бути непридатною.

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

Фіксуйте результати у форматі, корисному для розробників

Корисний аудит контрасту не каже «деякі сірі не проходять». Він визначає компонент, стан, поточні значення, очікуваний поріг і запропоноване виправлення.

Добре працює компактний формат:

| Component | State | Foreground | Background | Ratio | Target | Result | Suggested fix | |---|---:|---:|---:|---:|---:|---|---| | Метадані картки | За замовчуванням | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | Не проходить | Використати --color-text-muted-strong | | Основна кнопка | Hover | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | Проходить | Залишити | | Межа поля вводу | За замовчуванням | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | Не проходить | Затемнити токен межі |

Прив’язуйте виправлення до дизайн-токенів, якщо сайт їх має. Не латайте двадцять окремих компонентів, якщо справжня проблема — один слабкий токен.

Робіть виправлення трохи сильнішими за мінімум

Проблеми контрасту часто легко виправити погано. Команди підсувають колір, доки перевірка не покаже 4.51:1, і рухаються далі. Це не залишає запасу для рендерингу шрифтів, прозорості, відмінностей між браузерами, тем, варіативності зображень або майбутніх змін бренду.

Віддавайте перевагу комфортним цілям:

• Основний текст: ближче до 7:1, коли це практично.
• Приглушений текст: усе одно вище 4.5:1, якщо це справжній контент.
• Межі та іконки інтерфейсу: упевнено вище 3:1.
• Текст поверх зображень: використовуйте контрольоване накладення, а не здогадки для кожного зображення.

Веб переглядають на дешевих ноутбуках, тьмяних телефонах, яскравих тротуарах, тонованих моніторах і старих дисплеях. Мінімальна відповідність — не те саме, що комфортне читання.

<!-- tool-cta:start -->

💡 Спробуйте це: Під час перевірки контрастних пар, взятих із DevTools, Color Converter допомагає перетворювати значення між hex, RGB і HSL, щоб вони збігалися з вашими нотатками аудиту.

<!-- tool-cta:end -->

Чекліст аудиту контрасту без встановлення

Використовуйте цю послідовність, коли потрібен швидкий, але переконливий аудит:

1. Відкрийте виробничу сторінку в сучасному браузері.
2. Перелічіть основні текстові, інтерфейсні та станові патерни.
3. Інспектуйте обчислені кольори переднього плану й фону в DevTools.
4. Використайте вбудований вибір кольору або панель доступності, щоб прочитати контраст.
5. Примусово ввімкніть стани hover, focus, active, visited і invalid.
6. Перевірте текст поверх зображень і градієнтів відносно найгіршого правдоподібного фону.
7. Перевірте нетекстові частини інтерфейсу відповідно до вимоги 3:1.
8. Запустіть вбудований автоматизований аудит як підстраховку, а не як увесь аудит.
9. Фіксуйте проблеми за компонентом і токеном.
10. Виправляйте із запасом, а не ледь перетинаючи поріг.

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