Доступность: карта трека, кто и как пользуется интерфейсами

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

Слово «доступность» (accessibility, сокращённо a11y — одиннадцать букв между «a» и «y») в вебе означает вполне конкретную вещь: интерфейс работает не только тем способом, который вы себе представляли, когда его делали.

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

Отсюда рабочее определение, к которому мы будем возвращаться весь трек:

Доступный интерфейс — это интерфейс, который корректно передаёт своё содержание, структуру и состояние через любой канал восприятия и принимает ввод любым способом, а не только через зрение и мышь.

Три вещи, которые полезно проговорить сразу, потому что они определяют тон всего дальнейшего разговора.

Первое: это вопрос качества, а не благотворительности. Кнопка, которую не видит скринридер, — это ровно такой же дефект, как кнопка, которая не работает в Safari. У неё есть шаги воспроизведения, есть ожидаемое поведение, есть спецификация, которой она не соответствует. Не нужно «делать доступность ради людей с инвалидностью» точно так же, как не нужно «делать поддержку Safari ради пользователей Apple»: вы просто чините сломанное. Формулировки вроде «страдающие слепотой» или «люди с ограниченными возможностями» в этой рамке звучат так же нелепо, как «страдающие Safari». Незрячий человек — это не трагедия и не повод для умиления, это пользователь с другим способом взаимодействия. И этот пользователь, как правило, владеет своей ассистивной технологией куда лучше, чем вы владеете своей IDE: скорость речи 400–500 слов в минуту на слух — обычное дело, разработчик такую запись просто не разберёт.

Второе: барьер создаёт не человек, а среда. Медицинская модель говорит «человек не может пользоваться сайтом, потому что он не видит». Социальная модель говорит «человек не может пользоваться сайтом, потому что автор не подписал кнопки». Второе описание конструктивно: оно указывает на дефект, который можно починить, и на того, кто может его починить. Весь трек написан из этой рамки.

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

Эта картинка — сжатая версия модели Persona Spectrum из Microsoft Inclusive Design Toolkit. Смысл в правой колонке: одно техническое решение закрывает всю строку. Субтитры сделали ради глухих людей — ими пользуются в метро, в открытом офисе, при просмотре видео на неродном языке. Ровно поэтому доступность почти никогда не бывает «фичей для 2% пользователей»: реальный охват решения всегда шире группы, ради которой оно задумывалось. Это называют curb-cut effect — по съезду с тротуара, который сделали для колясок, а пользуются им родители с колясками детскими, курьеры с тележками и все, кто везёт чемодан.

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

На портале уже есть Гайд по Accessibility — сжатый практический свод рекомендаций для менеджеров, дизайнеров и разработчиков. Считайте его быстрым входом и памяткой на каждый день; этот трек — подробный разбор того же материала с объяснением механики: почему именно так, что происходит внутри браузера и как это проверять.

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

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

Теперь то же самое в виде инженерной таблицы: барьер → технология → что именно ломается в типичном приложении.

Обратите внимание на две последние строки: там никакой ассистивной технологии нет. Их нельзя починить «правильными ARIA-атрибутами» — они чинятся только решениями дизайна и текста. Это важная поправка к распространённому представлению, будто a11y — это про скринридеры и разметку.

Как ассистивная технология видит вашу страницу

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

Разберём шаги.

1. Ваш код — HTML, CSS, JS. Всё начинается и заканчивается здесь: ошибка на этом шаге не чинится ни на одном из следующих.
2. DOM и CSSOM. Браузер строит дерево узлов и вычисляет для каждого стили. Здесь уже становится ясно, что видимо, а что нет.
3. Дерево доступности (accessibility tree). Браузер строит из DOM параллельное дерево, где у каждого узла есть роль, доступное имя, описание, значение, состояния и связи с другими узлами. Это и есть модель, с которой работают ассистивные технологии. Дерево доступности заметно меньше DOM: узлы, не несущие смысла, схлопываются, скрытые — выбрасываются.
4. API операционной системы. Браузер публикует дерево через платформенный API: UI Automation в Windows, AT-SPI2 в Linux, NSAccessibility в macOS, Accessibility API в Android и iOS.
5. Ассистивная технология подписывается на этот API, получает дерево и события об изменениях, строит по ним свою модель.
6. Человек получает речь, брайль, увеличенную картинку или возможность сказать «нажми Сохранить».

