Какие accessibility-требования включать в закупку цифровой и физической системы

Короткий ответ

Доступность чаще всего «теряется» на этапе закупки: доработать несовместимую систему позже сложно и дорого. Надёжный путь — сделать соответствие стандарту условием договора до выбора поставщика: указать стандарт и уровень (WCAG 2.1/2.2 AA для интерфейсов, EN 301 549 или Section 508 для ИКТ, ADA/ABA или EN 17210 для физических элементов), требовать поэтапные доказательства и приёмочное тестирование, запрещать работы, снижающие доступность, и просить дорожную карту устранения недостатков.

Главные выводы

Указывайте в тендере конкретный стандарт и уровень: для интерфейсов — WCAG 2.1 или 2.2 AA, для ИКТ в целом — EN 301 549 либо Section 508, для зданий и среды — 2010 ADA Standards или EN 17210.
Добавляйте функциональные требования (например, п. 4.2 EN 301 549), описывающие способности системы для людей без зрения, слуха, с ограниченной моторикой, а не только технические критерии.
Делите доказательства на этапы: письменная декларация, затем конформный отчёт с методами тестирования, затем живая демонстрация на ассистивных технологиях у финалистов.
Пишите защитные формулировки: монтаж, настройка, хостинг и обслуживание не должны снижать уровень доступности, зафиксированный при заключении договора.
Ставьте приёмку в зависимость от конформного отчёта и демонстрации, а также резервируйте право на независимое тестирование.
Готовьтесь к частичному соответствию: требуйте от поставщика раскрыть пробелы, предоставить датированный план устранения и временные обходные решения.
Помните, что сроки и правила меняются: проверяйте актуальные даты и требования вашей юрисдикции перед составлением документа.

Почему доступность решается до выбора поставщика

Большинство барьеров доступности закладывается именно на стадии требований. Платформу, несовместимую со средствами чтения с экрана или недоступную для человека на коляске, сложно «починить» после ввода в эксплуатацию: исправления медленные, частичные и дорогие. Поэтому ряд правовых режимов прямо привязывает доступность к закупкам: в США федеральные информационно-коммуникационные технологии обязаны соответствовать Revised Section 508 Standards, а в Евросоюзе Европейский акт о доступности и Директива о доступности веб-контента подталкивают заказчиков учитывать доступность в технических спецификациях, критериях отбора и оценки.

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

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

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

Цифровые интерфейсы обычно описывают через Web Content Accessibility Guidelines. На практике заказчики требуют WCAG 2.1 или WCAG 2.2 уровня AA, и многие юрисдикции переходят с версии 2.1 на 2.2. Для информационно-коммуникационных технологий в целом — аппаратуры, киосков, операционных систем, документов — в Европе действует EN 301 549, а в США Section 508; эти стандарты близки по содержанию, и EN 301 549 принят и за пределами Европы, например в Австралии как AS EN 301 549.

Физические и строительные элементы описываются другими документами: в США scoping и технические требования к зданиям задаёт 2010 ADA Standards for Accessible Design, в Европе — функциональные требования EN 17210. Самодостаточные терминалы вроде банкоматов и киосков регистрации находятся на границе: их программное обеспечение оценивают по веб-правилам, а физическую досягаемость, тактильные элементы и звуковую обратную связь — как аппаратуру. Практичный приём — короткая функциональная формулировка плюс техническая ссылка на точный стандарт.

Интерфейсы и контент: WCAG 2.1 или 2.2, уровень AA.
ИКТ в целом (софт, аппаратура, документы): EN 301 549 (ЕС, Австралия) или Revised Section 508 (США).
Здания, маршруты, указатели: 2010 ADA Standards (США) или EN 17210 (ЕС).
Киоски и терминалы: веб-стандарт для интерфейса плюс эргономические требования к корпусу.

Формулировки, которые делают требования исполнимыми

Наиболее полезные условия трактуют доступность как результат с последствиями. Типовое формулирование, как в образцах федеральных документов США, включает: клаузу о соответствии — ИКТ обязано полностью отвечать указанному стандарту до поставки и до финальной приёмки; клаузу о доказательствах — предоставить Accessibility Conformance Report по актуальному шаблону; клаузу о приёмке — финальный платёж зависит от работающей демонстрации; и клаузу о несоответствии — поставщик обязан бесплатно устранить или заменить несоответствующие изделия в указанный срок.

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

Соответствие до поставки и до финальной приёмки.
Конформный отчёт по актуальному шаблону.
Приёмка после живой демонстрации.
Устранение несоответствий за счёт поставщика в оговорённый срок.

Физические системы: аппаратура и размещение

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

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

Доказательства по этапам, проверка при приёмке

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

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

Ограничения, сроки и юрисдикция

Требования не статичны, и сроки сдвигаются. Перед составлением документа проверьте актуальные даты вашей юрисдикции. Например, Минюст США промежуточным правилом от апреля 2026 года перенёс срок соответствия веб-контента и приложений по Разделу II ADA на 26 апреля 2027 года для крупных публичных органов и на 26 апреля 2028 года для меньших; стандарт EN 301 549 периодически пересматривается, а документ CEN-CENELEC-ETSI TR 101551:2026 помогает европейским заказчикам увязать технические спецификации с Европейским актом о доступности и Директивой о веб-доступности.

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

Практический инструмент

Библиотека типовых клауз для закупки цифровых и физических систем

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

