Зачем это нужно: люди, стандарты WCAG, требования и бизнес-аргументы

Есть два способа испортить разговор о доступности. Первый — свести её к благотворительности: «давайте сделаем доброе дело для несчастных людей». Второй — свести к бумажке: «юристы прислали чеклист, проставим галочки до релиза». Оба неверны, и оба приводят к продукту, которым нельзя пользоваться.

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

Эта статья — фундамент всего трека: карта того, ради кого мы работаем, какие стандарты описывают «достаточно хорошо», какие законы это требуют и как объяснить необходимость работы человеку, который держит бюджет. Практика по каждому пункту — в следующих статьях; карта трека — в обзоре. Если хочется быстрого набора практических рекомендаций «прямо сейчас», на портале уже есть Гайд по accessibility — вводный свод правил для менеджеров, дизайнеров и разработчиков. Дальше мы не пересказываем его, а объясняем, откуда эти правила берутся и как их доказывать.

1. Люди: кто и как пользуется интерфейсами

Терминология, с которой стоит начать

Язык здесь — не вежливость ради вежливости, а точность. Неточные слова ведут к неточным решениям.

Важная деталь: единого «правильного» варианта нет и в сообществе. Часть людей предпочитает person-first («человек с аутизмом»), часть — identity-first («аутичный человек», «Deaf» с большой буквы как культурная идентичность). Универсальное правило: спрашивайте, как человек себя называет, и используйте это. В интерфейсных текстах — нейтральные формулировки без пафоса и жалости.

И ещё одно, о чём часто забывают: инвалидность — это не свойство человека, а результат столкновения человека и среды. Это социальная модель инвалидности (WHO ICF). Незрячий человек не «не может пользоваться сайтом» — сайт не предоставляет текстовой альтернативы. Разница принципиальная: в первой формулировке чинить нечего, во второй есть конкретный тикет.

Спектр, а не категория

Матрица выше — адаптация Microsoft Inclusive Design Toolkit. Её смысл: интерфейс не знает и не может знать, почему человек не попадает по мелкой кнопке. У него тремор, гипс или он держит ребёнка на руках в трясущемся автобусе — техническое решение одно: цель размером не меньше 24×24 CSS-пикселей.

Отсюда практический вывод, который стоит запомнить дословно: вы проектируете не для «инвалидов», вы убираете барьеры. Убранный барьер работает на всех. Субтитры смотрят в метро без звука. Клавиатурная навигация ускоряет работу оператора колл-центра. Высокий контраст спасает на солнце. Простой язык помогает человеку, который читает на неродном языке.

По оценке ВОЗ, около 16% населения мира — 1,3 млрд человек — живут со значимой инвалидностью. Это не «маргинальный сегмент», а каждый шестой. Плюс временные и ситуативные ограничения, которые в течение года случаются практически со всеми.

Как это выглядит технически

Ключевая ментальная модель: скринридер не «читает экран». Он читает дерево доступности — отдельную структуру, которую браузер строит из DOM параллельно с деревом рендеринга. У каждого узла есть роль (что это), доступное имя (как называется), состояние и значение.

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

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

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

• По заголовкам. Клавиша H в NVDA/JAWS, ротор в VoiceOver. По данным опросов WebAIM, заголовки — самый частый способ сориентироваться на незнакомой странице. Отсюда цена бага «h3 идёт после h1»: это как оглавление с перепутанными номерами глав.
• По ориентирам (landmarks): D в NVDA. header, nav, main, footer, aside, search. Один прыжок вместо тридцати Tab через меню.
• По спискам элементов. NVDA+F7 открывает диалог со списком всех ссылок / заголовков / кнопок страницы. Здесь становится видно, почему двадцать ссылок «Подробнее» бесполезны: в списке они выглядят как двадцать одинаковых строк.
• По полям формы. F — следующее поле ввода. Поле без label озвучится как «правка, пусто» — угадывайте, что вводить.
• Режим просмотра и режим форм. У десктопных скринридеров два режима. В режиме просмотра буквы — это команды навигации; при попадании в поле ввода включается режим форм, и буквы снова становятся буквами. Кастомный компонент, который «съедает» клавиши, ломает переключение — типичная причина «не могу ничего ввести».