Практический вывод: доступное имя, роль и состояние — это три вещи, ради которых существует почти вся техническая часть a11y. Как их вычислить, задано отдельной спецификацией — Accessible Name and Description Computation. Для кнопки порядок такой: aria-labelledby → aria-label → собственное текстовое содержимое → title. Первый непустой источник побеждает, остальные игнорируются.

<!-- Роль: button. Имя: "Сохранить". Состояние: enabled. Всё бесплатно. -->
<button type="button">Сохранить</button>

<!-- Роль: none/generic. Имя: пустое для AT-навигации по элементам управления.
     В порядок обхода Tab не попадает, Enter и Пробел не работают.
     Скринридер прочитает "Сохранить" как обычный текст абзаца. -->
<div class="btn" onclick="save()">Сохранить</div>

<!-- Кнопка-иконка: видимого текста нет, значит имя надо задать явно.
     aria-hidden на svg убирает из дерева декоративную графику,
     чтобы скринридер не читал имена path и title изнутри иконки. -->
<button type="button" aria-label="Удалить черновик">
  <svg aria-hidden="true" focusable="false" width="16" height="16"><use href="#trash"/></svg>
</button>

Отдельная тонкость про сокрытие: визуально скрытый и скрытый от ассистивных технологий — это разные вещи, и путать их дорого.

/* Текст не виден глазом, но остаётся в дереве доступности.
   Классический приём для подписей, очевидных из контекста визуально. */
.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
  border: 0;
}

<!-- Глазом видна только иконка лупы, скринридер услышит "Поиск по каталогу, поле ввода" -->
<label for="q"><span class="visually-hidden">Поиск по каталогу</span>
  <svg aria-hidden="true" width="16" height="16"><use href="#search"/></svg>
</label>
<input id="q" type="search">

Обратное направление: display: none, visibility: hidden, атрибут hidden, aria-hidden="true" и inert убирают узел (или всё поддерево) из дерева доступности. А вот opacity: 0, прозрачный цвет текста или вынос за пределы экрана — не убирают. Отсюда два самых частых бага в этой области: «кнопка есть, но скринридер её не находит» (узел выкинут) и «скринридер читает то, чего на экране нет» (спрятали только визуально).

Проверяется всё это без всякого скринридера: DevTools → Elements → вкладка Accessibility → Computed Properties. Там видно вычисленное имя, роль и то, как имя получилось.

Пять минут с настоящим скринридером

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

Windows: NVDA. Бесплатный, открытый, установка занимает минуту, скачивается с nvaccess.org. Клавиша-модификатор NVDA — Insert или CapsLock (выбирается при установке).

Отдельно про Speech Viewer: меню NVDA → Инструменты → Просмотр речи открывает окно, куда текстом дублируется всё, что произносится. Для разработчика это меняет всё — можно читать глазами то, что услышит пользователь, и копировать в тикет.

macOS и iOS: VoiceOver. Включается Cmd + F5 на маке, тройным нажатием боковой кнопки на телефоне. Модификатор VO — Control + Option. VO + A — читать всё, VO + → и VO + ← — по элементам, VO + Пробел — активировать, VO + U — ротор (список заголовков, ссылок, ориентиров; переключается стрелками). В VoiceOver Utility включается Caption Panel — аналог Speech Viewer.

Linux: Orca, входит в GNOME, включается Super + Alt + S. Android: TalkBack — свайп вправо и влево по элементам, двойное касание для активации. Windows: Экранный диктор (Ctrl + Win + Enter) — годится посмотреть, но тестировать лучше на NVDA: у него доля рынка несопоставимо больше.

Что сделать в первые пять минут

1. Откройте NVDA или VoiceOver, откройте свой продукт. Не смотрите на экран — разверните окно поверх или отвернитесь. Серьёзно: соблазн подглядеть убивает весь смысл упражнения.
2. Нажмите H подряд десять раз. Вы услышали оглавление страницы? Если вместо структуры звучит «заголовок 1 уровня Логотип, заголовок 3 уровня Скидки, заголовок 3 уровня Скидки, заголовок 3 уровня Скидки» — оглавления у вас нет.
3. Нажмите D несколько раз. Есть ли banner, navigation, main, contentinfo? Если нет — человек не может перепрыгнуть шапку и идёт через все её ссылки на каждой странице.
4. Откройте список элементов (NVDA + F7) и посмотрите на ссылки. Сколько раз повторяется «Подробнее» и «Читать далее»? В этом списке нет контекста — только сами тексты ссылок.
5. Нажмите B до вашей главной кнопки. Она нашлась? Она озвучена осмысленно? «кнопка» без имени и «кнопка Изображение b7f2c1» — это баги.

