Почему мы избегаем темы доступности?
Кажется, что нужно выучить тонны спецификаций — WCAG, Section 503, EAA, ARIA. Но на самом деле начать можно с простого практического подхода, ориентированного на реальных пользователей.
Философия подхода
Доступность — это не про галочки в чек-листах, а про людей. Людей с постоянными ограничениями и тех, кто оказывается в ситуативно ограниченных условиях:
- Постоянно невидящий пользователь
- Временно человек с переломом руки
- Ситуативно мама с ребенком на руках
Если они не могут использовать ваш продукт — это провал.
🛠️ 5-шаговая методика быстрого аудита
1. Маркеры хорошего тона
Это быстрый индикатор культуры доступности в команде. Если эти штуки присутствуют на портале, то скорее всего и все остальное с большой долей вероятности будет впорядке.
- Accessibility Statement — есть ли заявление о доступности? Обычно это отдельная страничка ссылка на которую есть в подвале рядом с Privacy Policy, Terms of Use и Copyright. Его наличие говорит о том, что компания задумывается о доступности, берет на себя обязательства и предоставляет канал для обратной связи.
- Skip Links — появляется ли при нажатии Tab ссылка "пропустить навигацию" в шапке?
Это популярный шаблон доступной навигации.
Пример Accessibility Statement:
Пример 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.
Помните: доступность — это про людей, а не про галочки.