WCAG 2.1 AA и ГОСТ Р 52872-2019 для телемед-видео

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

Кратко

В России нет закона, который прямо обязывал бы частный телемед-продукт соответствовать WCAG, но планка доступности всё равно существует, и вполне конкретная. Национальный стандарт ГОСТ Р 52872-2019 построен на Web Content Accessibility Guidelines (WCAG) 2.1 и задаёт те же уровни соответствия A, AA и AAA. Он добровольный, но становится обязательным для вас, когда клиника или госзаказчик вписывает его в техническое задание. 181-ФЗ «О социальной защите инвалидов» требует от организаций любой формы собственности обеспечивать людям с инвалидностью доступ к услугам наравне с другими и допуск сурдопереводчика (ст. 15), а русский жестовый язык признаёт языком общения (ст. 14). Для живой видеоконсультации WCAG 2.1 AA означает конкретные вещи: субтитры в реальном времени, управление звонком с клавиатуры, подписи для скринридеров, озвучиваемые статусы и контраст. Но интерфейс – только половина задачи: глухому пациенту может понадобиться сурдопереводчик прямо в звонке, а субтитры консультации – это медданные под 152-ФЗ. В статье – откуда приходит требование доступности, что WCAG 2.1 AA значит для реального видеовизита и чек-лист аудита, который команда может пройти до запуска.

Зачем это читать

Доступность в медицине нельзя откладывать как «приятное дополнение». Пациенты с нарушениями зрения и слуха, пожилые люди, люди с моторными ограничениями – именно те, кому телемедицина нужнее всего, и интерфейс, которым они не могут воспользоваться, отрезает их от услуги. Для продукта это ещё и вопрос продаж: заказчик может вписать ГОСТ Р 52872-2019 в техзадание, и тогда несоответствие означает нарушение договора и проваленную приёмку, а не задачу в бэклоге. Статья написана для основателей, продакт-менеджеров, ИТ-руководителей клиник и тех, кто отвечает за комплаенс: откуда в России берётся требование доступности, что стандарт WCAG 2.1 AA требует от живой видеоконсультации и как доказать соответствие до того, как об этом спросит заказчик. Сделаете правильно – расширите аудиторию и спокойно пройдёте приёмку. Ошибётесь – получите доработку в спешке и пациентов, которые так и не дошли до врача.

Суть в одном предложении

Если сжать статью до одной фразы: стройте телемед-продукт под WCAG 2.1 уровня AA (это тот же уровень AA в ГОСТ Р 52872-2019), потому что именно эту планку вам предъявит заказчик, а 181-ФЗ требует, чтобы услуга была доступна людям с инвалидностью наравне с другими.

Дальше – подробности: что такое WCAG и ГОСТ, откуда приходит требование, что стандарт значит для каждой части видеовизита, где интерфейса недостаточно и как проверить свою работу.

Что такое WCAG 2.1 AA и ГОСТ Р 52872-2019

Начнём с самого стандарта: на него ссылаются все требования в статье.

Web Content Accessibility Guidelines, обычно просто WCAG, – технический стандарт, который публикует World Wide Web Consortium (W3C), организация, развивающая открытые веб-стандарты. Сам по себе WCAG не закон. Это инженерный чек-лист, который заимствуют законы, стандарты и договоры: согласованное определение того, что значит «доступно», в измеримых терминах.

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

«WCAG 2.1 уровня AA» означает конкретную версию – 2.1, опубликованную W3C как официальная рекомендация в 2018 году, – на среднем уровне соответствия, который включает все критерии уровней A и AA. Это около пятидесяти требований, и каждое можно проверить отдельно.

ГОСТ Р 52872-2019 – российский национальный стандарт с длинным официальным названием «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности». Он утверждён приказом Росстандарта от 29.08.2019 № 589-ст, введён в действие 01.04.2020 вместо ГОСТ Р 52872-2012 и прямо взял за основу WCAG 2.1. Уровни те же, только названы по-русски: A – «приемлемый», AA – «высокий», AAA – «наивысший». Критерии тоже легко узнать: например, требование живых субтитров в ГОСТ идёт под тем же номером 1.2.4 и называется «Титры (прямой эфир)». Обратите внимание на название: стандарт распространяется не только на сайты, но и на мобильные приложения и «иные пользовательские интерфейсы», то есть и на экран видеоконсультации.

Откуда приходит требование доступности