Реальная статистика подтверждает, что люди работают именно так: в опросах пользователей скринридеров WebAIM Screen Reader User Survey около двух третей респондентов на длинной странице первым делом идут по заголовкам. Заголовки для них — это не типографика, а навигация. Поэтому <h2>, выбранный «потому что нужен шрифт помельче», ломает не эстетику, а навигацию.

Режим обзора и режим форм

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

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

Из этого следуют два практических правила, которые мы подробно разберём в статьях про ARIA и компоненты:

• Правильная роль переключает режим сама. Роли textbox, combobox, listbox, grid, menu заставляют скринридер отдать клавиши приложению. Поставили роль — обязаны реализовать клавиатурную модель, которую эта роль обещает.
• Неправильная роль ломает и то, и другое. Повесили role="menu" на обычный список ссылок — человек попадает в режим форм, где H и K больше не работают, а стрелки, которые роль обещает, вы не реализовали. Получился интерфейс, из которого нет выхода. Это гораздо хуже, чем вообще без ARIA.

Что ломается чаще всего

Ежегодный отчёт WebAIM Million прогоняет автопроверку по главным страницам миллиона сайтов. Из года в год результат держится около 95% страниц с обнаружимыми автоматикой нарушениями WCAG, в среднем несколько десятков ошибок на страницу. И — важная деталь — ошибки почти всегда одни и те же:

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

Плохая новость тоже есть: автопроверки ловят от силы четверть реальных проблем. Ни один линтер не скажет вам, что alt="картинка" бессмысленен, что порядок обхода не совпадает с визуальным, что модалка не возвращает фокус или что текст ошибки не объясняет, как её исправить. Про соотношение автоматического и ручного подробно — в статье про тестирование и процесс.

Приоритизировать разумно так:

Пятиминутный ручной аудит

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

Несколько сниппетов, которые ускоряют шаги. Вставляются в консоль браузера.

// 1. Карта заголовков: видно дыры в уровнях и заголовки-украшения
console.table([...document.querySelectorAll('h1,h2,h3,h4,h5,h6')].map(h => ({
  уровень: Number(h.tagName[1]),
  текст: h.textContent.trim().slice(0, 70),
  виден: h.offsetParent !== null,
})));

// 2. Картинки без alt. Пустой alt="" — это нормально для декоративных,
//    а вот отсутствие атрибута означает, что скринридер прочитает имя файла.
console.table([...document.images]
  .filter(img => !img.hasAttribute('alt'))
  .map(img => ({ src: img.currentSrc.slice(-60) })));

// 3. Интерактивные элементы без видимого доступного имени.
//    Грубая эвристика: нет ни текста, ни aria-label, ни aria-labelledby, ни title.
const named = el =>
  el.textContent.trim() ||
  el.getAttribute('aria-label') ||
  el.getAttribute('aria-labelledby') ||
  el.getAttribute('title') ||
  (el.matches('input,select,textarea') && document.querySelector(`label[for="${el.id}"]`));
console.table([...document.querySelectorAll('a[href],button,input,select,textarea,[role="button"],[role="link"]')]
  .filter(el => !named(el))
  .map(el => ({ тег: el.tagName.toLowerCase(), классы: el.className, html: el.outerHTML.slice(0, 80) })));

// 4. Трассировка порядка обхода: жмите Tab и смотрите лог
document.addEventListener('focusin', () => {
  const el = document.activeElement;
  console.log('%c→ ' + el.tagName, 'color:#4f8ac9', el.className, el.textContent.trim().slice(0, 40));
});

// 5. Базовая гигиена документа
console.log({
  lang: document.documentElement.lang || '!!! не задан',
  title: document.title,
  landmarks: [...document.querySelectorAll('header,nav,main,aside,footer,[role]')]
    .map(el => el.getAttribute('role') || el.tagName.toLowerCase()),
  positiveTabindex: [...document.querySelectorAll('[tabindex]')]
    .filter(el => Number(el.getAttribute('tabindex')) > 0).length, // должно быть 0
});

