Методология оценки доступности цифровых ресурсов

Версия: 0.3.6
Дата: 24 сентября 2026 года
Статус: проект для обсуждения и апробации; до утверждения методика должна пройти апробацию на действующих ресурсах с участием пользователей. Документ не является утвержденным стандартом, нормативным правовым актом, сертификатом или автоматическим основанием для заявления о соответствии. Раздел о сайтах и веб-приложениях прошел внутреннюю апробацию; для электронных документов, мобильных приложений, настольного программного обеспечения, цифровых сервисов и терминалов самообслуживания изданы протоколы, но апробация не завершена (раздел 10 «Таблица готовности разделов»).

Часть I. Общая часть

Общая часть применяется к любому цифровому ресурсу независимо от готовности отраслевого раздела части II, посвященного этому ресурсу (раздел 10).

1. Назначение и принцип

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

Оценка отвечает на четыре разных вопроса:

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

Соответствие критериям не равно практической доступности для каждого человека. WCAG 2.2 (внешняя ссылка, откроется в новой вкладке) - основной стандарт для сайтов и веб-приложений (раздел А) - прямо указывает, что рекомендации не охватывают все потребности, особенно когнитивные, языковые и учебные; это ограничение относится и к иным основаниям, которые используют разделы части II. Пользовательская успешность также не доказывает формального соответствия всем критериям. Поэтому автоматическая, ручная и пользовательская оценки ведутся отдельно и сопоставляются только в заключении.

Единый процент доступности не используется ни для одного вида ресурса. Сканер не выдает сертификат. Числовой балл способен скрыть блокирующий дефект среди множества успешных проверок. WCAG-EM 2.0 (внешняя ссылка, откроется в новой вкладке) допускает агрегированный показатель только как дополнительный и предупреждает, что единой достаточно надежной метрики нет, а WCAG (Руководство по доступности веб-содержимого консорциума W3C; версия 2.2 принята как международный стандарт ISO/IEC 40500:2025, в России на основе версии 2.1 разработан ГОСТ Р 52872-2019) не предоставляет рейтинговую схему.

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

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

1.1. Область применения

Объект методологии - цифровые ресурсы: сайты и веб-приложения, электронные документы, мобильные приложения, настольное программное обеспечение, цифровые сервисы и процессы с авторизацией, терминалы самообслуживания. Общая часть (часть I) задает единые принципы оценки для любого вида ресурса; единицу оценки, порядок выборки, конфигурации и контрольный список для конкретного вида ресурса определяет соответствующий раздел части II. На дату этой версии готов и прошел внутреннюю апробацию только раздел А «Сайты и веб-приложения»; для разделов Б «Электронные документы», В «Мобильные приложения», Г «Настольное программное обеспечение», Д «Цифровые сервисы и процессы с авторизацией» и Е «Терминалы самообслуживания и киоски» изданы приложения с протоколами проверок, но апробация разделов не завершена. Полная таблица готовности - раздел 10.

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

Конкретный объект проверки - единица оценки того вида ресурса, который указан в паспорте области (раздел 3) и определен применимым разделом части II. Если один продукт представлен несколькими видами ресурса (например, сайтом, мобильным приложением, настольной версией и создаваемыми документами), каждый вид ресурса оценивается отдельно по своему разделу части II, и результат оценки одного вида не переносится автоматически на другой.

1.2. Термины и определения

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

• Цифровой ресурс - обобщающее обозначение объекта методологии: сайт и веб-приложение, электронный документ, мобильное приложение, настольное программное обеспечение, цифровой сервис или процесс с авторизацией, терминал самообслуживания; перечень разделов по видам ресурса и их готовность - раздел 10.
• Единица оценки - пара «ресурс + представление/состояние»: один URL (адрес страницы в интернете) с публичной и авторизованной ролью, открытым диалогом, ошибкой или мобильной компоновкой может давать несколько единиц (раздел А.1).
• Единица выборки - единица оценки, включенная в структурированную выборку, случайную выборку или состав полного процесса по правилам раздела А.1-А.5; к единице выборки привязывается конкретный результат проверки в реестре контрольных результатов (раздел 9.5).
• Структурированная выборка - выборка, включающая экземпляры всех выявленных общих представлений, существенных функций, типов, технологий и иных релевантных страниц (раздел А.2).
• Случайная выборка - число случайно выбранных уникальных страниц, представлений или состояний, добавляемых поверх структурированной выборки (раздел А.3).
• Полный процесс - начальная точка, все страницы и состояния основной последовательности, а также часто используемые и критичные ответвления (раздел А.4).
• Состояние - конкретное условие единицы оценки: роль, ошибка, пустой результат, модальное окно, уведомление или иное динамическое состояние, отличное от простого URL (раздел А.1, раздел 5).
• Конфигурация - зафиксированный набор параметров прогона проверки: версия/сборка продукта, ОС, браузер, вспомогательная технология, язык интерфейса, viewport, масштаб, способ ввода и системные настройки (раздел А.6).
• Серьезность дефекта - характеристика ущерба в конкретном продукте, назначаемая независимо от уровня WCAG A, AA или AAA (раздел 6).
• Блокирующий дефект (S1) - дефект, из-за которого целевая группа не может завершить критический процесс, доступного обхода нет, есть риск безопасности или необратимой потери (раздел 6).
• Предложение проекта - отдельная метка авторского, не нормативного элемента методологии; такой элемент не входит в обязательные требования WCAG, если заказчик не сделал его договорным условием (раздел 2).
• Юридически применимый профиль - профиль требований с проверенным основанием, редакцией и датой, обязательный для ресурса в силу права или договора (раздел 3).
• Добровольный целевой профиль - профиль, принятый как ориентир сверх юридически применимого, например WCAG 2.2 AA и предложения COGA (раздел 3).
• Декларация (заявление) о доступности - публикуемое заявление о доступности сайта, входящее в перечень инвентаризации и отдельно проверяемое в заключении, если для сайта установлена обязанность его публиковать (раздел А.1, раздел 7).
• WCAG (Web Content Accessibility Guidelines) - руководство по доступности веб-контента, которое разрабатывает и сопровождает консорциум W3C (международный консорциум, разрабатывающий стандарты веба; его рекомендации применяются в России добровольно, если на них не ссылаются ГОСТ, договор или техническое задание); в этой методике используется версия WCAG 2.2.
• W3C (World Wide Web Consortium) - международный консорциум, разрабатывающий стандарты и рекомендации для интернета, включая WCAG.
• WAI (Web Accessibility Initiative) - инициатива (программа) консорциума W3C, которая ведет разработку WCAG, WAI-ARIA (спецификация консорциума W3C для разметки доступности сложных интерфейсов) и сопутствующих документов по доступности.
• WCAG-EM (WCAG Evaluation Methodology) - методика консорциума W3C для пошаговой оценки соответствия сайта требованиям WCAG; издана как документ-заметка (Note), а не как формальная Рекомендация W3C.
• COGA (Cognitive and Learning Disabilities Accessibility Task Force) - рабочая группа консорциума W3C по когнитивной доступности; выпускает рекомендательные, не обязательные дополнения к WCAG для людей с когнитивными и обучающими нарушениями.
• ACT (формат воспроизводимых правил проверки доступности, разработанный консорциумом W3C; российского аналога нет) Rules (Accessibility Conformance Testing Rules Format) - формат консорциума W3C для описания правил автоматической и ручной проверки доступности по единым, воспроизводимым критериям.
• Уровни A, AA, AAA - три ступени соответствия WCAG по возрастанию строгости требований; методика ориентируется на уровень AA, для которого должны быть выполнены все применимые критерии уровней A и AA.
• Вспомогательные технологии (АТ) - программы и устройства, которыми пользуется человек с инвалидностью для работы с ресурсом: программа экранного доступа, экранная лупа, альтернативное устройство ввода и подобные средства.
• ISO (Международная организация по стандартизации; её стандарты получают силу в России через принятие в виде ГОСТ Р ИСО с указанием степени соответствия) - Международная организация по стандартизации, издающая международные стандарты, в том числе в области доступности; сам по себе международный стандарт не является нормативным правовым актом России, пока не принят в виде ГОСТ Р либо на него не сослались договор или техническое задание. Само по себе принятие стандарта в виде ГОСТ Р или ссылка на него в договоре не делает исполнение стандарта обязательным автоматически: обязательность конкретных требований устанавливается отдельно - текстом ГОСТ Р, законом или условием договора, прямо предписывающим их соблюдение.
• ГОСТ Р ИСО - обозначение российского национального стандарта, принятого на основе международного стандарта ISO (или ISO/IEC) с указанием степени соответствия - идентичный (IDT), модифицированный (MOD) или неэквивалентный (NEQ); идентичный стандарт (IDT) означает, что текст ГОСТ Р полностью совпадает с международным.
• PDF/UA (ISO 14289-1) - международный стандарт доступного тегированного PDF-документа; в России учтен при разработке ГОСТ Р 70176-2022 (раздел Б).
• PDF/A (ISO 19005) - семейство международных стандартов PDF (формат электронного документа с фиксированным макетом страницы) для долговременного архивного хранения документов; не относится к доступности и не тождественно PDF/UA.

