Доступность интерфейсов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как писать понятные пользователю тексты, читайте в гайде о редполитике.

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

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

Если использовать нативные элементы в качестве основы для контролов, например ‹button /› или ‹input /›, они реализуют доступность для читалок и других вспомогательных программ. Если контрол сложный, составной, описывайте в коде при помощи атрибутов role, title его роль и название. Атрибут role позволяет чётко указать назначение элемента страницы, например role=”banner” .

• Подписывайте поля формы с помощью тега ‹label /› и атрибута title.
• Создавайте человекочитаемые ссылки или добавляйте им название при помощи атрибута title.
• Добавляйте обязательный атрибут alt для тега ‹img /›. В атрибуте опишите то, что находится на картинке. Например, alt="Женщина оплачивает покупку через Контур.Кассу".

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

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

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

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

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

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

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

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