Реализация поддержки VoiceOver/Screen Reader для сайта (WCAG)

Представьте: ваш сайт загружается, но пользователь с screen reader слышит только «div, div, div». Это не просто плохой UX — это нарушение законодательства о доступности. По данным ВОЗ, более 253 млн человек имеют проблемы со зрением, и многие из них полагаются на screen reader. Игнорирование доступности — это потеря клиентов и репутационные риски. Согласно WebAIM, 98% домашних страниц содержат ошибки доступности, а компании, внедрившие WCAG, отмечают рост конверсии на 15-20%. Мы помогаем исправить такие ситуации, делая сайт доступным для незрячих и слабовидящих.

Почему поддержка screen reader критична для бизнеса

Screen reader — программа экранного доступа, которая озвучивает содержимое страницы и даёт возможность навигации с клавиатуры. VoiceOver (macOS/iOS), NVDA и JAWS (Windows), TalkBack (Android) — основные инструменты. Стандарт WCAG 2.1 уровень AA обязывает обеспечить полную поддержку этих программ. Если ваш сайт игнорирует accessibility tree, вы теряете аудиторию и рискуете судебными исками. Более 70% ошибок доступности связаны с плохой семантикой. Использование правильных ARIA-атрибутов может сократить время навигации на 30%.

Какие проблемы решаем

Мы решаем три ключевые проблемы:

• Отсутствие семантической разметки. DOM строится из div без ориентиров, заголовков и ролей. Screen reader не может построить навигацию.
• Некорректные ARIA-атрибуты. Часто встречаются лишние или неправильные атрибуты, которые ломают объявления.
• Динамический контент в SPA. Изменения DOM без aria-live не озвучиваются, пользователь остаётся в неведении.

Почему семантическая разметка критична для Screen Reader?

Screen reader использует Accessibility Tree — представление страницы, построенное из HTML и ARIA-атрибутов. Правильная разметка — основа доступности.

<!-- Плохо -->
<div class="header">
  <div class="nav">
    <div class="nav-item" onclick="go('/home')">Главная</div>
  </div>
</div>

<!-- Хорошо -->
<header>
  <nav aria-label="Основная навигация">
    <ul>
      <li><a href="/home">Главная</a></li>
    </ul>
  </nav>
</header>

Ориентиры (landmarks) облегчают навигацию: добавьте header, nav, main, aside, footer с соответствующими ролями. Это сокращает время поиска информации на 40%.

Как обеспечить поддержку динамических обновлений в SPA?

В SPA контент обновляется без перезагрузки страницы. Screen reader не узнает об изменениях, если не использовать aria-live. Пример на React:

function DataSection({ isLoading, data }) {
    return (
        <section>
            <div aria-live="polite" aria-atomic="true" className="sr-only">
                {isLoading ? 'Загрузка данных...' : 'Данные загружены'}
            </div>
            {isLoading ? (
                <div aria-busy="true">
                    <span className="sr-only">Загрузка...</span>
                    <Spinner aria-hidden="true" />
                </div>
            ) : (
                <ul>
                    {data.map(item => <li key={item.id}>{item.title}</li>)}
                </ul>
            )}
        </section>
    );
}

Также важно управлять фокусом при навигации. На SPA-переходах переносите фокус на заголовок страницы, используя tabIndex={-1} и ref.

Сравнение популярных screen reader

NVDA лучше для начального тестирования из-за бесплатности и частых обновлений. JAWS незаменим при корпоративных требованиях.

Сравнение критериев WCAG по важности

Аудит по уровню AA покрывает 90% потребностей пользователей screen reader.

Как мы обеспечиваем поддержку screen reader?

Наш подход включает несколько этапов:

Аудит

Проверяем семантику, ARIA, контрастность, навигацию. Используем axe-core + ручное тестирование с NVDA и VoiceOver. Также применяем jest-axe для модульного тестирования React-компонентов.

Проектирование

Составляем карту accessibility tree, исправляем ошибки в разметке.

Реализация

Правим шаблоны, добавляем aria-live для динамики, aria-describedby для подсказок, группируем поля через fieldset и legend. Используем WAI-ARIA как руководство.

Тестирование

Проверяем на реальных screen reader, исправляем баги.

Деплой и документация

Фиксируем рекомендации для будущей поддержки.

Пример работы с формами

<label for="email">Email</label>
<input type="email" id="email" name="email"
       aria-describedby="email-hint email-error"
       aria-required="true">
