Доступность UX: как сделать сайт удобным для людей с ОВЗ

Цифровая доступность — не опция, а необходимость. По данным ВОЗ, около 15 % населения планеты имеют те или иные формы инвалидности. Сайт, не адаптированный для людей с ограниченными возможностями здоровья (ОВЗ), исключает значительную часть аудитории. Разберём ключевые принципы и практические решения.

Почему доступность важна

• Юридическая обязанность: во многих странах (США, ЕС, РФ) действуют законы о цифровой доступности (например, WCAG, ADA, ФЗ‑419).
• Расширение аудитории: доступ к сервису получают люди с нарушениями зрения, слуха, моторики, когнитивными особенностями.
• Улучшение UX для всех: чёткая структура и контрастность полезны и для пользователей без ОВЗ.
• Репутация бренда: демонстрация социальной ответственности.
• SEO‑выгоды: семантически правильная разметка улучшает индексацию.

1. Контрастность текста: правила и инструменты

Проблема: низкий контраст делает текст нечитаемым для людей с ослабленным зрением.

Требования WCAG 2.1 (уровень AA):

• основной текст — контраст не менее 4.5 : 1;
• крупный текст (18 pt+ или 14 pt+ полужирный) — контраст не менее 3 : 1.

Как проверить:

• WebAIM Contrast Checker — вводите HEX‑коды цветов, получаете оценку.
• Colorable — визуализирует контраст в реальном времени.
• Lighthouse (Chrome DevTools) — автоматический аудит.

Практические советы:

• избегайте светло‑серого текста на белом фоне (#767676 на #FFFFFF — контраст 4.2 : 1, не проходит AA);
• для заголовков используйте насыщенные оттенки (например, #212529);
• тестируйте контрастность в тёмном режиме.

2. Клавиатурная навигация: без мыши — всё работает

Проблема: многие пользователи с моторными нарушениями не могут использовать мышь.

Что проверить:

• все интерактивные элементы (кнопки, ссылки, формы) доступны через Tab;
• порядок фокусировки логичен (слева направо, сверху вниз);
• видимый индикатор фокуса (например, синяя рамка) не убран CSS‑стилями;
• есть возможность выйти из циклических меню (например, аккордеонов).

Технические решения:

• используйте семантические HTML‑теги (<button>, <a>, <input>);
• добавьте tabindex="0" для кастомных интерактивных элементов;
• реализуйте Skip Navigation (ссылка «Перейти к контенту» в начале страницы);
• для сложных компонентов (табы, модальные окна) применяйте WAI‑ARIA (роли, состояния).

3. ARIA‑метки: семантика для скринридеров

Проблема: скринридеры (программы для озвучивания контента) не всегда понимают назначение динамических элементов.

Ключевые ARIA‑атрибуты:

• role — определяет тип элемента (например, role="navigation" для меню);
• aria-label — скрытая подпись (например, для иконок без текста);
• aria-labelledby — связывает элемент с видимой меткой;
• aria-describedby — добавляет подробное описание;
• aria-hidden="true" — скрывает элемент от скринридера (но не от визуала).

Примеры:


<button aria-label="Закрыть модальное окно">
<svg>...</svg>
</button>

<div role="alert" aria-live="assertive">
Ошибка: поле «Email» заполнено неверно.
</div>


Важно: ARIA — дополнение к семантическому HTML, а не замена. Используйте стандартные теги (<nav>, <header>), где это возможно.

4. Альтернативные описания изображений (alt‑текст)

Проблема: изображения без описаний недоступны для незрячих пользователей.

Правила написания alt‑текста:

• Краткость: 5–15 слов.
• Смысл: что изображено и зачем оно здесь?
• Контекст: если картинка — ссылка, опишите действие (например, «Перейти в каталог»).
• Исключения: декоративные элементы — alt="".

Примеры:

• ✅ <img src="product.jpg" alt="Смартфон XYZ, чёрный, с двойной камерой">
• ❌ <img src="decor.png" alt="Красивый узор"> (если это декор — alt="")
• ✅ <a href="/cart"><img src="cart-icon.png" alt="Перейти в корзину"></a>

Для сложных изображений (графики, диаграммы):

• используйте aria-describedby для ссылки на текстовое описание;
• размещайте описание рядом с картинкой (скрытое для визуала, но доступное для скринридера).

Дополнительные меры доступности

Масштабируемость текста

• обеспечьте увеличение шрифта до 200 % без потери функциональности;
• используйте относительные единицы (em, rem) вместо px.

Управление временем

• не ставьте таймеры менее 20 секунд без возможности паузы;
• для каруселей добавьте кнопки «Стоп/Старт».

Аудио и видео

• субтитры для видео;
• транскрипция аудиоконтента;
• возможность отключения звука.

Формы

• явные метки (<label>) для каждого поля;
• сообщения об ошибках рядом с полем;
• подсказки (например, формат даты).

Цветовая слепота

• избегайте пар «красный/зелёный» для критических сигналов;
• добавляйте текстовые индикаторы (иконки, подписи);
• тестируйте через симулятор цветовой слепоты (например, Color Oracle).

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

Автоматизированные инструменты:

• Lighthouse (в Chrome DevTools) — базовый аудит;
• Wave — визуализация проблем;
• Axe — расширенный анализ.

Ручное тестирование:

• навигация только клавиатурой (Tab, Enter, стрелки);
• проверка скринридером (NVDA, VoiceOver);
• тестирование с увеличением масштаба.

Пользовательские тесты:

• привлечение людей с ОВЗ для реальных сценариев;
• сбор обратной связи через формы или опросы.

Типичные ошибки

• Убранный фокус: outline: none без замены на видимый индикатор.
• Пустые alt‑тексты для значимых изображений.
• Недоступные кастомные элементы (например, кнопки на <div>).
• Низкий контраст в мелочах (подсказки, disabled‑элементы).
• Динамический контент без ARIA (уведомления, лоадеры).

Вывод

Доступность — это:

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

С чего начать:

1. Проверьте контрастность ключевых элементов.
2. Убедитесь, что сайт работает с клавиатурой.
3. Добавьте alt‑тексты к изображениям.
4. Внедрите базовые ARIA‑роли.
5. Проведите аудит с помощью Lighthouse.

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