Из инструментов, которые стоит поставить прямо сейчас и держать под рукой: расширение axe DevTools для Chrome и Firefox (лучший баланс точности и шума, почти нет ложных срабатываний), WAVE (показывает проблемы прямо поверх страницы — удобно объяснять дизайнеру), встроенная в Chrome DevTools панель Accessibility и Lighthouse. Ни один из них не заменяет Tab и скринридер, но пять из шести проблем из таблицы выше они ловят за секунды.

Как это регулируется: три уровня

Технические требования к доступности живут в трёх слоях спецификаций W3C, и путать их — распространённая ошибка.

• WCAG 2.2 — рекомендация W3C, действующая с октября 2023 года. Описывает результат, а не способ: «у нетекстового контента есть текстовая альтернатива», «весь функционал доступен с клавиатуры». Структура: четыре принципа POUR (Perceivable, Operable, Understandable, Robust) → 13 руководств → критерии успеха с уровнями A, AA, AAA. Практический ориентир индустрии и большинства законов — уровень AA. Версия 2.2 добавила девять критериев, из которых чаще всего вспоминают 2.5.8 «Размер цели» (минимум 24×24 CSS-пикселя), 2.4.11 «Фокус не перекрыт», 2.5.7 «Перетаскивание» (должна быть альтернатива без drag), 3.3.8 «Доступная аутентификация» (нельзя требовать запоминания и распознавания ребусов) и 3.3.7 «Повторный ввод».
• WAI-ARIA 1.2 — словарь атрибутов, которыми можно дописать роль, свойство или состояние туда, где HTML не выражает нужную семантику. ARIA ничего не делает: она не добавляет поведение, не даёт фокус, не обрабатывает клавиши. Она только меняет то, что браузер положит в дерево доступности. Отсюда первое правило ARIA: если задачу решает нативный элемент — используйте нативный элемент. Подробно — в статье про ARIA.
• ARIA Authoring Practices Guide (APG) — не спецификация, а сборник готовых образцов: диалог, табы, комбобокс, дерево, слайдер. Для каждого расписана клавиатурная модель и набор атрибутов. Это то место, куда идут перед тем, как писать компонент руками.

Юридический слой — тема следующей статьи; коротко: в ЕС действует European Accessibility Act и стандарт EN 301 549 (который по сути ссылается на WCAG), в США — ADA и Section 508, в России — ГОСТ Р 52872-2019 и требования к сайтам госорганов и организаций социальной сферы. Все они в конечном счёте приземляются на один и тот же набор критериев WCAG уровня AA.

Карта трека

Трек читается по порядку: каждая статья опирается на предыдущие. Блоки: контекст и мотивация (1), фундамент разметки (2–3), взаимодействие (4–5), восприятие (6), практика построения UI (7–8), процесс (9).

Быстрый вход и памятка на каждый день — Гайд по Accessibility.

Смежное на портале: семантический HTML и формы и валидация во фронтенд-треке дают ту же разметку с другой стороны; ручное тестирование и E2E и UI — про то, как встроить проверки в процесс; UX и требования — про то, как формулировать критерии приёмки, чтобы доступность попадала в них с самого начала.

Маршруты обучения

Три другие траектории.

Разработчику, у которого «завтра аудит»: статьи 2, 4, 7 и раздел про пятиминутный аудит из этой статьи. Это закроет большинство находок уровня A и AA. Затем 3 — чтобы не наделать хуже попытками всё исправить через ARIA.

Дизайнеру: 1, 6, 7 и раздел про спектр возможностей отсюда. Контраст, размеры целей, состояние фокуса, тексты ошибок и порядок элементов в макете задаются на этапе дизайна — разработчик потом либо реализует доступный макет, либо героически чинит недоступный.

Менеджеру или владельцу продукта: 1 и 9. Первая даёт язык для разговора с бизнесом и юристами, вторая — как встроить доступность в процесс, чтобы она не превращалась в разовый героический спринт раз в два года.

Мифы, которые дорого обходятся