<span id="email-hint" class="hint">Мы не будем отправлять спам</span>
<span id="email-error" role="alert" aria-live="polite"></span>

Что входит в работу

• Полный аудит доступности по WCAG 2.1 AA.
• Исправление семантики, ARIA, управление фокусом.
• Настройка aria-live для динамического контента.
• Тестирование с NVDA и VoiceOver.
• Техническая документация и передача знаний вашей команде.
• Поддержка после внедрения на 1 месяц.

Сроки ориентировочно

• Аудит: 1–2 дня.
• Исправление на существующем проекте: 3–7 дней.
• Тестирование и доводка: 2–3 дня.

Сроки зависят от размера проекта и сложности кода. Оцениваем индивидуально. Стоимость рассчитывается после аудита. Наша команда имеет более 50 успешных проектов по доступности.

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

• Использование aria-hidden="true" для всего подряд. Скрывает элементы от screen reader без необходимости.
• Пустые alt. Декоративные изображения должны иметь alt="", но информативные — осмысленный текст.
• Отсутствие фокуса при AJAX-загрузке. После обновления списка фокус остаётся на старом элементе.

Избегайте этих ошибок — и ваш сайт станет доступным для тысяч пользователей. Экономия бюджета на поддержку может достигать 20% за счёт сокращения баг-репортов.

Готовы сделать ваш сайт доступным? Закажите аудит доступности — наши сертифицированные специалисты проведут полную проверку. Свяжитесь с нами для консультации и получите детальную оценку работ.

Доступность сайтов: WCAG, скринриндеры, клавиатурная навигация

На сайте крупного банка кнопка «Подать заявку» в разметке была <div class="btn" onclick="...">. Скринридер NVDA её не анонсировал, Tab пропускал, Enter не срабатывал. Для тысяч незрячих пользователей этот банк просто не существовал как онлайн-сервис. Мы видим такие проблемы каждый день в десятках проектов — и разработка доступных сайтов по стандарту WCAG 2.2 AA становится единственным способом избежать дискриминации и юридических рисков. Штрафы за недоступность для юрлиц достигают 300 000 ₽, а судебные иски — миллионы.

В этой карточке — как мы делаем веб-доступность a11y работающей, на реальных кейсах, с конкретным стеком и цифрами. Без общих фраз.

Почему семантическая разметка — основа веб-доступности a11y?

Большинство проблем доступности решается правильным HTML, а не дополнительными ARIA-атрибутами. <button> вместо <div onclick>, <nav> вместо <div class="navigation">, <h1>–<h6> в правильной иерархии, <label for="field-id"> вместо <div class="label">. Это базовый уровень, но на практике каждая вторая форма в российских интернет-магазинах не имеет корректных <label>.

ARIA нужна там, где нативный HTML не справляется: кастомные компоненты — выпадающие меню, тултипы, модальные окна, табы, accordion. И вот тут начинается сложность.

Типичная ошибка в кастомных дропдаунах: скринридер не знает, что это combobox, не объявляет количество опций, не говорит какая выбрана, фокус не переходит в список при открытии. Правильная реализация:

• role="combobox" на инпуте
• aria-expanded="true/false" при открытии/закрытии
• aria-controls="listbox-id" указывает на список
• aria-activedescendant — ID текущего выбранного элемента
• role="option" и aria-selected на каждом варианте

Это не теория, это то, что тестируется скринридером. NVDA + Chrome или VoiceOver + Safari — обязательная часть QA.

<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Выберите город</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Города">
    <li role="option" aria-selected="false" id="opt-1">Москва</li>
    <li role="option" aria-selected="false" id="opt-2">Санкт-Петербург</li>
  </ul>
</div>

Стоимость исправления одного нарушения уровня A — от 5 000 до 15 000 ₽ в зависимости от сложности. Внедрение a11y с этапа проектирования сокращает бюджет на рефакторинг в 2–3 раза по сравнению с доработкой готового сайта.

Как правильно построить клавиатурную навигацию?

Tab-порядок должен совпадать с визуальным порядком элементов. Если в HTML кнопка «Отмена» стоит перед «Подтвердить», но CSS их меняет местами — пользователь клавиатуры в замешательстве.

Focus trap в модальных окнах. Когда модалка открывается, Tab должен циклиться только внутри неё. При закрытии — возврат фокуса на элемент, который открыл модалку. Без этого пользователь после закрытия оказывается в начале страницы.

