HIF / Документация / Доступность

Доступность и инклюзивность HIF

Статус: нормативная основа HIF 0.5

Этот документ определяет минимальные требования к доступности и инклюзивному дизайну. Сопутствующий Реестр обеспечения доступности и соответствия задаёт доказательства, необходимые для заявления о выполнении контракта.

1. Основная позиция

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

Инвалидность рассматривается во взаимодействии человека и среды. Ограничение может быть:

постоянным;
временным;
ситуативным;
созданным самим интерфейсом.

2. Базовый нормативный уровень

Для веб-интерфейсов целевым минимумом является уровень AA стандарта WCAG 2.2.

Для нативных интерфейсов и интерфейсов операционных систем применяются эквивалентные требования к:

программной семантике;
клавиатурному и альтернативному вводу;
фокусу;
масштабированию;
контрасту;
API ассистивных технологий;
субтитрам и альтернативным форматам;
обозначению ошибок;
документации.

WCAG не покрывает все когнитивные, нейроразнообразные и доменные потребности. Формальное соответствие не заменяет исследование.

3. Воспринимаемость

3.1. Текст

Текст MUST поддерживать увеличение.
Перекомпоновка MUST сохранять содержание и функции в заявленных пределах.
Длина строки, межстрочный интервал и расстояние между элементами SHOULD поддерживать длительное чтение.
Текст в изображениях MUST NOT использоваться там, где возможен настоящий текст, кроме логотипов и необходимых артефактов.

3.2. Цвет и контраст

Текст и значимая графика MUST иметь достаточный контраст.
Фокус и границы элементов управления должны быть видимы во всех состояниях.
Цвет MUST NOT быть единственным каналом передачи смысла.
Принудительные системные цвета MUST поддерживаться либо иметь равноценную адаптацию.

3.3. Медиа

Значимое изображение имеет текстовую альтернативу.
Видео с речью требует субтитров в применимом контексте.
Информация, представленная только звуком, требует альтернативы.
Автоматически воспроизводимые медиа не должны неожиданно мешать работе.

3.4. Движение и мигание

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

4. Управляемость

4.1. Клавиатура

Вся основная функция доступна с клавиатуры:

достижимые элементы управления;
видимый фокус;
предсказуемый порядок;
отсутствие ловушек клавиатурного фокуса;
корректная работа составных виджетов;
возвращение фокуса после закрытия временных слоёв.

4.2. Указатель и сенсорный ввод

Цели касания имеют достаточный размер и расстояние между собой.
Перетаскивание имеет альтернативу.
Наведение не является единственным способом доступа.
Жест с заданной траекторией имеет простую альтернативу, если жест не является самой задачей.
Действие не должно неожиданно срабатывать при нажатии указателя, если человеку нужна возможность отменить.

4.3. Ограничения времени

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

4.4. Голосовое управление и речевой ввод

Видимая подпись и доступное имя SHOULD совпадать или начинаться одинаково, чтобы человек мог назвать элемент управления.

5. Понятность

5.1. Согласованность

Одинаковая функция имеет устойчивое имя и положение в пределах контекста. Неожиданное изменение контекста не происходит только из-за получения фокуса или ввода данных.

5.2. Инструкции

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

5.3. Ошибки

Ошибка обозначается текстом.
Связанное поле программно определяется.
Предлагается исправление, когда оно известно.
Корректные данные сохраняются.

5.4. Когнитивная доступность

Интерфейс SHOULD:

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

6. Надёжность

6.1. Семантика

Каждый интерактивный элемент имеет:

роль;
доступное имя;
значение и состояние;
связи с другими элементами;
поддерживаемые действия.

В первую очередь используется нативная семантика. ARIA не добавляет поведение и не исправляет неверную модель клавиатурного взаимодействия.

6.2. Ассистивные технологии

Профиль продукта определяет матрицу поддержки:

программы экранного доступа;
увеличение экрана;
голосовое управление;
управление переключателями;
режим высокой контрастности;
дисплеи Брайля;
платформенные API доступности.

«Работает с ARIA» не является достаточным заявлением.

7. Пользовательские настройки

Система SHOULD уважать:

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

Настройка продукта не должна скрытно отменять более приоритетную системную настройку доступности.

8. Локализация и интернационализация

Доступность включает язык и культуру:

корректные метаданные языка;
правильное произношение программой экранного доступа;
письмо справа налево;
plural forms;
форматы дат, чисел и единиц измерения;
расширение строк;
редакторы методов ввода (IME) и составной ввод;
чтение смешанного программного кода и естественного языка.

9. Доступная аутентификация

