Веб-доступность: слепой мужчина использует скринридер

Требования к дизайну и разработке сайтов всё чаще включают веб‑доступность. Но если сайт корректно отображается в основных браузерах и адаптирован под разные устройства, разве этого недостаточно? Инструменты вроде Google Lighthouse позволяют замерять производительность, доступность, лучшие практики и SEO. Однако доступность важна не только для скоринга: она делает сайт работоспособным для реальных людей с ограничениями — зрения, моторики, когнитивных особенностей и пр.

По данным CDC, свыше 60 млн американцев живут с инвалидностью — это иллюстрирует масштаб аудитории, для которой важно правильно применять семантику и стили. Ниже — практическое руководство по HTML и CSS, примеры, чеклисты и методика быстрой проверки.

Почему семантика важна

Семантический HTML передаёт структуру и смысл контента помощникам (скринридерам), поисковым ботам и браузерам. Теги вроде

и заголовки

–

дают контекст, который нельзя надёжно воспроизвести с помощью чисто презентационного кода на

и .

Важно: CMS (например, WordPress) часто генерируют HTML автоматически, но ответственность за корректность разметки лежит на разработчике/контент-менеджере. Регулярно проверяйте вывод темы и плагинов.

Преимущества семантической разметки

Улучшенная навигация для скринридеров и голосовых помощников.
Больше встроенной доступности (например, клавиатурная фокусировка кнопок).
Положительный эффект на SEO через явную структуру и ключевые теги.
Проще поддерживать стиль и реагировать на адаптивность.

Примеры хорошей и плохой семантики

Ниже — прямой пример, где первая часть использует семантику, а вторая — презентационный код.


  
My heading  
Here's how you can make an accessible website using HTML and CSS  
My second heading  

  
My heading  
Here's how you can make an accessible website using HTML and CSS

Комментарий: первый блок легко обходит экранный чтец — он видит заголовки, может строить оглавление и переходить между разделами. Во втором примере семантика потеряна: скринридеру сложнее понять структуру, а селекторы и стили менее предсказуемы.

Структура страницы и порядок в исходном коде

Порядок элементов в HTML‑документе играет роль: скринридеры читают документ последовательно, поэтому визуальное позиционирование с использованием CSS не заменяет логический порядок в исходном коде. Современная структура страницы должна быть понятной и предсказуемой:

  
This is a header  
  
  

  
  

  
  

  
  
Article heading  

  
  
  
Related

Веб-доступность: семантический HTML в действии

Советы:

Держите содержания
после навигации и перед футером.
Избегайте использования табличной вёрстки для макета — таблицы нужны для табличных данных.
Если нужен порядок, отличный от визуального — используйте CSS Grid/Flexbox для позиционирования, но независимо поддерживайте логический порядок в HTML.

Контролы UI, таблицы и альтернативный текст

Элементы управления (кнопки, формы, ссылки) должны быть доступны с клавиатуры. Встроенные элементы, такие как

Кнопка по умолчанию поддерживает фокус и активацию с клавиатуры. Если вы переопределяете стили, не забывайте про состояния :focus и :active.

Таблицы данных должны содержать заголовки и атрибут scope (row/col), а при необходимости — или summary (устаревший, но иногда встречается). Это помогает создать краткий обзор для скринридеров.

Альтернативный текст (alt) — ключевой элемент для изображений и видео:

Если картинка декоративная — оставьте alt пустым: alt=””.
Если картинка информативна — укажите ёмкое описание.
Для повторяющихся изображений, где нужно дать общий текст — используйте aria-labelledby.

Пример:

Пример использования aria-labelledby:

  
A red flower ...

Это полезно, когда один и тот же текст должен сопровождать несколько графических элементов или когда описание длинное и лучше вынести его в блок.

Стандартный CSS для улучшения доступности

Дизайн должен поддерживать смысл страницы: шрифт, межбуквенное расстояние, размеры и контраст — всё это влияет на читаемость. Хорошая практика — использовать относительные единицы (rem, em) для масштабируемости и переменные CSS для тем и контрастов.

Пример базовых размеров (пример приведён для иллюстрации):

h1 {  
  font-size: 4rem;  
}  
  
p, li {  
  font-size: 1.5rem;  
  color: blue;  
}

Сохраняйте видимый индикатор фокуса (outline или box-shadow).
Обеспечьте различимые состояния :hover, :focus, :active.
Не используйте только цвет как единственный способ передать информацию — добавляйте текстовые метки или иконки с пояснениями.

Пример CSS поведения ссылок из исходника:

  
a {  
  color: #ff0000;  
}  
a:active {  
  color: #000000;  
  background-color: #a60000;  
}  
a:hover, a:visited, a:focus {  
  color: #a60000;  
  text-decoration: none;  
}

Важно: убедитесь, что выбранный цвет и фон соответствуют критериям контрастности WCAG (обычно WCAG AA 4.5:1 для обычного текста и 3:1 для крупного текста).

Цвет и скрытие элементов

Используйте инструменты проверки контраста (Color Contrast Checker) при выборе палитры.
Не полагайтесь исключительно на цвет для индикации ошибок или статусов — добавляйте текст, значки или ARIA‑маркеры.
Избегайте display: none и visibility: hidden для содержимого, которое должно быть доступно скринридерам, так как эти свойства полностью скрывают элемент от технологий вспомогательного доступа.

Возможность переопределить стиль пользователем

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

Мини‑методика для быстрой проверки доступности (8 шагов)

