Представьте, что вы заходите на сайт банка, чтобы оплатить счёт. Но кнопка «Отправить» не реагирует на клики мыши, а поля формы нельзя заполнить с клавиатуры. Или представьте, что все заголовки на странице для вас – просто жирный текст, и вы не можете понять структуру статьи. Это не гипотетические баги, а ежедневная реальность для миллионов людей, если команда разработки не думает о доступности веб-приложений.
Измерение доступности сайта – это не галочка для отчёта. Это способ убедиться, что ваш продукт работает для всех: для человека, который управляет интерфейсом только с клавиатуры, для того, кто воспринимает контент через скринридер вроде JAWS или NVDA, для коллеги, который не различает красный и зелёный. Как же перейти от абстрактного «нужно сделать доступным» к конкретным цифрам и фактам? Давайте разбираться.
Стандарт – ваш главный измерительный инструмент
В мире веб-доступности есть общепринятый стандарт – WCAG (Web Content Accessibility Guidelines). Это не закон, а подробная инструкция. WCAG строит рекомендации вокруг четырёх принципов: информация и элементы интерфейса должны быть воспринимаемыми, управляемыми, понятными и надёжными.
Стандарт делит критерии на три уровня соответствия: A (минимальный), AA (рекомендуемый и чаще всего требуемый законодательством) и AAA (максимальный). Для большинства проектов целью является уровень AA. Именно на его критерии и нужно ориентироваться при оценке.
Два подхода к измерению: автоматика и экспертиза
Оценить доступность интерфейса можно двумя взаимодополняющими способами.
Автоматизированное тестирование доступности
Это быстрый способ найти очевидные проблемы. Специальные программы-аудиторы сканируют код и отчётливо видят технические недочёты.
- Что измеряют: наличие альтернативного текста у изображений, достаточную контрастность цветов, корректность семантической вёрстки (используются ли теги `<button>` для кнопок, `<nav>` для навигации), наличие меток у полей форм.
- Инструменты: Встроенный в Chrome DevTools аудит Lighthouse выдаст первый отчёт за минуту. Плагины для браузера, такие как axe, позволяют проверять страницы прямо во время разработки. Эти инструменты находят около 30-40% проблем.
- Польза для вас: Вы быстро устраните барьеры, которые мешают работе assistive technology. Это как проверить орфографию перед отправкой текста – базовая, но необходимая гигиена.
Мануальное тестирование доступности
Здесь в дело вступает человеческий опыт и экспертиза. Автомат не поймёт, логичен ли порядок фокусировки при навигации с Tab, и не оценит, насколько понятно озвучивается интерфейс скринридером.
- Что измеряют: Качество работы с клавиатурой (всё ли можно сделать без мыши?), логичность озвучки скринридером (используются ли атрибуты ARIA для сложных виджетов?), понятность текстовых описаний и инструкций.
- Инструменты: Ваши руки (отключите мышь) и встроенные в системы программы экранного доступа. На Mac это VoiceOver, на Windows – NVDA (бесплатный) или JAWS. Попробуйте оплатить тестовый заказ в своём же интернет-магазине, используя только клавиатуру. Вы сразу увидите точки роста.
- Польза для вас: Вы найдёте проблемы в юзабилити для реальных пользователей. Это повышает удовлетворённость от продукта у всех, а не только у людей с ограниченными возможностями. Удобный порядок фокусировки – это удобно и для вас, когда вы быстро заполняете форму.
Чек-лист для практического замера
Чтобы оценка не была хаотичной, создайте для команды чек-лист на основе WCAG AA. Вот ключевые пункты, которые нужно проверить.
Восприятие контента
Всё ли доступно через разные каналы?
- Изображения и иконки: У всех ли не-декоративных изображений есть осмысленный альтернативный текст?
- Мультимедиа: Есть ли у видео субтитры? Предоставлена ли транскрипция для аудиофайлов?
- Цвет и контраст: Достаточен ли контраст текста относительно фона (минимум 4.5:1 для обычного текста)? Передаётся ли важная информация только цветом («красные поля – ошибки»)?
- Адаптация контента: Можно ли увеличить текст на странице в два раза без потери функциональности?
Управляемость интерфейсом
Можно ли им управлять разными способами?
- Клавиатурная навигация: Доступен ли весь интерактивный интерфейс с клавиатуры? Виден ли индикатор фокуса? Логичен ли его порядок?
- Время отклика: Не используются ли ограничения по времени, которые нельзя отключить или изменить?
- Безопасная навигация: Не возникает ли «ловушек фокуса», из которых нельзя выйти клавишами?
Понятность и надёжность
Ясен ли интерфейс и стабильно ли он работает?
- Веб-формы: Все ли поля имеют видимые и связанные подписи? Понятны ли сообщения об ошибках, которые объясняют проблему и путь её решения?
- Предсказуемость: Не вызывают ли изменения на странице (например, обновление контента) дезориентацию у пользователя скринридера?
- Совместимость: Корректно ли работают кастомные компоненты (слайдеры, модальные окна) с помощью ARIA и современных скринридеров?
Измерение – это путь, а не точка
Не пытайтесь сделать сразу всё идеально. Начните с аудита главной страницы и ключевого сценария (например, оформления заказа) с помощью автоматических инструментов для проверки доступности. Исправьте найденные ошибки.
Затем проведите сессию мануального тестирования доступности с фокусом на клавиатуре и одном скринридере. Внесите проверку доступности в Definition of Done для каждой новой фичи. Такой подход создаёт по-настоящему инклюзивный дизайн.
Измеряя и улучшая доступность для людей с ограниченными возможностями, вы делаете продукт удобнее для пожилого человека с тремором рук, для родителя, который держит ребёнка на руках и управляет сайтом одной рукой, для всех, кто ценит скорость и понятность. Доступность – это не про ограничения. Это про качество.