Как создать доступный сайт для людей с ограниченными возможностями зрения

Превратите ресурс в удобный доступный сайт за 5 шагов. Чек-лист по WCAG 2.1 и ГОСТ Р 52.872‑2019 — чтобы никто не остался за бортом!

В современном интернете доступность – это не просто «модно», а обязательное требование законодательства и международных стандартов. Сайт, пригодный для людей с ограниченными возможностями зрения (слепыми и слабовидящими), называется слепой или доступный (англ. accessible). В этой статье мы разберём, как спроектировать и реализовать такой сайт шаг за шагом, опираясь на ГОСТ Р 52.872‑2019, WCAG 2.1 и практический опыт.


Что такое «слепой» сайт?

Сайт считается слепым, если любой пользователь, в т.ч. использующий программы чтения с экрана (screen‑readers), синтезаторы речи, клавиатурные навигационные средства и специальные контрастные режимы, может полностью понять и взаимодействовать с контентом без визуального восприятия.

  • Текстовые элементы читаются программой‑чтецом.
  • Все интерактивные элементы доступны с клавиатуры (Tab, Enter, Space).
  • Изображения снабжены корректными alt‑текстами.
  • Контрастность текста и фоновых элементов удовлетворяет минимум 4.5:1 (AA) или 7:1 (AAA).
  • Структура страницы (заголовки, списки, таблицы) семантически правильна.

Ключевые стандарты

  1. ГОСТ Р 52.872‑2019 – национальный документ, описывающий требования к доступности веб‑ресурсов в России.
  2. WCAG 2.1 (Web Content Accessibility Guidelines) – международный набор рекомендаций от W3C.
  3. Section 508 (США), WaSP (Великобритания), DAL (Дания) – дополнительные рекомендации, часто упоминаемые в глобальных проектах.

План разработки доступного сайта

Ниже представлена последовательность действий, которую удобно использовать как чек‑лист.

Анализ требований

  • Определить целевую аудиторию (слепые, слабовидящие, пользователи с моторными ограничениями).
  • Согласовать список обязательных функций (по ГОСТ Р 52.872‑2019).
  • Выбрать уровень соответствия WCAG 2.1: AA (рекомендовано) или AAA (для критически важных сервисов).

Проектирование информационной архитектуры

  • Составить семантическую схему (заголовки h1‑h6, списки, навигационные роли).
  • Разработать логическую навигацию (главное меню, «skip to content», хлебные крошки).
  • Определить цветовую палитру с достаточным контрастом (использовать инструменты вроде Contrast Checker).

Выбор технологий и готовых решений

Для ускорения разработки можно воспользоваться готовыми модулями, которые автоматически генерируют «слепую» версию сайта:

  • Мибок – Версия для слабовидящих. Генерирует альтернативный дизайн, добавляет синтез речи и полную клавиатурную навигацию.
  • Плагины для WordPress: WP Accessibility, AccessiBe, One Click Accessibility.
  • Библиотеки JavaScript: ally.js, focus-visible, aria‑utils.

Реализация

Ниже – основные технические шаги.


Техническая реализация

<html lang=»ru»>
<head>
<meta charset=»UTF-8″>
<title>Пример доступного сайта</title>
<link rel=»stylesheet» href=»styles.css»>
</head>
<body>
<header role=»banner»>
<h1>Мой доступный сайт</h1;
<nav aria-label=»Главное меню»>
<ul>
<li><a href=»#home»>Главная</a></li>
<li><a href=»#about»>О проекте</a></li>
<li><a href=»#contact»>Контакты</a></li>
</ul>
</nav>
</header>

<main id=»content» role=»main»>
<section aria-labelledby=»intro»>
<p>Текст, который будет прочитан скрин‑ридером.</p>
</section>

<section aria-labelledby=»gallery»>
<h2 id=»gallery»>Галерея</h2>
<figure>
<img src=»photo.jpg» alt=»Солнечный пляж с пальмами»>
<figcaption>Пляжный день</figcaption>
</figure>
</section>
</main>

<footer role=»contentinfo»>
<p>&copy; 2026 Компания «Доступный веб».</p>
</footer>
</body>

Обратите внимание:

  • Каждый <section> имеет aria-labelledby, связывающий его с заголовком.
  • Навигация снабжена aria-label и role="banner" для лучшего восприятия.
  • Изображения имеют информативный alt. Декоративные изображения – пустой alt="".

Атрибуты ARIA

  • role="alert" – для сообщений об ошибках;
  • aria-live="polite" – динамический контент, который должен объявляться скрин‑ридером.
  • aria-controls и aria-expanded – для раскрывающихся меню.

CSS: контрастность и масштабируемость

