Архивная версия 2 сайта от 14 сентября 2026 г. Сохранена без изменений после доработки по ТЗ 1. Перейти к текущей версии
Доступно

Проект для обсуждения. Редакция 0.2. Сентябрь 2026 года

Методология разработки доступных сайтов

Версия: 0.2
Дата: 11 сентября 2026 года
Статус: проект для обсуждения и апробации. Документ не является утвержденным стандартом, нормативным правовым актом или доказательством соответствия законодательству.

Статус: проект для обсуждения. До утверждения методика должна пройти апробацию на действующих сайтах с участием пользователей.

1. Назначение и границы

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

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

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

  1. доступность собственного пользовательского интерфейса сайта;
  2. способность сайта создавать, принимать, преобразовывать, публиковать или экспортировать доступный контент.

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

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

2. Основания и уровни требований

В проекте различаются три слоя, которые нельзя смешивать.

2.1. Проверяемые критерии WCAG

WCAG 2.2 является Рекомендацией W3C и содержит проверяемые критерии уровней A, AA и AAA. WCAG прямо предупреждает, что даже соответствие AAA не закрывает потребности всех людей, особенно в области когнитивных, языковых и учебных особенностей. Утверждение о соответствии уровню AA возможно только при выполнении всех критериев A и AA, а также всех пяти требований к соответствию: полный уровень, полная страница, полный процесс, опора на поддерживаемые доступностью способы использования технологий и невмешательство несоответствующих технологий.

2.2. Рекомендательное руководство COGA

Making Content Usable for People with Cognitive and Learning Disabilities является W3C Working Group Note. Его цели и шаблоны дополняют WCAG и не обязательны для заявления о соответствии WCAG. В этом проекте они используются как источник требований практической когнитивной доступности: понятность, предсказуемость, профилактика ошибок, поддержка внимания, снижение нагрузки на память, помощь и персонализация.

2.3. Предложения проекта

Все требования, которые вводит эта методология сверх принятого профиля WCAG, маркируются словами «Предложение проекта». Заказчик может сделать их обязательными в техническом задании, договоре, дизайн-системе или внутреннем регламенте. Такая обязательность действует в рамках проекта и не превращает предложение в международный или российский нормативный критерий.

2.4. Российский юридический и стандартный профиль

В паспорте проекта российский профиль фиксируется отдельными строками с датой проверки применимости. Постановление Правительства РФ от 07.02.2026 № 102 действует с 01.03.2026 и образует специальный обязательный профиль для официальных сайтов государственных органов, органов местного самоуправления и подведомственных им организаций в части доступности для инвалидов по зрению. Его нельзя распространять на все сайты, другие группы владельцев или все виды ограничений без отдельного правового основания.

ГОСТ Р 52872-2019 имеет общий предмет доступности интернет-ресурсов, приложений и интерфейсов. ГОСТ Р 70176-2022 относится к доступности PDF-документов и не доказывает доступность интерфейса сайта или процесса преобразования. Соответствие PDF/A не означает соответствия PDF/UA. ГОСТ Р ИСО 21801-1-2022 дает общие руководящие указания по когнитивной доступности, но не является самостоятельным измеримым чек-листом сайта. Ни один из этих стандартов не тождественен профилю WCAG 2.2 AA, поэтому для проекта ведут раздельную трассировку.

Приказ Минтруда России от 14.11.2025 № 647н вступает в силу 01.09.2027. На дату этой версии он не действует. Его можно учитывать как будущую основу для понятных текстов, но не как действующее обязательное требование и не как замену проверке приложения к приказу после его вступления в силу.

3. Целевой профиль потребностей

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

Область потребностей Типичные барьеры Проектные ответы
Отсутствие зрения Нет текстовых альтернатив, неверный порядок чтения, неозвучиваемые статусы Семантическая структура, доступные имена и роли, текстовые альтернативы, проверка со скринридером
Слабое зрение и цветовосприятие Низкий контраст, обрезка при увеличении, смысл только цветом Контраст, масштаб и reflow, независимость от цвета, видимый фокус
Глухота и снижение слуха Смысл только в аудио, нет субтитров или расшифровки Точные субтитры, текстовая альтернатива аудио, визуальные уведомления
Ограничение движения Управление требует мыши, перетаскивания или точного попадания Полная клавиатурная работа, достаточные цели, альтернатива жестам и drag-and-drop
Речь Голос является единственным способом ввода или подтверждения Равноценный неголосовой канал, совместимость с альтернативным вводом
Внимание и сенсорная чувствительность Автозапуск, мигание, лишние уведомления, неожиданные переходы Управление движением, остановка обновлений, спокойная композиция, предсказуемость
Память и исполнительные функции Длинный процесс, повторный ввод, потеря прогресса, тайм-аут Пошаговый процесс, сохранение данных, понятный прогресс, помощь в контексте
Чтение, язык и понимание Жаргон, метафоры, сложные инструкции, перегруженные страницы Буквальный язык, короткие смысловые блоки, примеры, резюме и иллюстрации

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

