Привет, я Антон, UX-дизайнер. Работаю над библиотекой компонентов eLama. Расскажу о том, как мы обнаружили один из недостатков библиотеки и как его исправили.

Когда мы начали работать над компонентами, изначально мы уделили мало внимания контрастности. Поняли мы это быстро благодаря отзывам от недовольных пользователей.

Один пользователь заполнил форму, но не смог ее отправить: кнопка отправки была заблокирована, хотя все поля выглядели заполненными. На самом деле одно поле было пустым, просто информация из плейсхолдера совпала с реальными данными, а сам плейсхолдер был достаточно ярким и контрастным.

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

Немного теории

Контрастность — это отношение яркости элемента к яркости фона. Контрастность измеряется диапазоном от 1:1 до 21:1, где 1:1 — это минимальное значение, например, белый текст на белом фоне, а 21:1 — максимальное (черный текст на белом фоне).

В руководстве по доступности веб-контента (WCAG) очень подробно описаны требования к контрастности. Выделяются 2 уровня доступности:

1. AA — для людей со зрением немного хуже среднего (острота 0,5 или 20/40)

2. AAA — для людей с плохим зрением (острота 0,25 или 20/80)

Что с контрастностью у других компаний

У текста на цветных плашках в компонентах «Газпрома» преимущественно очень низкая контрастность:

У Semrush и «ВКонтакте» похожая ситуация:

Можно ли назвать эти интерфейсы плохими только из-за низкой контрастности? Вряд ли. Достаточный уровень контрастности — это важный, но не единственный критерий для оценки интерфейса. Главное, соблюдать требования к контрастности там, где это напрямую влияет на решение задачи пользователя — например, в тех же кнопках и плейсхолдерах.

Как мы улучшали контрастность в eLama

Мы замерили контрастность в Figma с помощью плагина Contrast:

Сначала мы проверили компоненты, которые имеют цветные подложки: кнопки, лейблы и беджи. Оказалось, что только у синей кнопки был допустимый уровень контрастности:

Контрастность лейблов и беджей оказалась низкой. Вот что получилось, когда мы увеличили контрастность лейблов минимум до 4,5:1:

Цвета основного и дополнительного текста сделали темнее. Для основного текста установили минимальный порог контрастности 13:1.

У дополнительного текста с новым цветом контрастность на белом фоне увеличилась до 4,25:1. Это меньше, чем допустимые 4,5:1. Но мы осознанно не стали увеличивать контрастность, чтобы основной текст отличался от дополнительного:

Также мы решили, что контрастность дополнительного текста на сером фоне должна быть минимум 3,5:1. Это снова меньше 4,5:1, и мы снова пришли к меньшему значению осознанно. Разница между вариантами с контрастностью 3,77:1 и 4,5:1 оказалась незначительной, поэтому мы решили не дробить токен дополнительного цвета на два — для белого фона и для серого.

А вот для плейсхолдера в поле мы, наоборот, уменьшили контрастность, чтобы текст выглядел как подсказка, а не как реальные данные, добавленные с помощью автозаполнения. При этом мы постарались сделать его читаемым:

Неактивные компоненты были самым слабым местом в нашей дизайн-системе с точки зрения контрастности. Гайдлайны WCAG говорят, что контрастность небольшого по размеру текста должна быть не меньше 4,5:1, кроме текста в неактивных элементах. И какого-то четкого ответа, какая должна быть контрастность в таких элементах, мы не нашли.

Мы решили, что контрастность должна быть от 2,5:1 до 3,5:1 в зависимости от фона текста — например, серого для обычной кнопки или белого для радиокнопки.

Контрастность самостоятельной иконки — иконки в поле, или кнопки-иконки — решили ограничить диапазоном от 1,5:1 до 2:1, чтобы они не выглядели кликабельными:

Главный вывод

Достаточный уровень контрастности делает интерфейс более удобным и помогает пользователю решать задачи. Поэтому не стесняйтесь жертвовать эстетикой и менять контрастность, если это поможет пользователям решать их задачи.