Сделать онлайн-заказ

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

ГОСТ Р 70186-2022

Скачать Действующий Печать
Все видео
Статус на 21.12.2024: Действующий

Федеральное агентство по техническому регулированию и метрологии


Знак ГОСТаНациональный
стандарт
Российской
Федерации
ГОСТ Р 70186—2022


Интернет-ресурсы и другая информация,
представленная в электронно-цифровой форме.

Инструменты разработки цифрового контента.
Требования доступности для
людей с инвалидностью и иных лиц с
ограничениями ЖИЗНЕДЕЯТЕЛЬНОСТИ

Дата введения — 2022—12—01

Предисловие

  1. РАЗРАБОТАН Федеральным государственным унитарным предприятием «Российский научно-технический центр информации по стандартизации, метрологии и оценке соответствия» (ФГУП «СТАНДАРТИНФОРМ»)
  2. ВНЕСЕН Техническим комитетом по стандартизации ТК 381 «Технические средства и услуги для инвалидов и других маломобильных групп населения»
  3. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от №

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок – в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования – на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (http://www.gost.ru)

Введение

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

При разработке настоящего стандарта за основу был взят актуальный на этот момент документ Authoring Tool Accessibility Guidelines (ATAG) 2.0 [1], созданный и сопровождаемый международной организацией World Wide Web Consortium. Этот документ содержит требования и рекомендации в отношении приложений для разработки цифрового контента, учитывающие как актуальные тенденции в сфере вспомогательных технологий, так и многолетний опыт становления Интернет и его самого популярного сегмента – «всемирной паутины» (WWW) – в качестве доступного информационного пространства.

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

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

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

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

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

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

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

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

Настоящий стандарт тесно связан с ГОСТ Р 52872-2019, поскольку уровень многих критериев выполнения зависит от уровней критериев ГОСТ Р 52872-2019.

Для того чтобы обеспечить простой процесс использования настоящего стандарта совместно с ГОСТ Р 52872-2019 при создании инструментов разработки, использована трехуровневая модель соответствия, схожая с используемой в ГОСТ Р 52872-2019: уровни А, АА и ААА. Три уровня соответствия основаны на критериях выполнения того же уровня. В настоящем стандарте также определены варианты полного и частичного соответствия (5.2), что позволяет учесть особенности применения инструментов разработки для решения различных задач.

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

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

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

Любое торговое наименование, использованное в настоящем стандарте, является информацией, приводимой для удобства пользователей, и не является свидетельством в пользу того или иного товара.

Стандарт разработан авторским коллективом в следующем составе: юриста, сертифицированного тренера и консультанта по адаптивным информационным технологиям А.В. Зеленова, сооснователя и администратора Портала Tiflocomp (www.tiflocomp.ru), разработчика адаптивных решений А.Н. Камынина, начальника отдела социокультурных проектов и программ ГМКЦ «Интеграция» им. Н.А. Островского, представителя Российской Федерации в глобальной инициативе за инклюзивные ИКТ (G3ICT/Smart cities for all) А.Д. Попко.

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

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

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

Настоящий стандарт является одним из стандартов по обеспечению доступности, действующих в Российской Федерации.

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

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 57891-2017 Тифлокомментирование и тифлокомментарий. Термины и определения

ГОСТ Р ИСО 9241-20-2014 Эргономика взаимодействия человек-система. Часть 20. Руководство по доступности оборудования и услуг в области информационно-коммуникационных технологий

ГОСТ Р ИСО 9999-2014 Вспомогательные средства для людей с ограничениями жизнедеятельности. Классификация и терминология

ISO 32000-2 Document management — Portable document format — Part 2: PDF 2.0

ISO/IEC 15948 Information technology — Computer graphics and image processing — Portable Network Graphics (PNG): Functional specification

ISO / IEC 26300

ISO/IEC 29500-1:2008 Information technology — Document description and processing languages — Office Open XML File Formats — Part 1: Fundamentals and Markup Language Reference

ISO/IEC 40314:2016Information technology — Mathematical Markup Language (MathML) Version 3.0 2nd Edition

ECMA-262 ECMAScript® 2020 language specification

ECMA-376 Office Open XML file formats

ECMA-388 Open XML paper specification

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

3. Термины, определения и сокращения

3.1 В настоящем стандарте применены термины по ГОСТ Р 57891, ГОСТ Р ИСО 9241-20, ГОСТ Р ИСО 9999, а также следующие термины с соответствующими определениями:

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

3.1.2 Cascading Style Sheets: Обобщенное название нескольких версий языка описания свойств стиля контента. CSS специфицирован и развивается международной организацией World Wide Web Consortium [2].

3.1.3 Digital accessible information system: Открытая спецификация формата «цифровых говорящих книг», разработанная и поддерживаемая организацией DAISY Consortium. Данный формат основан на XML и производных форматах, сочетает различные способы представления контента: обычный текст, аудио и иллюстрации. Многоуровневая навигация обеспечивает быстрый переход к нужной книге, разделу, главе или странице. Также данный формат предоставляет возможность выбора способа воспроизведения книги: прослушивание аудио в дикторском исполнении либо озвучивание текста при помощи синтеза речи, поддерживаемого DAISY плеером или пользовательским агентом для представления книг в формате DAISY. Современная версия DAISY поддерживает математическую нотацию на языке MathML. Формат DAISY 3.0 был принят в качестве национального стандарта ANSI/NISO Z39.86-2005.

3.1.4 Electronic Publication: Открытый формат электронных версий книг, разработанный Международным форумом по цифровым публикациям (International Digital Publishing Forum) в 2007 году. Формат позволяет издателям производить и распространять цифровую публикацию в одном файле, обеспечивая совместимость между программным и аппаратным обеспечением, необходимым для воспроизведения цифровых книг и других публикаций с плавающей версткой.

3.1.5 FictionBook: Основанные на XML несколько версий формата представления электронных вариантов книг, где каждый элемент книги описывается своими тегами. Применение XML позволяет создавать документы, готовые к непосредственному использованию и программной обработке (преобразованию, хранению, управлению) в любой среде. Документы могут содержать структурную разметку основных элементов текста, информацию о книге, а также вложения с двоичными файлами, в которых могут храниться иллюстрации [8].

3.1.6 HTMLHelp: Корпоративный формат файлов контекстной справки, разработанный Microsoft и выпущенный в 1997 году. Файлы HTMLHelp содержат в сжатом виде набор HTML-страниц, могут также включать в себя содержание со ссылками на страницы, предметный указатель и базу для полнотекстового поиска по содержимому страниц.

3.1.7 HyperText Markup Language: Обобщенное название нескольких версий языка разметки гипертекстового содержимого, используемого в среде WWW. HTML специфицирован и развивается международной организацией World Wide Web Consortium [3].

3.1.8 Javascript: Мультипарадигменный язык программирования, реализующий спецификацию ECMAScript (стандарт ECMA-262 [7]). Javascript обычно используется как встраиваемый язык для программного доступа к внутренней объектной модели приложения или данных. Наиболее широко Javascript применяется в пользовательских агентах (например, web-браузерах) как язык сценариев для придания интерактивности отображаемому ими контенту. Также Javascript применяется в качестве языка сценариев на стороне сервера, в мобильных приложениях и в качестве базового языка программирования на операционных системах, использующих пользовательские агенты для построения своего пользовательского интерфейса (например, Joli OS, Chromium OS, SimplyWebOS 4).

3.1.9 Mathematical Markup Language: Язык разметки на основе XML для представления математических символов и формул в документах WWW. MathML рекомендован математической группой World Wide Web Consortium (W3C). В 2015 году MathML утвержден в качестве стандарта ISO/IEC 40314.

3.1.10 Office Open XML: Набор форматов файлов для хранения электронных документов пакетов офисных приложений — в частности, Microsoft Office. Форматы представляют собой сжатые и заархивированные в единый файл текст в виде XML, графику и другие данные. В 2006 году Office Open XML был объявлен свободным и открытым форматом, который принят в качестве двух отличающихся стандартов — ECMA-376 [10] и ISO/IEC 29500-1:2008.

3.1.11 OpenDocument Format: Открытый формат файлов документов для хранения и обмена редактируемыми офисными документами, в том числе текстовыми документами (такими как заметки, отчеты и книги), электронными таблицами, рисунками, базами данных, презентациями. Формат был разработан индустриальным сообществом OASIS и основан на XML. В 2006 году принят как международный стандарт ISO / IEC 26300. В 2015 году стандартизован формат версии 1.2 [9].

3.1.12 Portable Document Format: Межплатформенный открытый формат электронных документов, изначально предназначавшийся для представления полиграфической продукции в электронном виде, но впоследствии ставший одним из распространенных форматов для электронных документов в сети Интернет. Формат принят в качестве стандарта ISO 32000-2.

3.1.13 Portable Network Graphics: Формат хранения растровой графической информации, использующий сжатие без потерь. Формат принят в качестве стандарта в ISO 15948.

3.1.14 Scalable Vector Graphics: Спецификация формата векторного изображения на основе XML для двумерных изображений с поддержкой интерактивности и анимации, разработанная Консорциумом World Wide Web (W3C).

3.1.15 Uniform Resource Locator: Унифицированный локатор (определитель местонахождения) ресурса, а также система унифицированной адресации электронных ресурсов. URL позволяет специфицировать как локальный ресурс (например, в файловой системе настольного компьютера), так и глобальный (например, интернет-ресурс).

3.1.16 Web Accessibility Initiative — Accessible Rich Internet Applications: Техническая спецификация, опубликованная Консорциумом World Wide Web (W3C), и разрабатываемая с участием ведущих компаний индустрии информационных технологий. Данная спецификация указывает, как улучшить доступность интернет контента, в частности, динамического контента, а также пользовательского интерфейса компонентов, разработанных с использованием Ajax, HTML, Javascript и сопутствующих технологии [4].

3.1.17 World Wide Web: Глобальная распределенная система гипермедиа, часто называемая «всемирной паутиной» и размещенная в сети Интернет.

3.1.18 XML Paper Specification: Открытый формат фиксированной разметки документов на основе XML, ориентированный преимущественно на использование в документообороте. Разработан компанией Microsoft и утвержден в качестве стандарта ECMA-388 Open XML paper specification.

3.1.19 eXtensible Markup Language: Спецификация языка разметки, который определяет набор правил для представления документов в едином человеко-читаемом и машиночитаемом формате, а также правила, позволяющие разрабатывать специализированные языки разметки на основе XML. Спецификация разработана и поддерживается Консорциумом World Wide Web (W3C).

3.1.20 eXtensible Stylesheet Language: Набор спецификаций, разработанных Консорциумом World Wide Web (W3C) и описывающих языки преобразования и визуализации документов в формате XML или производных от него.

3.1.21 проблемы доступности: Несоответствие требованиям доступности компонентов приложения, реализующих взаимодействие с пользователем. Настоящий стандарт различает два типа проблем доступности:

  1. проблемы доступности пользовательского интерфейса Инструмента разработки: аспекты пользовательского интерфейса Инструмента разработки, которые не соответствуют критериям выполнения части 4.1;
  2. проблемы доступности контента: аспекты контента, которые не соответствуют ГОСТ Р 52872 (уровень А, АА или ААА).

3.1.22 информация доступности: Информация, которую должен содержать цифровой контент, чтобы соответствовать требованиям доступности (ГОСТ Р 52872) на уровне А, АА или ААА. Например, программно связанный альтернативный контент ( в том числе текстовая альтернатива изображений), информация о роли и состоянии элементов управления, взаимосвязи в сложных таблицах.

Примечание — Для целей настоящего стандарта информация доступности ограничивается программно определяемым контентом.

3.1.23 функции поддержки доступности контента: Любые функции инструмента разработки, которые напрямую поддерживают авторов в повышении доступности редактируемого контента. Это функции, которые должны присутствовать, чтобы соответствовать критериям выполнения части 4.2.

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

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

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

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

3.1.28 программно-связанный альтернативный контент: Альтернативный контент, местоположение и цель которого могут быть программно-определены из исходного контента, для которого он служит альтернативой. Например, абзац может служить текстовой альтернативой изображению, но он программно связан только в том случае, если это отношение правильно закодировано (например, в HTML 5 с помощью атрибута «aria-labeledby»).

3.1.29 вспомогательные технологии: Аппаратное и программное обеспечение, применяющееся пользователями с ограничениями жизнедеятельности ( авторами и конечными пользователями) (2.8 ГОСТ Р ИСО 9999-2019) отдельно или совместно с основным аппаратно-программным комплексом для обеспечения функциональности, недостижимой с помощью обычных аппаратных и программных средств (3.1.13 ГОСТ Р 52872). Вспомогательные технологии не являются частью инструмента разработки, однако некоторые инструменты разработки могут также предоставлять функции прямого доступа.

Примеры вспомогательных технологий:

  1. программы увеличения экрана, а также другие вспомогательные средства, которые используются людьми с различными нарушениями зрения или восприятия печатной информации для изменения шрифта, размера, интервала, цвета текста, синхронизации с речью и т. д., чтобы улучшить восприятие отображаемого текста и/или изображений.
  2. программы экранного доступа, которые используются людьми с полной потерей зрения для получения текстовой информации при помощи синтезированной речи или шрифта Брайля.
  3. программное обеспечение для преобразования текста в речь, которое используется людьми с когнитивными, языковыми проблемами и сложностями в обучении для преобразования текста в синтезированную речь.
  4. программное обеспечение для распознавания речи, которым пользуются люди с физическими ограничениями или нарушениями.
  5. альтернативные клавиатуры, которые используются людьми с физическими ограничениями или нарушениями для имитации клавиатуры (включая альтернативные клавиатуры, которые используют головные указатели, одиночные переключатели, технологии «глоток / затяжка» и другие специальные устройства ввода).
  6. альтернативные указывающие устройства, которые используются людьми с физическими ограничениями или нарушениями для имитации наведения мыши и активации кнопок.
ПЦУ Мышь 130x70x60мм 10170
Увеличитель портативный цифровой ПЦУ-Мышь Артикул: 10170 Размеры: 60x70x130 мм Производитель в России: ООО «Вертикаль» Скачать тех. задание

3.1.30 аудио: Технология контента, основанная на воспроизведении звука. Аудио может быть создано синтетически (включая синтез речи), записано из реальных звуков или и того, и другого.

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

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

3.1.33 разрешение автора: Авторизация, позволяющая изменять данный контент.

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

3.1.35 обратимое действие: Действие в процессе разработки контента, которое может быть немедленно и полностью отменено инструментом разработки по запросу автора. Примеры запросов на отмену: «отменить», «отменить последнее действие», «повторить последнее действие» (если это была отмена), «вернуться» и «откатить».

Примечание — Инструмент разработки может объединять итерации по вводу текста (например, несколько напечатанных слов, серию удалений) в одно обратимое действие.

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

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

3.1.38 доступная авторская практика: Авторская практика, в ходе которой создается авторский результат, соответствующий требованиям доступности цифрового контента (ГОСТ Р 52872) на уровне А, АА или ААА. Некоторые доступные авторские практики опираются на информацию доступности.

3.1.39 авторская сессия: Состояние инструмента разработки, в котором контент может редактироваться автором.

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

Примечания
  1. Настоящий стандарт применим как в отношении отдельных приложений, так и в отношении коллекций приложений.
  2. Несколько авторов могут участвовать в создании контента и, в зависимости от инструмента разработки, каждый автор может работать с разными представлениями контента и разными разрешениями автора.
  3. Для целей настоящего стандарта не является инструментом разработки программное обеспечение, которое собирает данные от человека для других целей (например, онлайн-форма заказа продуктов), а затем создает контент из этих данных (например, складской заказ в Интернете) без информирования человека (однако ГОСТ Р 52872 все равно применяется в отношении таких приложений).
  4. Для целей настоящего стандарта не является инструментом разработки программное обеспечение, используемое для создания контента исключительно в технологиях, не подпадающих под действие ГОСТ Р 52872.
  5. Для целей настоящего стандарта не являются инструментами разработки приложения, которые позволяют людям изменять контент, с которым сталкиваются только они сами (например, настройки отображения электронной почты в Интернете) или которые предоставляют только ввод для автоматизированных процессов (например, страница поиска по каталогу библиотеки).

Примеры программного обеспечения, которое считается инструментами разработки в настоящем стандарте:

  1. инструменты разработки web-страниц (например, редакторы WYSIWYG HTML).
  2. программное обеспечение для прямого редактирования исходного кода;
  3. программное обеспечение для преобразования в технологии web-контента (например, функция «Сохранить как HTML» в приложениях для работы с офисными документами);
  4. интегрированные среды разработки (например, для разработки web-приложений);
  5. программное обеспечение, которое генерирует web-контент на основе шаблонов, сценариев, ввода из командной строки или процессов типа "мастера";
  6. программное обеспечение для быстрого обновления частей web-страниц (например, блоги, вики, онлайн-форумы);
  7. программное обеспечение для создания / управления целыми web-сайтами (например, системы управления контентом, инструменты курсов, агрегаторы контента);
  8. почтовые клиенты, которые для представления и редактирования сообщений используют технологии web-контента;
  9. Инструменты разработки мультимедиа;
  10. программное обеспечение для создания мобильных web-приложений.

Примеры программного обеспечения, которое не считается инструментами разработки в настоящем стандарте (во всех случаях ГОСТ Р 52872 по-прежнему применяется, если программное обеспечение основано на использовании технологий контента):

  1. настраиваемые личные порталы, чей редактируемый контент доступен только владельцу портала;
  2. Формы заказа электронной коммерции, поскольку цель такой формы — заказать продукт, а не общаться с другими людьми посредством контента, даже если данные, собранные с помощью данной формы, используются для создания контента (например, страниц сопровождения заказа);
  3. автономные средства выявления дефектов доступности, если данные средства не содержат функции автоматического или полуавтоматического изменения контента. Автоматизированные средства устранения дефектов доступности или автоматизированные средства выявления дефектов доступности, которые входят в состав более крупного процесса разработки, будут считаться инструментом разработки.

3.1.41 пользовательский интерфейс инструмента разработки: Механизм отображения и управления, который авторы используют для работы с программным обеспечением инструмента разработки. Пользовательские интерфейсы могут быть основаны на технологиях контента, не основанными на технологиях контента или сочетать данные компоненты (например, инструмент разработки, не основанный на технологиях контента, может иметь справку в формате HTML, то есть основанную на технологиях контента).

3.1.42 пользовательский интерфейс инструмента разработки, не основанный на технологиях контента: Любые части пользовательского интерфейса инструмента разработки, которые не реализованы на основе технологий контента и работают непосредственно на платформе, которая не является пользовательским агентом (например, Windows, Mac OS, виртуальная машина Java, iOS, Android).

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

3.1.44 доступный пользовательский интерфейс инструмента разработки: Пользовательский интерфейс инструмента разработки, соответствующий критериям выполнения части 4.1.

3.1.45 проверка на доступность: Процесс оценки контента на предмет наличия дефектов доступности. Настоящий стандарт выделяет три типа проверки – по степени автоматизации тестов:

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

Инструмент разработки может поддерживать любую комбинацию типов проверки.

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

3.1.47 доступный контент: Контент, который соответствует ГОСТ Р 52872 на уровне А, АА или ААА, при условии, что технологии контента, от которых зависит соответствие критериям выполнения ГОСТ Р 52872, поддерживаются вспомогательными технологиями.

Примечания
  1. Если используемые технологии контента не поддерживаются вспомогательными технологиями, то контент не будет соответствовать ГОСТ Р 52872. В результате одна или несколько групп конечных пользователей с инвалидностью или иными ограничениями жизнедеятельности, вероятно, столкнутся с трудностями при доступе к контенту.
  2. Соответствие ГОСТ Р 52872 даже на самом высоком уровне (то есть уровне ААА) не может сделать контент «доступным для лиц со всеми типами, степенями или комбинациями ограничений жизнедеятельности».

3.1.48 редактируемый контент: Контент, который автор может изменять во время сеанса разработки. Редактируемый контент может быть полным фрагментом контента (например, изображением, таблицей стилей) или только частью большего фрагмента контента (например, обновлением статуса). Редактируемый контент включает только контент в технологиях контента, которые поддерживает инструмент разработки (например, редактор WYSIWYG HTML позволяет редактировать HTML-контент редактируемой web-страницы, но не растровые изображения).

3.1.49 свойства контента: обособленные фрагменты информации, составляющие контент (например, атрибуты и содержимое элементов, информация таблицы стилей).

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

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

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

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

  1. типичное отображение (или «что видишь, то и получаешь»): отображение контента примерно совпадает с представлением, которое по умолчанию сформирует пользовательский агент на основе этого же контента. В то время как «WYSIWYG», обозначающий «Что видишь, то и получаешь», является общим термином, различия в пользовательских агентах и настройках конечных пользователей означают, что на практике пользовательский опыт может существенно варьироваться;
  2. нетипичное отображение: контент отображается иначе, чем в типичном пользовательском агенте (например, визуальное представление аудиофайла в виде графической волновой формы, а не воспроизведение аудио);
  3. частичное отображение: отображаются, воспроизводятся или исполняются одни аспекты контента, но не другие (например, покадровый видеоредактор отображает графическую, но не временную составляющую видео).

3.1.53 трансформации контента: Процессы, которые принимают контент в одной технологии контента в качестве входных данных и создают контент, который был оптимизирован, реструктурирован или перекодирован:

  1. оптимизация контента: преобразования, при которых не изменяется технология контента, а также сохраняются все используемые структурные особенности технологии контента. Предполагается, что данные изменения не приводят к потере информации (например, удаление пробелов, замена встроенных стилей внешней таблицей стилей).
  2. реструктуризация контента: преобразования, при которых технология контента остается прежней, но изменяются структурные особенности технологии, используемой для разметки контента (например, линеаризация таблиц, разделение документа на страницы);
  3. перекодирование контента: преобразования, в которых технология контента, используемая для кодирования контента, изменяется (например, HTML на XHTML, редактируемый документ в HTML).
Примечание — Операции с буфером обмена, при которых содержимое копируется в буфер обмена платформы или вставляется из него, не считаются преобразованиями контента.

3.1.54 настройки управления: Настройки, которые относятся к тому, как авторы управляют инструментом разработки, например, с помощью клавиатуры или мыши.

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

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

3.1.57 настройки представления: Параметры, относящиеся к тому, как авторы воспринимают инструмент разработки. Настройки представления включают:

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

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

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

3.1.60 элемент: Любая дискретная единица контента (например, конкретное изображение, видео, звук, заголовок, список или элемент списка). Набор поддерживаемых элементов зависит от технологий контента.

3.1.61 конечный пользователь: Человек, который взаимодействует с контентом после его создания (включая пользователей вспомогательных технологий).

3.1.62 естественный язык: Язык, на котором изъясняются при помощи устной, письменной и жестовой речи (воспринимая последнюю визуально или тактильно) при общении с людьми.

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

наклейки на клавиатуру, наклейки на клавиши клавиатуры, наклейки на клавиатуру прозрачные, наклейки со шрифтом брайля, наклейки букв на клавиатуру
Тактильные наклейки 100x350мм Артикул: 10047 Размеры: 100x350x1 мм Производитель в России: ООО «Вертикаль» Скачать тех. задание
Примечание — Эмуляторы мыши, управляемые клавиатурой, такие как MouseKeys, не считается работой через интерфейс клавиатуры, поскольку данные эмуляторы используют интерфейсы указывающих устройств, а не интерфейсы клавиатуры.

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

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

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

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

3.1.67 язык разметки: Технология контента, основанная на Системе текстовых аннотаций (например, элементы в HTML) и правил обработки, которые могут использоваться для определения структуры, представления или семантики контента. Примеры языков разметки включают HTML и SVG.

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

3.1.69 нетекстовый контент: Любой контент, который не является последовательностью символов, которая может быть определена программно, или такая последовательность символов, которая не выражает что-либо на естественном языке. Нетекстовый контент включает в себя ASCII Art (который представляет собой образец символов), смайлики и графическое представление текста.

3.1.70 платформа: Программная среда, в которой функционирует инструмент разработки. Платформы обеспечивают согласованную операционную среду поверх программных платформ или оборудования более низкого уровня. Для пользовательских интерфейсов инструментов разработки, основанных на технологиях контента, наиболее подходящей платформой является пользовательский агент (например, браузер). Для пользовательских интерфейсов, не основанных на технологиях контента, диапазон платформ включает, помимо прочего, настольные операционные системы (например, рабочий стол GNOME в Linux, Mac OS, Windows), мобильные операционные системы (например, Android, BlackBerry, iOS), или среды с несколькими ОС (например, Java) и т.д.

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

3.1.71 служба доступности платформы: Программный интерфейс, специально разработанный для обеспечения взаимодействия между приложениями и вспомогательными технологиями (например, MSAA, IAccessible2 и UI Automation для приложений Windows, AXAPI для приложений Mac OS X, API GNOME Accessibility Toolkit для приложений GNOME, Java Access для приложений Java). На некоторых платформах дальнейшее улучшение данного взаимодействия происходит за счет реализации объекта документа.

3.1.72 подключаемый модуль: Программа (плагин, расширение, надстройка), которая запускается как часть инструмента разработки (например, сторонний инструмент проверки и исправления ) и не является частью редактируемого контента. Авторы обычно включают или отключают подключаемые модули в используемых инструментах разработки.

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

Примечания
  1. Для шаблонов, то есть для незавершенной формы предварительно созданного контента, см. 4.2.2.4.
  2. Если инструмент разработки автоматически использует предварительно созданный контент, см. 4.2.1.1

3.1.74 предварительно созданный доступный контент: Предварительно созданный контент, который либо уже является доступным контентом, либо станет доступным, если он будет надлежащим образом вставлен в пустой документ.

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

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

3.1.76 отображение: Предоставление контента в форме, понятной авторам или конечным пользователям.

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

  1. обработка контента: может ли инструмент разработки извлекать информацию из контента (например, получить информацию о языке контента из разметки);
  2. взаимодействие между инструментом разработки и вспомогательными технологиями: для пользовательских интерфейсов, не основанных на технологиях контента, это означает использование служб доступности платформы, API-интерфейсов и, в некоторых случаях, объектных моделей документов. Для пользовательских интерфейсов, основанных на технологиях контента, это означает обеспечение того, чтобы пользовательский агент мог передавать информацию (например, с помощью WAI-ARIA).

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

3.1.79 столь же воспринимаемый: Компонент пользовательского интерфейса A считается «по крайней мере таким же воспринимаемым», как другой компонент B, когда из состояния по умолчанию компонент A отображается (и включается) тем же или меньшим количеством «действий открытия», необходимых для отображения (и включения) компонента B.

Примечания
  1. Когда контейнер открыт, все включенные компоненты в контейнере (например, элементы в списке, элементы в меню, кнопки на панели инструментов, все компоненты в диалоговом окне) считаются отображаемыми (и, следовательно, по крайней мере, такими же воспринимаемыми, как остальные), даже если контейнер необходимо прокрутить, чтобы они стали видимыми. При этом учитывается, что разные размеры экрана и предпочтения авторов будут влиять на то, какие компоненты видны в данный момент.
  2. «Действия открытия» — это действия, выполняемые авторами над компонентами в пользовательском интерфейсе, которые приводят к отображению или включению новых компонентов. Например: ввод сочетания клавиш для пункта меню верхнего уровня для отображения вложенного меню, клавиша быстрого доступа, позволяющая активировать кнопку и вывести на экран диалоговое окно, щелчок мышью по флажку, чтобы включить ранее отключенные элементы и т. д. Действия, которые не приводят к тому, что новые компоненты становятся активными (например, перемещение фокуса, прокрутка списка), не считаются «действиями открытия»;
  3. сочетания клавиш для компонентов в закрытых контейнерах не считаются «действиями открытия», поскольку компоненты не выделяются, когда они не отображаются. То же самое верно, когда авторы должны использовать «поиск» для выявления компонентов в закрытых контейнерах.
  4. «Состояние по умолчанию» — это состояние инструмента разработки в начале сеанса разработки, установленное разработчиком. Состояние по умолчанию многих инструментов разработки — это режим редактирования.

3.1.80 подсказка: Любой запрос к автору, инициированный инструментом разработки для получения решения или части информации. Этот термин охватывает как запросы, на которые необходимо немедленно отвечать (например, модальные диалоговые окна), так и менее срочные запросы (например, подчеркивание слова с ошибкой).

3.1.81 публикация: Любой момент, когда авторы или инструмент разработки делают контент доступным для конечных пользователей (например, загрузка web-страницы, фиксация изменения в вики, прямая трансляция).

3.1.82 диапазон: Более одного элемента в наборе из нескольких элементов.

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

3.1.83 отношения: Значимые ассоциации между отдельными частями контента.

3.1.84 исправление: Процесс устранения проблем доступности, которые были выявлены в контенте. Определены три типа исправлений, основанные на повышении уровня автоматизации:

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

3.1.85 ограничения, ограниченное создание web-контента: Когда контент, который авторы могут указать с помощью инструмента разработки, должен включать или не включать определенный контент (например, элементы, атрибуты, виджеты). Многие инструменты разработки каким-либо образом ограничивают создание, что может либо улучшить доступность (например, если требуется альтернативный текст для нетекстового содержимого), либо уменьшить доступность (например, если атрибуты для определения альтернативного текста недоступны). Напротив, инструменты разработки, которые позволяют неограниченное создание контента, не требуют, чтобы какой-либо конкретный контент был включен или не включен (например, многие виды редактирования исходного кода).

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

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

3.1.88 технологии контента: Механизм кодирования инструкций и данных, которые должны отображаться, воспроизводиться или выполняться пользовательскими агентами. Технологии контента могут включать языки разметки, форматы данных или языки программирования, которые авторы могут использовать по отдельности или в комбинации для создания возможностей конечного пользователя, которые варьируются от статического текстового контента до мультимедийных презентаций и динамических приложений. Некоторые распространенные примеры технологий контента включают XML, XSL, HTML, CSS, SVG, PNG, PDF, JavaScript, AJAX, ePub, FictionBook, XPS, DAISY, MathMl, HTMLHelp, OpenDocument Format, Office Open XML.

3.1.89 шаблон: Шаблоны контента, которые заполняются авторами или инструментом разработки для создания контента для конечных пользователей (например, шаблоны документов, шаблоны управления контентом, темы презентаций). Как правило, шаблоны заранее определяют некоторые авторские решения.

3.1.90 доступный шаблон: Шаблон, который можно заполнить для создания контента, отвечающего требованиям ГОСТ Р 52872 (уровень А, АА или ААА), если одновременно выполняются следующие условия:

  1. Автор правильно следует всем предоставленным инструкциям (например, правильно отвечает на запросы, правильно заменяет выделенные заполнители);
  2. Дальнейшей разработки не происходит.
Примечание — В этих условиях некоторые шаблоны приводят к полностью пустым документам, которые по умолчанию считаются доступными.

3.1.91 недоступный шаблон: Шаблон, не соответствующий определению термина "доступный шаблон".

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

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

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

3.1.95 пользовательский агент: Любое программное обеспечение, которое извлекает, обрабатывает и облегчает взаимодействие конечного пользователя с контентом (например, web-браузеры, подключаемые модули браузера, медиаплееры).

3.1.96 пользовательский агент, присутствующий на рынке: Пользовательский агент, который может быть приобретен представителями общественности (бесплатно или иным образом). Обычно пользовательский агент, присутствующий на рынке, представляет собой отдельное программное обеспечение от инструмента разработки; однако иногда программное обеспечение может сочетать в себе функции пользовательского агента и Инструмента разработки. Эти случаи включают:

  1. Только для предварительного просмотра: если пользовательский агент может отображать только контент, который он получает от связанных функций разработки, тогда программное обеспечение является инструментом разработки с функцией предварительного просмотра. Такие функции, предназначенные только для предварительной версии, не считаются пользовательскими агентами, имеющимися на рынке.
  2. Пользовательский агент с режимом инструмента разработки: если функциональность агента пользователя должна извлекать и открывать контент, прежде чем его можно будет отправить в функциональность инструмента разработки, то программное обеспечение является агентом пользователя с режимом инструмента разработки. Если пользовательский агент используется для предварительного просмотра контента, созданного в режиме инструмента разработки, он должен рассматриваться как пользовательский агент, присутствующий на рынке.
  3. Комбинированный пользовательский агент / средство разработки: пользовательский агент, в котором режим взаимодействия с пользователем по умолчанию позволяет редактировать контент. Эти инструменты не нуждаются в предварительном просмотре, потому что автор уже знаком с контентом так же, как и конечные пользователи.

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

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

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

  1. область редактирования: представление, в котором можно редактировать часть или весь контент;
  2. предварительный просмотр: представления, в котором не предусмотрены действия по созданию (т. е. представление не редактируется). Предварительные просмотры предусмотрены для представления редактируемого контента с помощью Инструмента разработки в том виде, как это представят пользовательские агенты конечным пользователям. Предварительный просмотр может быть реализован с использованием реальных пользовательских агентов, присутствующих на рынке, но это не является обязательным.

Возможны несколько вариантов отображения контента:

  1. исходное содержимое: контент представлен в необработанной форме (например, разметка контента в текстовых редакторах).
  2. визуализированные отображение: представлены визуализации контента (обычные, нестандартные или частичные).
  3. отображение свойств: представлены только свойства содержимого. Затем инструмент разработки использует эти свойства для автоматической генерации контента, который будет опубликован (например, виджет календаря CMS, который генерирует календарь по числовым значениям месяца и года).

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

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

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

3.1.103 капча (captcha): Акроним, означающий «полностью автоматизированный тест Тьюринга для различения компьютеров и людей» («Completely Automated Public Turing test to tell Computers and Humans Apart»)

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

3.1.104 недоступный контент: Контент, не соответствующий определению термина "доступный контент".

3.1.105 параметр по умолчанию: Параметр или значение параметра, которое автоматически назначается средством разработки и остается в силе, если оно не отменено или не изменено автором.

3.1.106 предварительно созданный недоступный контент: Предварительно созданный контент, не соответствующий определению термина "предварительно созданный доступный контент".

3.1.107 Цифровой контент: См. контент.

3.2 В настоящем стандарте приняты следующие сокращения:

  • AJAX — Asynchronous Javascript and XML;
  • API: Application Programming Interface;
  • CSS — Cascading Style Sheets;
  • DAISY — Digital accessible information system;
  • DOM — Document Object Model;
  • ePub — Electronic Publication;
  • HTML — (HyperText Markup Language;
  • MathML — Mathematical Markup Language;
  • PDF — Portable Document Format;
  • PNG — Portable Network Graphics;
  • SVG — Scalable Vector Graphics;
  • URL — Uniform Resource Locator;
  • WAI-ARIA — Web Accessibility Initiative — Accessible Rich Internet Applications;
  • WWW — World Wide Web;
  • XML — eXtensible Markup Language;
  • XPS — XML Paper Specification;
  • XSL — eXtensible Stylesheet Language.

4. Доступность инструментов разработки цифрового контента

4.1 Доступный пользовательский интерфейс

Примечания по применимости требований соответствия части 4.1:

  1. критерии выполнения части 4.1 применяются ко всем аспектам пользовательского интерфейса инструмента разработки, которые связаны с созданием контента на основе поддерживаемых инструментом технологий. Это включает в себя область редактирования контента и компоненты, которые не зависят от редактируемого контента (например, настройки пользователя, документация и такие элементы пользовательского интерфейса, как меню, кнопки, строка состояния и так далее);
  2. инструмент разработки должен обеспечивать такой способ отображения редактируемего контента в области редактирования, который более доступен для авторов с ограничениями жизнедеятельности (например, обеспечить, чтобы альтернативный текст в содержании был программно определен). Однако, если проблема доступности пользовательского интерфейса инструмента разработки вызвана непосредственно редактируемым контентом (например, если изображение в контенте не имеет альтернативного текста), то это не будет считаться проблемой доступности пользовательского интерфейса инструмента разработки;
  3. критерии выполнения Части 4.1 применяются только к пользовательскому интерфейсу инструмента разработки, предоставленному разработчиком. Они не применяются к любым последующим модификациям сторонних разработчиков, кроме разработчика инструмента (например, пользовательские модификации настроек по умолчанию, сторонние подключаемые модули). Также и уровни соответствия относятся к указанному инструменту разработки и не распространяются на последующие модификации сторонних разработчиков;
  4. Инструмент разработки може полагаться на функции пользовательского агента (например, навигация с помощью клавиатуры, функции поиска, настройки отображения, функции отмены) для удовлетворения критериев выполнения. В документации должны быть указаны соответствующие пользовательские агенты;
  5. критерии выполнения части 4.1 применяются ко всему пользовательскому интерфейсу инструмента разработки, включая любые функции, добавленные для соответствия критериям выполнения Части 4.1 (например, документация, функции поиска). Единственное исключение — режим предварительного просмотра, если он соответствуют критериям выполнения, указанным в 4.1.3.7, обрабатывается иначе, чем режим редактирования, потому что все авторы, в том числе с ограничениями жизнедеятельности, заинтересованы в том, чтобы предварительный просмотр соответствовал представлению контента в пользовательских агентах, которые фактически применяются конечными пользователями;
  6. когда критерии выполнения требуют, чтобы инструменты разработки обрабатывали цифровой контент в соответствии с семантическими критериями, критерии выполнения применяются только тогда, когда эта семантика кодируется программно (например, текст, описывающий изображение, может считаться альтернативным текстом для нетекстового контента, когда эта роль представлена в разметке).

4.1.1 Принцип 1: Пользовательские интерфейсы инструмента разработки соответствуют применимым требованиям доступности

4.1.1.1 Реализация требований ГОСТ Р 52872-2019

Инструмент разработки или его части, пользовательский интерфейс которых основан на технологиях контента, в отношении которых применим ГОСТ Р 52872-2019, должны соответствовать требованиям ГОСТ Р 52872-2019. Это облегчит доступ к пользовательскому интерфейсу всех авторов, включая тех, кто использует вспомогательные технологии.

4.1.1.1.1. Доступность по ГОСТ Р 52872-2019

Если инструмент разработки содержит пользовательский интерфейс, в отношении которого применим ГОСТ Р 52872-2019, то этот интерфейс соответствует ГОСТ Р 52872-2019 (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019).

4.1.1.1.2 Реализация требований доступности платформы

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

4.1.1.2.1 Соответствие требованиям платформы

Если инструмент разработки содержит пользовательские интерфейсы, в отношении которых не применяется ГОСТ Р 52872-2019,то эти пользовательские интерфейсы соответствуют требованиям или рекомендациям по обеспечению доступности пользовательского интерфейса платформы (уровень А).

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

4.1.1.2.2 Службы доступности платформы

Если инструмент разработки содержит пользовательские интерфейсы, в отношении которых не применяется ГОСТ Р 52872-2019, то эти пользовательские интерфейсы предоставляют информацию доступности через службы доступности платформы (уровень А).

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

4.1.2 Принцип 2: Воспринимаемость области редактирования

4.1.2.1 Доступность альтернативного контента

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

4.1.2.1.1 Альтернативный текст для визуализированного нетекстового контента

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

4.1.2.1.2 Альтернативный контент для временных медиа

Если область редактирования отображает временные медиа, то верно хотя бы одно из следующих условий (уровень А):

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

4.1.2.2 Идентификация представления в области редактирования

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

4.1.2.2.1 Индикаторы состояния области редактирования

Если область редактирования добавляет индикаторы состояния к редактируемому контенту, то информация, передаваемая индикаторами состояния, может быть определена программно (уровень А).

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

4.1.2.2.2 Доступ к свойствам визуализированного текста

Если область редактирования отображает какие-либо свойства форматирования текста, которые авторы могут изменять в области редактирования, то эти свойства могут быть определены программно (уровень АА).

4.1.3 Принцип 3: Работоспособность области редактирования

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

4.1.3.1.1 Доступ с клавиатуры (минимум)

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

Примечания
  1. интерфейсы клавиатуры — это программные службы, предоставляемые многими платформами, которые позволяют работать независимо от устройства. Этот критерий выполнения не подразумевает наличие аппаратной клавиатуры.
  2. исключение пути относится к базовой функции, а не к способу ввода. Например, при использовании рукописного ввода для ввода текста метод ввода (рукописный ввод) требует ввода, зависящего от пути, а основная функция (ввод текста) — нет. Исключение пути охватывает другие входные переменные, которые непрерывно выбираются с указывающих устройств, включая давление, скорость и угол.
  3. этот критерий выполнения не запрещает и не должен препятствовать использованию других методов ввода (например, мыши, касания) в дополнение к работе с клавиатурой.

4.1.3.1.2 Отсутствие клавиатурных ловушек

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

4.1.3.1.3 Эффективный доступ с клавиатуры

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

4.1.3.1.4 Доступ с клавиатуры (расширенный)

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

4.1.3.1.5 Настройка доступа с клавиатуры

Если инструмент разработки поддерживает клавиатурные команды, то эти клавиатурные команды можно настроить (уровень ААА).

4.1.3.1.6 Текущие клавиатурные команды

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

4.1.3.2 Отсутствие ограничений времени

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

4.1.3.2.1 Автосохранение (минимум)

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

4.1.3.2.2 Регулировка времени

Инструмент разработки не имеет ограничений по времени или верно хотя бы одно из следующих условий (уровень А):

  1. авторам предоставлена возможность отключать ограничение по времени до того, как оно возникнет;
  2. Авторам предоставлена возможность регулировать продолжительность ограничения по времени до того, как оно возникнет, в широком диапазоне, который как минимум в десять раз превышает значение настройки по умолчанию;
  3. авторов предупреждают до истечения времени, и им дается не менее 20 секунд, чтобы продлить срок с помощью простого действия (например, «нажмите клавишу пробела»), и авторам разрешается продлевать срок не менее десяти раз;
  4. ограничение по времени является обязательной частью события в реальном времени (например, совместной авторской системы), и никакая альтернатива ограничения по времени невозможна;
  5. ограничение по времени является существенным, и его продление сделало бы действие недействительным;
  6. 20-часовое исключение: ограничение по времени превышает 20 часов.

4.1.3.2.3 Неподвижные компоненты, принимающие пользовательский ввод

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

4.1.3.2.4 Сохранение изменений контента (расширенные)

Инструмент разработки можно настроить на автоматическое сохранение изменений контента, сделанных с помощью инструмента разработки (уровень ААА).

4.1.3.3 Предотвращение вспышек, которые могут вызвать судороги

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

4.1.3.3.1 Вариант статического просмотра

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

4.1.3.4 Улучшение навигации и редактирования с помощью структуры контента

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

4.1.3.4.1 Структурная навигация

Если область редактирования отображает элементы разметки редактируемого контента, то элементы разметки (например, исходный код, отображения контента) можно выбрать и предоставлен механизм перемещения фокуса выбора между элементами (уровень АА).

4.1.3.4.2 Навигация по программным взаимосвязям

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

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

4.1.3.5 Текстовый поиск по контенту

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

4.1.3.5.1 Текстовый поиск

Если инструмент разработки предоставляет область редактирования для текстового содержимого, то область редактирования позволяет выполнять поиск по тексту, так что выполняются все следующие условия (уровень АА):

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

Инструмент разработки должен предоставлять авторам возможность установить свои собственные параметры отображения таким образом, чтобы они отличались от представления, которое они хотят определить для опубликованного контента. Предоставление возможности сохранять и перезагружать наборы настроек клавиатуры и отображения полезно авторам, потребности которых со временем меняются (например, из-за усталости).

4.1.3.6.1 Независимость отображения

Если инструмент разработки поддерживает параметры отображения для областей редактирования, то инструмент разработки позволяет авторам настраивать эти параметры без изменения редактируемого контента (уровень А).

4.1.3.6.2 Сохранение настроек

Если инструмент разработки поддерживает параметры отображения и/или управления, то эти параметры можно сохранять между сеансами разработки (уровень АА).

4.1.3.6.3 Настройки платформы

Инструмент разработки учитывает изменения в настройках отображения и управления платформой, если только авторы не выберут конкретные параметры отображения и управления с помощью инструмента разработки (уровень АА).

4.1.3.7 Доступность предварительного просмотра

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

4.1.3.7.1 Предварительный просмотр (минимум)

Если предварительный просмотр предоставляется, то верно хотя бы одно из следующих условий (уровень А):

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

4.1.4 Принцип 4: Понятность области редактирования

4.1.4.1 Предотвращение и исправление ошибок

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

4.1.4.1.1 Обратимые изменения контента (минимум)

Все действия по разработке контента либо обратимы, либо инструмент разработки требует подтверждения автора для продолжения (уровень А).

4.1.4.1.2 Подтверждение изменения настроек

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

4.1.4.1.3 Обратимые изменения контента (улучшенные)

Авторы могут последовательно отменить серию обратимых авторских действий (уровень ААА).

Примечание — Допускается очищать историю действий в конце сеанса разработки.

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

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

4.1.4.2.1 Для каждой функции инструмента разработки, которая используется для соответствия Части 4.1 настоящего стандарта, выполняется хотя бы одно из следующих условий (уровень A):

  1. Использование функции объясняется в документации инструмента разработки;
  2. использование функции объясняется в пользовательском интерфейсе инструмента разработки;
  3. функция — это служба, предоставляемая базовой платформой;
  4. функция не используется напрямую авторами (например, передача информации в службу доступности платформы).
Примечание — Доступность документации регулируется 4.1.1.1 и 4.1.1.2.

4.1.4.2.2Документирование всех функций

Для каждой функции инструмента разработки выполняется хотя бы одно из следующих условий (уровень АА):

  1. Использование функции объясняется в документации инструмента разработки;
  2. использование функции объясняется в пользовательском интерфейсе инструмента разработки;
  3. функция — это служба, предоставляемая базовой платформой;
  4. функция не используется напрямую авторами (например, передача информации в службу доступности платформы).
Примечание — Доступность документации регулируется 4.1.1.1 и 4.1.1.2.

4.2 Создание доступного контента

Примечания по применимости требований соответствия части 4.2:

  1. любые критерии выполнения Части 4.2, относящиеся к авторам, применяются только во время сеансов разработки.
  2. критерии выполнения Части 4.2 применимы только к инструменту разработки, предоставленному разработчиком. Сюда не входят последующие изменения, внесенные сторонами, кроме разработчика инструмента разработки (например, сторонние подключаемые модули, пользовательские шаблоны, пользовательские модификации настроек по умолчанию).
  3. инструменты разработки обеспечивают доступность контента, которые они автоматически создают после окончания авторской сессии разработки (см 4.2.1.1.1). Например, если разработчик изменяет общесайтовые шаблоны системы управления контентом, они должны соответствовать требованиям доступности для автоматически генерируемого контента. Инструменты разработки не несут ответственности за изменения доступности контента, вызванные автором, независимо от того, был ли контент создан автором или автоматически создается другой системой, указанной автором (например, сторонним источником контента).
  4. согласно определению инструмента разработки в настоящем стандарте, несколько программных инструментов могут использоваться вместе для удовлетворения требований Части 4.2 (например, инструмент разработки может использовать сторонний инструмент проверки доступности).
  5. критерии выполнения части 4.2 применяются ко всему пользовательскому интерфейсу инструмента разработки, включая любые функции, которые должны присутствовать, чтобы соответствовать критериям выполнения в Части 4.2 (например, инструменты проверки, инструменты для исправления, учебники, документация).
  6. инструмент разработки может поддерживать несколько ролей авторов, каждой из которых соответствуют разные представления контента и разрешения на его редактирование (например, система управления контентом может разделять роли дизайнеров, авторов статей и лиц, выполняющих модерирование). В этих случаях критерии выполнения Части 4.2 применяются к инструменту разработки в целом, а не к представлению, соответствующему какой-либо конкретной роли автора. Функции поддержки доступного контента должны быть доступны любой роли автора, где это может быть необходимо.
  7. когда критерии выполнения требуют, чтобы инструменты разработки обрабатывали цифровой контент в соответствии с семантическими критериями, критерии выполнения применяются только тогда, когда эта семантика кодируется программно (например, текст, описывающий изображение, может считаться альтернативным текстом для нетекстового контента, когда эта роль кодируется в разметке).

4.2.1 Принцип 5: Создание доступного контента автоматическими процессами

Если инструмент разработки автоматически создает контент, то созданный контент должен соответствовать требованиям ГОСТ Р 52872-2019.

4.2.1.1.1 Автоматическое создание контента после сеансов разработки

Инструмент разработки не создает автоматически контент после завершения сеанса разработки, или авторы могут указать, что создаваемый контент должен быть доступным контентом (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019).

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

4.2.1.1.2 Автоматическое создание контента во время сеансов разработки

Если инструмент разработки предоставляет функциональные возможности для автоматического создания контента во время сеанса разработки, то выполняется хотя бы одно из следующих условий (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; Уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019):

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

4.2.1.2 Сохранение информации доступности

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

4.2.1.2.1 Реструктуризация и перекодирование

Если инструмент разработки обеспечивает реструктуризацию или перекодирование контента, и если эквивалентные механизмы существуют в технологии результирующего контента, то выполняется хотя бы одно из следующих условий (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; Уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019):

  1. информация доступности сохраняется в выходных данных;
  2. по умолчанию инструмент разработки предупреждает авторов о том, что информация доступности может быть потеряна (например, при сохранении векторной графики в формат растрового изображения);
  3. после преобразования инструмент разработки выполняет проверку доступности;
  4. после преобразования инструмент разработки предлагает авторам выполнить проверку доступности.
Примечания
  1. Для альтернативного текста нетекстового контента см 4.2.1.2.4.
  2. Этот критерий выполнения применяется только тогда, когда технология результирующего контента должна соответствовать настоящему стандарту.

4.2.1.2.2 Копирование и вставка внутри процесса разработки

Если инструмент разработки поддерживает копирование и вставку структурированного контента, то любая информация доступности в скопированном контенте сохраняется, если инструмент разработки является и источником, и местом назначения для копирования и вставки, а источник и место назначения используют одну и ту же технологию контента (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019).

4.2.1.2.3 Сохранение информации доступности при оптимизации

Если инструмент разработки обеспечивает оптимизацию контента, то любая информация доступности (во входных данных сохраняется в выходных (уровень А).

4.2.1.2.4 Сохранение альтернативного текста для нетекстового контента

Если инструмент разработки предоставляет преобразования контента, которые сохраняют нетекстовый контент в выходных данных, то любой альтернативный текст для этого нетекстового контента также сохраняются, если эквивалентные механизмы существуют в технологии контента выходных данных (уровень А).

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

4.2.2 Принцип 6: Поддержка авторов в создании доступного контента

4.2.2.1 Возможность создания доступного контента

Инструмент разработки должен предоставлять автору возможность создавать контент, соответствующий требованиям ГОСТ Р 52872-2019, а также необходимую для этого функциональность.

4.2.2.1.1 Возможный доступный контент

Инструмент разработки не накладывает ограничений на контент, который могут указывать авторы, или эти ограничения не препятствуют выполнению критериев ГОСТ Р 52872-2019 (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019).

4.2.2.2 Указание авторам на возможность создания доступного контента

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

4.2.2.3.1 Воспринимаемость вариантов с доступным контентом

Если инструмент разработки предоставляет авторам выбор действий для достижения одного и того же результата (например, стилизация текста), то варианты, которые приведут к созданию доступного контента, будут по крайней мере столь же воспринимаемы, как и варианты, которые этого не делают (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019).

4.2.2.3.2 Настройка специальных возможностей

Если инструмент разработки предоставляет механизмы для установки свойств контента (например, значений атрибутов), то также предоставляются механизмы для установки свойств контента, связанных с информацией доступности (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019).

Примечание — Описание механизмов см. 4.2.4.1.4.

4.2.2.3 Помощь авторам в управлении альтернативным контентом

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

Примечание — Если нетекстовый контент автоматически добавляется инструментом разработки, см. 4.2.1.1.

4.2.2.3.1 Альтернативный контент доступен для редактирования

Если инструмент разработки предоставляет возможности для добавления нетекстового содержимого, то авторы могут программно изменять связанный альтернативный текст для нетекстового контента (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019).

Примечание — Исключение может быть сделано, если известно, что нетекстовое содержимое является оформлением, форматированием, невидимым или капчей.

4.2.2.3.2 Автоматическое восстановления альтернативного текста

Инструмент разработки не пытается восстановить альтернативный текст для нетекстового контента, или выполняются все следующие условия (уровень А):

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

4.2.2.3.3 Сохранение для повторного использования

Если инструмент разработки предоставляет возможности для добавления нетекстового контента, то когда авторы вводят программно связанный альтернативный текст для нетекстового контента, одновременно выполняются следующие условия (уровень ААА):

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

4.2.2.3.4 Доступные шаблоны

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

4.2.2.4.1 Выбор доступных шаблонов

Если инструмент разработки предоставляет шаблоны, то предоставляются и варианты доступных шаблонов для различных диапазонов использования шаблонов (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019).

4.2.2.4.2 Идентификация доступного шаблона

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

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

4.2.2.4.3 Шаблоны, созданные автором

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

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

4.2.2.4.4 Доступные параметры шаблона (расширенные)

Если инструмент разработки предоставляет шаблоны, то все шаблоны доступны для всех (до уровня АА ГОСТ Р 52872-2019) (уровень ААА).

4.2.2.4 Предварительно созданный доступный контент

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

4.2.2.4.1 Варианты предварительно созданного доступного контента

Если инструмент разработки предоставляет автору предварительно созданный контент, то предоставляется и варианты предварительно созданного доступного контента, соответствующие ГОСТ Р 52872-2019 до уровня АА включительно (уровень АА).

4.2.2.4.2 Идентификация предварительно созданного доступного контента

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

Примечание — Различие может включать предоставление информации о предварительно созданном доступном контенте, о предварительно созданном недоступном контенте или о том и другом.

4.2.3 Принцип 7: Улучшение доступности существующего контента

4.2.3.1 Выявление проблем доступности

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

4.2.3.1 Выявление проблем доступности

Если инструмент разработки предоставляет авторам возможность добавлять или изменять контент таким образом, что критерий ГОСТ Р 52872-2019 может быть нарушен, то предоставляется проверка доступности для этого критерия (например, инструмент разработки HTML-документа, при вставке изображения должен проверять наличие альтернативного текста; инструмент разработки видео с возможностью редактирования текстовых дорожек должен проверять наличие субтитров) (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019).

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

4.2.3.1.2 Инструкции по выявлению проблем доступности

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

4.2.3.1.3 Идентификация проверяемого контента

Если инструмент разработки выполняет ручную или полуавтоматическую проверки, которые требуют от авторов решения, правильно ли выявлена потенциальная проблема доступности, то связанный с проблемой контент идентифицируется авторами (уровень А).

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

4.2.3.1.4 Отчет о результатах проверок

Авторы могут получить отчет о статусе доступности на основе результатов проверок доступности, выполненных инструментом разработки (уровень АА).

Примечание — Формат отчета о состоянии доступности не указан, и он может содержать список обнаруженных проблем или уровень соответствия ГОСТ Р 52872-2019 и т.д.

4.2.3.1.5 Программная ассоциация результатов

Инструмент разработки может программно связать результаты выполненной им проверки доступности с проверяемым контентом (уровень АА).

4.2.3.2 Устранение проблем доступности

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

4.2.3.2.1 Помощь в исправлении

Если проверка (4.2.3.1.1) может обнаружить, что критерий ГОСТ Р 52872-2019 не соблюдается, то предлагаются варианты исправлений (уровень А для соответствия критериям ГОСТ Р 52872-2019 Уровень А; Уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019).

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

4.2.4 Принцип 8: Интеграция специальных возможностей инструментов разработки

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

4.2.4.1.1 Функции, активные по умолчанию

Все функции поддержки доступного контента включены по умолчанию (уровень А).

4.2.4.1.2 Возможность повторной активации функций

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

4.2.4.1.3 Предупреждение об отключении функции

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

4.2.4.1.4 Воспринимаемые функции

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

4.2.4.2 Документация, способствующая созданию доступного контента

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

4.2.4.2.1 Типовая практика

Диапазон примеров в документации (например, разметка, скриншоты WYSIWYG области редактирования) показывают методы разработки доступного контента (уровень А соответствует критериям ГОСТ Р 52872-2019 уровня А; уровень АА соответствует критериям ГОСТ Р 52872-2019 уровней А и АА; уровень ААА соответствует всем критериям ГОСТ Р 52872-2019 на).

4.2.4.2.2 Инструкции по функциям

Инструкции по использованию любых функций поддержки доступного контента приведены в документации (уровень А).

4.2.4.2.3 Учебное пособие

Инструмент разработки предоставляет учебное пособие для специфичного для этого инструмента разработки процесса разработки доступного контента(уровень ААА).

4.2.4.2.4 Указатель инструкций

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

5. Реализация соответствия настоящему стандарту

Соответствие настоящему стандарту означает, что инструмент разработки удовлетворяет применимым критериям выполнения, определенным в предыдущем разделе. Настоящий раздел описывает варианты соответствия и перечисляет правила проверки на соответствие.

5.1 Требования к соответствию

5.1.1 Соответствие критериям выполнения

Для определения соответствия Настоящему стандарту необходимо выполнить оценку соответствия критериям выполнения. Возможные результаты:

  1. неприменимо: определение инструмента разработки в настоящем стандарте является всеобъемлющим и, как таковое, охватывает программное обеспечение с широким диапазоном возможностей и контекстов работы. Чтобы учесть инструменты разработки с ограниченным набором функций (например, редактор фотографий, редактор CSS, поле обновления статуса в приложении социальной сети), многие критерии выполнения настоящего стандарта являются условными и применяются только к инструментам разработки с данными функцииями. В документации инструмента разработки должно быть объяснение того, почему конкретный критерий выполнения не применяется;
  2. "Да" (выполняется на соответствующем уровне): в случае некоторых критериев уровень будет связан с критериями ГОСТ Р 52872-2019 ((уровни А, АА или ААА);
  3. "Нет" (не выполняется).

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

Согласно 5.4 ГОСТ Р 52872-2019: «Способы использования технологий только с поддержкой средств доступности гарантированно удовлетворяют критериям успешного применения. Любая информация или функциональность, представленная без поддержки средств доступности, также должна быть представлена альтернативной версией с поддержкой средств доступности".

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

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

  1. Настоящий стандарт не использует 5.4 ГОСТ Р 52872-2019. В результате критерии выполнения Настоящего стандарта не ссылается на соответствие ГОСТ Р 52872-2019, а вместо этого ссылается на соответствие критериям ГОСТ Р 52872-2019.
  2. После того, как инструмент разработки будет установлен и введен в действие, можно будет проверить контент, создаваемый этим инструментом, на соответствие ГОСТ Р 52872-2019 (в том числе соблюдение требования 5.4 ГОСТ Р 52872-2019). Однако эта проверка на соответствие ГОСТ Р 52872-2019 будет полностью независимой от проверки соответствия инструмента разработки настоящему стандарту.

5.2 Варианты соответствия

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

5.2.1 Соответствие настоящему стандарту (уровень А, АА или ААА)

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

  1. уровень А: инструмент разработки соответствует всем применимым критериям выполнения уровня А;
  2. Уровень АА: инструмент разработки соответствует всем применимым критериям выполнения уровней А и уровня АА;
  3. Уровень ААА: инструмент разработки соответствует всем применимым критериям выполнения.
Примечания
  1. Необходимо учитывать примечания о применимости соответствий в частях 4.1 и 4.2.
  2. Если минимальный уровень соответствия (уровень А) не был достигнут (т. Е. Не был соблюден хотя бы один применимый критерий выполнения уровня А), рекомендуется в документации указать, какие критерии выполнения были соблюдены.

5.2.2 Частичное соответствие — компонент процесса (уровень А, АА или ААА)

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

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

Примечания
  1. Инструменты разработки не обеспечивают частичное соответствие, если они не позволяют дополнительным компонентам процесса разработки соответствовать критериям выполнения (например, по соображениям безопасности).
  2. Необходимо учитывать примечание о применимости соответствий в частях 4.1 и 4.2.

5.2.3 Частичное соответствие — ограничения платформы (уровень А, АА или ААА)

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

5.3 Производные технологии цифрового контента

Инструменты разработки соответствуют настоящему стандарту только при указании определенного контента, создаваемого с использованием соответствующих технологий данного контента (например, Соответствие Уровня А в отношении создания XHTML 1.0).

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

5.4 Инструменты для создания контента в реальном времени

Настоящий стандарт может применяться к инструментам разработки с рабочими процессами, которые включают в себя создание контента в реальном времени (например, некоторые инструменты для совместной работы). Из-за особенностей, присущих публикации в реальном времени, соответствие части 4.2 настоящего стандарта для этих инструментов разработки может включать некоторую комбинацию поддержки до (например, поддержка в подготовке доступных слайдов) во время (например, создание субтитров в реальном времени, как того требует ГОСТ Р 52872-2019 на уровне АА.) и после сеанса создания в реальном времени (например, возможность добавить текстовую расшифровку в архив презентации, которая изначально была опубликована в режиме реального времени).

Библиография

  1. Консорциум Всемирной Паутины (World Wide WEB Consortium – W3C) Authoring Tool Accessibility Guidelines (ATAG) 2.0
  2. URL: https://www.w3.org/TR/ATAG20/

  3. Консорциум Всемирной Паутины (World Wide WEB Consortium – W3C) HTML 5.2
  4. W3C Recommendation, 14 December 2017

    URL: https://www.w3.org/TR/html52/

  5. Консорциум Всемирной Паутины (World Wide WEB Consortium – W3C) Cascading Style Sheets
  6. URL: https://www.w3.org/Style/CSS/O...

  7. Консорциум Всемирной Паутины (World Wide WEB Consortium – W3C) Accessible Rich Internet Applications (WAI-ARIA) 1.1
  8. URL: https://www.w3.org/TR/wai-aria...[5] DOM Standard

  9. Консорциум Всемирной Паутины (World Wide WEB Consortium – W3C)) DOM Standard
  10. URL: https://dom.spec.whatwg.org/

  11. ECMA-388 Open XML paper specification (OpenXPS) 1st edition, June 2009
  12. URL:https://www.ecma-international...

  13. ECMAScript® 2020 language specification
  14. URL:https://www.ecma-international...

  15. официальный сайт FictionBook
  16. URL: http://fictionbook.org/

  17. OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2
  18. URL: http://docs.oasis-open.org/off...

  19. ECMA-376 Office Open XML file formats
  20. URL:https://www.ecma-international...

  21. Daisy 3: A Standard for Accessible Multimedia Books (PDF)
  22. URL: http://digbib.ubka.uni-karlsru...


УДК 681.3.002.53.006.354 / ОКС 11.180.30

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