1.3. Нормативные ссылки

• ГОСТ Р 52872-2019 (внешняя ссылка, откроется в новой вкладке)
• ГОСТ Р 70176-2022 (внешняя ссылка, откроется в новой вкладке)
• ГОСТ Р ИСО 21801-1-2022 (внешняя ссылка, откроется в новой вкладке)
• Постановление Правительства РФ от 07.02.2026 № 102 (внешняя ссылка, откроется в новой вкладке)
• WCAG 2.2 (внешняя ссылка, откроется в новой вкладке)
• WCAG Evaluation Methodology 2.0 (внешняя ссылка, откроется в новой вкладке)

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

2. Версии источников и российский профиль

Основным стандартом проверки является WCAG 2.2 (внешняя ссылка, откроется в новой вкладке), Рекомендация W3C в актуальной публикации от 12 декабря 2024 года. Целевой уровень, обычно A или AA, задает заказчик. Для уровня AA (расширенный уровень соответствия WCAG: выше базового A, ниже максимального AAA) должны быть выполнены все применимые критерии A и AA, а не среднее или большинство.

Для организации выборки и отчета применяется WCAG Evaluation Methodology 2.0 (внешняя ссылка, откроется в новой вкладке), опубликованная 23 июля 2026 года как W3C Group Note. На дату этой версии она уже не является черновиком, однако Group Note не равна W3C Recommendation и не добавляет требований к WCAG. WCAG-EM 1.0 от 10 июля 2014 года (внешняя ссылка, откроется в новой вкладке) сохраняется как предыдущая версия и не должна ошибочно выдаваться за текущую.

Для когнитивной доступности используется Making Content Usable for People with Cognitive and Learning Disabilities (внешняя ссылка, откроется в новой вкладке). Это рекомендательное дополнение W3C, а не часть требований для соответствия WCAG. Проверки COGA в отчете получают отдельную метку «рекомендательная проверка» либо «Предложение проекта», если заказчик сделал их договорным условием.

Для описания прозрачных тестовых правил можно использовать ACT Rules Format 1.1 (внешняя ссылка, откроется в новой вкладке). Формат правила не гарантирует полноту реализации и не превращает отдельное правило в сертификат соответствия всему стандарту.

2.1. Российский профиль

Постановление Правительства РФ от 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 и на дату этой версии не действует. Размещенное DOCX-приложение имеет незаполненные реквизиты в грифе, поэтому его содержание можно использовать только как источник проектной идеи цикла адаптации понятного текста, а не как сверенный действующий нормативный текст.

3. Паспорт области оценки

Единица оценки и способ ее определения зависят от вида ресурса: для сайтов и веб-приложений это пара «ресурс + представление/состояние» (раздел А.1); для иных видов ресурсов единицу оценки, ее границы и способ инвентаризации определяет соответствующий раздел части II. Поля паспорта ниже - общие для всех видов ресурса; отраслевой раздел вправе дополнить их специфическими полями.

До проверки фиксируются:

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

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

Предложение проекта Если применимое право предусматривает исключение из требований (например, несоразмерное бремя), основание документируется в паспорте; методология такого основания не создает. Оценщик отражает в заключении сам факт заявленного исключения и не подтверждает его обоснованность как факт, а фиксирует расхождение, если заявленная причина видимо не соответствует наблюдаемой ситуации. Подход к документированному исключению описан по аналогии с финским законом о цифровых услугах (Laki digitaalisten palvelujen tarjoamisesta 306/2019, §§ 8, 10d-10e (внешняя ссылка, откроется в новой вкладке)).

Юридически применимый и добровольный профили оцениваются раздельно. Если право или договор ссылаются на иную редакцию требований, успешная проверка применимого к виду ресурса стандарта не подменяет юридический анализ, а более узкий юридический профиль не ограничивает добровольную цель. В заключении для каждого профиля приводится собственное сопоставление. WCAG 2.2 AA в этом проекте является рекомендуемой добровольной целью для сайтов и веб-приложений, пока для конкретной области не установлено иное проверенным основанием.

Если продукт представлен несколькими видами ресурса (например, сайтом, мобильным приложением, настольной версией и создаваемыми документами), паспорт составляется отдельно на каждый вид ресурса, и оценка одного вида не переносится автоматически на другой (разделы А, Б, В, Г, Д, Е части II). Способность продукта создавать доступные документы проверяется отдельно от доступности его интерфейса (раздел Б).

4. Три слоя проверки

4.1. Автоматические проверки

Автоматические средства применяются к программно определимым признакам: отсутствие доступного имени, некоторые ошибки структуры, язык документа, часть контраста, повторяющиеся идентификаторы и отдельные ARIA-состояния. Результаты перепроверяются человеком. Автоматический pass означает только отсутствие обнаруженной данным правилом ошибки в данной области.

В отчете указываются набор правил и версия, проверенные страницы и состояния, количество проверенных элементов, каждый подтвержденный дефект, ложные срабатывания и остаток, требующий ручной проверки. Повторяющийся HTML (язык разметки, из которого строятся веб-страницы) id сам по себе не означает нарушение исключенного из WCAG 2.2 критерия 4.1.1: отдельно устанавливается его влияние на применимые критерии, например 1.3.1 или 4.1.2. Автоматические результаты не смешиваются с ручными в общий процент.

4.2. Ручная проверка по стандарту

Оценщик проходит все применимые критерии целевого уровня на каждой единице выборки, проверяет полные страницы, процессы, поддерживаемые способы использования технологии и невмешательство. Повторяющийся компонент можно не анализировать заново в каждой идентичной реализации, но все отличающиеся состояния и шаблоны проверяются. Основание: пять требований к соответствию WCAG (внешняя ссылка, откроется в новой вкладке) и шаг 4 WCAG-EM 2.0 (внешняя ссылка, откроется в новой вкладке).

Предложение проекта Формула подсчета результата критерия по выборке, по аналогии с правилом портала RGAA о оценке соответствия (внешняя ссылка, откроется в новой вкладке), если заключение агрегирует несколько единиц: критерий считается выполненным на уровне выборки, только если он выполнен на всех единицах выборки, где применим; критерий считается применимым на уровне выборки, если он применим хотя бы на одной единице выборки; критерий считается неприменимым на уровне выборки, только если он неприменим на всех единицах без исключения. Формула не заменяет карточку дефекта по каждой единице (раздел 5) и применяется только для агрегированной строки реестра контрольных результатов (шаблон 9.5). Агрегированный результат критерия не отменяет и не ослабляет правила заключения раздела 7 и не влияет сам по себе на вывод о соответствии всей заявленной области.

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

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

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

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

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

Задания и правила проведения проверки с пользователями для любого вида ресурса (разделы А-Е части II) заданы в приложении «Протокол понятности и когнитивной доступности»: проверки К01-К12, согласие и остановка, карточка наблюдения, правила решения и хранения. Его результат хранится отдельно от решения о соответствии и не заменяет протоколы проверок разделов части II.

5. Доказательства и регистрация результата

Для каждого результата сохраняются:

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

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

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

6. Серьезность дефекта

Серьезность назначается независимо от уровня A, AA или AAA. Уровень WCAG отражает модель соответствия, а серьезность отражает ущерб в конкретном продукте.

Приоритет исправления учитывает серьезность, распространенность компонента, частоту процесса, число затронутых групп, цену ошибки и вероятность повторения. Массовый S3 (уровень серьёзности дефекта по шкале методики: S1 - самый тяжёлый, S4 - самый лёгкий) в общем шаблоне может иметь более высокий приоритет, чем единичный S2 на архивной странице.