Речь идёт быстро: опытные пользователи ставят скорость синтеза в 400–500 слов в минуту, вдвое-втрое выше комфортной для новичка. Это тоже про уважение к времени: лишние «нажмите здесь», «изображение изображения», зачитывание длинных URL — это буквально украденные секунды на каждом элементе.

2. Проверка за пять минут: сделайте прямо сейчас

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

Шаг 1. Только клавиатура. Уберите руку с мыши совсем. Пройдите Tab по странице от начала до конца. Вопросы: видно ли, где фокус, на каждом шаге? Совпадает ли порядок обхода с визуальным? Можно ли открыть меню и закрыть его по Esc? Можно ли выйти из модалки? Не проваливается ли фокус в скрытый оффскрин-блок? Это две минуты и обычно половина всех находок. Подробности — в статье Клавиатура и фокус.

Шаг 2. Масштаб. Ctrl + + до 200% — по WCAG 1.4.4 текст должен увеличиваться вдвое без потери контента и функциональности. Затем 400% при ширине окна 1280px, что эквивалентно 320 CSS-пикселей — критерий 1.4.10 Reflow запрещает появление скролла в двух направлениях одновременно. Липкие шапки, съедающие пол-экрана, и таблицы с min-width ловятся именно здесь.

Шаг 3. Структура. Быстрый скрипт в консоли DevTools:

// Выводит план документа: уровни заголовков и их текст.
// Красным помечены пропуски уровней — они ломают навигацию по H.
let prev = 0;
document.querySelectorAll('h1,h2,h3,h4,h5,h6').forEach((h) => {
  const level = Number(h.tagName[1]);
  const skip = prev && level > prev + 1;          // с h2 сразу на h4 — пропуск
  console.log(
    `%c${'  '.repeat(level - 1)}h${level}: ${h.textContent.trim().slice(0, 70)}`,
    skip ? 'color:#c0392b;font-weight:bold' : 'color:inherit',
  );
  prev = level;
});

Шаг 4. Автопроверка. Расширение axe DevTools или вкладка Lighthouse → Accessibility. В CI это одна команда:

# разовая проверка URL без установки
npx @axe-core/cli https://example.com --tags wcag2a,wcag2aa,wcag22aa

# набор страниц по конфигу, удобно для смоука в пайплайне
npx pa11y-ci --sitemap https://example.com/sitemap.xml

Важно честно понимать предел: автоматические проверки ловят по разным оценкам от трети до половины реальных проблем — они видят отсутствующий alt, но не видят, что alt="изображение123"; видят низкий контраст, но не видят, что порядок фокуса абсурден. Ноль ошибок в axe не означает доступный продукт. Подробно — в статье Тестирование и процесс.

Шаг 5. Три минуты со скринридером. Не «научиться», а почувствовать.

Совет для зрячего разработчика: в NVDA включите Speech Viewer (меню NVDA → Tools → Speech Viewer) — окно, где текстом печатается всё, что произносится. Это снимает главный барьер: можно читать глазами то, что слышит пользователь, и сразу видеть «кнопка, кнопка, кнопка» вместо осмысленных имён.

3. Стандарты: карта территории

WCAG: как устроен стандарт

WCAG (Web Content Accessibility Guidelines) — рекомендация W3C, де-факто единственный международный технический стандарт доступности веб-контента. Действующая версия — WCAG 2.2, получившая статус W3C Recommendation в октябре 2023 года: www.w3.org/TR/WCAG22/.

Иерархия строгая и полезная:

1. 4 принципа (POUR) — рамка, а не требования:
   • Perceivable (воспринимаемость) — информация должна быть представлена так, чтобы её можно было воспринять; если контент только визуальный, у него есть текстовая альтернатива.
   • Operable (управляемость) — интерфейсом можно управлять; в первую очередь — с клавиатуры, без ловушек и без жёстких таймаутов.
   • Understandable (понятность) — текст читаем, поведение предсказуемо, ошибки объяснены.
   • Robust (надёжность) — контент корректно интерпретируется браузерами и вспомогательными технологиями, в том числе будущими.
