Почему мы избегаем темы доступности?
Кажется, что нужно выучить тонны спецификаций — WCAG, Section 508, ADA, EAA, ARIA, ATAG, UAAG.
И это не предел, у многих стран и даже отдельных штатов и регионов могут быть свои собственные акты или директивы.
Но на самом деле начать можно с простого практического подхода, ориентированного на реальных пользователей. По примеру "Простых проверок", которые предлагает WAI, у меня есть свой очень "приземленный" подход, который может взять себе на вооружение человек любой роли: программист-разработчик, дизайнер, тестировщик или менеджер продукт.
Философия подхода
Доступность — это не про галочки в чек-листах, а про людей. Людей с постоянными ограничениями и тех, кто оказывается в ситуативно ограниченных условиях:
- Постоянно невидящий пользователь.
- Временно человек с переломом руки.
- Ситуативно мама с ребенком на руках.
- Человек при ярком солнечном свете на улице.
- Человек с нарушением восприятия цвета.
Если человек не может использовать ваш продукт — это провал. Причин много: это плохой UX, упущенная аудитория, несоответствие современным стандартам. Подробности и статистику ВОЗ оставим для более объёмных материалов.
🛠️ 5-шаговая методика быстрого аудита
1. Маркеры хорошего тона
Это быстрый индикатор культуры доступности в команде. Если эти штуки присутствуют на портале, то скорее всего и все остальное с большой долей вероятности будет впорядке.
Заявление о доступности (Accessibility Statement)
Первым делом проверьте, есть ли на сайте заявление о доступности. Обычно ссылка на него находится в подвале сайта вместе с политикой конфиденциальности и пользовательским соглашением.
Его наличие — хороший знак. Это значит, что команда публично заявляет о своей работе над доступностью, фиксирует обязательства и предоставляет канал для обратной связи по этой теме.
В таком заявлении часто можно найти полезную информацию:
- Как проводится тестирование (вручную, автоматически, с привлечением людей с инвалидностью).
- Какие стандарты и инструменты используются (WCAG, скринридеры и т.д.).
- Известные проблемы (какие барьеры ещё не устранены).
- Контакты для сообщения о трудностях.
Для команды разработки создание базового варианта такой страницы — задача, которая почти ничего не стоит, но сразу добавляет прозрачности и доверия.
Пример Accessibility Statement:
Конечно, отличная доступность сайта — это прежде всего качественная реализация «под капотом», а не наличие красивого заявления. Фундаментально, сайт может быть полностью доступен без этого документа и этих шаблонов.
Однако наличие заявления о доступности — это гораздо больше, чем просто галочка в чек-листе. Это мощный коммуникационный инструмент, который работает в нескольких плоскостях:
- Сигнал о приоритетах. Для пользователей это явный маркер того, что команда держит вопрос инклюзивности в фокусе. Сам факт его наличия формирует доверие и демонстрирует зрелый подход к разработке.
- Окно прозрачности. В заявлении можно четко обозначить что протестировано и работает, а где еще есть барьеры.
- Канал для диалога. Самый важный аспект — это предоставление прямого и понятного способа для обратной связи. Он превращает монолог в диалог, позволяя пользователям сообщать о проблемах и тем самым помогать вам делать продукт лучше.
Таким образом, заявление о доступности — это не про «должен» по правилам, а про «целесообразно» для построения доверительных и открытых отношений со всеми пользователями без исключения.
"Пропустить навигацию" (Skip Links)
Проверьте, реализованы ли ссылки для пропуска навигации (Skip Links). Нажмите Tab при загрузке страницы — в шапке должна появиться первая ссылка с текстом вроде «Перейти к основному содержимому» или «Пропустить меню».
Эта простая и популярная практика позволяет пользователям скринридеров и клавиатуры сразу переходить к контенту, минуя повторяющиеся блоки навигации.
Пример Skip Links:
2. Цвет и контраст
Проблемы с цветом — одни из самых распространенных.
- Проверяем сомнительные цвета через Colour Contrast Analyser (CCA) - я использую внешний десктопный инструмент от TPGi, потому что он не мешает мне переключаться между вкладками и окнами абстрагируясь от браузера. Хотя можно использовать и какое-нибудь расширение или онлайн сервис вроде WebAIM. Это критично для людей с ослабленным зрением, дальтонизмом или для использования на улице при ярком солнечном свете.
- Убеждаемся, что цвет — не единственный источник информации, желательно чтобы обратная связь была усилена текстом.
Проверка контраста веб-сайта:
3. Навигация с клавиатуры
Если сайт не usable с клавиатуры, он недоступен для многих пользователей.
- Доступны ли ВСЕ интерактивные элементы через Tab/Shift+Tab?
- Виден ли фокус? Не убрали ли outline без кастомной замены? Достаточно ли он заметен и имеет хороший контраст?
- Логичен ли порядок навигации? Логический порядок: Порядок перемещения фокуса должен быть логичным и соответствовать визуальному потоку страницы (сверху вниз, слева направо).
4. Имитация ограничений
Это самый мощный шаг — сразу показывает, насколько интерфейс полагается на идеальное зрение, он позволяет по-настоящему почувствовать проблемы пользователей с ограничениями.
- Включаем сильное размытие (эффект плохого зрения) - для этого я сделал себе небольшое расширения для браузера, но можно просто в консоле выполнить код:
document.body.style = 'filter: blur(5px) !important;- Активируем скринридер (в моем случае это VoiceOver, но отталкиваясь от вашей ОС это может быть любой популярный: NVDA, JAWS, Narrator, Orca) и пытаемся выполнить базовые задачи с озвучкой и клавиатурой
Проверка веб-сайта с VoiceOver:
5. Автоматизированное сканирование
Инструменты не найдут всех проблем, но отлично ловят технические ошибки. По статистике до 30% проблем можно отловить автоматическими инструментами.
Запускаем связку следующих инструментов:
- axe DevTools - наверное, лучший сканер сейчас на рынке для подобной работы
- WAVE - этим инструментом я обычно наглядно проверяю структуру страницы и доступность информации на ней
- Lighthouse и ARC Toolkit - как доп. проверка после axe
Проверка веб-сайта с axe DevTools:
Проверка веб-сайта с WAVE:
Они ловят технические ошибки: отсутствие alt-текстов, некорректный HTML, ошибки ARIA, несоответствие WCAG. Вам даже не надо глубоко знать все эти спецификации, инструменты сами подскажут что нужно поправить для соответствия.
🚩 Красный флаг: волшебные оверлеи
Сразу скажу, что смысла делать аудит веб-приложения у которого есть оверлей или виджет я не вижу. Т.е. для меня это сразу же маркер провала.
Наличие виджетов вроде AccessiBe, UserWay и аналогичных — не решение, а скорее симптом.
Почему это проблема:
- Лечат симптомы, а не болезнь
- Создают иллюзию доступности
- Не работают с динамическим контентом
- Часто ломают нативную доступность
- Против сообщества пользователей с ограничениями
Оверлей = высокая вероятность фундаментальных проблем с доступностью в коде. Цель таких продуктов не удобство пользователей, а уменьшение вероятности получить многомиллионный судебный иск.
💡 Результат
За 15-30 минут такого аудита вы получите:
- Ясную картину состояния доступности
- Список критических барьеров для пользователей
- Понимание, куда двигаться дальше
Не нужно быть сертифицированным экспертом, чтобы начать делать продукты доступнее. Достаточно поставить себя на место пользователя и проверить эти 5 пунктов.
Этот подход фокусируется на сути, а не на формальном соблюдении стандартов. Хотя после этих 5 шаго я почти уверен, что вы впишитесь в WCAG Level AA.
Помните: доступность — это про людей, а не про галочки.