Доступно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Критический процесс - процесс от входа до подтвержденного результата, для которого действует требование WCAG (Руководство по доступности веб-содержимого консорциума W3C; версия 2.2 принята как международный стандарт ISO/IEC 40500:2025, в России на основе версии 2.1 разработан ГОСТ Р 52872-2019) о полном процессе; примеры: регистрация, вход и восстановление доступа, поиск продукта, заполнение и отправка заявления, загрузка и подписание документа, оплата, обращение в поддержку, изменение персональных данных (этап 0).
  • Профиль потребностей - описание функций, условий использования и барьеров конкретного критического процесса, включая устройства, вспомогательные технологии, уровень цифрового опыта, язык, стрессовые условия и цену ошибки, составленное вместо перечня диагнозов (раздел 3).
  • Паспорт требований - документ, фиксирующий источник, применимость, проверяемое условие, страницы, состояния и компоненты, метод проверки, ожидаемый результат, ответственного и этап контроля для одного требования (шаблон 9.1).
  • Общий компонент - компонент дизайн-системы, у которого несколько команд продукта являются потребителями; изменение общего компонента считается изменением всех его потребителей (этап 8).
  • Дизайн-система - библиотека переиспользуемых компонентов, которая хранит требования доступности рядом с самим компонентом, а не в отдельном контрольном списке (этап 8).
  • Условный допуск - решение о выпуске при некритических отклонениях от предложений проекта, с определенными владельцем, сроком и способом информирования пользователей; не применяется к невыполненному критерию, если релиз заявляет соответствие WCAG (раздел 8).
  • Предложение проекта - требование, которое эта методология вводит сверх принятого профиля WCAG; заказчик может сделать его обязательным в техническом задании, договоре, дизайн-системе или внутреннем регламенте (раздел 2.3).
  • Юридически применимый профиль - требования, которые распространяются на конкретный сайт в силу проверенных правовых оснований, договора или закупочной документации (этап 0).
  • Добровольный целевой профиль - более высокий или широкий набор требований, который владелец принимает для развития продукта, например WCAG 2.2 AA и дополнительные предложения COGA (этап 0).
  • Доступная альтернатива - равноценный по результату способ получить контент или завершить процесс, когда основной вариант сделать доступным нельзя или пока нельзя (этапы 4 и 9, раздел 8).
  • Технологическая база - зафиксированные версии браузеров, устройств и вспомогательных технологий, на которых проверена совместимость продукта (этап 5).
  • Декларация соответствия поставщика по критериям WCAG - приложение к договору на сторонний компонент с перечнем применимых критериев целевого профиля и статусом по каждому из них (этап 9).
  • WCAG (Web Content Accessibility Guidelines) - руководство по доступности веб-контента, которое разрабатывает и сопровождает консорциум W3C (международный консорциум, разрабатывающий стандарты веба; его рекомендации применяются в России добровольно, если на них не ссылаются ГОСТ, договор или техническое задание); в этой методике используется версия WCAG 2.2.
  • W3C (World Wide Web Consortium) - международный консорциум, разрабатывающий стандарты и рекомендации для интернета, включая WCAG.
  • WAI (Web Accessibility Initiative) - инициатива (программа) консорциума W3C, которая ведет разработку WCAG, WAI-ARIA (спецификация консорциума W3C для разметки доступности сложных интерфейсов) и сопутствующих документов по доступности.
  • COGA (Cognitive and Learning Disabilities Accessibility Task Force) - рабочая группа консорциума W3C по когнитивной доступности; выпускает рекомендательные, не обязательные дополнения к WCAG для людей с когнитивными и обучающими нарушениями.
  • WAI-ARIA (Accessible Rich Internet Applications) - спецификация консорциума W3C для разметки динамичных интерфейсов (роли, состояния, свойства элементов), которая помогает работе программ экранного доступа.
  • Уровни A, AA, AAA (максимальный уровень соответствия WCAG, выше расширенного AA) - три ступени соответствия 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. Нормативные ссылки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предложение проекта Реестр требований дополнительно размечается по типу компонента или зоны интерфейса из закрытого перечня: общие компоненты дизайн-системы, шаблоны страниц, контент, документы и медиа, сторонние встраиваемые компоненты. Такая разметка не заменяет привязку к конкретному критерию WCAG и не применяется к требованиям, которые относятся ко всему сайту целиком, а не к отдельному типу компонента. Она позволяет дизайнеру на этапе 3 и разработчику на этапе 5 видеть только тот срез реестра, который относится к их текущей задаче, вместо единого монолитного списка требований. Источник модели: Digital Service Standards Control Catalog и Accessibility Checklist государственного цифрового агентства Сингапура GovTech, где каждый пункт размечен типом компонента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предложение проекта Проверка понятности текста для критического процесса ориентируется не только на формальные признаки текста (длина предложения, число слогов), но и на прямой критерий успеха читателя: нашел нужную информацию, правильно понял ее и смог применить для завершения задачи. Формальные метрики читаемости используются как ориентир для автора при написании, а не как самостоятельное доказательство понятности при приемке. Результат такой проверки документируется как находка с указанием задачи пользователя и конкретного вопроса или места текста, на котором читатель споткнулся. Модель критерия описана в изложении Австралийской комиссии по правам человека о национальном стандарте простого языка AS ISO 24495.1:2024 (AHRC, «Standards and guidelines for digital accessibility»); прямая страница стандарта ISO 24495-1 на iso.org на момент подготовки правки не открылась, поэтому первоисточником служит это изложение, а не текст самого стандарта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предложение проекта Служба поддержки подтверждает получение обращения о барьере доступности и дает содержательный ответ не позднее двух недель с момента обращения; если нужно собрать больше сведений или подготовить альтернативный формат, срок продлевается еще на две недели с уведомлением заявителя о причине и новом сроке. Если запрошенный доступный формат или обходной путь предоставить нельзя, заявителю выдается короткое письменное мотивированное объяснение отказа. Эти сроки - внутренний норматив именно для обращений о барьере доступности; они не заменяют сроки ответа на обращения, установленные законодательством, в том числе для государственных органов - законодательством об обращениях граждан. Источник модели: Laki digitaalisten palvelujen tarjoamisesta 306/2019, § 10.