2. 13 руководств — цели («1.4 Различимость», «2.4 Навигация»).
3. 86 критериев успеха — единственное, что реально проверяемо: 31 на уровне A, 24 на AA, 31 на AAA. Формулируются так, чтобы ответ был «да» или «нет» и не зависел от технологии.
4. Understanding и Techniques — информативные (необязательные) документы: зачем критерий нужен, какие приёмы его удовлетворяют, какие типичные ошибки его нарушают. Techniques — не закон: критерий можно выполнить и другим способом.

Различие нормативного и информативного важно на практике. Аудитор проверяет критерии, а не техники. «Мы не использовали технику H37, значит нарушение» — некорректный вывод; корректный — «у изображения нет доступного имени, нарушен 1.1.1».

Уровни A, AA, AAA

Ключевое: уровни кумулятивны. «Соответствие AA» = все критерии A и AA, то есть 55 критериев. И ещё одна ловушка формального соответствия — условия соответствия (conformance requirements) из раздела 5 WCAG: соответствие определяется для полных страниц и полных процессов. Доступная карточка товара при недоступном шаге оплаты — нулевое соответствие для процесса покупки, как бы ни выглядел отчёт по отдельным страницам.

Что нового в WCAG 2.2

Девять новых критериев, все — про реальные боли, которые накопились за годы:

Одновременно из стандарта убран критерий 4.1.1 Parsing: современные парсеры устойчивы к невалидному HTML, и требование стало избыточным. Это редкий и полезный сигнал: стандарт живой, а не свод догм.

Отдельно про 3.3.8 — это тот случай, когда критерий бьёт по устоявшейся практике. Запрет paste в поле кода из SMS, «введите 3-ю и 7-ю букву кодового слова», картинка-капча без альтернативы — всё это нарушение AA с 2023 года. И это правильно: такие механизмы отсекают не ботов, а людей с нарушениями памяти и внимания.

Разбор одного критерия целиком

Возьмём 2.5.8 Target Size (Minimum) и посмотрим, как читать критерий, чтобы не наделать ошибок.

Текст критерия: размер цели для указательного ввода — не менее 24×24 CSS-пикселей, кроме случаев:

• Spacing — цель меньше, но вокруг неё достаточно пустого места: в круг диаметром 24px, центрированный на цели, не попадают другие цели;
• Equivalent — то же действие доступно другой целью нужного размера на той же странице;
• Inline — ссылка внутри строки текста (иначе пришлось бы ломать типографику);
• User agent control — размер задаёт браузер, а не автор (нативный чекбокс);
• Essential — размер существенен для смысла (точка на интерактивной карте).

/* Плохо: иконка 16×16 в шапке — цель 16×16 */
.icon-btn { padding: 0; width: 16px; height: 16px; }

/* Хорошо: визуально та же иконка, но цель нажатия 24×24 и больше.
   Обратите внимание: увеличиваем именно область попадания, а не рисунок. */
.icon-btn {
  display: inline-grid;
  place-items: center;
  inline-size: 24px;
  block-size: 24px;
  padding: 0;
  border: 0;
  background: none;
}
.icon-btn > svg { inline-size: 16px; block-size: 16px; }

/* Ещё лучше для мобильных: 44×44 через псевдоэлемент,
   если увеличить сам блок нельзя из-за раскладки. */
.icon-btn::before {
  content: '';
  position: absolute;
  inset: 50% auto auto 50%;
  inline-size: 44px;
  block-size: 44px;
  translate: -50% -50%;
}

Что здесь показательно: критерий не говорит «сделайте кнопки больше». Он говорит «обеспечьте попадание», и исключения дают легальные способы это сделать без переделки дизайна. Именно поэтому читать нужно Understanding-документ, а не пересказ в блоге. И да, в мобильных гайдлайнах Apple и Google цифра больше — 44×44pt и 48×48dp; WCAG задаёт минимум, а не идеал.

ARIA и остальная семья

WAI-ARIA (Accessible Rich Internet Applications, версия 1.2 — Recommendation с 2023 года) — не альтернатива HTML, а набор атрибутов для случаев, когда нативного элемента не существует: role, aria-* свойства и состояния. Правило номер один в ARIA in HTML звучит буквально так: не используйте ARIA, если можно использовать нативный элемент. Подробный разбор — в статьях Семантика как фундамент и ARIA.