/* Пример базовой стилизации с учётом контрастности /
body {
 background:#ffffff;
 color:#212121; / контраст 15:1 /
 font-size:1rem;
}
a {
 color:#0066cc; / контраст 7.1:1 /
}
a:focus, button:focus {
 outline: 3px solid #ffbf00; / яркая обводка для клавиатурного фокуса /
}
@media (prefers-reduced-motion: reduce) {
  {
 animation-duration: 0s !important;
 transition-duration: 0s !important;
 }
}

Не забывайте о медиа‑запросе prefers-reduced-motion – пользователи с чувствительностью к анимации могут отключить её.

JavaScript: управление клавиатурой и синтез речи

Для обеспечения полной клавиатурной навигации добавьте обработчики keydown и используйте tabindex только там, где это действительно необходимо.

// Пример «skip to content» – позволяет сразу перейти к основному контенту
document.querySelectorAll('a[href^="#"]').forEach(link => {
 link.addEventListener('click', e => {
 const target = document.querySelector(link.getAttribute('href'));
 if (target) {
 target.setAttribute('tabindex', '-1');
 target.focus;
 }
 });
});

// Синтез речи (опционально, если нужен озвученный интерфейс)
function speak(text) {
 if ('speechSynthesis' in window) {
 const utter = new SpeechSynthesisUtterance(text);
 utter.lang = 'ru-RU';
 window.speechSynthesis.speak(utter);
 }
}
document.getElementById('speakBtn').addEventListener('click',  => {
 speak('Привет! Это пример синтеза речи.');
});

Интеграция готового модуля «Мибок»

Если вы хотите быстро добавить «слепую» версию без глубокого кодинга, подключите модуль Мибок:

<script src="https://cdn.mibok.ru/visually-impaired.js"></script>
<script>
 Mibok.init({
 speech: true, // включить синтез речи
 highContrast: false, // пользователь может переключить
 keyboardNav: true
 });
</script>

Модуль автоматически генерирует альтернативный стиль, добавляет кнопку переключения и озвучивает элементы интерфейса.


Тестирование доступности

Автоматические инструменты

  • Lighthouse (Chrome DevTools) – проверка WCAG 2.1 (AA/AAA).
  • axe DevTools – детальная диагностика ARIA‑ошибок.
  • WAVE – визуальная карта проблем доступности.

Тестирование с реальными скрин‑ридерами

  1. NVDA (Windows) – бесплатный, поддерживает большинство функций.
  2. JAWS (Windows) – коммерческий, часто используется в корпоративных проектах.
  3. VoiceOver (macOS/iOS) – встроенный в Apple‑устройства.
  4. TalkBack (Android) – для мобильных тестов.

Проверьте, что:

  • Все заголовки читаются в правильном порядке.
  • Фокус перемещается логически (Tab → Shift+Tab).
  • Изображения без alt игнорируются, а важные – читаются.
  • Динамический контент (модальные окна, сообщения) объявляеться через aria-live.

Тесты на контрастность и масштабирование

Используйте Chrome DevTools → Rendering → Emulate vision deficiencies (дальтонизм, протанопия) и проверьте, как выглядит сайт при масштабировании до 200 %.


Деплой и поддержка

  1. Документируйте все решения по доступности (список ARIA‑ролей, используемые плагины, уровни WCAG).
  2. Включите проверку доступности в CI/CD (например, запуск axe-cli в GitHub Actions).
  3. Обучайте контент‑менеджеров: они должны писать корректные alt, использовать заголовки и избегать «текстовых изображений».
  4. Регулярно обновляйте зависимости (модули, библиотеки) – новые версии часто исправляют проблемы с доступностью.

Часто задаваемые вопросы (FAQ)

Вопрос: Нужно ли создавать отдельный «слепой» шаблон?

Вопрос: Как обеспечить доступность в одностраничных приложениях (SPA)?

Для SPA важно управлять фокусом после навигации и обновлять aria-live‑области. Библиотеки react-aria или vue-a11y помогают автоматизировать эти задачи.

Вопрос: Что делать, если клиент отказывается от WCAG AA?

Объясните, что большинство государственных и коммерческих заказов требуют минимум AA, а несоответствие может привести к юридическим рискам. При невозможности полного соответствия предложите компромиссный план поэтапного улучшения.


Создание «слепого» сайта – это совокупность правильного планирования, семантической разметки, использования ARIA, контрастных стилей и тщательного тестирования. Следуя рекомендациям ГОСТ Р 52.872‑2019 и WCAG 2.1, а также применяя готовые решения вроде Мибок, вы сможете обеспечить комфортную работу для всех пользователей, независимо от их физических возможностей.

Помните: доступность – это не «добавка», а фундаментальная часть пользовательского опыта. Инвестируя в неё сейчас, вы повышаете репутацию проекта, расширяете аудиторию и соблюдаете закон.