Резервный канал сообщения о барьере, не совпадающий с потенциально проблемным элементом основного канала, фиксируется отдельным полем шаблона 9.5 «Карточка поддержки» и остается доступным, даже если основной канал технически недоступен пользователю с тем же барьером. Источник модели, в изложении по официальному стандарту: Digital Transformation Agency Австралии, Digital Service Standard v2.0, критерий 3 «Leave no one behind», по изложению Intopia.

Предложение проекта При передаче продукта на сопровождение другой команде или смене подрядчика новый исполнитель получает реестр известных барьеров доступности с их статусом (устранено, в работе, риск принят), владельцем и сроком - как обязательную часть комплекта передачи, наравне с доступами и документацией по инфраструктуре. Для каждого риска со статусом «риск принят» дополнительно указывается срок пересмотра решения. Источник модели: AHRC, «How to provide equal access to digital goods and services», раздел «Accessibility and risk management».

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

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

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

Предложение проекта Если один и тот же визуальный компонент или паттерн взаимодействия используется одновременно на сайте и в мобильном приложении того же продукта, паспорт компонента (шаблон 9.3) ведется как единый документ для обеих реализаций, с отдельными полями там, где реализация для каждой платформы действительно отличается. Единый паспорт компонента нельзя использовать как доказательство соответствия мобильного приложения: обязательный профиль приложения по-прежнему определяется отдельно, единым ведется только реестр требований к общему компоненту. Источник модели: пакет стандартов Digital Inclusion Standard австралийского Digital Transformation Agency, применяемый одновременно к сайтам и приложениям.

Предложение проекта Общий компонент допускается в библиотеку только после ручной проверки клавиатуры, фокуса, имени, роли, значения и динамических сообщений минимум в двух существенно разных конфигурациях. Для сложных виджетов используются модели ARIA APG и отдельная проверка фактической совместимости. Пример APG (руководство консорциума W3C по практикам применения ARIA) рассматривается как отправная точка, а не готовое доказательство соответствия. Паспорт компонента (шаблон 9.3, поле «Проверенные конфигурации») называет конкретные вспомогательные технологии, на которых компонент фактически проверен, а не общую формулировку «проверено со скринридером», и обновляется при каждом значимом изменении компонента вместе с версией технологической базы, зафиксированной на этапе 5. Список фиксирует только факт проверки, не является рекомендацией к закупке конкретной вспомогательной технологии и не заменяет профиль потребностей целевой группы. Источник модели: GOV.UK Design System, Accessibility strategy.

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

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