Рядом стоит ARIA Authoring Practices Guide (APG) — сборник готовых паттернов клавиатурного поведения для табов, комбобоксов, деревьев, модалок. Это то, что стоит открывать перед написанием любого нестандартного компонента, а не после.

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

• ATAG — требования к инструментам создания контента (CMS, конструкторы, редакторы). Если вы делаете админку, ваша обязанность — не только доступный редактор, но и помощь автору в создании доступного контента: обязательное поле alt, предупреждение о контрасте.
• UAAG — требования к браузерам и медиаплеерам.
• ACT Rules — формализованные правила автоматической проверки, чтобы разные инструменты одинаково трактовали критерии.
• PDF/UA, EPUB Accessibility — для документов и книг; напоминание, что «выложили PDF» не равно «опубликовали доступно».

Про WCAG 3.0 стоит сказать отдельно, потому что о нём часто спрашивают: это ранний черновик с принципиально другой моделью оценки (баллы и уровни Bronze/Silver/Gold вместо бинарных критериев). Он не является действующим стандартом и не заменит WCAG 2.x в ближайшие годы. Планировать соответствие нужно по WCAG 2.2 AA.

4. Требования: законы и закупки

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

• Евросоюз. European Accessibility Act (Директива 2019/882) — применяется с 28 июня 2025 года и, в отличие от прежних правил, распространяется не только на госсектор, но и на бизнес: электронную коммерцию, банковские услуги, транспортные билеты, электронные книги, телеком. Технический критерий — гармонизированный стандарт EN 301 549, который, по сути, инкорпорирует WCAG на уровне AA (сверяйтесь с актуальной редакцией на сайте ETSI — она периодически подтягивается к новым версиям WCAG). Для госсектора продолжает действовать Web Accessibility Directive 2016/2102 с обязательной публикацией «декларации о доступности».
• США. Раздел 508 Закона о реабилитации — для федеральных закупок, ссылается на WCAG 2.0 AA. ADA прямых техтребований к сайтам исторически не содержал, что породило поток судебных исков (самый известный — Robles v. Domino’s Pizza, где Верховный суд в 2019 году отказался пересматривать решение в пользу истца; ранее — NFB v. Target с урегулированием на 6 млн USD). В апреле 2024 года Минюст США выпустил финальное правило по ADA Title II, прямо закрепившее WCAG 2.1 AA для государственных и муниципальных органов со сроками соответствия в 2026–2027 годах.
• Великобритания. Equality Act 2010 плюс отдельные регламенты для публичного сектора.
• Россия. ГОСТ Р 52872-2019 «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности» — гармонизирован с WCAG/EN 301 549. Обязателен для сайтов государственных органов и учреждений, для бизнеса применяется добровольно либо через требования конкретных заказчиков в закупках.

Прикладной артефакт, который стоит знать по имени: VPAT (Voluntary Product Accessibility Template) и заполненный на его основе ACR (Accessibility Conformance Report). Это стандартная форма отчёта «какие критерии поддержаны полностью, частично, не поддержаны». В корпоративных и государственных закупках ACR требуют как обычный документ, наравне с SOC 2 в безопасности. Нет ACR — вы просто не проходите отбор, и никакой демо-звонок этого не исправит.

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

5. Бизнес-аргументы, которые выдерживают проверку

Плохой аргумент: «16% населения — это ваш потерянный рынок». Он рассыпается на первом же вопросе финдиректора, потому что не все 16% — ваша аудитория и не все барьеры блокируют конверсию. Хорошие аргументы конкретнее.

1. Прямая потеря выручки, измеримая на своих данных. Не берите чужие проценты — посчитайте свои. Найдите в аналитике сессии с признаками вспомогательных технологий (нельзя определить надёжно и не нужно пытаться идентифицировать человека — смотрите на прокси: включённый prefers-reduced-motion, экстремальные размеры шрифта, навигация исключительно с клавиатуры, время на шаге формы в верхнем перцентиле) и сравните конверсию воронки. Британское исследование Click-Away Pound оценило «упущенную выручку» онлайн-магазинов Великобритании от покупателей с инвалидностью в 17,1 млрд GBP в год — но сила аргумента не в чужой цифре, а в вашей воронке.

