Вы когда-нибудь пробовали пользоваться любимым сайтом с закрытыми глазами? Или только одной рукой? А может быть с громко играющей музыкой в наушниках, которая мешает сосредоточиться на интерфейсе? В такие моменты каждый из нас хотя бы отчасти приближается к пониманию того, что испытывают люди с инвалидностью ежедневно.

Доступность (Accessibility, часто сокращаемая как A11y — где 11 означает количество букв между 'A' и 'y') — это не просто моральный долг или соответствие юридическим нормам. Это фундаментальное качество продукта, определяющее, сможет ли им воспользоваться каждый пятый житель планеты.

В данной статье мы рассмотрим международный стандарт WCAG 2.2, научимся проектировать для разных групп пользователей и разберем практические инструменты тестирования, включая работу со скрин-ридерами.

Часть 1: WCAG 2.2 — Навигационная карта доступности

Web Content Accessibility Guidelines (WCAG) — это «золотой стандарт» доступности, разработанный Консорциумом Всемирной паутины (W3C). В октябре 2023 года была утверждена новая редакция — WCAG 2.2, которая пришла на смену версии 2.1.

1.1. Четыре принципа POUR

В основе WCAG лежат четыре фундаментальных принципа, известных по аббревиатуре POUR. Контент должен быть:

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

1.2. Что нового в WCAG 2.2?

Главное изменение в версии 2.2 — фокус на пользователей с ограниченной моторикой и когнитивными нарушениями . Добавлено 9 новых критериев, а один устаревший исключен . Вот ключевые нововведения, на которые стоит обратить внимание:

• Фокус не должен исчезать (Focus Appearance — уровень AA): Визуальный индикатор фокуса клавиатуры (обычно контур вокруг элемента) должен иметь достаточный контраст и размер, чтобы его было легко заметить.
• Перетаскивание (Dragging — уровень AA): Действия, требующие перетаскивания объектов (drag & drop), должны иметь альтернативный простой способ выполнения (например, нажатие кнопок), так как многие пользователи с моторными нарушениями не могут удерживать кнопку мыши при перемещении.
• Целевой размер (Target Size — уровень AA): Для интерактивных элементов (кнопок, ссылок) рекомендуется минимальный размер 24x24 пикселя, чтобы по ним было легко попасть людям с тремором рук или при использовании мобильных устройств. Исключения делается для ссылок внутри текстового абзаца.
• Аутентификация (Accessible Authentication — уровень AA): Процессы входа в систему не должны требовать решения задач, основанных на запоминании пароля или распознавании объектов (капча), если для этого нет альтернативы. Это критически важно для людей с когнитивными нарушениями.

Понимание WCAG 2.2 становится обязательным не только для госсектора. С 28 июня 2025 года Европейский акт о доступности (EAA) распространяет требования уровня AA на частный бизнес в ЕС: интернет-магазины, банки, телеком-операторов и многих других .

Часть 2: Дизайн для всех — учет особенностей пользователей

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

2.1. Нарушения зрения (от слепоты до дальтонизма)

Это самая очевидная аудитория для применения стандартов доступности. По данным ВОЗ, более 2,2 млрд человек имеют те или иные нарушения зрения.

Практические советы:

• Контрастность: Обеспечьте достаточный контраст между текстом и фоном. Для обычного текста на уровне AA требуется контраст 4.5:1, для крупного текста — 3:1 . Используйте инструменты проверки контраста (Color Contrast Analyser, WebAIM).
• Визуальные сигналы: Не используйте цвет как единственный сигнал, дающий информацию о состоянии объекта. Статус системы должен быть визуально понятным даже в черно-белом исполнении. Простыми словами, дублируйте сигнал иконками, текстом или подчеркиванием .
• Текстовые альтернативы: Все значимые изображения должны иметь атрибут alt с описанием содержания. Декоративные изображения должны быть скрыты от скрин-ридеров (пустой alt="") , .
• Масштабируемость: Интерфейс должен корректно отображаться при увеличении экрана до 400% без потери функциональности.

2.2. Нарушения моторики

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

Что делать дизайнеру:

• Управление с клавиатуры: Все функции, доступные мышью, должны быть доступны с клавиатуры. Это означает логичный порядок фокуса (обычно совпадающий с визуальным порядком на странице) и видимый индикатор фокуса .
• Крупные кликабельные области: Как требует WCAG 2.2, кнопки и ссылки должны быть большими, чтобы в них было легко попасть .
• Достаточно времени: Избегайте таймеров или давайте возможность их продлить/отключить. Людям с моторными нарушениями может потребоваться больше времени на заполнение формы.
• Отказ от сложных жестов: Предоставляйте простую альтернативу сложным жестам (смахивание, мультитач).

2.3. Когнитивные особенности

Это одна из самых сложных и разнообразных групп. Она включает людей с нарушениями обучаемости (дислексия), памяти, внимания, а также пожилых людей.

Что делать на практике:

• Простота и предсказуемость: Интерфейс должен быть последовательным. Навигация и кнопки должны находиться на привычных местах. Избегайте неожиданных переходов и всплывающих окон.
• Понятный язык: Используйте короткие предложения, избегайте сложных терминов и жаргона. Расшифровывайте аббревиатуры . Пишите "Январь" вместо "Янв".
• Четкая структура: Используйте заголовки, списки и иконки для визуального разделения информации . Пользователю должно быть легко сканировать страницу взглядом.
• Упрощенная аутентификация: Дайте возможность войти по биометрии или с помощью ссылки на email вместо запоминания сложного пароля.