Аутентификация не должна требовать:

запоминания или транскрипции без альтернативы;
проверки когнитивных функций как единственного пути;
сложного моторного действия;
недоступной CAPTCHA.

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

10. Документация и поддержка

Документация основной функции MUST быть доступна. Она SHOULD описывать:

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

Процесс поддержки является частью доступности.

11. Исследование

Люди с инвалидностью участвуют в исследовании не только в финальной приёмке. Нужны:

репрезентативные задачи;
реальные ассистивные технологии;
разные уровни опыта;
конфиденциальность и достойная компенсация;
отсутствие требования раскрывать диагноз без необходимости.

Нельзя экстраполировать опыт одного участника на всю группу.

12. Проверка

Минимальный набор:

проверка семантики;
работа только с клавиатуры;
проверка фокуса и масштаба;
проверка контраста и принудительных системных цветов;
проверка уменьшенного движения;
автоматическое сканирование;
сценарии с программами экранного доступа;
альтернативные способы работы с указателем;
проверка содержания и ошибок;
пользовательская проверка соразмерно риску.

Автоматическое сканирование обнаруживает только часть барьеров.

13. Исключения

Исключение из требований доступности MUST содержать:

затронутую функцию;
группу пользователей;
причину;
риск;
доступную альтернативу;
ответственного;
срок пересмотра.

Ссылка на «техническую сложность» без анализа альтернатив не является достаточным обоснованием.

14. Область инклюзивности

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

Процесс проектирования MUST учитывать как минимум:

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

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

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

15. Стандарты и правовые профили

15.1. Техническая цель по умолчанию

Техническая основа HIF для веб-интерфейсов по умолчанию — WCAG 2.2 уровня AA с проверкой всех применимых критериев успеха и требований к соответствию. Выбранные критерии уровня AAA и руководство W3C по когнитивной доступности SHOULD применяться, когда они отвечают выявленным потребностям пользователей.

Уровень AA WCAG — нижняя граница, а не полное определение инклюзивного продукта. Сам по себе он не устанавливает соответствие каждому закону, требованию к нативному программному обеспечению, закупочной спецификации или договорному обещанию.

Для более широкой ICT- и организационной практики профили SHOULD учитывать:

ISO/IEC 40500:2025, публикацию WCAG 2.2 в ISO;
ISO 9241-171:2025, доступность программного обеспечения;
ISO/IEC 30071-1:2019, организационную практику доступности и разработку инклюзивных ИКТ;
EN 301 549 V3.2.1, когда применимы его область ИКТ или правовой статус.

15.2. Реестр юрисдикций

Каждый профиль продукта MUST фиксировать:

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

Отдельно рассматриваются, например:

обязанности государственного сектора Великобритании по сайтам и приложениям, Equality Act 2010 или Disability Discrimination Act 1995 в Северной Ирландии;
Директива ЕС о доступности веб-сайтов и European Accessibility Act;
разделы II и III ADA США, Section 508 и право штатов;
отраслевые правила для транспорта, финансов, связи, образования, здравоохранения, занятости и терминалов самообслуживания.

HIF использует более новую техническую основу там, где это возможно, но MUST NOT скрыто подменять точную версию, включённую в применимый закон или договор.

15.3. Зависящие от времени правовые факты

Правовой реестр нельзя переносить в новый выпуск без проверки. По состоянию на 30 июля 2026 года:

руководство правительства Великобритании указывает уровень AA WCAG 2.2 и заявление о доступности как основу публичных сайтов и приложений;
Директива ЕС о доступности веб-сайтов сейчас связывает презумпцию соответствия с гармонизированным EN 301 549 V3.2.1; более новый проект стандарта не становится юридически равнозначным только из-за своего существования;
European Accessibility Act применяется к определённым продуктам и услугам, выводимым на рынок или оказываемым после 28 июня 2025 года, с учётом его области действия и национальной имплементации;
действующее правило раздела II ADA США для веб-сайтов и мобильных приложений указывает уровень AA WCAG 2.1; перед заявлением необходимо проверить актуальные сроки и исключения;
федеральный раздел 508 США содержит требования за пределами веб-содержания и использует собственную нормативно включённую версию WCAG.

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

16. Заявление о соответствии и его границы

Заявление о соответствии WCAG относится к полным веб-страницам и полным процессам, а не к выбранным компонентам или успешному результату сканера. Реестр MUST определять:

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

Формулировки «вдохновлено WCAG», «готово к ARIA», «прошло Lighthouse», «совместимо с программами экранного доступа» и «есть доступная тема» не являются заявлениями о соответствии.