Соответствие: «Все поставляемые по договору результаты должны соответствовать [названный стандарт, например WCAG 2.2 AA / EN 301 549 / Revised Section 508] до поставки и до финальной приёмки».
Функциональная возможность: «Система должна быть пригодна для людей без зрения, с ограниченным зрением, без слуха, с ограниченным слухом или моторикой, с ограниченными когнитивными или языковыми способностями применительно к функциям из технического задания».
Ассистивные технологии: «Решение должно работать с массовыми ассистивными технологиями (экранные дикторы, лупы, речевой ввод, управление выключателем, субтитры) и не блокировать и не ломать их».
Защита при монтаже: «Установка, настройка и интеграция не должны выполняться способом, снижающим соответствие названному стандарту».
Защита в жизненном цикле: «Обслуживание, обновления, замены и подстановки не должны снижать уровень соответствия, зафиксированный при заключении договора; любое изменение интерфейса требует нового конформного отчёта».
Хостинг: «Хостинг-услуги не должны ухудшать доступность размещённого контента; заказчик вправе тестировать хостинг-решение в течение срока договора».
Доказательства: «Поставщик обязан предоставить Accessibility Conformance Report по актуальному шаблону для каждого изделия ИКТ, заполненный по инструкции шаблона».
Приёмочные испытания: «До приёмки подрядчик демонстрирует рабочую версию, показывая, где соответствие достигнуто, а где нет, по требуемым методикам и на ассистивных технологиях».
Независимое тестирование: «Заказчик сохраняет право провести независимое тестирование поставленного решения на соответствие названному стандарту».
Несоответствие: «Если заказчик установит, что изделие не отвечает названному стандарту, подрядчик обязан бесплатно устранить или заменить его в указанный срок».
Дорожная карта: «Там, где полное соответствие не заявляется, поставщик раскрывает пробелы и предоставляет датированный план устранения, а также задокументированные временные обходные решения».
Кадры и записи: «Специалисты по доступности должны обладать нужными знаниями и предоставлять документацию по запросу; полные записи тестирования и принятых мер сохраняются».

Частые вопросы

Что указывать в тендере — WCAG 2.1 или WCAG 2.2?

Зависит от вашей юрисдикции и даты. Многие правила ссылаются на WCAG 2.1 AA (например, правило Минюста США по Разделу II ADA), а ряд организаций и стандартов уже переходят на WCAG 2.2 AA. Чтобы не оказаться ниже обязательного порога, сначала проверьте действующую норму вашего региона, затем выбирайте: если ваша норма допускает новую версию, требуйте WCAG 2.2 AA как более свежую, иначе фиксируйте WCAG 2.1 AA с оговоркой о праве требовать более высокого уровня. Добавьте пункт, что новая версия не должна снижать доступность.

Что такое функциональное требование к производительности и зачем оно в закупке?

Это формулировка на уровне способностей пользователя — например, что система должна работать без зрения, с ограниченным зрением, без слуха, с ограниченной моторикой или когнитивными ограничениями. В EN 301 549 такие положения собраны в п. 4.2 (Functional Performance Statements). В отличие от узких технических критериев они описывают ожидаемый результат и передают поставщику выбор, какие именно требования релевантны его решению. Включение функциональной клаузы вместе с технической ссылкой закрывает пробелы и упрощает оценку заявок.

Какие доказательства просить у поставщика и когда?

Распределите бремя по этапам. В начале — письменное заявление о полном, частичном или нулевом соответствии. Для прошедших — заполненная декларация о соответствии с указанием методов тестирования и уровня по стандарту (например, по WCAG или EN 301 549). У финалистов — живая демонстрация на ассистивных технологиях и функциях доступности массовых операционных систем. До финальной приёмки требуйте конформный отчёт по актуальному шаблону, результаты тестов по признанным методикам и оставляйте за собой право независимой проверки.

Поставщик заявляет лишь частичное соответствие. Как поступить?

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

Киоск — это и софт, и «железо». Какие стандарты применять?

Разделите уровни. Программную часть интерфейса оценивайте по веб-правилам доступности (WCAG 2.1/2.2 AA) и по положениям ИКТ-стандарта (EN 301 549 или Section 508). Физическую часть — досягаемость органов управления, высоту сенсора и клавиатуры, тактильные отметки, звуковую обратную связь — описывайте отдельными эргономическими и аппаратурными клаузами. Если терминал размещается в здании, добавьте условие о доступном маршруте и свободном пространстве перед устройством.

Влияют ли сроки вступления норм в силу на договор, который я пишу сейчас?

Да, напрямую. Например, правило Минюста США по доступности веб-контента и приложений для органов власти (Раздел II ADA) предусматривало даты, которые промежуточным правилом апреля 2026 года перенесены: для органов с населением от 50 000 человек — на 26 апреля 2027 года, для меньших и специальных округов — на 26 апреля 2028 года. В Евросоюзе требования Европейского акта о доступности и сроки зависят от продукта и страны. Обязательно сверяйте даты и исключения для вашей юрисдикции на момент выпуска документа.

Источники и дополнительные материалы

Источники проверены при подготовке страницы. Изменяемые даты, нормы и цены уточняйте у первоисточника.

Define Accessibility Criteria in ContractsU.S. General Services Administration (Section508.gov)
Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local GovernmentsU.S. Department of Justice (ADA.gov)
2010 ADA Standards for Accessible DesignU.S. Department of Justice (ADA.gov)
Government accessibility standards for ICTNSW Government (Buy NSW)
Revised TR 101551: Integrating Accessibility Requirements into ICT ProcurementCEN, CENELEC and ETSI
Procuring Section 508 Conformant ICT Products and ServicesU.S. General Services Administration (Section508.gov)