Предложение проекта План исправлений фиксирует срок устранения дефекта по уровню его серьезности и согласовывает этот срок с владельцем ресурса, если иное не установлено договором или предписанием контролирующего органа: более короткий срок для S1 и S2, более длинный - для S3 и S4. Массовое S1/S2-нарушение в общем шаблоне или библиотеке компонентов не может получить более длинный срок устранения, чем аналогичное точечное нарушение. Как ориентир, а не как норму методики, зарубежные режимы мониторинга применяют сроки первой письменной реакции около 5 рабочих дней и полного устранения около 8-12 недель (Эстония, TTJA, отчет о цифровой доступности публичного сектора за 2024 год (внешняя ссылка, откроется в новой вкладке); Норвегия, Uutilsynet, порядок надзора за сайтами и приложениями (внешняя ссылка, откроется в новой вкладке); Великобритания, GOV.UK, отчет о мониторинге доступности сайтов и приложений публичного сектора за 2022-2024 годы (внешняя ссылка, откроется в новой вкладке)).

7. Правила заключения

Заключение содержит:

1. точную область, версию и период;
2. целевой профиль WCAG и дополнительные критерии;
3. метод и состав структурированной, случайной и процессной выборки;
4. конфигурации и ограничения доступа;
5. раздельные итоги автоматических, ручных и пользовательских проверок;
6. перечень дефектов по серьезности, критериям, процессам и группам потребностей;
7. ограничение вывода пределами выборки;
8. условия повторной проверки;
9. Предложение проекта. Если для сайта установлена обязанность публиковать заявление (декларацию) о доступности, отдельно проверяются его наличие, дата последнего пересмотра, соответствие заявленного статуса результатам проверки и работающий канал обратной связи. Полнота содержания заявления по установленной форме проверяется только там, где такая форма установлена правом или заказчиком. Расхождение между заявленным статусом и результатами проверки фиксируется как отдельная находка независимо от технических дефектов сайта. Подход по аналогии с проверкой декларации доступности в Финляндии (внешняя ссылка, откроется в новой вкладке) и Дании (внешняя ссылка, откроется в новой вкладке).

Предложение проекта Если заключение публикуется как заявление о соответствии профилю AA либо используется для получения знака доступности или включения в реестр, оно проходит независимое контрольное рецензирование: специалистом или организацией, не участвовавшими в основной проверке и не связанными с исполнителем и владельцем сайта, по аналогии с обязательным рецензированием BIK BITV-Test (внешняя ссылка, откроется в новой вкладке). Рецензент проверяет выборочно не менее 10% карточек результатов и все карточки дефектов уровня S1. Для приемочной проверки релиза и иных случаев, где заключение не публикуется как заявление о соответствии, достаточно второй подписи внутри команды исполнителя. Расхождения фиксируются и разрешаются до публикации заключения; если согласия достичь не удалось, в заключении сохраняются обе позиции с указанием ответственных, по аналогии с правилом раздела 5 о расхождении специалистов.

Допустимые формулировки:

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

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

Формулировка «сайт соответствует WCAG 2.2 AA» допустима только при наличии основания для всей заявленной области и выполнении всех пяти требований соответствия (внешняя ссылка, откроется в новой вкладке). По обычной выборочной оценке формулируется результат выборки, а не соответствие всего сайта. Отсутствие ошибок автоматической проверки нельзя описывать как отсутствие барьеров.

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

COGA-выводы приводятся отдельно: «соответствует предложению», «частично поддерживает», «обнаружен пользовательский барьер». Они не повышают и не понижают уровень WCAG сами по себе.

8. Повторная проверка и регрессия

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

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

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

Предложение проекта Если методика применяется как регулярный мониторинг нескольких ресурсов одного владельца или ведомства (раздел 1.1, сфера применения «регулярный мониторинг»), состав выборки ресурсов на каждый цикл строится по принципу: объем выборки цикла зависит от размера портфеля ресурсов, выборка ротируется так, чтобы часть объектов повторялась для сравнения динамики, а часть обновлялась для охвата новых зон, и ни один ресурс портфеля не остается непроверенным дольше периода, согласованного в паспорте мониторинга. Как пример такого принципа, а не как обязательная норма методики: решение Европейской комиссии (EU) 2018/1524 и практика ряда стран ЕС используют формулу «базовое число плюс надбавка на объем портфеля» и правило ротации не менее 50% новых и не менее 10% повторных объектов за цикл (Эстония, TTJA, цифровая доступность публичного сектора (внешняя ссылка, откроется в новой вкладке); Дания, Digitaliseringsstyrelsen, мониторинг и надзор (внешняя ссылка, откроется в новой вкладке); Испания, Observatorio de Accesibilidad Web, отчет о мониторинге (внешняя ссылка, откроется в новой вкладке)). Паспорт мониторинга обосновывает выбранные параметры объема и ротации для конкретного портфеля.

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

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

9. Шаблоны

Шаблоны 9.1-9.6 при оформлении пакета документов используются как приложения № 1-6 к методологии.

9.1. Паспорт оценки

Продукт и владелец:
Версия, сборка, период:
Домены и исключения:
Роли и языковые версии:
Юридически применимый профиль и основание:
Добровольный целевой профиль:
Целевой профиль WCAG:
Дополнительные требования:
Технологии и сторонние контуры:
Критические процессы:
Ограничения доступа и тестовых данных:
Версия генерального реестра, способ перечисления и дедупликация:
Размер структурированной выборки, расчет 10%, seed и дата выбора:
Ответственные лица:

9.2. Матрица покрытия

ID единицы:
URL или способ открыть состояние:
Тип: структурированная / случайная / полный процесс:
Шаблон страницы:
Функции:
Технологии:
Роль и состояние:
Фикстура, способ входа, TTL сессии и сброс:
Адаптивный вариант:
Документы и медиа:
Покрываемые критерии и конфигурации:
Причина включения:
Связанные полные процессы и состояния:

9.3. Карточка дефекта

ID и краткое название:
Серьезность и обоснование:
Источник требования и прямая ссылка:
Страница, состояние, версия:
Конфигурация:
Предварительные условия:
Фикстура, тестовая роль, способ входа и TTL:
Шаги:
Точная последовательность клавиш/жестов:
Ожидаемый результат:
Фактический результат:
Доказательство:
Влияние на пользователя:
Повторяемость и связанные страницы:
Владелец риска и срок:
Временный доступный обход:
Предлагаемый критерий приемки исправления:
Связанный компонент и объем регрессии:
Статус повторной проверки:

9.4. Пользовательский протокол

Код участника без лишних персональных данных:
Модель взаимодействия и привычная конфигурация:
Согласованные условия и формат общения:
Информированное согласие и дата:
Компенсация и условия:
Отдельное согласие на аудио/видео/экран:
Право остановиться и решение об отзыве данных:
Срок хранения и дата удаления:
Доступные условия, перерывы и поддержка:
Риск, инцидент и помощь после сессии:
Цель и начальное состояние задачи:
Наблюдаемые шаги:
Достигнутый результат:
Ошибки, возвраты, подсказки и помощь:
Понимание последствий:
Потеря данных или контекста:
Самооценка нагрузки и уверенности:
Цитата участника при согласии:
Барьер и связь с дефектом:
Статус сессии: не проводилась / завершена / остановлена

9.5. Реестр контрольных результатов

Проверка:
Критерий WCAG или предложение проекта:
Единица выборки:
Версия/сборка продукта:
ОС и версия:
Браузер и версия:
AT и версия:
Язык, viewport, ориентация и масштаб:
Способ ввода и системные настройки:
Фикстура и последовательность клавиш/жестов:
Статус:
Ожидаемый результат:
Фактический результат:
Доказательство:
Дефект:
Ссылка на вывод AT или иное доказательство:
Связанный компонент и регрессия:
Оценщик и дата:
Примечание о применимости:

9.6. Структура итогового отчета

1. Резюме для принятия решения
2. Область, версия и ограничения
3. Стандарты и дополнительные правила
4. Метод исследования и выборка
5. Конфигурации
6. Итоги автоматических проверок
7. Итоги ручных проверок
8. Итоги пользовательских проверок
9. Дефекты по серьезности и процессам
10. Матрица покрытия
11. Ограничения заключения
12. План исправлений и повторной проверки

10. Таблица готовности разделов

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

Автоматическая проверка сервиса проекта (раздел А.7, карта автоматизируемости) на дату этой версии реализована только для сайтов и веб-приложений. Для электронных документов издан воспроизводимый экспериментальный анализатор отдельных программных признаков (раздел Б.6), для мобильных приложений выполнен пробный статический разбор пакета (раздел В.6), а для цифровых сервисов - экспериментальный сценарий записи отдельных шагов, фокуса и программных сообщений (раздел Д.6). Эти средства не включены в сервис проекта, не являются обязательным автоматическим слоем и не подтверждают прохождение проверки. Для настольного программного обеспечения и терминалов самообслуживания автоматической проверки нет: оценка ведется вручную, если иное не будет отдельно объявлено при обновлении соответствующего раздела. Инструментальное измерение размеров, силы, звука и контраста терминала остается ручной проверкой и не дает автоматического статуса.