Предложение проекта Если поставщик или подрядчик обслуживает сайт по договору, часть функций которого не относится к предмету этого договора, обязательный профиль доступности распространяется именно на те экраны и функции, которые относятся к исполнению этого контракта, а не на весь цифровой продукт поставщика целиком. Границу контура фиксирует заказчик в техническом задании поименным перечнем экранов, страниц или API (программный интерфейс для обмена данными между системами), а не общей формулировкой «весь сервис». Такая граница сужает зону ответственности подрядчика по конкретным элементам, но не снимает с владельца сайта ответственность за доступность пользовательского процесса целиком и за доступную альтернативу там, где часть процесса остается вне контура подрядчика. Источник модели: годовой отчет TTJA о цифровой доступности государственного сектора Эстонии, раздел 2.2.3.

Предложение проекта К закупочной документации на сторонний компонент, виджет или готовое решение прилагается декларация соответствия поставщика по критериям WCAG (зарубежный аналог: отчет о соответствии в формате VPAT) - перечень применимых критериев целевого профиля, статус по каждому (соответствует, частично соответствует, не соответствует, неприменимо), краткое пояснение и протестированная конфигурация. Наличие такой декларации является квалификационным условием закупки и обязательным приложением к договору, а не отдельным баллом в оценке заявок. Если поставщик малый и не готовит декларацию самостоятельно, заказчик или его специалист по доступности вправе заполнить ее сам по итогам собственной быстрой проверки компонента. Источник модели: AHRC, «How to provide equal access to digital goods and services», раздел о закупках.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9. Шаблоны

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

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

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

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

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

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

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

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

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

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

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

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

  1. W3C, Web Content Accessibility Guidelines (WCAG) 2.2, Recommendation от 12 декабря 2024 года.
  2. W3C, WCAG 2.2 Conformance Requirements.
  3. W3C, Making Content Usable for People with Cognitive and Learning Disabilities, Working Group Note от 29 апреля 2021 года.
  4. W3C WAI, Involving Users in Evaluating Web Accessibility.
  5. W3C, Accessibility Conformance Testing Rules Format 1.1, Recommendation от 5 февраля 2026 года.
  6. W3C WAI, Tutorials.
  7. W3C WAI, ARIA Authoring Practices Guide.
  8. Правительство РФ, постановление от 07.02.2026 № 102, действует с 01.03.2026 в пределах установленной им области.
  9. Росстандарт, официальные карточки ГОСТ Р 52872-2019, ГОСТ Р 70176-2022 и ГОСТ Р ИСО 21801-1-2022.
  10. Минтруд России, приказ от 14.11.2025 № 647н, вступает в силу 01.09.2027.
  11. Australian Human Rights Commission, «Chapter 3 | Standards and guidelines for digital accessibility» (2025), в части национального стандарта простого языка AS ISO 24495.1:2024.
  12. Australian Human Rights Commission, «Chapter 2 | How to provide equal access to digital goods and services» (май 2025), в части декларации соответствия поставщика в закупке и реестра барьеров при передаче продукта.
  13. GovTech Singapore, Digital Service Standards Control Catalog и Accessibility Checklist.
  14. Tarbijakaitse ja Tehnilise Järelevalve Amet (Эстония), годовой отчет о цифровой доступности государственного сектора за 2024 год.
  15. Selkokeskus (Финляндия), процедура присвоения знака простого языка selkotunnus.
  16. Финляндия, Laki digitaalisten palvelujen tarjoamisesta 306/2019, § 10.
  17. GOV.UK (портал правительства Великобритании) Design System, «Accessibility strategy».
  18. Digital Transformation Agency (Австралия), Digital Inclusion Standard.
  19. Intopia, Andrew Arch, «Australia's Digital Service Standard gets an upgrade» (15 февраля 2024 года), изложение официального стандарта Digital Service Standard v2.0 Digital Transformation Agency, критерий 3 «Leave no one behind».

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

Нужно техническое задание по этой методологии для вашего сайта?

Оставить заявку