Доступность сайта: для кого она на самом деле и с чего начать

Часть 1 из 8 серии «Доступный веб на практике».

Доступность принято считать заботой о небольшой группе пользователей. На деле с барьерами в интерфейсах сталкивается почти каждый, а 95,9% популярных сайтов содержат ошибки, которые находятся автоматически. В первой части серии разберёмся, кого касается доступность, как люди на самом деле пользуются сайтами и как устроен стандарт WCAG 2.2.

Не «для инвалидов», а для всех

Когда разработчик слышит слово «доступность», он обычно представляет незрячего человека со скринридером. Такие пользователи действительно есть, и для них доступность — вопрос того, можно ли вообще воспользоваться сайтом. Но это лишь часть картины.

По данным ВОЗ, около 1,3 миллиарда человек — 16% населения Земли, каждый шестой — живут со значимыми ограничениями здоровья (WHO, 2023). Это постоянные ограничения. Добавьте к ним временные и ситуативные — и выяснится, что с барьерами в интерфейсах сталкивается почти каждый.

Microsoft в своём руководстве по инклюзивному дизайну описывает это как спектр (Microsoft Inclusive Design):

Постоянное	Временное	Ситуативное
Нет руки	Рука в гипсе	Ребёнок на руках
Слепота	Расширенные зрачки после окулиста	Яркое солнце на экране телефона
Глухота	Ушная инфекция	Шумный бар, видео без звука в метро
Тремор, ДЦП	Сломанный палец	Едущий автобус
Дислексия, СДВГ	Сотрясение, усталость, лекарства	Отвлекающая обстановка, стресс

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

Насколько всё плохо

Ежегодно проект WebAIM проверяет главные страницы миллиона самых популярных сайтов. Отчёт за февраль 2026 года (WebAIM Million 2026):

• 95,9% главных страниц содержат автоматически обнаруживаемые ошибки WCAG (в 2025 году — 94,8%);
• в среднем 56,1 ошибки на странице, на 10% больше, чем годом ранее;
• шесть самых частых проблем:

Проблема	Доля страниц
Низкий контраст текста	83,9%
Нет альтернативного текста у изображений	53,1%
Нет подписей у полей форм	51,0%
Пустые ссылки	46,3%
Пустые кнопки	30,6%
Не указан язык документа	13,5%

Обратите внимание: все шесть проблем решаются базовыми средствами HTML и CSS. Никаких сложных технологий — только внимание к деталям. Этим мы и займёмся.

Как люди на самом деле пользуются сайтами

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

Скринридеры (программы экранного доступа) читают интерфейс вслух или выводят его на брайлевский дисплей. Основные: NVDA и JAWS на Windows, VoiceOver на macOS и iOS, TalkBack на Android. Пользователь скринридера редко читает страницу подряд: он прыгает по заголовкам, ориентирам (landmarks), ссылкам и полям форм, вызывая списки этих элементов.

Клавиатура. Многие люди не могут пользоваться мышью или им так удобнее: моторные нарушения, тремор, незрячие пользователи, а также опытные пользователи, которые просто быстрее работают с клавиатуры. Основные клавиши: Tab / Shift+Tab — перемещение между интерактивными элементами, Enter и Space — активация, стрелки — навигация внутри составных виджетов, Esc — закрытие.

Голосовое управление. Voice Control на macOS и iOS, Voice Access на Android, Dragon на Windows. Пользователь говорит «нажать „Отправить“» — и программа ищет элемент с таким доступным именем. Если видимая подпись кнопки «Отправить», а в aria-label написано «submit-btn», голосовая команда не сработает.

Увеличение. Масштабирование браузера до 200–400%, экранные лупы, увеличенный системный шрифт. Вёрстка должна выдерживать это без горизонтальной прокрутки и наложения текста.

Альтернативные устройства ввода: переключатели (switch access), управление взглядом, джойстики. Все они так или иначе эмулируют клавиатуру — ещё одна причина, почему клавиатурная доступность критична.

Дерево доступности

