Доступность

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

Ограничения бывают:

• Ситуативные: солнце светит в экран смартфона; в руках сумки, а нужно ответить на звонок.
• Временные: рука в гипсе; сломался ноутбук, и есть доступ только к медленному или старому устройству.
• Постоянные: инвалидность с нарушением зрения или опорно-двигательного аппарата.

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

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

Web Content Accessibility Guidelines (WCAG) выделяет четыре принципа доступности приложения: воспринимаемость, управляемость, понятность и надёжность.

Ниже мы перечислили, на что следует обращать внимание, разрабатывая интерфейсы Контура.

Это доступность информации и интерфейса для любого пользователя.

Текст с низким контрастом к фону труднее разбирать, а при возникновении ограничений такой текст может стать совсем нечитаемым. Текст с высоким контрастом к фону тоже утомляет глаза — ресурс колбочек и палочек исчерпаем.

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

Проверяйте контрастность текста. Используйте рекомендации из гайда «Цвет»:

• Текст должен иметь контрастность 4,5:1
• Крупный текст размером от 18 pt — 3:1

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

Дополняйте обратную связь контрола иконками и текстом:

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

С клавиатуры некоторые формы заполняются быстрее. Фокусные состояния у контролов и элементов интерфейсов помогают пользователю восстановить контекст, если он отвлёкся или страдает расстройствами внимания.

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

В нативных элементах браузер уже решает основные сценарии управления с клавиатуры. При создании кастомных или сложных контролов берите за основу нативные и следуйте гайду от w3c. Основные его положения:

• Контролы должны иметь привычные стили для состояний focus, hover, active и visited.
• Контролами можно управлять с помощью клавиш Tab, пробела ⎵, Enter и стрелок ← ↓ ↑ → клавиатуры.

Заключайте поля формы в тег ‹form›, так программы для чтения страницы корректно поймут, что на странице форма.

Проверьте, что форму можно заполнить и отправить, используя только клавиатуру.

Чем меньше экран и сложнее расположены контролы, тем больше должны быть их размеры. Кнопки и контролы в интерфейсах Контура должны иметь ширину и высоту минимум 32 px на десктопе и 40 px на мобильных и планшетах, с расстоянием между ними не меньше 8 px.

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

Принципы работы с интерфейсом должны быть консистентны в рамках экосистемы Контура и тем более внутри одного продукта. Следуйте уже заложенным паттернам: например, если одна форма сохраняет изменения при каждом изменении значений полей, то и остальные должны делать так же, а не сохранять изменения только по нажатию кнопки «Сохранить».

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

Подробнее о том, как писать понятные пользователю тексты, — в гайде «Текст в интерфейсе».

Подробнее об оформлении текста, размерах и шрифтах — в гайде «Текстовые стили».

Контент и интерфейс должны сохранять понятность и воспринимаемость при использовании сторонних пользовательских программ, озвучивающих интерфейс: NVDA, JAWS, встроенный в MacOS ассистент. Если верстать по стандарту, как это описывает WCAG, то для этого не потребуются дополнительные доработки. Реализуя интерфейс, следите за семантикой тегов. Проверяйте интерфейс программами для чтения с экрана.

Подписывайте элементы на странице — так их назначение понятно всем, в том числе тем, кто пользуется скринридером:

• добавляйте названия полям и контролам формы тегом ‹label›;
• пишите текст ссылки так, чтобы он был понятен без соседнего текста: скринридер читает ссылки отдельным списком, вне абзаца;
• Добавляйте атрибут alt к тегу ‹img› и описывайте в нём, что изображено:alt="Женщина оплачивает покупку через Контур.Кассу". Исключение — декоративные картинки: у них оставляйте alt="", чтобы скринридер их пропустил.

Создавая разметку, используйте специальные html-теги по смыслу блока, aria-атрибуты для придания смысла разметке при чтении её скринридером.

Используйте тег ‹a› для ссылок, а ‹button› для кнопок исходя из их функциональности, а не внешнего вида, чтобы пользователь скринридера корректно воспринимал страницу.

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

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

Адаптивная вёрстка подстраивает сервисы под размер экрана пользователя и предоставляет наиболее удобный способ взаимодействия с ними, меняя размер и расположение компонентов интерфейса.

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

Инструменты для тестирования и проверки интерфейсов

• В браузерах есть встроенные инструменты проверки вёрстки на контрастность (при помощи color picker) и семантику разметки. Используйте их при вёрстке. Подробнее в статье от chrome.
• Расширение браузера aXe проверит и выведет ошибки в панель разработчика браузера. Также его можно внедрить как шаг в CI.
• Расширение Lighthouse от Google проводит аудит сайта на основные правила доступности.