2. Стоимость исправления растёт со стадией. Это классическая кривая из инженерии качества, и в доступности она особенно крутая: доступность закладывается в макет и в компонентную базу. Поменять токен фокуса в дизайн-системе — час. Найти и починить 400 мест в проде — квартал.

3. Доступность оплачивает соседние статьи бюджета. Один и тот же труд даёт несколько эффектов:

• SEO. Заголовочная структура, осмысленные тексты ссылок, alt, язык страницы, title — то же самое, что любит поисковый робот. Он тоже «незрячий пользователь».
• Тестируемость. Testing Library и Playwright ищут элементы по ролям и доступным именам: getByRole('button', { name: 'Оплатить' }). Доступная разметка автоматически даёт стабильные, не завязанные на классы тесты — см. тестирование фронтенда.
• Голос и автоматизация. Голосовое управление, автозаполнение браузера, менеджеры паролей, парсеры-агенты — все опираются на семантику и доступные имена.
• Мобильные и «плохие» условия. Размер целей, контраст, работа без наведения курсора — это ровно то, что нужно на телефоне под солнцем.

// Один и тот же селектор ролями работает и как тест, и как проверка семантики:
// если тест не находит элемент — скринридер тоже его «не видит».
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('оформление заказа доступно', async ({ page }) => {
  await page.goto('/checkout');

  // 1. Функциональная проверка через доступное имя и роль
  await page.getByRole('textbox', { name: 'Адрес доставки' }).fill('Москва');
  await page.getByRole('button', { name: 'Оплатить' }).click();

  // 2. Автопроверка правил WCAG на текущем состоянии страницы
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])
    .analyze();

  // Падаем только на серьёзных нарушениях, чтобы не заблокировать пайплайн шумом
  const serious = results.violations.filter((v) =>
    ['critical', 'serious'].includes(v.impact ?? ''),
  );
  expect(serious, JSON.stringify(serious, null, 2)).toEqual([]);
});

4. Риск и репутация. Иск, отказ в тендере, публичный разбор в соцсетях — редкие, но дорогие события. В терминах риск-менеджмента это низкая вероятность при высоком ущербе; аргумент работает так же, как аргумент про резервные копии.

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

Про виджеты-накладки

Отдельный пункт, потому что предложение приходит в почту каждому CTO: «одна строка JavaScript — и ваш сайт соответствует WCAG». Не соответствует. Накладка (overlay) работает поверх готового DOM и не может ни исправить смысл разметки, ни узнать назначение картинки, ни починить порядок фокуса; часто она вдобавок конфликтует с настоящим скринридером пользователя, у которого уже всё настроено. Сообщество разработчиков со вспомогательными технологиями сформулировало позицию в Overlay Fact Sheet — документе, подписанном сотнями специалистов, включая тех, кто сам пользуется скринридерами ежедневно. Иски к компаниям, установившим накладки, тоже существуют. Единственное честное применение такого виджета — временный костыль на время реальной работы, и то с оговорками.

6. Как это выглядит как процесс

Разовый аудит даёт список дефектов и ноль устойчивости: через два спринта регресс возвращается. Работает встраивание в обычный цикл разработки.

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

# .github/workflows/a11y.yml — базовый барьер против регресса
name: accessibility
on: [pull_request]
jobs:
  static:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22', cache: npm }
      - run: npm ci
      # eslint-plugin-jsx-a11y ловит часть ошибок ещё до сборки:
      # onClick на div, img без alt, autoFocus, некорректные role
      - run: npx eslint . --max-warnings=0
      - run: npm run build
      # axe на списке ключевых страниц: главная, каталог, карточка, корзина, оплата
      - run: npm run test:a11y

И пять пунктов в шаблон pull request — они закрывают большинство типовых регрессов:

1. Всё интерактивное достижимо и активируется с клавиатуры, фокус видно.
2. У каждого интерактивного элемента есть осмысленное доступное имя.
3. Новые цвета проверены на контраст 4.5:1 для текста и 3:1 для границ и иконок.
4. Ошибки формы связаны с полями и объявляются, а не только краснеют.
5. Изменения контента без перезагрузки объявляются (живые области) или сопровождаются переносом фокуса.