Часть II. Разделы по видам ресурсов

Каждый раздел части II применяет часть I к конкретному виду цифрового ресурса: определяет его единицу оценки, конфигурации и, где это возможно, контрольный список. Раздел, отсутствующий в этой версии в развернутом виде, все равно подчинен части I - недостает только отраслевой конкретизации (раздел 10).

А. Сайты и веб-приложения

Статус раздела: готов.

Что уже применимо из общей части. Раздел использует часть I без изменений: назначение и принцип (раздел 1), версии источников и российский профиль (раздел 2), паспорт области (раздел 3), три слоя проверки (раздел 4), доказательства и регистрацию результата (раздел 5), серьезность дефекта (раздел 6), правила заключения (раздел 7), повторную проверку и регрессию (раздел 8) и шаблоны (раздел 9). Ниже - специфика инвентаризации, выборки, конфигураций и контрольного списка для сайтов и веб-приложений.

А.1. Инвентаризация

Оценщик выявляет:

1. общие страницы и представления: главная, вход, регистрация, поиск, карта сайта, контакты, помощь, юридическая информация, заявление о доступности и обратная связь;
2. существенные функции: получение услуги, создание документа, заполнение формы, отправка, оплата, подтверждение, загрузка, публикация, восстановление доступа;
3. типы страниц и состояний: шаблоны, роли, ошибки, пустые результаты, модальные окна, уведомления, таблицы, редакторы, панели и динамические состояния;
4. технологии: HTML, CSS (язык стилей, отвечающий за оформление страницы), JavaScript, WAI-ARIA, графика, медиаплееры, форматы документов и сторонние компоненты;
5. чувствительные и высокорисковые функции: аутентификация, персональные данные, юридические и финансовые действия;
6. отличающиеся адаптивные, языковые и персонализированные варианты.

Эта схема следует этапу 2 WCAG-EM 2.0 (внешняя ссылка, откроется в новой вкладке).

До выбора образцов создается генеральный реестр области. Единицей является не только URL, но пара «ресурс + представление/состояние»: один URL с публичной и авторизованной ролью, открытым диалогом, ошибкой или мобильной компоновкой может давать несколько единиц. Реестр строится из карты сайта и маршрутов приложения, выгрузки CMS (система управления содержимым сайта), разрешенного обхода ссылок, перечня процессов и данных владельца. Для каждой единицы сохраняются стабильный ID, канонический URL или способ открытия, роль, язык, шаблон, функция, технология, состояние, дата обнаружения и источник перечисления.

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

А.2. Структурированная выборка

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

А.3. Случайная выборка

По шагу 3.2 WCAG-EM 2.0 (внешняя ссылка, откроется в новой вкладке) число случайно выбранных уникальных страниц, представлений или состояний составляет 10% от размера структурированной выборки. Они добавляются поверх нее. Если структурированная выборка содержит 80 единиц, случайная содержит 8, итог до добавления страниц полных процессов равен 88. Доля считается от структурированной выборки, а не от общего числа страниц сайта.

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

Алгоритм случайной части:

1. заморозить версию генерального реестра и структурированной выборки;
2. удалить из кандидатов все структурированные единицы и документированные дубли;
3. рассчитать 10% от числа структурированных единиц; округление вверх является Предложением проекта;
4. записать алгоритм, seed, дату и порядок исходного списка;
5. выбрать без возвращения уникальные единицы и добавить их поверх структурированной выборки;
6. сохранить выбранные и отклоненные как недоступные единицы с причиной замены;
7. если случайная часть выявила новый тип, технологию, состояние или новый класс дефекта, добавить соответствующие экземпляры в структурированную часть, пересчитать случайную часть и повторять сравнение до репрезентативности.

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

Выбор не должен подбираться вручную по удобству или меняться после просмотра результатов. Псевдослучайный алгоритм с заранее фиксированным seed допустим как предложение проекта; его воспроизводимость необходима для повтора. Генеральный список, способ его получения, алгоритм и ограничения перечисления входят в доказательства.

Предложение проекта Область проверки (раздел 3) определяет заказчик в паспорте оценки. Внутри уже согласованной области итоговый состав структурированной и случайной выборки определяет оценщик и не согласовывает его с заказчиком постранично, по аналогии с правилом BIK BITV-Test о формировании выборки (внешняя ссылка, откроется в новой вкладке). Заказчик вправе предоставить перечень критических процессов и технологий для инвентаризации (раздел А.1) и указать на объективные ограничения доступа, но не вправе исключать конкретные страницы, состояния или экземпляры из уже сформированной выборки по мотиву неудобства проверки. Любое изменение выборки по инициативе заказчика после начала проверки фиксируется отдельно с указанием инициатора и обоснования и не может привести к исключению уже выявленного дефекта из заключения.

А.4. Полные процессы и состояния

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

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

Авторизованные типовые условия проверки (в тестировании: фикстура) включают разрешенный стенд, тестовую роль и права, обезличенные данные, способ получить начальное состояние без передачи пароля оценщику, срок жизни сессии, условия MFA (многофакторная аутентификация: вход с дополнительным подтверждением, например кодом из смс) или CAPTCHA (проверка «я не робот», отличающая человека от программы), ожидаемые ответы сервера, процедуру сброса и владельца очистки. Реальные платежи, отправки заявлений и изменение чужих данных не выполняются. Записи и снимки маскируют персональные, платежные и аутентификационные данные; временные учетные записи и данные после прогона отзываются или очищаются.

WCAG 2.2 требует (внешняя ссылка, откроется в новой вкладке), чтобы при заявлении соответствия процесса все его страницы соответствовали целевому уровню. А WCAG-EM 2.0 (внешняя ссылка, откроется в новой вкладке) требует включать в выборку все единицы выбранного процесса.

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

А.5. Когда проверяется весь сайт

Полная проверка предпочтительна, если продукт мал, число представлений ограничено либо его нельзя осмысленно разделить. Выборка снижает объем проверки, но ограничивает вывод. Она не доказывает отсутствие дефектов вне проверенных единиц. WCAG-EM 2.0 (внешняя ссылка, откроется в новой вкладке) предупреждает, что по одной выборке нельзя заявить соответствие всего сайта, поскольку на непроверенных страницах могут оставаться ошибки.

А.6. Конфигурации и вспомогательные технологии

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

Предложение проекта Минимальная матрица для публичного адаптивного сайта включает:

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

Версии выбираются по реальной аудитории и фиксируются полностью. Для каждого прогона обязательны: версия/сборка продукта, ОС и версия, браузер и версия, вспомогательная технология и версия, язык интерфейса, viewport и ориентация, масштаб, способ ввода, системные настройки движения/контраста, дата, результат и ссылка на доказательство. Исключение поля допускается только с причиной. Успех в одной комбинации не переносится на все платформы. WCAG связывает «поддерживаемый доступностью» способ использования технологии с проверенной совместимостью со вспомогательными технологиями и пользовательскими агентами: определение accessibility supported (внешняя ссылка, откроется в новой вкладке).

Предложение проекта Владелец методологии ведет и обновляет не реже раза в год отдельный эталонный перечень («реестр инструментов») - конкретные версии браузеров, операционных систем и вспомогательных технологий, включая как минимум один скринридер, распространенный среди русскоязычных пользователей, которым оценщики пользуются по умолчанию при отсутствии иных указаний заказчика, по аналогии с перечнем инструментов BIK BITV-Test (внешняя ссылка, откроется в новой вкладке). Отклонение от эталонного перечня в конкретной проверке фиксируется в паспорте оценки с причиной. Перечень фиксирует среду проверки и не является рекомендацией к закупке.

А.7. Базовый набор из 34 контрольных проверок

Эти 34 пункта служат базовым маршрутом проверки частых рисков и не являются полным контрольным списком WCAG 2.2 A/AA (уровни соответствия WCAG: базовый A и расширенный AA). Для заявления о профиле AA оценщик обязан пройти все 55 действующих критериев A и AA по приложению «Протоколы проверок WCAG 2.2 A/AA» и связать каждый результат с единицей выборки, состоянием и доказательством. Исключенный критерий 4.1.1 в число 55 не входит; критерии 2.2.6 и 2.5.6 имеют уровень AAA и не входят в обязательный профиль AA.

Каждая проверка выполняется на применимых единицах выборки и состояниях. В колонке «Источник» WCAG означает проверяемое требование, COGA означает рекомендательное дополнение.