4. Управление и роли

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

Один человек может совмещать роли, но решения должны оставаться различимыми. Автор компонента не закрывает собственный критический дефект без независимой проверки. Пользовательское тестирование не заменяет проверку WCAG, а проверка WCAG не заменяет пользовательское тестирование. Такой комбинированный подход соответствует позиции W3C о необходимости совмещать оценку по стандарту и исследование с пользователями: Involving Users in Evaluating Web Accessibility.

5. Процесс разработки

Этап 0. Определение области и критических процессов

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

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

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

В паспорте проекта обязательно сохраняются два разных поля:

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

Если юридический профиль ссылается на другую редакцию стандарта, команда не подменяет его WCAG 2.2. Она ведет обе трассировки и показывает различия. Добровольная цель WCAG 2.2 AA не объявляется универсальной правовой обязанностью.

Этап 1. Требования и критерии готовности

Каждое требование содержит: источник; применимость; проверяемое условие; страницы, состояния и компоненты; метод проверки; ожидаемый результат; владельца; момент проверки. Формулировка «сделать доступно» не является требованием.

Минимальный рабочий профиль обычно строится вокруг WCAG 2.2 A и AA, но окончательный профиль определяется заказчиком с учетом права и договора. Для каждого критерия команда использует нормативный текст WCAG как источник требования. Материалы Understanding WCAG и Techniques for WCAG помогают понять и реализовать критерии, но сами по себе не являются нормативными и не исчерпывают все допустимые способы.

Требования и приемочные сценарии трассируются к приложению «Протоколы проверок WCAG 2.2 A/AA». Оно содержит 55 действующих критериев A/AA, отдельные решения по применимости, прохождению, нарушению, NA и «не проверено». Удаленный 4.1.1 и критерии AAA 2.2.6 и 2.5.6 в этот профиль не входят.

Предложение проекта Для критических услуг к обязательному профилю разработки добавляются применимые шаблоны COGA, даже если они не следуют из WCAG. Отказ от конкретного шаблона COGA должен сопровождаться кратким обоснованием и результатом проверки с целевыми пользователями.

Этап 2. Информационная архитектура и пользовательские пути

Архитектура предоставляет несколько способов найти важный раздел, кроме случаев, когда страница является шагом процесса. Это поддерживает WCAG 2.4.5. Заголовки и подписи описывают тему или назначение согласно WCAG 2.4.6. Повторяющаяся навигация сохраняет порядок, а одинаковые функции идентифицируются последовательно: WCAG 3.2.3 и 3.2.4.

Предложение проекта Наиболее важные действия видны на первом осмысленном экране, путь к ним не маскируется рекламой или второстепенными карточками. Длинная задача разбивается на понятные шаги; перед началом пользователь видит требуемые данные, примерное содержание этапов и последствия отправки. Это опирается на цели COGA «помочь найти нужное», «помочь сосредоточиться» и «не полагаться на память».

Этап 3. Проектирование экранов и компонентов

Все компоненты проектируются минимум в состояниях: по умолчанию, hover, клавиатурный фокус, выбран, отключен, загрузка, успех, предупреждение и ошибка. Для модального окна, меню, вкладок, раскрывающихся блоков, автодополнения и таблиц указывается клавиатурная модель и поведение фокуса. ARIA Authoring Practices Guide можно использовать как справочник проверенных шаблонов взаимодействия, но реализация должна тестироваться в реальной технологической среде.

Ключевые ограничения дизайна:

Предложение проекта В сложных и стрессовых процессах применяется спокойная композиция: без декоративного движения по умолчанию, искусственного дефицита, давящих таймеров и конкурирующих призывов. Пользователь может скрыть второстепенный контент, остановить движение и вернуться к прерванной задаче. Это проектное применение COGA, а не отдельный критерий WCAG.

Этап 4. Контент, документы и медиа