Оценка выборки MAY обосновывать ограниченный вывод о выборке. Его MUST NOT обобщать на весь сайт, если метод выборки и полная оценка соответствия не обосновывают такой вывод.

17. Матрица ассистивных технологий

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

операционная система и версия
+ браузер или среда выполнения приложения и версия
+ ассистивная технология и версия
+ устройство ввода или вывода
+ язык и значимые настройки

Возможные сочетания включают VoiceOver на платформах Apple, TalkBack и Switch Access на Android, Narrator на Windows, а также распространённые сторонние программы экранного доступа там, где их требует аудитория. Упоминание в этом списке не делает каждое сочетание обязательным.

Матрица MUST покрывать релевантные продукту возможности:

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

Эмуляция MAY помогать отладке, но MUST NOT быть единственным доказательством для требуемого сценария на реальном устройстве с ассистивной технологией.

18. Контракт невизуального интерфейса

Доступное представление является самостоятельным интерфейсом. Оно MUST передавать задуманные:

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

Только визуальная близость MUST NOT передавать обязательную связь. DOM, семантический порядок и порядок дерева доступности MUST иметь смысл без CSS.

18.1. Критические сценарии с программами экранного доступа

Как минимум квалифицированный тестировщик выполняет репрезентативные задачи, включающие:

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

Для каждого элемента управления оценивается качество объявления, а не только наличие доступного имени. Избыточное, длинное, устаревшее или вводящее в заблуждение сообщение может быть так же вредно, как отсутствующее.

18.2. Динамические и нестандартные интерфейсы

Изменение маршрута на стороне клиента MUST восстанавливать ориентацию через заголовок страницы, заголовок раздела и осознанное управление фокусом.
Модальное окно MUST удерживать фокус во время работы, иметь доступный способ закрытия и предсказуемо восстанавливать фокус.
Динамические области MUST использоваться сдержанно и MUST NOT постоянно прерывать пользователя.
Виртуализированные списки MUST передавать положение, размер набора и рабочую модель обхода.
Canvas, WebGL, карты, диаграммы и нестандартная отрисовка MUST иметь равноценное семантическое представление, позволяющее выполнить задачу.
Нестандартные элементы управления MUST реализовывать применимый платформенный паттерн взаимодействия; добавить роль без поведения недостаточно.

19. Слабое зрение, контраст и визуальная адаптация

19.1. Увеличение и перекомпоновка

Веб-содержание MUST:

позволять увеличение текста минимум до 200% без потерь;
обеспечивать перекомпоновку на эталонной ширине WCAG, эквивалентной 320 CSS-пикселям, кроме содержания, которому действительно нужна двумерная компоновка;
сохранять содержание и элементы управления при масштабе 400%;
выдерживать заданные WCAG интервалы текста без обрезки или наложения;
не отключать масштабирование браузера;
не позволять закреплённым областям, уведомлениям о файлах cookie и элементам поддержки перекрывать задачу.

Нативные продукты MUST учитывать платформенные настройки размера текста и масштабирования экрана в пределах, записанных в профиле продукта.

19.2. Контраст

По WCAG 2.2 Level AA:

обычный текст требует минимум 4.5:1;
крупный текст требует минимум 3:1;
значимые нетекстовые границы, значки и состояния требуют минимум 3:1 относительно соседних цветов;
цвет MUST NOT быть единственным способом передачи смысла.

Измеряется отрисованная цветовая пара в каждом требуемом состоянии, включая наведение, фокус, выбор, содержательно значимую недоступность, проверку, перекрывающие слои, градиенты и изображения. Расчёт палитры не доказывает контраст компонента.

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

19.3. Принудительные системные цвета и высокая контрастность

Тёмная тема не является режимом высокой контрастности. Собственная высококонтрастная тема не заменяет уважение к настройкам операционной системы.

При активных принудительных системных цветах:

семантическая структура и границы элементов управления остаются видимыми;
предпочтительны системные цвета;
фокус, выбор, отмеченное и недоступное состояния остаются различимыми;
смысловые значки остаются воспринимаемыми;
фоновые изображения и тени не являются единственными носителями информации;
forced-color-adjust: none используется только для доказанной потребности доступности и с явно заданным альтернативным оформлением.

Там, где позволяет поддерживаемая платформа, тестируется минимум одна светлая и одна тёмная пользовательская контрастная палитра. Нормативное поведение в вебе определено в CSS Color Adjustment Level 1.

20. Слух, речь и медиа