tabindex="-1" — элемент не попадает в Tab-последовательность, но может получить фокус программно. Используется для элементов, которые получают фокус через JavaScript (заголовки секций после навигации по якорям).

tabindex="1" и выше — почти всегда ошибка. Явный порядок ломает естественный и создаёт непредсказуемое поведение. Управляйте порядком через DOM, не через tabindex.

Skip links — ссылка «Перейти к содержимому», скрытая визуально, видимая при Tab. Позволяет пользователям скринридеров пропустить повторяющуюся навигацию.

Цвет и контраст: требования и частые нарушения

WCAG 2.2 AA требует контраст 4.5:1 для обычного текста, 3:1 для крупного (18px+ или 14px+ bold). AAA требует 7:1 и 4.5:1.

Самые частые нарушения: серый placeholder в инпутах (#999 на белом = 2.9:1), светло-серый secondary текст, белый текст на пастельном фоне.

Цвет не должен быть единственным индикатором: «поля обязательные выделены красным» без звёздочки — нарушение для людей с цветовой слепотой.

Инструменты проверки: axe DevTools, WAVE, Accessibility Inspector в Chrome DevTools. axe-core интегрируется в Playwright-тесты: автоматическая проверка на 80+ правил при каждом деплое. Ручное тестирование находит примерно на 60% больше ошибок, чем автоматическое.

Медиаконтент и динамика: что важно?

Изображения без alt — частый базовый провал. alt должен быть смысловым: не alt="image_123.jpg", а описание содержимого, релевантное контексту. Декоративные изображения — alt="" (пустой, не отсутствующий атрибут).

Видео должно иметь субтитры. YouTube автосубтитры — не стандарт, они ошибаются. WebVTT-файлы с корректными субтитрами для всего образовательного и маркетингового видеоконтента.

Анимации — проблема для пользователей с вестибулярными расстройствами. @media (prefers-reduced-motion: reduce) — медиа-запрос, отключающий или замедляющий анимации для пользователей с такой настройкой в ОС.

Что изменилось в WCAG 2.2?

Версия 2.2 вступила в силу с новыми критериями:

Эти критерии повышают порог входа, но мы уже включаем их в стандартный чек-лист.

Аудит и устранение нарушений

Автоматические инструменты находят около 30–40% нарушений. Остальное — только ручное тестирование. Минимальный сценарий: пройти весь критический user flow (регистрация, покупка, форма) только клавиатурой и со скринридером.

Процесс работы

1. Автоматический аудит — axe-core, Lighthouse, WAVE — выдача 80+ правил.
2. Ручное тестирование — NVDA, VoiceOver, клавиатура — 2–3 дня на типовой сайт.
3. Приоритизация нарушений — P1 (блокирует использование), P2 (создаёт сложности), P3 (улучшения).
4. Исправление — итерациями, встраиваем проверки в CI через Playwright + axe.
5. Повторный аудит — закрытие всех P1/P2 перед релизом.
6. Документация и передача — отчёт с результатами, рекомендации по поддержке, обучение команды.

Результаты и объём работ

• Полный отчёт по аудиту с приоритизацией нарушений (PDF/HTML)
• Исправленный код: семантическая разметка, ARIA, клавиатурная навигация
• Интеграция axe-core в CI/CD для регрессионного контроля
• Обучение разработчиков заказчика по работе с a11y (2-часовая сессия)
• Доступ к репозиторию с примерами корректных компонентов
• Гарантия соответствия WCAG 2.2 AA на момент сдачи

Сроки

Бюджет рассчитывается индивидуально после аудита. Свяжитесь с нами — оценим ваш проект за 1 день. Получите консультацию и чек-лист бесплатно при заказе аудита.

Опыт и гарантии

Мы занимаемся веб-доступностью a11y более 8 лет. Реализовали более 50 проектов для банков, ритейла и госсектора. Сертифицированные специалисты (IAAP CPACC, WAS). Гарантируем прохождение аудита третьей стороной или дорабатываем бесплатно.

Стандарт WCAG 2.2 — официальная рекомендация W3C, определяющая требования к доступности веб-контента.

Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA

— уровни веб-доступности a11y по версии 2.2.

Закажите аудит сейчас — получите чек-лист и предварительную оценку бесплатно. Пишите в Telegram или на почту — ответим в течение часа.