Проверка ограничения времени по WCAG 2.2.1 (внешняя ссылка, откроется в новой вкладке) выполняется отдельной карточкой полного реестра: для каждого установленного контентом лимита проверяются выключение, настройка или продление и точные исключения критерия. Сохранение введенных данных после тайм-аута является отдельным когнитивным Предложением проекта и не подменяет 2.2.1.

Пункты 32-34 выполняются по приложению «Протокол понятности и когнитивной доступности», где К01-К12 заданы как авторские сценарии. Их результат хранится отдельно от решения по 55 критериям WCAG A/AA и не повышает или не понижает уровень WCAG автоматически.

Б. Электронные документы

Статус раздела: в работе.

Что уже применимо из общей части. Назначение и принцип (раздел 1), три слоя проверки (раздел 4), доказательства и регистрация результата (раздел 5), серьезность дефекта (раздел 6), правила заключения (раздел 7) и повторная проверка (раздел 8) применяются без изменений. Паспорт области (раздел 3) дополняется реестром документов из Б.2. Шаблоны раздела 9 используются с заменой веб-специфичных полей на идентификатор файла, страницу или объект документа и конфигурацию просмотра.

Процедуры для всех контрольных проверок Б-01-Б-17 изданы в приложении «Протоколы проверок электронных документов». Базовый набор является маршрутом частой проверки, а не заявлением о полном соответствии стандарту. Юридически применимый профиль и редакции источников по-прежнему фиксируются в паспорте области.

Основания раздела:

• EN 301 549 V4.1.1, раздел 10 (внешняя ссылка, откроется в новой вкладке) распространяет требования на невеб-документы, включая загружаемые документы, связанные с веб-страницами, и не исключает документы только из-за шифрования, электронной подписи или водяного знака;
• WCAG2ICT (внешняя ссылка, откроется в новой вкладке) объясняет применение критериев WCAG 2.2 к невеб-документам и программному обеспечению. Это информативный документ W3C, а не отдельный стандарт соответствия;
• ISO 14289-1:2014 (внешняя ссылка, откроется в новой вкладке) задает применение ISO 32000-1 для доступных электронных документов PDF (PDF/UA-1). Само наличие заявления PDF/UA не заменяет наблюдаемую проверку;
• официальная карточка ГОСТ Р 70176-2022 (внешняя ссылка, откроется в новой вкладке) приводит точное название стандарта: «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Файлы формата PDF. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности». Карточка подтверждает область PDF и не используется здесь для утверждения о происхождении текста стандарта;
• техники W3C для PDF уточняют проверяемые реализации: PDF3 (внешняя ссылка, откроется в новой вкладке) для порядка чтения и обхода, PDF6 (внешняя ссылка, откроется в новой вкладке) для таблиц, PDF7 (внешняя ссылка, откроется в новой вкладке) для распознавания сканированного текста, PDF9 (внешняя ссылка, откроется в новой вкладке) для заголовков, PDF10 (внешняя ссылка, откроется в новой вкладке) и PDF23 (внешняя ссылка, откроется в новой вкладке) для форм, PDF16 (внешняя ссылка, откроется в новой вкладке) и PDF19 (внешняя ссылка, откроется в новой вкладке) для языка, PDF18 (внешняя ссылка, откроется в новой вкладке) для заголовка документа, PDF11 (внешняя ссылка, откроется в новой вкладке) для ссылок, PDF21 (внешняя ссылка, откроется в новой вкладке) для списков и PDF2 (внешняя ссылка, откроется в новой вкладке) для закладок.

Б.1. Объект и единица оценки

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

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

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

В раздел не входят интерфейс программы просмотра или редактора (раздел Г), доступность страницы до ссылки на файл (раздел А, кроме связи с альтернативой в Б-15), медиаматериал как самостоятельный объект и бумажный оригинал. Если документ встроен в страницу, сам документ проверяется по разделу Б, а оболочка, кнопки и путь получения - по разделу А. Содержимое, которое только внешне похоже на документ, но является обычной веб-страницей, проверяется по разделу А.

Б.2. Инвентаризация документов ресурса

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

Для каждого экземпляра фиксируются:

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

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

Б.3. Выборка

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

Случайная часть добавляется поверх структурированной. Ее объем равен 10% от числа единиц структурированной части с округлением вверх. Если структурированная часть содержит от 1 до 9 единиц и вне нее есть остаток, добавляется не менее одной случайной единицы. Это числовое правило и округление являются Предложением проекта по аналогии с А.3.

Воспроизводимый выбор выполняется так:

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

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

Б.4. Конфигурации и вспомогательные технологии

Перед проверкой фиксируется матрица конфигураций. Минимум включает:

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

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

Б.5. Базовый набор контрольных проверок

Б.6. Карта автоматизируемости

Автоматический результат является предварительным сигналом. Наличие тега или свойства не доказывает его смысловую правильность, а отсутствие извлекаемого признака может быть ограничением формата или анализатора. Статус «прохождение» по Б-01-Б-17 ставит оценщик после полного протокола.

Б.7. Доказательства и серьезность

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

Серьезность назначается по разделу 6 части I, а не по номеру проверки. Типичные ориентиры:

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

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

Б.8. Ограничения и переход в статус «готов»

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

Статус останется «в работе», пока одновременно не выполнены следующие условия:

1. протокол Б-01-Б-17 применен минимум двумя оценщиками к независимому корпусу PDF, документов текстового редактора, презентаций, таблиц и форм;
2. измерена согласованность результатов и устранены неоднозначные шаги;
3. ручной слой апробирован с программой экранного доступа, увеличением, высокой контрастностью и перекомпоновкой в зафиксированных конфигурациях;
4. пользовательский слой проведен с участниками, для которых документы реально являются частью задачи;
5. автоматический слой повторно проверен на размеченном эталонном наборе, опубликованы ложные срабатывания и пропуски;
6. нормативные ссылки и юридически применимые профили повторно проверены на дату выпуска.

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

В. Мобильные приложения

Статус раздела: в работе.

Что уже применимо из общей части. Назначение и принцип, версии источников, паспорт области, три слоя проверки, доказательства, серьезность дефекта, правила заключения и повторная проверка (разделы 1-8) применяются без изменений. Ниже установлена специфика мобильного приложения. Процедуры В-01-В-22 изданы в приложении «Протоколы проверок мобильных приложений».

Основания раздела: ГОСТ Р 52872-2019 (внешняя ссылка, откроется в новой вкладке), точное название которого включает приложения для стационарных и мобильных устройств и иные пользовательские интерфейсы; EN 301 549 V4.1.1, раздел 11 (внешняя ссылка, откроется в новой вкладке), который распространяет требования к невеб-программному обеспечению на мобильные приложения; WCAG2ICT (внешняя ссылка, откроется в новой вкладке) как информативное руководство по применению WCAG 2 к невеб-документам и программному обеспечению, включая мобильные приложения. WCAG2ICT не является самостоятельным стандартом соответствия и не определяет полный набор требований к продукту.

В.1. Объект и единица оценки

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

Единица выборки - экран, диалог, устойчивое состояние экрана или законченный пользовательский сценарий внутри единицы оценки, а не URL. Загрузка, ошибка, пустой результат, открытая клавиатура, системный запрос разрешения, уведомление, увеличенный текст и активное веб-представление образуют отдельные единицы выборки, если меняют доступные действия или программное представление. Результат карточки В-NN записывается для сочетания единицы оценки и единицы выборки; результат одной конфигурации, роли, языка или состояния не переносится на другую автоматически.

Гибридное приложение остается объектом раздела В. Нативный контейнер, переходы, системные диалоги и итоговое взаимодействие проверяются по В. Встроенное веб-представление не считается отдельной веб-страницей для целей EN 301 549 V4.1.1, раздел 11 (внешняя ссылка, откроется в новой вкладке), однако применимые процедуры раздела А используются для проверки семантики и поведения веб-содержимого. Результат записывается один раз по В-20 без двойного учета. Если приложение открывает самостоятельную страницу во внешней программе, страница становится отдельным объектом раздела А, а доступность перехода и возврата остается в разделе В.

Не входят в результат раздела В: доступность платформы как отдельного продукта; веб-версия сервиса; настольное приложение; содержимое загружаемого файла; аппаратные свойства устройства; качество связи, безопасность, производительность и функциональная корректность, если они не создают барьер доступности. Загружаемый документ проверяется по разделу Б, сквозной процесс с авторизацией - также по разделу Д, а внешний веб-ресурс - по разделу А. Результаты между платформами, устройствами и версиями не переносятся автоматически.

В.2. Инвентаризация экранов и состояний

До выборки составляется генеральный реестр:

1. точек входа, основных вкладок, меню, навигационных уровней и экранов;
2. ролей, учетных состояний, настроек, локалей и вариантов первого запуска;
3. пустых, загружаемых, успешных, ошибочных, автономных и восстановленных состояний;
4. форм, экранной клавиатуры, автозаполнения, поиска, фильтров и выбора данных;
5. жестов, перетаскиваний, действий движением устройства и их альтернатив;
6. системных разрешений, уведомлений, ссылок приложения, переходов во внешние средства и возврата;
7. встроенных веб-представлений, медиа, загружаемых документов и иных границ с разделами А, Б и Д;
8. настроек текста, масштаба, контраста, цвета, движения, времени и ориентации;
9. действий внешней клавиатурой, переключателями и иным альтернативным вводом;
10. критических сценариев, фоновых операций и состояний после прерывания или перезапуска.

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

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

В.3. Выборка экранов и сценариев

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

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

Предложение проекта Случайная часть добавляется поверх структурированной отдельно для каждого основного типа. Знаменатель группы - число структурированных единиц этого типа; объем равен 10 процентам знаменателя с округлением вверх. Если в структурированной части типа от 1 до 9 единиц и после исключений остается кандидат, выбирается не менее одной случайной единицы. Группа с нулевым знаменателем не формируется, а отсутствие типа проверяется как дефект инвентаризации.

Воспроизводимый выбор выполняется так:

1. заморозить версии генерального реестра, структурированной части и порядка кандидатов до просмотра результатов;
2. сохранить устойчивый идентификатор и основной тип каждой единицы, затем удалить из кандидатов структурированные единицы и документированные дубли;
3. записать для каждой группы знаменатель, расчетный объем, алгоритм псевдослучайного выбора, seed, дату и кодировку исходного списка;
4. отсортировать кандидатов по устойчивому идентификатору, перемешать выбранным алгоритмом с зафиксированным seed и выбрать без возвращения первые единицы в расчетном количестве;
5. если кандидатов меньше расчетного объема, включить весь остаток и записать нехватку; при пустом остатке случайная часть равна нулю с указанием причины;
6. недоступную единицу оставить в области со статусом «не проверено» и причиной, а замену при необходимости взять следующим элементом того же перемешанного списка; замена не снимает ограничение по недоступной единице;
7. сохранить выбранные единицы, недоступные единицы, замены и исключенные дубли; при обнаружении нового типа, состояния, функции или класса дефекта добавить его экземпляр в структурированную часть, пересчитать затронутые группы и повторять до стабильности.

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

В.4. Конфигурации

Минимальная матрица включает две распространенные мобильные платформы и встроенную программу экранного доступа каждой. Для каждой платформы проверяются: обычная конфигурация; максимальный системный размер шрифта; экранная лупа; режим высокой контрастности или инверсии, если он предусмотрен платформой; книжная и альбомная ориентации; внешняя клавиатура; управление переключателями (switch); уменьшение движения. Если сочетание не поддерживается устройством или приложением, записываются точная причина и статус «не проверено» либо NA (не применимо: критерий не относится к проверяемой странице), но оно не считается прохождением.

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

В.5. Базовый набор контрольных проверок

Предложение проекта Рекомендации выбранной платформы по целевому размеру и расстоянию между элементами фиксируются в паспорте как дополнительный профиль. Они могут быть строже В-06, но не подменяют порог, исключения и единицы WCAG 2.5.8. Статический размер в разметке является только признаком: фактическая область активации и расстояние измеряются на устройстве.

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

В.6. Карта автоматизируемости

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

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

Повторный пробный разбор трех открытых пакетов после исключения скрытых элементов, числовых значений исключения из дерева доступности и вычисляемого компоновкой размера 0dp дал 0 компоновок в одном пакете, 46 и 74 кандидата изображений в двух остальных пакетах и 0 кандидатов малой цели. Машинный сигнал полезен для отбора, но нестабилен для интерфейса, создаваемого кодом, и составных элементов. Поэтому автоматическая проверка не является обязательной частью протокола версии 0.1. Отсутствие сигнала не считается прохождением, а найденный кандидат получает результат только после ручного подтверждения.

В.7. Доказательства и серьезность

Минимальная запись содержит объект и версию, платформу и модель устройства, конфигурацию В.4, ID экрана и состояния, предусловия, действие, ожидаемый и фактический результат, фокус до и после, доступное имя и объявление, снимок экрана и ссылку на иное доказательство. Для дефекта семантики прикладывается выгрузка соответствующего фрагмента дерева доступности; для порядка и сообщения - запись озвучивания с расшифровкой; для жеста, движения, переключателя, клавиатуры, ориентации и увеличения - короткая запись последовательности. Если использован статический разбор, дополнительно записываются число найденных и декодированных компоновок, ошибки разбора и непроверенные ссылки на ресурсы. Секреты, одноразовые коды, содержимое персональных полей и лишние уведомления других приложений в доказательство не включаются.

Серьезность назначается по разделу 6 части I по наблюдаемому последствию в сценарии, а не по происхождению сигнала. Блокирующий недостижимый шаг критического сценария обычно соответствует S1 при отсутствии доступного обхода; внешний или несвоевременный обход может соответствовать S2; затруднение с надежным самостоятельным завершением - S2 или S3 по последствиям. Один общий дефект регистрируется один раз с перечнем платформ, экранов и состояний. Результат на одной платформе не снижает серьезность дефекта на другой.

В.8. Ограничения и переход в статус «готов»

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

Статус останется «в работе», пока одновременно не выполнены следующие условия:

1. В-01-В-22 применены минимум двумя оценщиками к независимым приложениям двух распространенных мобильных платформ, включая нативное и гибридное приложение;
2. проверены критические сценарии, состояния разрешения, уведомления, ошибки, прерывания и возврата, а также границы с разделами А, Б и Д;
3. ручной слой пройден в полной матрице В.4 на физических устройствах, включая обе встроенные программы экранного доступа, максимальный текст, лупу, контраст или инверсию, обе ориентации, внешнюю клавиатуру, переключатели и уменьшение движения;
4. измерена согласованность результатов оценщиков и устранены неоднозначные шаги протокола;
5. пользовательский слой проведен с людьми, для которых выбранные приложения решают реальные задачи;
6. статический анализатор и обход дерева проверены на размеченном эталонном наборе, а ложные срабатывания, пропуски и границы опубликованы;
7. нормативные ссылки, юридически применимые профили и рекомендации платформ повторно проверены на дату выпуска.

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

Г. Настольное программное обеспечение

Статус раздела: в работе.

Что уже применимо из общей части. Назначение и принцип, версии источников, паспорт области, три слоя проверки, доказательства, серьезность дефекта, правила заключения и повторная проверка (разделы 1-8) применяются без изменений. Ниже установлена специфика настольного программного обеспечения. Процедуры Г-01-Г-29 изданы в приложении «Протоколы проверок настольного программного обеспечения».

Основания раздела: ГОСТ Р 52872-2019 (внешняя ссылка, откроется в новой вкладке), точное название которого прямо включает приложения для стационарных и мобильных устройств и иные пользовательские интерфейсы; EN 301 549 V4.1.1 (внешняя ссылка, откроется в новой вкладке), где раздел 11 посвящен невеб-программному обеспечению, раздел 12 - информации о продуктах и услугах, а раздел 5.10 - средствам создания контента; WCAG2ICT (внешняя ссылка, откроется в новой вкладке) как информативное руководство по применению WCAG 2 к невеб-документам и программному обеспечению. WCAG2ICT не является самостоятельным стандартом соответствия и не определяет полный набор требований к продукту.

Г.1. Объект и единица оценки

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

Единица выборки - окно, диалог, режим или законченный пользовательский сценарий внутри единицы оценки, а не URL. Разные редакторы, рабочие пространства и режимы образуют отдельные единицы выборки, если меняют доступные функции или интерфейс. Результат карточки Г-NN записывается для сочетания единицы оценки и единицы выборки; результат одной конфигурации, роли или состояния не переносится на другую автоматически.

Для приложения, которое создает контент, оцениваются два независимых свойства: доступность собственного интерфейса по разделу Г и способность создать, проверить, сохранить и экспортировать доступный результат. Полученный файл отдельно проверяется по разделу Б. Наличие команды экспорта или встроенной проверки не доказывает доступность результата. EN 301 549 V4.1.1, раздел 5.10 (внешняя ссылка, откроется в новой вкладке) требует поддерживать создание доступного результата в пределах сведений доступности, поддерживаемых выходным форматом; сохранять такие сведения при преобразовании, когда существуют эквивалентные механизмы; предлагать исправление проблемы, которую средство способно обнаружить; при наличии шаблонов предоставлять и обозначать как минимум один шаблон, поддерживающий создание доступного контента.

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