Браузер строит из DOM отдельное дерево доступности (accessibility tree) и передаёт его вспомогательным технологиям через API операционной системы. У каждого узла дерева есть:

• роль (role) — что это: кнопка, ссылка, заголовок, флажок;
• имя (accessible name) — как это называется: «Отправить», «Главная»;
• состояние и свойства — нажато ли, раскрыто ли, отмечено ли, недоступно ли;
• значение — для полей ввода и ползунков.

Посмотреть дерево можно прямо в DevTools: в Chrome — панель Elements → вкладка Accessibility (и переключатель «полного дерева доступности»), в Firefox — панель Accessibility. Это лучший способ понять, что «видит» скринридер.

Почти вся работа над доступностью сводится к одному: чтобы у каждого элемента в дереве доступности были правильные роль, имя и состояние. Лучше всего с этим справляется семантический HTML.

WCAG 2.2 за пять минут

WCAG (Web Content Accessibility Guidelines) — стандарт W3C, на который ссылается большинство руководств и аудитов. Текущая рекомендованная версия — WCAG 2.2, опубликованная в октябре 2023 года (W3C).

Стандарт построен на четырёх принципах, сокращённо POUR:

1. Perceivable — воспринимаемость. Информацию можно воспринять хотя бы одним доступным органом чувств: у изображений есть текстовая альтернатива, у видео — субтитры, текст достаточно контрастен.
2. Operable — управляемость. Интерфейсом можно управлять: всё работает с клавиатуры, хватает времени, ничего не мигает опасно, есть способы навигации.
3. Understandable — понятность. Текст читаем, поведение предсказуемо, есть помощь при ошибках ввода.
4. Robust — надёжность. Код корректно интерпретируется браузерами и вспомогательными технологиями, включая будущие.

Каждый критерий имеет уровень: A (минимум), AA (стандартная цель для большинства сайтов и ориентир большинства требований) и AAA (повышенный, целиком обычно не требуется). Когда говорят «сайт соответствует WCAG», почти всегда имеют в виду уровень AA.

Что нового в 2.2

Для разработчика важны новые критерии:

Критерий	Уровень	Суть
2.4.11 Focus Not Obscured (Minimum)	AA	Элемент в фокусе не должен быть полностью закрыт липкой шапкой, баннером cookies и т. п.
2.5.7 Dragging Movements	AA	У любого перетаскивания должна быть альтернатива одиночными нажатиями
2.5.8 Target Size (Minimum)	AA	Цели нажатия не меньше 24×24 CSS-пикселя (или с достаточным отступом)
3.2.6 Consistent Help	A	Ссылки на помощь — в одном и том же месте на всех страницах
3.3.7 Redundant Entry	A	Не заставлять вводить одни и те же данные повторно в одном процессе
3.3.8 Accessible Authentication (Minimum)	AA	Вход без когнитивных тестов: разрешать вставку пароля и менеджеры паролей

Критерий 4.1.1 Parsing из версии 2.2 удалён: современные браузеры одинаково исправляют ошибки разметки, и он потерял смысл.

Читать полный текст стандарта подряд тяжело. Удобнее начинать с WCAG Quick Reference с фильтрами по уровню и технологии и с пояснений «Understanding WCAG» к каждому критерию.

Серия «Доступный веб на практике»

1. Доступность сайта: для кого она на самом деле и с чего начать — вы здесь
2. Семантический HTML и альтернативный текст: фундамент доступного сайта
3. Доступные формы: подписи, подсказки, ошибки и автозаполнение
4. Клавиатура и фокус: как сделать сайт, которым можно пользоваться без мыши
5. Контраст, анимация и размер кнопок: визуальная доступность сайта
6. ARIA и динамический контент: когда атрибуты помогают, а когда вредят
7. Доступность в React: id, фокус при смене маршрута и объявления
8. Как тестировать доступность: автоматика, ручная проверка и чеклист

Следующая часть: Семантический HTML и альтернативный текст: фундамент доступного сайта

Agama Labs — разработка сайтов и веб-приложений. Если хотите проверить доступность своего сайта, напишите нам: hello@agamalabs.com