Предварительно записанная речь и смысловой звук требуют синхронизированных субтитров там, где этого требует применимый критерий.
Прямые трансляции требуют субтитров в реальном времени, если этого требует профиль.
Субтитры обозначают говорящих и смысловые неречевые звуки.
Существенная визуальная информация требует тифлокомментария или допустимой равноценной альтернативы.
Информация только в аудио- или видеоформате требует применимой альтернативы.
Расшифровка поддерживает поиск, перевод, вывод на дисплей Брайля и чтение в своём темпе, но автоматически не заменяет обязательные субтитры или тифлокомментарий.
Перевод на жестовый язык определяется потребностью аудитории и применимым уровнем или законом; он не считается взаимозаменяемым с письменными субтитрами.
Оповещения, проверка и поддержка MUST NOT зависеть только от слуха или речи.
Элементы управления медиа доступны с клавиатуры и ассистивных технологий, а представление субтитров остаётся адаптируемым.

21. Моторика и независимость ввода

Каждая задача MUST оставаться выполнимой без точного наведения указателя, если точность не является сущностью самой задачи.

Клавиатурное управление включает все действия, а не только достижение элементов управления.
Порядок фокуса следует логике задачи, а сам фокус остаётся видимым и не перекрытым.
Составные виджеты используют установленную внутреннюю модель клавиатурного управления.
Для многоточечных жестов и жестов с заданной траекторией есть альтернативы с одним указателем.
Перетаскивание имеет альтернативу без перетаскивания.
Активация движением имеет обычную альтернативу в виде элемента управления.
Требования уровня AA WCAG 2.2 к размеру цели проверяются вместе с расстоянием между элементами и указанными исключениями; HIF SHOULD предпочитать более крупные цели, где позволяет контекст.
Time limits удаляются, регулируются или продлеваются, если не действует исключение.
Односимвольные сочетания клавиш можно отключить, переназначить или сделать активными только при фокусе там, где это требуется.
Пользователи голосового управления могут обратиться к элементу управления словами, видимыми на экране.

Проверка с клавиатурой MUST NOT сводиться к нажатию Tab: клавиши со стрелками, Escape, Enter, пробел, платформенные клавиши навигации и команды редактирования текста проверяются согласно модели элемента управления.

22. Когнитивные, учебные и нейроразнообразные потребности

Продукт SHOULD:

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

Руководство W3C по когнитивной доступности носит информационный характер и намеренно выходит за пределы соответствия WCAG. Основанное на нём требование MUST обозначаться как требование HIF или продукта, а не ошибочно выдаваться за критерий успеха WCAG.

23. Мигание, движение и вестибулярная безопасность

Содержание MUST соответствовать применимым порогам мигания.
Необязательная анимация учитывает системную настройку уменьшения движения.
Уменьшение движения убирает крупные пространственные перемещения, параллакс, масштабирование и повторяющуюся пульсацию; одного сокращения длительности может быть недостаточно.
Движущееся, мигающее, прокручивающееся или автоматически обновляемое содержание можно приостановить, остановить или скрыть там, где это требуется.
Автоматическое воспроизведение не захватывает фокус и не создаёт неожиданный звук.
Необходимое движение имеет документированное обоснование и более безопасную альтернативу, где это возможно.

24. Инклюзивное содержание, язык и идентичность

Инклюзивный дизайн учитывает инвалидность, но не ограничивается ею.

Людей описывают терминами, которые они используют для себя.
Текст интерфейса не предполагает способности, гендер, структуру семьи, культуру, формат адреса или идентичность без причины, связанной с задачей.
Перевод, транслитерация, письмо справа налево, произношение и уровень сложности текста проверяются, а не предполагаются.
Существенная информация остаётся доступной при низкой пропускной способности и нестабильном соединении, если этого требует контекст продукта.
Настройки доступности без необходимости не раскрывают сведения об инвалидности другим пользователям, работодателям, рекламодателям или аналитическим системам.
Биометрические и опосредованные ИИ сценарии предоставляют равноценные альтернативы.

25. Контракт доступности компонента

Каждый многократно используемый компонент MUST документировать:

семантическая роль и нативный элемент
источник доступного имени
состояния, свойства и связи
модель клавиатурного и альтернативного ввода
получение, удержание, перемещение и восстановление фокуса
порядок чтения и порядок DOM
поведение при масштабировании, перекомпоновке и изменении интервалов текста
поведение контраста и принудительных системных цветов
поведение при уменьшении движения
правила объявлений и динамических областей
локализация и двунаправленное письмо
поддерживаемые сочетания ассистивных технологий
автоматические и ручные приёмочные проверки
известные ограничения и запрещённые способы применения

