Реализация поддержки 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% за счёт сокращения баг-репортов.

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