7. Мифы, которые стоит разобрать один раз

«У нас нет таких пользователей». Скорее всего, они пробовали и ушли. Аналитика показывает тех, кто дошёл; она структурно не показывает тех, кто не смог зарегистрироваться. Отсутствие сигнала здесь — не доказательство отсутствия проблемы.

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

«Доступность — это про скринридеры». Пользователи скринридеров — заметное меньшинство даже среди людей с инвалидностью. Гораздо больше людей со слабым зрением (масштаб, контраст), с моторными нарушениями (клавиатура, размер целей), с когнитивными особенностями (простой язык, отсутствие таймеров, предсказуемость).

«Мы прогнали axe, ошибок нет — значит, доступно». Автоматика проверяет то, что формализуемо. Она не скажет, что порядок обхода абсурден, что alt="картинка" бессмысленен, что модалка не возвращает фокус, что подсказка исчезает раньше, чем её успевают прочитать.

«Добавим ARIA и всё починится». Неверная ARIA хуже её отсутствия: role="button" на div обещает скринридеру поведение кнопки, которого нет. Плохая ARIA — это ложь машине, которую человек принимает за правду.

«Доступность мешает дизайну». Мешает не доступность, а привычка к серому тексту 12px на белом фоне. Контраст, читаемые размеры и заметный фокус — это ограничения ровно того же рода, что сетка и типографическая шкала; хорошие дизайнеры внутри ограничений работают лучше, а не хуже.

«Сначала запустимся, потом починим». Технический долг доступности накапливается быстрее любого другого, потому что распространяется через переиспользуемые компоненты: одна недоступная кнопка в дизайн-системе — это сотни дефектов в продукте.

Мини-итог

• Доступность — характеристика качества продукта, а не благотворительность и не формальность. Барьер убирается один раз и работает на всех: постоянные, временные и ситуативные ограничения требуют одних и тех же решений.
• Язык имеет значение: люди с инвалидностью — пользователи, а не объекты помощи. Барьер создаёт среда, а не диагноз, и именно среду мы чиним.
• Скринридер читает не экран, а дерево доступности через API операционной системы. Пользуются им прыжками по заголовкам, ориентирам и спискам элементов — отсюда цена структурных дефектов.
• Технический стандарт — WCAG 2.2: 4 принципа POUR, 13 руководств, 86 критериев, целевой уровень AA (55 критериев). Соответствие определяется для полных страниц и полных процессов.
• Законы (EAA в ЕС с июня 2025, ADA Title II и Section 508 в США, ГОСТ Р 52872-2019 в России) ссылаются на WCAG. В закупках это материализуется в форме отчёта ACR/VPAT.
• Пять минут ручной проверки — Tab, зум 400%, структура заголовков, axe, три минуты со скринридером — дают больше, чем час чтения теории. Автоматика ловит от трети до половины проблем, накладки-виджеты не ловят ничего.
• Бизнес-аргументы считаются на своих данных: конверсия, стоимость исправления по стадиям, побочные выгоды в SEO и тестируемости, риск в тендерах.

Источники

• WCAG 2.2 — W3C Recommendation и How to Meet WCAG — Quick Reference — нормативный текст и фильтруемый список критериев.
• WAI-ARIA 1.2 и ARIA Authoring Practices Guide — словарь ролей и готовые паттерны компонентов.
• MDN: Accessibility — практическая документация с примерами.
• WHO: Disability fact sheet — данные о распространённости.
• WebAIM Screen Reader User Survey и WebAIM Million — как реально пользуются и как реально сделано.
• Microsoft Inclusive Design Toolkit — методика спектра ограничений.
• Overlay Fact Sheet — позиция сообщества по виджетам-накладкам.
• ETSI EN 301 549 — европейский технический стандарт закупок.
• Laura Kalbag, «Accessibility for Everyone» (A Book Apart) — короткое введение для команды целиком.
• Sarah Horton, Whitney Quesenbery, «A Web for Everyone» — про проектирование, а не про код.

Что дальше

Мы разобрались, зачем и по каким правилам. Теперь — с чего всё начинается технически: 95% требований WCAG выполняются бесплатно, если использовать те теги, которые уже есть в HTML.

Семантика как фундамент: нативные элементы против div-супа