Компонент не бывает «доступным» независимо от содержания, композиции и контекста задачи. Одобрение компонента сокращает число повторных дефектов, но не отменяет проверку страниц и пользовательских сценариев.

26. Жизненный цикл обеспечения доступности

Доступность проверяется на каждом этапе:

Этап	Обязательное доказательство
политика и исследование	правовой профиль, риски аудитории, план участия людей с инвалидностью
содержание и дизайн	аннотированная семантика, порядок чтения, альтернативы, состояния и адаптация
разработка компонентов	семантический контракт, клавиатурные проверки, автоматические правила, визуальные адаптации
интеграция	DOM и дерево доступности, фокус, объявления, адаптивность и принудительные системные цвета
пользовательский сценарий	выполнение задач с клавиатурой и выбранными ассистивными технологиями
перед выпуском	матрица критериев с заданными границами, дефекты, исключения, пользовательская оценка и заявление
эксплуатация	канал сообщения о барьерах, срок ответа, защита телеметрии, регрессионные и периодические проверки

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

27. Критичность и приоритизация

Критичность проблемы доступности основывается на вреде пользователю, а не на визуальной заметности или уровне WCAG:

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

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

WCAG A, AA и AAA — уровни соответствия, а не критичность дефекта. Ошибка уровня A не обязательно вреднее каждой ошибки уровня AA.

28. Требования к доказательствам

Каждая выявленная проблема MUST включать:

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

Чувствительные записи и связанные с инвалидностью исследовательские данные подчиняются политике конфиденциальности, согласия и сроков хранения. Качество доказательства MUST NOT зависеть от публикации личности или диагноза участника.

29. Заявления, альтернативы и исключения

Заявление о доступности SHOULD быть легко найдено и написано для пользователей. Он указывает:

продукт и границы заявления;
стандарт и заявленный статус;
метод и дату оценки;
поддерживаемые среды;
известные ограничения простым языком;
доступные альтернативы и запланированные исправления;
доступные каналы обратной связи и срок ответа;
обязательный порядок правоприменения или эскалации.

Заявление — не рекламный знак. Формулировка «полностью соответствует» требует актуальных доказательств для заявленных границ. Известные существенные нарушения нельзя скрывать за общей декларацией о приверженности.

Альтернативный способ MUST предоставлять равноценные информацию и функции с сопоставимыми сроками, конфиденциальностью, стоимостью, надёжностью и достоинством. Номер телефона не автоматически равноценен независимой приватной онлайн-транзакции.

«Disproportionate burden», «undue burden», «fundamental alteration» и подобные исключения являются юридическими критериями. Их может заявить только уполномоченная организация после документированного анализа и, где требуется, юридического согласования.

30. Нативные и настольные интерфейсы и интерфейсы операционной системы

Доступность нативных приложений обеспечивается через платформенные API, а не через слой ARIA, имитирующий веб. Применимый профиль фиксирует, например:

UI Automation и Narrator на Windows;
API доступности Apple, VoiceOver, Voice Control и Switch Control;
семантика доступности Android, TalkBack и Switch Access;
AT-SPI и поддерживаемые ассистивные технологии в настольных средах Linux.

Нестандартно отрисованные элементы управления MUST передавать равноценные объект, имя, роль, состояние, значение, действия, границы, фокус и события. События доступности создаются при значимом для пользователя изменении состояния, а не для каждого внутреннего события реализации.

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

31. Средства создания, сгенерированное содержание и ИИ

Продукты, позволяющие людям создавать или публиковать содержание, SHOULD применять ATAG 2.0 там, где он релевантен: интерфейс создания доступен, а инструмент поддерживает создание и исправление доступного результата.

ИИ или автоматическая генерация не снимают ответственность:

сгенерированные текстовые альтернативы проверяются в контексте;
декоративное содержание не получает избыточных описаний;
сгенерированный интерфейс использует одобренные семантические компоненты;
потоковый и частичный вывод не создаёт шквал объявлений;
разговорные интерфейсы имеют неречевые способы ввода и вывода;
сводки и упрощённые версии сохраняют существенный смысл;
сгенерированные субтитры и расшифровки проверяются соразмерно риску;
для задач с серьёзными последствиями доступны сведения о неопределённости и обращение к человеку.

32. Закупки и третьи стороны

Договоры и закупочные требования MUST определять:

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

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

33. Контрольный этап доступности перед выпуском

Выпуск MUST NOT заявлять о соответствии требованиям доступности, если:

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

Для этого контрольного этапа используется Реестр обеспечения доступности и соответствия.

34. Первоисточники