Пройти по странице с выключенными стилями (view-source/disable CSS) — логика и порядок остаются.
Навигация только с клавиатуры (Tab, Shift+Tab, Enter, Space) — все контролы доступны и имеют видимый фокус.
Запустить скринридер (NVDA/VoiceOver) и пройти сквозь структуру — заголовки логичны.
Проверить alt‑атрибуты для всех значимых изображений.
Протестировать контраст всех текстов и интерактивных элементов.
Проверить формы: ассоциированные , aria-describedby для ошибок.
Прогоны с автоматическими инструментами: Lighthouse, axe, WAVE — фиксировать предупреждения и ошибки.
Протестировать на мобильных устройствах и в браузерах с увеличенным масштабом.

Контрольный чеклист для команд (роль‑ориентированный)

Дизайнеры:

Использовать контрастную палитру и доступные варианты тем.
Обозначать состояния (ошибка, успех) не только цветом.
Думать о читаемости при разных размерах шрифта.

Разработчики фронтенда:

Применять семантические теги и поддерживать логический порядок DOM.
Не эмулировать элементы управления через
/ без ARIA и клавиатурной поддержки.
Обеспечивать видимые фокусные состояния и правильные роли (role) там, где это нужно.

Контент-менеджеры:

Проверять alt‑текст и заголовки перед публикацией.
Избегать длинных бессвязных блоков текста; использовать подзаголовки.
Использовать расширения и аббревиатуры с расшифровкой при первом упоминании.

QA/тестировщики:

Автоматические проверки + ручные проверки скринридером.
Тесты клавиатурной навигации.
Тесты на разных масштабах шрифта и в режимах высокого контраста.

Когда семантика и CSS не решат проблему (ограничения и альтернативы)

Counterexamples/когда это не сработает:

Динамические виджеты, созданные с помощью кастомного JS, без правильных ARIA‑ролей и управления фокусом, будут недоступны, даже при корректном HTML/CSS.
Глубоко вложенные таблицы и сложные интерактивные визуализации требуют продуманного взаимодействия (альтернативные текстовые описания, дополнительные представления данных).

Альтернативные подходы:

Использовать ARIA‑роли и состояния только как дополнение, а не замену нативным элементам.
Для сложных виджетов создавать «progressive enhancement»: базовая функциональность доступна без JS, а улучшения добавляются поверх.

Примеры кода и паттерны (шаблоны)

Простой шаблон доступной формы:


  Email
  
  Мы не передаём адреса третьим лицам.

Паттерн для объявления областей:


  
    Главная
    О нас

Mermaid‑дерево принятия решения: когда использовать ARIA против нативных элементов

flowchart TD
  A[Нужен интерактивный элемент?] -->|Да| B{Есть нативный элемент?}
  A -->|Нет| C[Используйте статический HTML]
  B -->|Да| D[Используйте нативный элемент]
  B -->|Нет| E[Используйте семантику + ARIA + управление фокусом]
  E --> F[Тестируйте с клавиатурой и скринридером]
  D --> F
  C --> G[Проверить необходимость добавления роли aria]

Критерии приёмки

Вся смысловая графика имеет корректный alt или aria-labelledby.
Все интерактивные элементы доступны с клавиатуры и имеют видимый фокус.
Заголовки используются по иерархии и позволяют построить оглавление.
Контраст соответствует требованиям (проверено инструментом).
Формы имеют ассоциированные и понятные сообщения об ошибках.

Фактбокс: ключевые числа и практики

По данным CDC, более 60 млн человек в США имеют инвалидность (источник: CDC).
Стандарт WCAG (уровни A, AA, AAA) — ориентир требований доступности.
Базовая цель: соответствие WCAG уровня AA для большинства публичных веб‑ресурсов.

Важно: не пытайтесь сразу достигнуть AAA для всего сайта — начните с A/AA и расширяйте покрытие.

Тестовые сценарии и критерии приёмки

При отключённых стилях структура страницы остаётся читаемой.
Клавиатурная навигация: табуляция проходит по всему интерактивному содержимому и логично.
Скринридер: основные заголовки и разделы объявляются корректно; ключевые кнопки озвучиваются.
Формы: при вводе некорректных данных экранные подсказки озвучиваются и видимы.

Совместимость и миграция

При миграции теме/фреймворка проверьте, как система генерирует заголовки и aria‑атрибуты.
Убедитесь, что компоненты UI (кнопки, модальные окна, вкладки) корректно управляют фокусом и возвращают его после закрытия.

Безопасность и конфиденциальность

Доступность не должна раскрывать лишние данные: если альтернативный текст содержит чувствительную информацию, подумайте о её необходимости. Приватность и GDPR остаются актуальными при добавлении описаний и метаданных.

Резюме

Веб‑доступность — это сочетание семантического HTML и продуманного CSS, дополненное тестами и процедурами проверки. Начните с базовой семантики, обеспечьте клавиатурную навигацию и корректные alt/aria‑атрибуты, затем улучшайте стили и тестирование. Регулярный аудит и роль‑ориентированные чеклисты помогут поддерживать доступность при росте проекта.

Краткие шаги для старта:

Пройдите мини‑методику аудита (8 шагов).
Исправьте «крупные» ошибки: отсутствие alt у информативных изображений, недоступные формы, потерянные заголовки.
Внедрите визуальные индикаторы фокуса и проверку контраста.
Планируйте регулярные проверки и включайте доступность в Definition of Done.

Важно: доступность — это процесс, а не одноразовая задача. Регулярно собирайте обратную связь от реальных пользователей и улучшайте интерфейс по приоритетам.