Этот вопрос часто пропускают, хотя от него зависит всё остальное. Требование к доступности телемед-продукта в России приходит несколькими путями, и какие из них касаются вас, зависит от того, кому вы продаёте и что продукт делает с данными, а не от технологии. Можно оказаться на нескольких ветках сразу.

Нажмите, чтобы увеличить

Закон: 181-ФЗ «О социальной защите инвалидов в Российской Федерации». Статья 15 обязывает не только органы власти, но и организации независимо от их организационно-правовых форм обеспечивать людям с инвалидностью условия для беспрепятственного доступа к объектам и к предоставляемым в них услугам, а также доступ к услугам с учётом ограничений жизнедеятельности. Среди этих условий – допуск сурдопереводчика и тифлосурдопереводчика и помощь сотрудников в преодолении барьеров, которые мешают получать услуги наравне с другими. Закон даже предусматривает, что там, где объект невозможно полностью приспособить, услугу можно оказать дистанционно, и тогда доступность самого дистанционного канала перестаёт быть формальностью. Сайты, приложения и WCAG статья прямо не называет, поэтому 181-ФЗ задаёт цель (услуга должна быть доступна), но не технический стандарт.

Стандарт: ГОСТ Р 52872-2019. Он отвечает на вопрос, что значит «доступно» для интерфейса, в проверяемых критериях. Как и любой национальный стандарт, он применяется добровольно: сам по себе он не создаёт обязанности и не грозит штрафом. Но это единственный российский документ, который превращает расплывчатое «обеспечить доступность» в чек-лист, поэтому на него ссылаются и заказчики, и проверяющие, и внутренние аудиторы.

Договор: техническое задание заказчика. Здесь добровольный стандарт становится обязательным. Государственная клиника, региональный оператор медицинской системы или частная сеть клиник может вписать в техзадание соответствие ГОСТ Р 52872-2019 на нужном уровне, и тогда это условие приёмки, за невыполнение которого отвечаете вы как подрядчик. Для B2B-продукта это самый частый и самый жёсткий путь: требование приходит с датой и проверкой.

Данные: 152-ФЗ. Функции доступности обрабатывают медданные: живые субтитры, расшифровки, подключение переводчика. Это отдельный слой требований, который действует для всех веток; подробнее – в разделе о субтитрах ниже.

Какой бы путь ни был вашим, техническая цель одна – WCAG 2.1 AA, то есть уровень AA ГОСТ Р 52872-2019. Вопрос лишь в том, кто и когда это проверит.

Версии, статус и когда начинать

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

Нажмите, чтобы увеличить

Версия. Новейшая версия WCAG – 2.2 (2023), и в рекомендациях вы встретите её как лучшую практику. Но ГОСТ Р 52872-2019 построен на 2.1, поэтому WCAG 2.1 AA – практический минимум для российского рынка, а 2.2 – задел на будущее. Сборка под 2.2 AA не ломает соответствие 2.1 AA, так что, если команда уже работает по 2.2, ничего переделывать не придётся.

Статус. На октябрь 2026 года ГОСТ Р 52872-2019 действует. Прежде чем писать в коммерческом предложении «соответствует ГОСТ Р 52872-2019», перепроверьте статус стандарта и редакцию, на которую ссылается заказчик: техзадания иногда цитируют отменённую редакцию 2012 года.

Когда начинать. «Добровольный» звучит успокаивающе, но посчитаем. Допустим, сеть клиник предупредила, что со следующего договорного цикла впишет в техзадание соответствие ГОСТ Р 52872-2019 на уровне AA, а отбор подрядчиков начнётся через 9 месяцев. Полный цикл «аудит плюс доработка» на реальном видеопродукте занимает 3–6 месяцев, ещё 1–2 месяца уйдёт на независимую проверку и исправления по её итогам, а отчёт о соответствии нужен до подачи заявки:

9 месяцев до отбора − 6 месяцев (аудит и доработка, верхняя оценка)
                    − 2 месяца (независимая проверка и исправления)
                    = 1 месяц запаса

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

Что WCAG 2.1 AA значит для живой видеоконсультации

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

Нажмите, чтобы увеличить

Субтитры на звонке – критерий, будто созданный для телемедицины

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

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

К живой консультации, то есть к разговору пациента и врача в реальном времени, относится критерий 1.2.4 Субтитры (живые), в ГОСТ – «Титры (прямой эфир)», уровень AA. Его цель – позволить людям, которые не слышат или плохо слышат, следить за происходящим в реальном времени. Для продукта это значит, что платформе нужно субтитрировать живое аудио визита, а не только выдавать расшифровку потом. Живые субтитры обычно строятся на автоматическом распознавании речи (ASR). Инженерия этого конвейера – потоковое распознавание, точность на русской медицинской лексике, кто вправе обрабатывать аудио – отдельная тема, она разобрана в статье о транскрипции и субтитрах консультаций в реальном времени.

