Дизайн для всех: внедрение инклюзивных практик в UX/UI

Инклюзивный дизайн — подход, при котором интерфейсом может пользоваться человек с ослабленным зрением, с ограниченной подвижностью рук, тот, кто работает с клавиатуры вместо мыши, и тот, кто читает сайт с телефона на ярком солнце. Это не отдельный «режим для людей с инвалидностью», а набор требований к макету и вёрстке, которые проверяются так же, как адаптивность или скорость загрузки. Ниже — что мы проверяем, в каком порядке и чем.

Доступность и инклюзивный дизайн: в чём разница

Доступность (accessibility) — измеримое свойство интерфейса: есть контраст, работает клавиатура, элементы подписаны. Её проверяют по списку и получают ответ «да» или «нет». Инклюзивный дизайн шире: это решение о том, кого мы считаем пользователем продукта и какие сценарии закладываем в проектирование.

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

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

Уровни WCAG и что из них брать в работу

WCAG (Web Content Accessibility Guidelines) — свод рекомендаций по доступности веб-контента, разделённый на три уровня соответствия.

• A — базовый минимум. Без него часть пользователей просто не выполнит задачу: форма, недоступная с клавиатуры, изображение-ссылка без текстовой альтернативы.
• AA — практический рабочий уровень: контраст текста 4,5:1, видимый индикатор фокуса, структура заголовков, подписи и понятные сообщения об ошибках, работа страницы при увеличении. На коммерческих проектах мы ориентируемся на него.
• AAA — повышенные требования: контраст 7:1, ограничения на длину строки и выравнивание. Целиком уровень достижим редко, отдельные критерии берём выборочно.

Требования сгруппированы по четырём принципам: воспринимаемость, управляемость, понятность и надёжность. Формулировки сухие, но каждое проверяется руками, и это удобно: спор «красиво или нет» превращается в проверку с однозначным исходом.

Что проверяем на макете

Дешевле всего чинить доступность до вёрстки. На макете смотрим шесть вещей.

1. Контраст текста и элементов управления. Обычный текст — от 4,5:1, крупный (от 18 пунктов или 14 полужирных) — от 3:1. Границы полей, иконки-кнопки и индикаторы состояния тоже должны быть контрастными. Светло-серый текст на белом фоне — самая частая находка.
2. Размер шрифта. Основной текст мельче 16 пикселей на мобильном заставляет увеличивать масштаб на каждом экране. Мелкий шрифт живёт в подписях и условиях — там же, где обычно важная информация.
3. Цвет как единственный носитель смысла. Красная рамка поля без текста ошибки, серая и зелёная точка статуса без подписи, ссылка в абзаце, отличающаяся только цветом, — всё это дублируем значком, подчёркиванием или словом.
4. Состояние фокуса. В макете нужен вид элемента при переходе на него с клавиатуры. Иначе при вёрстке фокус либо уберут вовсе, либо он потеряется на фоне.
5. Зоны нажатия. Цель меньше 44 пикселей по меньшей стороне промахивается регулярно. Соседние кликабельные элементы разводим по расстоянию.
6. Заголовочная структура. Один H1 на страницу, дальше уровни без пропусков. Для человека со скринридером заголовки — основной способ пролистать страницу, а не просто размер шрифта.

Что проверяем в вёрстке

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

• Семантика. Кнопка должна быть кнопкой, ссылка — ссылкой с адресом. Блок с обработчиком клика не получает ни фокуса, ни реакции на клавиши, ни объявления вслух.
• Порядок табуляции. Последовательность совпадает с визуальной, фокус не уходит в скрытые элементы и не попадает в ловушку без выхода — типичная беда самописных модальных окон.
• Подписи полей. Подпись связывается с полем программно. Плейсхолдер подписью не является: он исчезает при вводе, и человек уже не помнит, что вводил.
• Сообщения об ошибках. Текст рядом с полем, объясняющий, что конкретно не так, плюс программная связь с полем, чтобы сообщение прозвучало. Общее «Ошибка заполнения формы» вверху страницы не помогает никому.
• Альтернативный текст изображений. Содержательным картинкам — описание по существу, декоративным — пустая альтернатива. Имя файла и слово «картинка» только удлиняют озвучивание.
• Автовоспроизведение и мигание. Звук и видео не запускаются сами, движущиеся блоки можно остановить, мигания чаще трёх раз в секунду нет вовсе — это про светочувствительную эпилепсию, а не про вкус.
• Масштабирование. Страница остаётся рабочей при увеличении до 200%. Запрет масштабирования в мобильной вёрстке снимаем всегда.

Чек-лист приёмки

Этот список проходим перед сдачей и повторяем после крупных доработок. Он короткий намеренно: длинные чек-листы не выполняют.

Чем проверяем и где пределы автоматики

Автоматические проверки — встроенные аудиты браузера и расширения-анализаторы — находят часть проблем за минуту: недостаточный контраст, отсутствие альтернативных текстов, поля без подписей. Начинать удобно с них, но полагаться целиком нельзя: машина не оценит, осмысленна ли альтернатива к картинке, логичен ли порядок табуляции, понятен ли текст ошибки. Это проверяется руками, и на это уходит основное время.

Минимальный набор ручных проверок, который мы применяем на каждом проекте:

• пройти основной сценарий с клавиатуры, не касаясь мыши;
• увеличить страницу до 200% и повторить тот же сценарий;
• включить режим уменьшенного движения и посмотреть, что изменилось;
• прослушать ключевые экраны в скринридере, встроенном в операционную систему;
• открыть сайт на телефоне при ярком свете: слабый контраст и мелкие цели видно сразу.

Как встроить доступность в процесс

Доступность, добавленная в конце проекта, выходит дорого: приходится переделывать компоненты, цветовую схему, иногда логику форм. Мы распределяем работу по этапам.

1. Аналитика. Договариваемся об уровне соответствия — обычно AA — и фиксируем его в требованиях, а не в устной договорённости.
2. Дизайн. В библиотеку компонентов сразу закладываем состояния наведения, нажатия, фокуса, ошибки и отключённого элемента. Контраст проверяем у всей палитры, а не у отдельных экранов.
3. Вёрстка. Семантическая разметка по умолчанию, ручные атрибуты доступности — только там, где готовых элементов не хватает.
4. Приёмка. Проходим чек-лист выше и заводим найденное как обычные задачи, а не как пожелания.
5. Поддержка. Повторяем проверку после крупных изменений: новые блоки и сторонние виджеты ломают доступность чаще всего.

Что это даёт помимо соответствия требованиям

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

Спроектируем интерфейс, которым можно пользоваться

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

На проекте это отдельный этап: проектирование интерфейсов — сценарии, прототипы и проверка на живых пользователях.