Палітра створює характер, але не повинна приховувати зміст
Уявімо список заявок: біля однієї зелена крапка, біля іншої — помаранчева. Для автора макета все очевидно. Відвідувачеві доводиться здогадуватися: заявку прийнято, перевірено чи вже виконано? Проблема не лише у сприйнятті кольору, а й у відсутності пояснення. Критерій WCAG 1.4.1 вимагає не покладатися тільки на колір для передавання інформації. Практичний початок роботи — знайти всі місця, де зміна відтінку змінює значення, і записати це значення звичайними словами. Декоративний градієнт може залишитися декоративним; статус оплати — ні.
Помилка має називати наступний крок
Червона рамка навколо поля підказує, де щось не так, але не пояснює, що саме виправити. Для вигаданої форми запису корисніше повідомлення: «Вкажіть дату пізніше сьогоднішньої» поруч із полем дати. Додаткова піктограма допомагає помітити повідомлення, та не замінює його. Не варто позначати обов’язкові поля лише іншим кольором: слово «обов’язково» або заздалегідь пояснений символ знімає неоднозначність. Текст помилки потрібно також програмно пов’язати з відповідним полем. Видима підказка і доступність для допоміжних технологій — дві окремі частини одного рішення, а не взаємозамінні прийоми.
Статус потребує назви, а не лише індикатора
У картці замовлення крапка може супроводжувати напис «Очікує підтвердження». Після зміни стану змінюється і текст: «Підтверджено». Так людина не мусить пам’ятати легенду кольорів. Якщо оновлення відбувається без перезавантаження, команда окремо перевіряє, чи повідомляється воно допоміжним технологіям доречним способом. Не слід робити кожен косметичний рух терміновим оголошенням. Для перемикача або вибраного пункту важливо зберігати і видиму ознаку вибору, і правильний програмний стан. Напис у кутку екрана не виправить контроль, який технічно залишається невибраним.
Графік повинен читатися без кольорового ребуса
Уявний графік запитів із двох каналів можна позначити не лише синьою та зеленою лініями, а й різними маркерами та прямими підписами біля серій. Якщо лінії перетинаються, назви тільки в далекій легенді змушують погляд постійно мандрувати. Під графіком доречно подати головний висновок словами, а для точних значень — доступну таблицю. Штрихування допомагає розрізняти області, але надмірна кількість візерунків створює шум. Вибирайте мінімум засобів, достатній саме для цього порівняння. Зображення графіка без текстового пояснення не стає повністю доступним лише завдяки новій палітрі.
Контраст і значення — різні перевірки
Темніший зелений може краще вирізнятися на світлому тлі, але не пояснює, що означає зелений. Контраст допомагає побачити знак; підпис допомагає його зрозуміти. WCAG 1.4.11 окремо розглядає контраст важливих нетекстових елементів. У роботі це означає перевіряти потрібні межі, індикатори й значущі частини графіки, а не механічно вимагати рамку навколо всього. Для тексту діють окремі вимоги. Іконка з чудовим контрастом може бути незрозумілою, а добре сформульований напис — надто блідим. Жодна з цих переваг не компенсує іншу проблему.
Перевіряйте сценарій, а не тільки скриншот
Тимчасово переведіть макет у відтінки сірого й спробуйте знайти помилку, вибраний тариф та завершене завдання. Це швидкий спосіб помітити залежність від кольору, але не доказ відповідності WCAG і не точна модель усіх особливостей зору. Далі пройдіть справжній сценарій клавіатурою, перевірте назви й стани контролів, читабельність повідомлень та потрібні контрасти. Попросіть людину, яка не бачила макета раніше, пояснити значення позначень без підказки. Перед передаванням у розробку зафіксуйте правило компонента: який текст, знак і програмний стан супроводжують кожен результат. Так рішення переживе наступну зміну палітри.