Часть 3: Техническая реализация и семантическая верстка

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

3.1. Почему семантика — это основа?

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

Например, можно сделать "кнопку" так:

<div class="btn" role="button" tabindex="0">Купить</div>

Но гораздо правильнее и проще так:

<button>Купить</button>

Элемент <button> «из коробки» имеет правильную роль, управление с клавиатуры (Tab, Enter/Пробел) и фокус .

Ключевые семантические теги:

• <header>, <nav>, <main>, <footer>, <aside> — создают навигационные вехи (landmarks), по которым пользователи скрин-ридеров могут быстро перемещаться.
• <h1> — <h6> — создают иерархию заголовков. Никогда не пропускайте уровни (не перескакивайте с <h2> на <h4>). <h1> должен быть на странице один.
• <ul>, <ol>, <li> — для списков.
• <table> с <th> — для таблиц с данными (указывайте заголовки столбцов/строк).
• <a> — для ссылок. Текст ссылки должен быть понятен вне контекста (никогда не пишите "нажмите здесь") .

3.2. Доступные формы

Формы — частый источник проблем. Чтобы сделать их доступными:

• Каждый <input>, <select> или <textarea> должен быть связан с подписью через связку id и <label for="id"> или быть вложенным в <label>.
• Группируйте логически связанные поля (например, адрес) в <fieldset> и давайте группе имя через <legend>.
• Четко обозначайте обязательные поля и формат ввода данных в подписях, а не только цветом.

3.3. Когда HTML не справляется: WAI-ARIA

Иногда мы создаем сложные интерфейсные компоненты (например, кастомный выпадающий список с автодополнением), для которых нет подходящего HTML-тега. В таких случаях на помощь приходит WAI-ARIA (Accessible Rich Internet Applications).

ARIA позволяет добавить к элементам атрибуты, которые сообщают скрин-ридеру дополнительную информацию:

• Роль (role): Что это за элемент? (role="dialog", role="tablist", role="progressbar").
• Состояние и свойства: В каком он состоянии? (aria-expanded="true/false", aria-checked="true", aria-hidden="true").

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

Подробнее о создании доступной среды благодаря HTML

Часть 4: Тестирование — Смотрим и слушаем мир чужими глазами

Автоматические инструменты (Lighthouse, axe) — отличный первый шаг, но они находят лишь около 30% проблем. Настоящее тестирование доступности — это ручной труд и эмпатия.

4.1. Тестирование клавиатурой

Самый простой и эффективный тест. Отключите мышь и попробуйте пользоваться сайтом только с клавиатуры.

1. Используйте клавишу Tab, чтобы перемещаться по интерактивным элементам.
2. Всегда ли видно, где находится фокус (синяя или пунктирная обводка)?
3. Логичен ли порядок перехода? Не прыгает ли фокус с главного меню сразу в подвал?
4. Можно ли открыть все выпадающие списки, выбрать пункт и закрыть их?
5. Можно ли активировать все кнопки пробелом или энтером?

4.2. Тестирование со скрин-ридерами

Скрин-ридеры (читалки экрана) преобразуют цифровой текст в синтезированную речь или шрифт Брайля. Это основной инструмент для незрячих пользователей. Тестирование с ними — обязательный этап. 

Популярные комбинации скрин-ридеров:

• Windows: NVDA (бесплатный, лучше всего работает с Firefox). Или JAWS (платный, самый популярный в корпоративном секторе) .
• macOS: VoiceOver (встроен в систему, лучше всего работает с Safari).
• Android: TalkBack (встроен).
• iOS: VoiceOver (встроен).

Что проверять с помощью скрин-ридера:

• Чтение содержимого: Пройдитесь по странице стрелками (режим виртуального курсора). Все ли элементы озвучиваются? Правильно ли озвучиваются изображения (через alt)?
• Навигация по заголовкам (клавиша H): Можете ли вы составить "карту" страницы и перейти к нужному разделу только по заголовкам? Не пропущены ли уровни? .
• Навигация по ссылкам (клавиша K): Понятно ли, куда ведут ссылки, при прослушивании их вне контекста?
• Навигация по вехам (landmarks) (клавиша D): Можно ли быстро перейти к основному контенту (<main>), минуя шапку и навигацию?
• Работа с формами (клавиши F, E, C, R, B): Озвучивается ли подпись поля, когда вы входите в него? Правильно ли читаются сообщения об ошибках?
• Динамический контент: Оповещает ли скрин-ридер о появлении всплывающих окон или обновлении части страницы?

4.3. Инструменты для помощи в тестировании

Помимо ручного тестирования, полезно использовать:

• Accessibility Insights for Web (браузерный плагин): Помогает проходить проверки пошагово.
• Lighthouse (встроен в Chrome DevTools): Быстрая автоматическая проверка основных метрик.
• Инструменты разработчика (браузера): Позволяют инспектировать дерево доступности (Accessibility Tree), чтобы увидеть, какую именно информацию браузер передает скрин-ридеру.

Заключение

Доступность — это не финальный штрих и не чек-лист для галочки. Это философия проектирования, которая ставит человека в центр вселенной продукта. Интегрируя знания о WCAG 2.2, создавая продуманный дизайн для разных групп пользователей, опираясь на семантическую верстку и проверяя свою работу с реальными инструментами (от клавиатуры до VoiceOver), мы перестаем делить мир на "обычных" и "особенных" пользователей. Мы просто создаем качественный, удобный и честный продукт для всех.