Сразу оговоримся: у живых субтитров свои вопросы точности и защиты данных. Ошибки распознавания в клинических терминах могут ввести пациента в заблуждение, а аудио консультации и его расшифровка – сведения о здоровье (специальная категория по ст. 10 152-ФЗ) и врачебная тайна (ст. 13 323-ФЗ). Поэтому сервис распознавания речи – лицо, обрабатывающее данные по поручению оператора, с условиями поручения в договоре (ст. 6 152-ФЗ) и базами данных в России (ст. 18 ч. 5). Зарубежные облачные API распознавания для этого не подходят: это трансграничная передача специальной категории данных и прямой конфликт с локализацией. Рабочие варианты – российские облачные сервисы распознавания (SaluteSpeech, Yandex SpeechKit, в том числе в локальной поставке) или открытые модели вроде Whisper на собственных серверах. Как оформить поручение, разобрано в статье о поручении обработки ПДн и договорах с подрядчиками. «Доступно» и «законно» – две разные проверки, и функция субтитров должна пройти обе.

Есть ещё 1.2.5 Аудиоописание (записанное) – критерий уровня AA для записанного видео, где важная визуальная информация не передана звуком. К живой двусторонней консультации он применяется редко, но к записанным обучающим видео внутри продукта – применяется.

Управление звонком без мыши

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

2.1.1 Клавиатура (уровень A) требует, чтобы всей функциональностью можно было управлять с одной клавиатуры. Пациент, который пользуется переключателем или навигацией с клавиатуры, должен суметь дойти клавишей Tab до кнопки микрофона и включить его. 2.1.2 Нет ловушки клавиатуры (уровень A) требует, чтобы фокус всегда мог уйти из компонента: видеопанель, которая захватывает клавиатуру, этот критерий не проходит. 2.4.7 Видимый фокус (уровень AA) требует заметного индикатора фокуса, чтобы пользователь видел, какой элемент выбран. Вместе эти три критерия делают звонок управляемым для пользователей клавиатуры и переключателей.

Поддержка скринридера – имя, роль, значение

Незрячий пациент ориентируется по скринридеру – программе, которая читает интерфейс вслух. Чтобы это работало, каждый элемент должен сообщать три вещи: как он называется, что это за элемент и в каком он состоянии. Это 4.1.2 Имя, роль, значение (уровень A). Кнопка микрофона в виде голой кликабельной иконки без доступного имени читается как «кнопка, кнопка» и бесполезна; сделанная правильно – как «Микрофон, переключатель, включён». Именно этот критерий кастомные видеоинтерфейсы не проходят чаще всего: самописные элементы и элементы, нарисованные на canvas, часто остаются без доступного имени или роли.

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

Цвет и контраст – читаемо и различимо

1.4.3 Контраст (минимум) (уровень AA) требует, чтобы обычный текст имел коэффициент контраста с фоном не менее 4,5:1 (3:1 для крупного текста). Медицинские интерфейсы любят светло-серые подписи на белом, и многие не проходят этот критерий. 1.4.11 Контраст нетекстовых элементов (уровень AA) распространяет минимум 3:1 на значимые части элементов и графику – контур кнопки микрофона, индикатор активной записи, – чтобы слабовидящий пользователь мог их найти. А 1.4.1 Использование цвета (уровень A) запрещает передавать информацию только цветом: красной точке «идёт запись» нужна ещё подпись или иконка, потому что человек с нарушением цветового зрения может не отличить красный.

Формы – понятно и без ловушек

У форм записи и анкет свои критерии. 1.3.1 Информация и связи и 3.3.2 Подписи или инструкции (оба уровня A) требуют, чтобы у каждого поля была программная подпись, которую читает скринридер, а 3.3.1 Идентификация ошибки и 3.3.3 Подсказка по ошибке – чтобы ошибки проверки описывались текстом, а не только красной рамкой. 1.4.4 Изменение размера текста и 1.4.10 Перекомпоновка (уровень AA) требуют, чтобы вёрстка выдерживала увеличение до 200% и узкий экран без горизонтальной прокрутки; это напрямую касается слабовидящих и мобильных пациентов.

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

Где WCAG заканчивается: коммуникация с пациентом

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