Страница имеет корректный язык по WCAG 3.1.1, а фрагменты на другом языке обозначаются по 3.1.2. Заголовки отражают структуру, списки являются списками, таблицы имеют определимые связи заголовков и ячеек в соответствии с WCAG 1.3.1. Значимые изображения получают эквивалентную текстовую альтернативу, а декоративные не создают шума: WCAG 1.1.1.

Предложение проекта Авторы используют частые и буквальные слова, короткие предложения и отдельные инструкции, раскрывают аббревиатуры, объясняют последствия действий и дают краткое резюме длинного материала. Эти решения основаны на COGA Design Guide и проверяются с людьми, для которых понимание и память являются источником барьеров.

Записанное видео имеет точные синхронные субтитры по WCAG 1.2.2. Значимая визуальная информация передается аудиоописанием или медиальтернативой согласно применимым критериям 1.2.3 и 1.2.5. Прямой эфир сопровождается субтитрами для уровня AA по 1.2.4. Автозапуск звука и движение управляются согласно 1.4.2 и 2.2.2.

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

Этап 5. Реализация

Разработчик предпочитает нативные HTML-элементы и добавляет ARIA только для семантики, отсутствующей в выбранной технологии. Все функции доступны через клавиатурный интерфейс по WCAG 2.1.1, фокус не попадает в ловушку по 2.1.2, а порядок фокуса сохраняет смысл по 2.4.3. Видимая подпись входит в доступное имя элемента по 2.5.3.

Программно определимые имя, роль, значение и состояние обеспечиваются по WCAG 4.1.2. Сообщения о загрузке, ошибке, добавлении или завершении передаются вспомогательным технологиям без обязательного перемещения фокуса по 4.1.3. Технологическая база поддержки фиксирует версии браузеров, устройств и вспомогательных технологий, на которых проверена совместимость. WCAG требует опоры на способы использования технологий, поддерживаемые доступностью, но не задает универсальный перечень продуктов и версий: определение accessibility supported.

Формы содержат постоянные видимые подписи и необходимые инструкции по WCAG 3.3.2. Ошибка определяется текстом по 3.3.1, а известный способ исправления предлагается по 3.3.3. Для юридически значимых, финансовых и изменяющих данные операций действует проверка, подтверждение или отмена по 3.3.4. Уже введенные данные не запрашиваются повторно без предусмотренного исключения по 3.3.7. Аутентификация не должна требовать когнитивного теста без альтернативы или механизма помощи по 3.3.8.

Этап 6. Проверка и приемка

Приемка включает три независимых слоя:

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

Автоматический результат не является сертификатом и не доказывает доступность. Правила автоматической и ручной проверки должны содержать область применимости, ожидание и процедуру. Для их описания можно применять ACT Rules Format 1.1, опубликованный как Рекомендация W3C 5 февраля 2026 года.

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

Для каждого прогона фиксируются версия и сборка продукта, версия ОС, браузер и его версия, вспомогательная технология и ее версия, язык, размер viewport, масштаб, способ ввода, системные настройки движения и контраста, дата, результат и ссылка на доказательство. Название продукта без версии недостаточно.

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

Этап 7. Выпуск и поддержка

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

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

Этап 8. Дизайн-система и управление повторным использованием

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

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

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

Этап 9. Сторонние компоненты и закупка

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

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

Этап 10. Редакторский контроль

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

Для авторов создаются короткие инструкции по типам материала: новость, длинное руководство, таблица, диаграмма, форма, видео и документ. Ориентиром служат WAI Tutorials по изображениям, таблицам, структуре и формам. Перед публикацией важного материала автор проверяет линейный порядок, увеличение, ссылки, подписи и доступную версию вложения. Периодическая выборка опубликованного контента выявляет системные ошибки обучения и шаблонов.

6. Специальные случаи приемки

Динамическое окно проверяется с момента открытия до возврата в исходный контекст: доступное имя, объявление, перевод фокуса внутрь, ограничение фокуса при модальности, закрытие, возврат фокуса и отсутствие доступа к фону. Таблица проверяется и как визуальный объект, и как последовательность заголовков и ячеек. Редактор проверяется на создание доступного результата: заголовочная структура, альтернативы, язык, списки, таблицы и сохранение семантики при экспорте.

Для формы отдельно проверяются подсказка до ввода, формат, обязательность, автозаполнение, ошибка, сводка ошибок, сохранение корректных данных, повторный ввод, подтверждение и отмена. Подробные основания и примеры собраны в материалах Understanding 3.3.2, Understanding 3.3.7 и Understanding 3.3.8.

