Что такое a11y и почему это не ваша проблема — пока не станет

a11y — сокращение от «accessibility» (между первой и последней буквой 11 символов). Веб-доступность означает, что сайтом могут нормально пользоваться люди с ограниченными возможностями: нарушениями зрения, слуха, моторики, когнитивными особенностями.

По данным ВОЗ, в мире около 1,3 миллиарда людей с инвалидностью. В России — порядка 11 миллионов официально зарегистрированных. Это не маленькая аудитория, которую можно проигнорировать ради экономии бюджета.

Но дело не только в этом. Многие улучшения доступности помогают вообще всем:

  • Субтитры к видео смотрят не только глухие, но и те, кто в метро без наушников
  • Высокий контраст текста удобен при ярком солнце на улице
  • Клавиатурная навигация нужна не только людям с нарушениями моторики, но и всем, кто привык к горячим клавишам

Четыре принципа WCAG — что за стандарт и почему он важен

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

Стандарт строится на четырёх принципах:

Perceivable (Воспринимаемый) — пользователь должен воспринимать весь контент. У каждого изображения — alt-текст, у видео — субтитры.

Operable (Управляемый) — интерфейс работает с клавиатуры, нет ловушек фокуса, контент не мигает слишком быстро (это может вызвать приступы у людей с фотосенситивной эпилепсией).

Understandable (Понятный) — язык страницы указан, ошибки в формах объяснены, поведение интерфейса предсказуемо.

Robust (Надёжный) — контент корректно работает со вспомогательными технологиями: скринридерами, брайлевскими дисплеями, альтернативными указателями.

У каждого принципа три уровня: A (минимальный), AA (рекомендуемый), AAA (расширенный). Большинство компаний ориентируется на AA.

Реальные проблемы, которые встречаются на каждом втором сайте

Это не теоретические кейсы — вот что реально ломается.

Отсутствие alt у изображений. Скринридер зачитывает «img_2847394.png». Пользователь не понимает, что на картинке. Лечится одной строкой: alt="Фотография офиса компании в центре Москвы". Декоративные изображения — пустой alt: alt="", чтобы скринридер их пропускал.

Плохой контраст текста. WCAG требует соотношение контраста минимум 4.5:1 для обычного текста и 3:1 для крупного (от 18pt). Серый текст на белом фоне — классика провала. Проверить легко: инструмент Contrast Checker от WebAIM покажет точное соотношение.

Формы без связанных лейблов. Placeholder в поле ввода — это не замена <label>. Когда пользователь начинает вводить текст, placeholder исчезает. Правильно: <label for="email">Email</label><input id="email" type="email">.

Кнопки без текста. Иконка корзины без текстового описания — загадка для скринридера. Добавьте aria-label="Удалить товар из корзины" или скрытый текст через CSS-класс .visually-hidden.

Фокус при клавиатурной навигации исчезает. Дизайнер убрал outline через outline: none — «некрасиво». В итоге пользователь с клавиатурой не видит, где находится. Вместо удаления — заменяйте: outline: 2px solid #0066cc; outline-offset: 2px.

Скачущий порядок вкладок. При нажатии Tab фокус должен идти логично — сверху вниз, слева направо. Если порядок ломается из-за CSS или JS, это дезориентирует.

Семантическая вёрстка — основа основ

Самое дешёвое и эффективное вложение в доступность — правильная семантика HTML. Скринридеры ориентируются по структуре документа, и если вся страница сделана из <div> и <span>, у них нет шансов.

Заголовки. Иерархия <h1> → <h2> → <h3> должна отражать структуру контента, а не размер шрифта. На странице один <h1>, в нём — тема страницы. Не делайте <h2> заголовком только потому, что хочется крупный текст.

Ориентиры (landmarks). Используйте семантические теги: <header>, <nav>, <main>, <aside>, <footer>. Пользователи скринридеров прыгают между ориентирами, чтобы не слушать весь контент подряд.

Списки. Набор ссылок в меню — это список. Используйте <ul> и <li>, а не кучку <div>.

Кнопки и ссылки. Кнопка — для действия (отправить, удалить, открыть). Ссылка — для перехода. Не делайте <div onclick="..."> вместо <button>. Кнопки по умолчанию активируются с клавиатуры, div — нет.

ARIA — когда HTML не хватает

ARIA (Accessible Rich Internet Applications) — набор атрибутов, которые расширяют семантику HTML для сложных интерфейсов.

Главное правило: используйте ARIA только там, где нативный HTML не справляется. Первое правило W3C буквально гласит: «Не используйте ARIA, если можно использовать нативный элемент HTML».

Когда ARIA реально нужна:

  • Кастомные компоненты: аккордеоны, табы, модальные окна, дропдауны
  • Динамически обновляемый контент: aria-live="polite" для уведомлений
  • Иконочные кнопки без видимого текста: aria-label="Закрыть"
  • Состояния: aria-expanded="true/false", aria-checked, aria-disabled

Пример модального окна:

<div role="dialog" aria-modal="true" aria-labelledby="modal-title">
  <h2 id="modal-title">Подтверждение удаления</h2>
  <p>Вы уверены, что хотите удалить этот файл?</p>
  <button>Удалить</button>
  <button>Отмена</button>