Г.2. Инвентаризация

До выборки составляется реестр:

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

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

Г.3. Выборка сценариев

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

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

Предложение проекта Случайная часть добавляется поверх структурированной отдельно для каждого основного типа. Знаменатель группы - число структурированных единиц этого типа; объем группы равен 10 процентам знаменателя с округлением вверх. Если в структурированной части типа от 1 до 9 единиц и после исключений остается хотя бы один кандидат этого типа, выбирается не менее одной случайной единицы. Группа с нулевым знаменателем не формируется, а отсутствие типа в структурированной части проверяется как дефект инвентаризации.

Воспроизводимый выбор выполняется так:

1. заморозить версии генерального реестра, структурированной части и порядка кандидатов до просмотра результатов;
2. сохранить для каждой единицы устойчивый идентификатор и основной тип, затем удалить из кандидатов структурированные единицы и документированные дубли;
3. записать для каждой группы знаменатель, расчетный объем, алгоритм псевдослучайного выбора, seed, дату и кодировку исходного списка;
4. отсортировать кандидатов по устойчивому идентификатору, перемешать выбранным алгоритмом с зафиксированным seed и выбрать без возвращения первые единицы в расчетном количестве;
5. если кандидатов меньше расчетного объема, включить весь остаток и записать нехватку; при пустом остатке случайная часть группы равна нулю с указанием причины;
6. недоступную единицу оставить в области со статусом «не проверено» и причиной, а замену, если она нужна для выполнения объема выборки, взять следующим элементом того же перемешанного списка; замена не снимает ограничение по недоступной единице;
7. сохранить выбранные единицы, недоступные единицы, замены и исключенные дубли; если обнаружен новый тип, режим, функция, формат или класс дефекта, добавить его экземпляр в структурированную часть, пересчитать затронутые группы и повторять до стабильности.

Повторная проверка той же единицы оценки использует тот же замороженный реестр, алгоритм и seed. Новый реестр или новая версия приложения получают отдельную версию выборки; прежний результат сохраняется для сопоставления. Эти правила конкретизируют А.2-А.3, Б.3 и Д.3 для настольного программного обеспечения.

Г.4. Конфигурации

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

Минимум проверяется: управление только клавиатурой; работа с программой экранного доступа, соответствующей платформе; увеличение экранной лупой; высокая контрастность и системные цвета; увеличенный системный шрифт и масштаб. Для приложения, которое редактирует текстовые данные и передает текстовые диапазоны, минимум одна конфигурация включает брайлевский дисплей с клавишами маршрутизации. Для иных приложений брайлевский вывод, альтернативный ввод и дополнительные сочетания добавляются при наличии подтвержденной аудитории или заявленной поддержки. EN 301 549 V4.1.1, 11.5-11.7 (внешняя ссылка, откроется в новой вкладке) связывает невеб-программу с документированными службами доступности платформы, запрещает непреднамеренно нарушать их работу и требует учитывать пользовательские настройки в установленных стандартом условиях.

Г.5. Базовый набор контрольных проверок

Г.6. Карта автоматизируемости

Инспекция дерева доступности подтверждает только наблюдаемое программное представление. Она не заменяет ручную работу с клавиатурой, программой экранного доступа, экранной лупой и системными режимами. На дату версии отдельной автоматической проверки настольного ПО сервис проекта не предоставляет (раздел 10).

Г.7. Доказательства и серьезность

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

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

Г.8. Ограничения и переход в статус «готов»

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

Статус «готов» возможен после апробации Г-01-Г-29 как минимум на двух существенно разных настольных приложениях, включая средство создания контента, на двух семействах операционных систем, в том числе на применимой отечественной системе; независимого воспроизведения выборки и серьезности; проверки созданных файлов по разделу Б; устранения противоречий протокола и публикации обезличенного отчета апробации. До этого раздел имеет статус «в работе».

Д. Цифровые сервисы и процессы с авторизацией

Статус раздела: в работе.

Что уже применимо из общей части. Назначение и принцип, паспорт области, три слоя проверки, доказательства, серьезность дефекта, правила заключения и повторная проверка (разделы 1, 3-8) применяются без изменений. Раздел развивает подход части I к полным процессам (раздел А.4), включая случаи, когда процесс продолжается за пределами одного вида ресурса.

Шаблоны раздела 9 применяются к процессу с заменой адреса страницы на идентификатор процесса и варианта, роль, шаг и состояние; перечень полей записи пути и доказательств задан в Д.7. Процедуры для контрольных проверок Д-01-Д-20 изданы в приложении «Протоколы проверок цифровых сервисов». Базовый набор задает маршрут проверки процесса, но не заменяет полный применимый профиль требований для каждого сайта, документа, приложения или иного вида ресурса, включенного в процесс.

Д.1. Объект и единица оценки

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

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

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

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

Д.2. Инвентаризация и критичность процессов

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

Обязательно выявляются, если существуют:

1. вход, выход, повторный вход, восстановление доступа и подтверждение личности;
2. поиск и выбор услуги, оформление, сохранение черновика, подача и отмена заявления;
3. согласия, разрешения и изменение значимых настроек;
4. платеж, возврат, подтверждение и получение документа об операции;
5. загрузка, замена, удаление и получение документов;
6. уведомления, отслеживание статуса, исправление и обжалование результата;
7. переходы на другой сайт, в приложение, документ или канал подтверждения.

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

Д.3. Выборка процессов и состояний

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

Случайная часть добавляется поверх структурированной по правилам А.3: 10% от числа структурированных единиц, округление вверх и минимум одна единица при наличии остатка являются Предложением проекта. До выбора фиксируются версия генерального реестра, исключенные дубли, порядок списка, алгоритм и seed. Выбор выполняется без возвращения. Если случайная часть выявила новый тип процесса, состояния или перехода, он добавляется в структурированную часть, объем случайной части пересчитывается.

Выбранный процесс проверяется целиком, а не отдельным экраном. Включаются все веб-страницы основной последовательности согласно шагу 3.c WCAG-EM (внешняя ссылка, откроется в новой вкладке) и все содержимое каждой страницы согласно требованию соответствия 2 WCAG 2.2 (внешняя ссылка, откроется в новой вкладке). Предложение проекта. Для каждого применимого процесса проверяются успешный путь, пустые обязательные поля, одно неверное значение, исправление, возврат, отмена, истечение сессии, продление, повторный вход, восстановление и итоговое подтверждение. Если безопасно воспроизвести состояние нельзя, его не имитируют на действующих данных, а отмечают «не проверено» с причиной и согласованным способом будущей проверки.

Д.4. Условия проверки и конфигурации

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

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

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

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

Д.5. Базовый набор контрольных проверок

Д.6. Карта автоматизируемости

Автоматический слой применяется к каждому веб-шагу по разделу А и способен подтвердить отдельный программный признак или нарушение. Он не устанавливает, что процесс в целом понятен, безопасно завершен и доступен во всех каналах. Статус «прохождение» по Д-01-Д-20 ставит оценщик после полного маршрута.

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

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

Серьезность назначается по разделу 6 части I с учетом результата всего процесса:

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

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

Д.8. Ограничения и переход в статус «готов»

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

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

Статус останется «в работе», пока одновременно не выполнены следующие условия:

1. Д-01-Д-20 применены минимум двумя оценщиками к независимым процессам входа, восстановления, услуги, загрузки документа и юридически или финансово значимого действия на разрешенных стендах;
2. проверены успешные, ошибочные, отмененные, истекшие и восстановленные состояния, а также переходы между видами ресурса и каналами;
3. измерена согласованность результатов и устранены неоднозначные шаги протокола;
4. ручной слой пройден в матрице конфигураций Д.4, включая программу экранного доступа и альтернативный ввод;
5. пользовательский слой проведен с людьми, для которых эти процессы являются реальной задачей;
6. автоматический сценарий проверен на размеченных состояниях, а его пропуски и ложные выводы опубликованы;
7. нормативные ссылки и юридически применимые профили повторно проверены на дату выпуска.

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

Е. Терминалы самообслуживания и киоски

Статус раздела: в работе: протоколы проверок изданы (приложение, версия 0.1), апробация не завершена.

Что уже применимо из общей части. Назначение и принцип, версии источников, паспорт области, три слоя проверки, доказательства, серьезность дефекта, правила заключения и повторная проверка (разделы 1-8) применяются без изменений. Ниже установлена специфика терминала. Процедуры Е-01-Е-22 изданы в приложении «Протоколы проверок терминалов самообслуживания и киосков».