Видео проверяется на точность, синхронность и полноту субтитров, а не только на наличие дорожки. Аудиоописание должно сообщать значимую визуальную информацию, отсутствующую в основной звуковой дорожке. У плеера проверяются доступные кнопки, клавиатура, фокус, регулировка громкости, выбор дорожек и отсутствие неконтролируемого автозапуска. Практические пояснения дает раздел WAI Audio and Video Media.

7. Проверки с пользователями

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

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

Предложение проекта Цикл адаптации понятного текста включает выявление потребностей и состава команды, адаптацию, экспертную оценку с участием представителя целевой группы, переработку и дополнительное чтение другими людьми. Этот цикл использует содержание опубликованного приложения к приказу № 647н как проектную рекомендацию. Реквизиты в грифе доступного DOCX-приложения не заполнены, приказ еще не действует, а число участников такого протокола не считается достаточной исследовательской выборкой.

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

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

8. Критерии допуска релиза

Решение принимает владелец продукта по заключению специалиста по доступности и тестирования.

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

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

9. Шаблоны

9.1. Паспорт требований

Идентификатор:
Название:
Статус: WCAG / договорное / Предложение проекта
Профиль: юридически применимый / добровольный целевой
Источник и прямая ссылка:
Область применения:
Пользовательская потребность:
Проверяемое условие:
Ожидаемый результат:
Методы проверки:
Страницы, состояния, компоненты:
Ответственный:
Этап контроля:
Связанные риски и исключения:

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

Цель пользователя:
Начальная точка и предварительные условия:
Устройство и способ взаимодействия:
Шаги и ветви, включая ошибочные данные:
Ожидаемый подтвержденный результат:
Как пользователь понимает прогресс и последствия:
Возможность отмены, возврата и восстановления:
Требования WCAG:
Дополнительные предложения COGA:
Критерии успеха пользовательской проверки:

9.3. Паспорт дизайн-компонента

Компонент и версия:
Назначение:
Видимые состояния:
Доступные имя, роль, значение, описание:
Клавиатурная модель и порядок фокуса:
Поведение со скринридером и увеличением:
Контраст и размер цели:
Поведение при reflow и изменении интервалов текста:
Ошибки, статусы, загрузка:
Поддержка reduced motion и персонализации:
Примеры допустимого и недопустимого использования:
Проверенные конфигурации:
Связанные критерии и доказательства:

9.4. Лист допуска релиза

Продукт, версия, дата:
Область допуска и исключения:
Юридически применимый профиль и основание:
Добровольный целевой профиль:
Целевой профиль WCAG:
Критические процессы и результаты:
Ручная проверка:
Автоматическая проверка:
Пользовательская проверка:
Открытые дефекты по серьезности:
Риски сторонних компонентов:
Доступные каналы поддержки:
Решение: допуск / условный допуск / запрет
Ответственный за решение:
Дата повторной проверки:

9.5. Карточка поддержки

Канал и часы работы:
Доступные способы связи:
Как сообщить о барьере без использования проблемного элемента:
Какие сведения запросить у пользователя:
Срок первичного ответа:
Маршрут блокирующего обращения:
Временный доступный обходной путь:
Связанный дефект и владелец:
Дата проверки исправления с пользователем:

10. Основные источники

  1. W3C, Web Content Accessibility Guidelines (WCAG) 2.2, Recommendation от 12 декабря 2024 года.
  2. W3C, WCAG 2.2 Conformance Requirements.
  3. W3C, Making Content Usable for People with Cognitive and Learning Disabilities, Working Group Note от 29 апреля 2021 года.
  4. W3C WAI, Involving Users in Evaluating Web Accessibility.
  5. W3C, Accessibility Conformance Testing Rules Format 1.1, Recommendation от 5 февраля 2026 года.
  6. W3C WAI, Tutorials.
  7. W3C WAI, ARIA Authoring Practices Guide.
  8. Правительство РФ, постановление от 07.02.2026 № 102, действует с 01.03.2026 в пределах установленной им области.
  9. Росстандарт, официальные карточки ГОСТ Р 52872-2019, ГОСТ Р 70176-2022 и ГОСТ Р ИСО 21801-1-2022.
  10. Минтруд России, приказ от 14.11.2025 № 647н, вступает в силу 01.09.2027.

Ссылки и статусы источников проверены на дату версии документа. При пересмотре методологии их следует проверять заново.

Наверх