</div>

При открытии модального окна фокус должен перемещаться внутрь него. При закрытии — возвращаться на элемент, который его открыл.

Цвет — не единственный способ передать информацию

Около 8% мужчин и 0,5% женщин имеют то или иное нарушение цветовосприятия. Самый распространённый вариант — неразличение красного и зелёного.

Если вы показываете ошибку только красным цветом, часть пользователей её просто не заметит. Добавьте иконку, текстовое сообщение или изменение формы элемента.

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

Симулятор цветовой слепоты встроен в Chrome DevTools: Rendering → Emulate vision deficiencies.

Мобильная доступность

На мобильных устройствах свои требования.

Размер цели касания. WCAG 2.5.5 рекомендует минимум 44×44px для интерактивных элементов. Маленькие кнопки рядом друг с другом — источник постоянных промахов.

Жесты. Если функция доступна только через свайп или сложный жест, она должна дублироваться простым нажатием.

Масштабирование. Не блокируйте зум через user-scalable=no в мета-теге viewport. Пользователи со слабым зрением масштабируют страницу — не лишайте их этой возможности.

VoiceOver и TalkBack. Протестируйте ключевые сценарии на iOS (VoiceOver) и Android (TalkBack). Это займёт час, но покажет реальные проблемы, которые автоматические проверки пропустят.

Инструменты для проверки доступности

axe DevTools (расширение для Chrome/Firefox) — самый популярный инструмент. Находит нарушения WCAG прямо в браузере, объясняет проблему и указывает, как исправить. Бесплатная версия покрывает большинство нужд.

Lighthouse (встроен в Chrome DevTools) — даёт оценку доступности от 0 до 100. Удобно для первичного аудита.

NVDA (бесплатный скринридер для Windows) и VoiceOver (встроен в macOS и iOS) — для ручного тестирования. Автоматические инструменты находят около 30% проблем доступности. Остальное ловится только руками.

WebAIM Contrast Checker — проверка контраста по HEX-значениям.

Accessibility Insights от Microsoft — расширение с пошаговыми руководствами по тестированию.

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

Почему это выгодно бизнесу — не только этика

SEO. Alt-тексты помогают Google понять изображения. Правильная структура заголовков лучше индексируется. Семантическая вёрстка читается парсерами. Это не побочный эффект — это прямое пересечение интересов.

Юридические риски. В США компании судятся за недоступные сайты сотнями в год (Domino's Pizza дошла до Верховного суда). В России для государственных ресурсов требования к доступности обязательны по ГОСТ Р 52872. Крупный бизнес учитывает это при работе с госзаказчиками.

Аудитория. 11 миллионов людей с инвалидностью в России — это рынок. Добавьте пожилых пользователей, людей в ситуативных ограничениях: сломанная рука, яркое солнце, шумное место. По оценкам Click-Away Pound, британские компании ежегодно теряют £17 миллиардов из-за недоступных сайтов.

Качество кода. Сайт с хорошей доступностью, как правило, лучше структурирован, легче тестируется и поддерживается.

Как начать — без боли и лишних затрат

Если у вас уже есть сайт и вы хотите улучшить доступность, не нужно переделывать всё с нуля.

  1. Запустите axe DevTools или Lighthouse. Начните с критических ошибок.
  2. Добавьте alt-тексты ко всем значимым изображениям. Декоративным — пустой alt.
  3. Проверьте контраст на главных страницах. Серый на белом, светло-жёлтый на белом — типичные провалы.
  4. Пройдитесь по форме с клавиатурой. Tab, Shift+Tab, Enter, Space. Можете заполнить форму без мыши?
  5. Проверьте viewport. user-scalable=no нигде не должно стоять.
  6. Добавьте lang к <html>. <html lang="ru"> — секунда работы, но важно для скринридеров.

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

Что делать с контентом

Доступность — это не только технические вещи.

Описание ссылок. «Нажмите здесь» — плохо. «Скачать прайс-лист в PDF» — хорошо. Пользователи скринридеров часто слушают список ссылок на странице вырванными из контекста.

Субтитры и транскрипты. Есть видео — добавьте субтитры. Есть аудио — транскрипт. YouTube генерирует субтитры автоматически с погрешностями, но это лучше, чем ничего.

Мигающий контент. Контент, который мигает более трёх раз в секунду, может вызвать приступ у людей с фотосенситивной эпилепсией. Проверяйте анимации и рекламные блоки.

Простой язык. WCAG AAA рекомендует читаемость на уровне средней школы для основного контента. Не «писать примитивно» — избегать ненужного усложнения.

Тест с закрытыми глазами

Один из лучших способов понять проблемы доступности — включить VoiceOver на Mac или NVDA на Windows и пройти ключевой сценарий вашего сайта с закрытыми глазами.

Например: найти нужный товар, добавить в корзину, оформить заказ.

После пяти минут такого теста становится понятно, почему «просто добавить alt» — это только начало. Порядок чтения, объявления о динамическом контенте, управление фокусом, понятные названия кнопок — всё это складывается в реальный пользовательский опыт.

Доступный сайт — это не сайт с зелёной галочкой в Lighthouse. Это сайт, которым реально можно пользоваться.