• «Доступность — это для слепых». Незрячие пользователи — заметная, но меньшая часть. Люди, которым нужен только контраст и масштаб, или только клавиатура, или только понятные ошибки, гораздо многочисленнее — и они обычно даже не сообщают о проблеме, просто уходят.
• «Сделаем отдельную доступную версию сайта». Отдельная версия всегда отстаёт по функциональности, потом протухает и в итоге унижает больше, чем отсутствие доступности. Все современные стандарты, включая WCAG, требуют равного доступа к тому же контенту, а не к его усечённой копии.
• «Поставим виджет-оверлей». Скрипты, обещающие «доступность в одну строку кода», по факту чинят единицы проблем, ломают работу настоящих ассистивных технологий и вызывают устойчивое раздражение у пользователей. Открытое письмо Overlay Fact Sheet подписали сотни экспертов и разработчиков ассистивных технологий, включая незрячих специалистов; там же перечислены иски, где оверлей не спас от ответственности.
• «Автотесты покажут, доступен ли продукт». Показывают примерно четверть — и почти ничего из того, что связано со смыслом: качество альтернативного текста, логику порядка обхода, понятность ошибок.
• «Это дорого». Дорого — переделывать. Требования, учтённые в дизайн-системе и в критериях приёмки, стоят почти ничего: подписать поле, оставить outline, выбрать контрастный токен. Порядок величин по разным оценкам такой: исправление на этапе дизайна дешевле исправления после релиза примерно на порядок.
• «ARIA делает интерфейс доступным». ARIA меняет только то, что скринридер объявит. Поведение — фокус, клавиши, порядок — по-прежнему целиком на вас. Неправильная ARIA хуже её отсутствия: она обещает то, чего нет.
• «Наши пользователи такими не пользуются». Обычно это означает, что они не могут пользоваться и потому не появляются в аналитике. Отсутствие сигнала — не доказательство отсутствия спроса.

Чеклист: трек освоен, если вы можете

• Объяснить на схеме, как из вашей разметки получается дерево доступности, и назвать, что убирает узел из этого дерева, а что нет.
• Пройти ключевой сценарий своего продукта только с клавиатуры и только на слух со скринридером, ни разу не взглянув на экран.
• Посмотрев на кастомный компонент, назвать его роль, доступное имя, состояния и клавиатурную модель, которую эта роль обязывает реализовать.
• Объяснить разницу между aria-label, aria-labelledby и <label for> и сказать, какой из них выиграет при вычислении имени.
• Написать критерий приёмки для задачи так, чтобы доступность проверялась при приёмке, а не всплывала на внешнем аудите.
• Найти в WCAG 2.2 конкретный критерий под конкретную находку и указать его номер и уровень в тикете.

Источники

• Web Content Accessibility Guidelines 2.2 — сам стандарт; практичнее читать его через How to Meet WCAG (Quick Reference) с фильтром по уровню.
• WAI-ARIA 1.2, ARIA in HTML и ARIA Authoring Practices Guide — словарь, правила применения и готовые образцы компонентов.
• MDN: Доступность — лучший учебный материал по теме, частично переведён на русский.
• WebAIM — WebAIM Million, опросы пользователей скринридеров и контрастный чекер.
• NV Access — NVDA; руководство Apple по VoiceOver.
• Inclusive Components Хейдона Пикеринга — разбор компонентов «с нуля и доступно», и его же книга Inclusive Design Patterns.
• Microsoft Inclusive Design Toolkit — откуда взялась модель спектра возможностей.
• Overlay Fact Sheet — почему виджеты-накладки не работают, с подписями специалистов отрасли.
• Deque axe DevTools и axe-core — движок автопроверок, который стоит почти за всеми линтерами доступности.

Мини-итог

Доступность — это инженерная работа с тремя опорами. Семантика: браузер строит дерево доступности по вашей разметке, и почти всё нужное нативные элементы дают бесплатно. Взаимодействие: всё должно работать с клавиатуры, фокус должен быть виден и предсказуем, а состояние — объявляться. Восприятие: контраст, масштаб, отсутствие зависимости от одного канала (только цвет, только звук, только зрение).

Инструменты и фреймворки над этими опорами меняются, сами опоры — нет: <button> работает одинаково хорошо в jQuery, React и во всём, что придёт после. Начинать стоит не с ARIA и не с оверлеев, а с двух вещей, которые доступны прямо сейчас: убрать руку с мыши и включить скринридер на собственном продукте. Дальше разбираемся, зачем это нужно с точки зрения людей, стандартов и бизнеса.

Что дальше

Зачем это нужно: люди, стандарты WCAG, требования и бизнес-аргументы — кто именно оказывается за бортом и по каким причинам, как устроен WCAG 2.2 изнутри, чем отличаются уровни A, AA и AAA, какие требования действуют в разных юрисдикциях и как разговаривать о доступности с бизнесом, не сводя разговор к моральному давлению.