Соответствие WCAG 2.1 AA делает доступным программный интерфейс, но само по себе не делает доступной консультацию для глухого пациента, который общается на русском жестовом языке. 181-ФЗ признаёт русский жестовый язык языком общения людей с нарушениями слуха и (или) речи и закрепляет, что перевод на него выполняют квалифицированные сурдопереводчики (ст. 14), а среди условий доступности услуг называет допуск сурдопереводчика и тифлосурдопереводчика (ст. 15). Жестовый язык – самостоятельный язык со своей грамматикой, и для части глухих пациентов субтитры к устной речи врача – не равноценная замена переводчику.

Нажмите, чтобы увеличить

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

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

Разобранный пример: аудит одного экрана консультации

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

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

Частые ошибки команд телемедицины

Одни и те же ошибки доступности повторяются из продукта в продукт:

• Считать это проблемой только сайта. Команды проверяют маркетинговый сайт и забывают про живую консультацию: субтитры, управление звонком с клавиатуры и статусы. Специфичные для видео критерии находятся именно там, и внедрять их задним числом тяжелее всего.
• «Версия для слабовидящих» вместо доступности. Кнопка, переключающая сайт на крупный шрифт и чёрно-белую схему, – привычный элемент российских сайтов, но она не даёт ни управления с клавиатуры, ни имён для скринридера, ни озвучиваемых статусов. Доступным должен быть основной интерфейс, и прежде всего экран консультации.
• Кастомный видеоинтерфейс без доступных имён. Самописные или нарисованные на canvas элементы регулярно превращаются в безымянные кнопки, которые скринридер не может озвучить (нарушение 4.1.2). Готовый видео-SDK не решает это автоматически: подписи всё равно на вас.
• «Автосубтитры включены, значит, готово». Живые субтитры закрывают критерий 1.2.4, но не решают ни точность на клинических терминах, ни потребность глухого пациента в сурдопереводчике.
• Забыть, что субтитры – это медданные. Аудио, отправленное в зарубежный сервис распознавания, превращает функцию доступности в нарушение 152-ФЗ.
• «ГОСТ добровольный – сделаем потом». Требование появляется в техзадании с датой приёмки, а доработка видеоинтерфейса задним числом занимает месяцы.
• Низкоконтрастные клинические интерфейсы. Серое на белом и тонкие контуры кнопок не проходят 1.4.3 и 1.4.11. В «чистом» медицинском дизайне это обычное дело; исправить рано – дёшево, поздно – дорого.

Где здесь Фора Софт

Фора Софт разрабатывает видеософт с 2005 года: телемедицину, видеоконференции, стриминг, электронное обучение и видеонаблюдение. Доступность – как раз то место, где работа с видео в реальном времени встречается с регуляторными требованиями. Мы проектируем от требований. Элементы интерфейса консультации несут корректные имена, роли и состояния для скринридеров, звонком можно управлять с клавиатуры с видимым фокусом, контраст выдерживает 4,5:1 и 3:1. Живые субтитры работают на российском сервисе распознавания или на собственных серверах и оформлены поручением обработки, чтобы функция была и доступной, и законной. Многосторонняя архитектура звонка позволяет подключить сурдопереводчика с тем качеством видео, которого требует жестовый язык. Цель – платформа, которая проходит аудит по WCAG 2.1 AA и ГОСТ Р 52872-2019 и поддерживает коммуникацию с пациентом; доступность в ней встроена в видеоядро, а не прикручена перед приёмкой.

Главное

• В России закон не называет WCAG; техническую планку задаёт ГОСТ Р 52872-2019 на основе WCAG 2.1 – добровольный, но обязательный, когда его вписали в договор.
• 181-ФЗ требует от организаций любой формы собственности обеспечивать людям с инвалидностью доступ к услугам наравне с другими и допуск сурдопереводчика (ст. 15).
• Цель для продукта – WCAG 2.1 AA (уровень AA ГОСТ); WCAG 2.2 – лучшая практика сверх минимума.
• Для живой консультации критичны субтитры (1.2.4), клавиатура (2.1.1), фокус (2.4.7), имена и роли (4.1.2), статусы (4.1.3), контраст (1.4.3 / 1.4.11).
• Субтитры не заменяют сурдопереводчика: русский жестовый язык – язык общения (ст. 14 181-ФЗ), и потоку переводчика нужно качество видео, при котором видны руки, пальцы и мимика.
• Субтитры и расшифровки – медданные: сервис распознавания работает по поручению и хранит данные в России.

Что читать дальше

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