Е.1. Объект, единица оценки и единица выборки

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

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

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

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

Е.2. Инвентаризация и заморозка реестра

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

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

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

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

Е.3. Выборка операций и состояний

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

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

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

1. идентификаторы нормализуются как точные строки реестра и сортируются по возрастанию кодовых точек Unicode;
2. seed записывается как terminal:<версия-реестра>:<идентификатор-единицы-оценки>:<дата-оценки>;
3. для каждого кандидата вычисляется SHA-256 последовательности seed, LF (U+000A), идентификатор, закодированной в UTF-8 без BOM; тестовый вектор terminal:v1:unit-01:2026-09-24 + LF + операция-01 дает 29c2c1012cc84f1e9bb441900570f6e8b48bafc874e246cba1ab28cb03d77bfa;
4. кандидаты сортируются по хешу, затем по идентификатору, и берется первый без возвращения.

Если кандидатов меньше требуемого числа, берутся все и публикуются план, факт и причина нехватки. Недоступная выбранная операция не заменяется молча: ей присваивается «не проверено», затем берется следующий кандидат того же типа по уже рассчитанному порядку как дополнительная единица. Исходный знаменатель и доля покрытия не пересчитываются. Ручное добавление операции допускается только сверх выборки с причиной и не меняет случайный результат.

Е.4. Условия и безопасность проверки

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

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

Е.5. Конфигурации

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

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

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

Е.6. Базовый набор и карта автоматизируемости

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

На дату версии все двадцать две карточки имеют режим «вручную». Измерители размера, расстояния, силы, звука и контраста дают отдельные значения, а запись экрана и событий помогает собирать доказательства, но ни один инструмент не определяет применимость, не проходит физическую операцию и не присваивает итоговый статус. Автоматической проверки терминалов в сервисе проекта нет.

Для закрытых частей приоритетны требования 5.1 EN 301 549 (европейский стандарт требований доступности информационно-коммуникационных технологий; российского аналога нет). Пункты раздела 11 применяются к экранному программному интерфейсу в пределах собственных предусловий; открытая часть не исключается только потому, что находится в том же корпусе. Базовый набор задает маршрут частой проверки, а не подтверждает полный юридически применимый профиль.

Е.7. Доказательства, статусы и серьезность

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

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

Серьезность назначается по разделу 6 части I с учетом всей операции:

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

Е.8. Ограничения и переход в статус «готов»

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

Статус останется «в работе», пока одновременно не выполнены следующие условия:

1. Е-01-Е-22 применены минимум двумя оценщиками к не менее чем двум независимым моделям стационарных терминалов и всем предусмотренным типам операций;
2. проверены успешные, ошибочные, отмененные, истекшие и восстановленные состояния, отказ периферии, возврат носителя и связь с поддержкой;
3. физические размеры, сила, громкость, контраст и время измерены повторно, а расхождения оценщиков разобраны;
4. ручной слой пройден во всех конфигурациях Е.5;
5. пользовательский слой проведен с людьми, для которых выбранные операции являются реальной задачей;
6. опубликованы знаменатели, фактическая выборка, непроверенные состояния и ограничения демонстрационного или действующего стенда;
7. нормативные ссылки и юридически применимые профили повторно проверены на дату выпуска.

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

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

1. W3C, Web Content Accessibility Guidelines (WCAG) 2.2 (внешняя ссылка, откроется в новой вкладке), Recommendation от 12 декабря 2024 года.
2. W3C, WCAG 2.2 Conformance Requirements (внешняя ссылка, откроется в новой вкладке).
3. W3C, WCAG Evaluation Methodology 2.0 (внешняя ссылка, откроется в новой вкладке), Group Note от 23 июля 2026 года.
4. W3C, Website Accessibility Conformance Evaluation Methodology 1.0 (внешняя ссылка, откроется в новой вкладке), предыдущая Working Group Note от 10 июля 2014 года.
5. W3C, Making Content Usable for People with Cognitive and Learning Disabilities (внешняя ссылка, откроется в новой вкладке), Working Group Note от 29 апреля 2021 года.
6. W3C WAI, Involving Users in Evaluating Web Accessibility (внешняя ссылка, откроется в новой вкладке).
7. W3C, Accessibility Conformance Testing Rules Format 1.1 (внешняя ссылка, откроется в новой вкладке), Recommendation от 5 февраля 2026 года.
8. W3C WAI, ARIA Authoring Practices Guide (внешняя ссылка, откроется в новой вкладке).
9. W3C WAI, Tutorials (внешняя ссылка, откроется в новой вкладке).
10. Правительство РФ, постановление от 07.02.2026 № 102 (внешняя ссылка, откроется в новой вкладке), действует с 01.03.2026 в пределах установленной им области.
11. Росстандарт, официальные карточки ГОСТ Р 52872-2019 (внешняя ссылка, откроется в новой вкладке), ГОСТ Р 70176-2022 (внешняя ссылка, откроется в новой вкладке) и ГОСТ Р ИСО 21801-1-2022 (внешняя ссылка, откроется в новой вкладке).
12. Минтруд России, приказ от 14.11.2025 № 647н (внешняя ссылка, откроется в новой вкладке), вступает в силу 01.09.2027.
13. Эстония, TTJA (Департамент защиты прав потребителей и технического надзора Эстонии), «Eesti avaliku sektori digiligipääsetavus 2024. aastal» (внешняя ссылка, откроется в новой вкладке), ежегодный отчет о цифровой доступности публичного сектора.
14. Эстония, TTJA, обзор регулярного мониторинга доступности (внешняя ссылка, откроется в новой вкладке).
15. Норвегия, Uutilsynet, «Slik fører vi tilsyn med nettsteder og apper» (внешняя ссылка, откроется в новой вкладке).
16. Норвегия, Uutilsynet, «Forenklet kontroll og statusmåling med nettsteder» (внешняя ссылка, откроется в новой вкладке).
17. Великобритания, GOV.UK (портал правительства Великобритании), «Accessibility monitoring of public sector websites and mobile apps from 2022 to 2024» (внешняя ссылка, откроется в новой вкладке).
18. Франция, DINUM (Межведомственная дирекция цифровых технологий Франции), портал RGAA (французский государственный справочник доступности), «Évaluation de la conformité» (внешняя ссылка, откроется в новой вкладке).
19. Франция, DINUM, портал RGAA, «Déclaration d'accessibilité» (внешняя ссылка, откроется в новой вкладке).
20. Германия, BIK BITV-Test (DIAS GmbH, сеть BIK Prüfverbund), «Beschreibung des Prüfverfahrens» (внешняя ссылка, откроется в новой вкладке).
21. Дания, Digitaliseringsstyrelsen, «Monitorering og tilsyn» (внешняя ссылка, откроется в новой вкладке).
22. Дания, Digitaliseringsstyrelsen, «Overordnede resultater for 2024» (внешняя ссылка, откроется в новой вкладке).
23. Испания, Observatorio de Accesibilidad Web, отчет о мониторинге доступности сайтов (внешняя ссылка, откроется в новой вкладке).
24. Финляндия, закон о предоставлении цифровых услуг 306/2019 (внешняя ссылка, откроется в новой вкладке).
25. Финляндия, Traficom, порядок проверки соответствия закону о цифровых услугах (внешняя ссылка, откроется в новой вкладке).
26. ETSI (Европейский институт телекоммуникационных стандартов), EN 301 549 V4.1.1 «Accessibility requirements for ICT products and services» (внешняя ссылка, откроется в новой вкладке), разделы 5, 8, 10-12.
27. W3C, «Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT)» (внешняя ссылка, откроется в новой вкладке).
28. ISO, ISO 14289-1:2014 (PDF/UA-1) (внешняя ссылка, откроется в новой вкладке).
29. ГОСТ Р 70176-2022 (внешняя ссылка, откроется в новой вкладке) «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Файлы формата PDF. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности».
30. Банк России, информационное письмо от 29.12.2020 № ИН-01-59/184 о рекомендациях по доступности дистанционных цифровых каналов (внешняя ссылка, откроется в новой вкладке).

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

Соответствие нумерации редакции 0.2

Таблица сопоставляет нумерацию редакции 0.2 (версия от 11 сентября 2026 года, документ «Методология оценки доступности сайтов») с нумерацией этой редакции, чтобы прежние ссылки на конкретный раздел можно было найти в новой структуре. Разделы Б, В, Г, Д и Е в редакции 0.2 отсутствовали: их содержание новое, кроме раздела Д, который развивает материал прежнего раздела 4.4 (перенесен в раздел А.4 без изменений, а раздел Д написан заново).