wcag
1.0.0
Пожалуйста, используйте этот филиал в качестве цели для запросов на привлечение до 10 июля 2016 года.
Этот репозиторий используется для разработки контента для WCAG 2, а также ассоциированного понимания документов и методов.
@@ завершить
См. Также: WCAG 2 Guide
WCAG 2.0 поддерживался в другой структуре файлов, чем в последующих версиях WCAG. Исходные файлы для WCAG 2.0 находятся в папке WCAG20 и существуют в основном для архивных целей. Не редактируйте контент в этой папке.
Содержание для WCAG 2.1, а затем организовано в соответствии со структурой файла ниже. Репозиторий WCAG содержит источники и вспомогательные файлы для WCAG 2, понимание WCAG 2 и в конечном итоге методы. Он также содержит вспомогательные файлы, которые поддерживают автоматизированное форматирование документа. Чтобы облегчить многопартийное редактирование, каждый критерий успеха находится в отдельном файле, состоящий из фрагмента HTML, который может быть включен в основные руководящие принципы. Ключевые файлы включают:
guidelines/index.html - основной файл руководствguidelines/sc/{version}/*.html - файлы для каждого критерия успехаguidelines/terms/{version}/*.html - файлы для каждого определенияunderstanding/{version}/*.html - Понимание файлов для каждого критерия успеха Где {version} - «20», контент поступает из WCAG 2.0. «21» используется для контента, введенного в WCAG 2.1, 22 »для WCAG 2.2 и т. Д.
Менеджеры критериев успеха подготовят критерии успеха кандидатов, готовые к включению в документ руководства. Чтобы подготовить критерии успеха, выполните эти шаги:
#1 .Критерии успеха используют простую структуру элементов HTML с несколькими значениями атрибутов класса, чтобы обеспечить согласованность. Сценарии улучшения и стиль ключа от этой структуры. Содержание, которое вы предоставляете, указан в брекетах. Элементы после комментариев являются необязательными.
< section class =" sc " >
< h4 > {SC Handle} </ h4 >
< p class =" conformance-level " > {Level} </ p >
< p class =" change " > {Change} </ p >
< p > {Main SC Text} </ p >
<!-- if SC has sub-points -->
< dl >
< dt > {Point Handle} </ dt >
< dd > {Point Text} </ dd >
</ dl >
<!-- if SC has notes -->
< p class =" note " > {Note} </ p >
</ section >Обратите внимание, что вы не предоставляете номер SC. Числа будут назначены, и, скорее всего, автоматически генерируется позже.
Значения, которые вы предоставляют, описаны ниже. Обратитесь к критерию успеха 2.2.1 для примера каждого из этих произведений контента.
`Элементы могут быть предоставлены.
Если вы предоставляете определения терминов вместе со своим SC, включите их в каталог соответствующих guidelines/terms/{version} , с использованием следующего формата: Следующий формат:
< dt > < dfn id =" dfn-{shortname} " > {Term} </ dfn > </ dt >
< dd > {Definition} </ dd > Элемент dfn сообщает сценарию, что это термин и вызывает особенности специального стиля и связывания. Чтобы связаться с термином, используйте элемент <a> без атрибута href ; Если текст ссылки такой же, как и термин, ссылка будет правильно сгенерирована. Например, если на странице есть термин <dfn>web page</dfn> , ссылка в форме <a>web page</a> приведет к правильной ссылке.
Если текст ссылки имеет отличную форму от канонического термина, например, «Веб-страницы» (обратите внимание на множественное число), вы можете дать намек на определение термина с атрибутом data-lt . В этом примере измените термин как <dfn data-lt="web pages">web page</dfn> . Несколько альтернативных имен для термина могут быть разделены с символами труб, без ведущего или следственного пространства, например, <dfn data-lt="web pages|page|pages">web page</dfn> .
Есть один понимающий файл на критерий успеха, плюс индекс:
understanding/index.html - индексная страница, необходимость понаправляться или добавить ссылку на отдельные страницы понимания, поскольку они становятся доступнымиunderstanding/{version}/*.html - файлы для каждой страницы «Понимание», названная так же, как файл критерия успеха в руководящих принципахФайлы заполнены шаблоном, который обеспечивает ожидаемую структуру. Оставьте структуру шаблона на месте и добавьте контент, в зависимости от необходимости в разделах. Элементы с классом = «инструкции» дают руководство о том, какой контент включать в этот раздел; Вы можете удалить эти элементы, если хотите, но не нужно. В шаблоне для примеров предлагается либо список пулей, либо серию подразделений, выберите один из этих подходов и удалите другой из шаблона. Шаблон для методов включает в себя подразделы для «ситуаций», удалите эту секцию обертки, если не требуется.
Понимание файлов ссылается на соответствующий критерий успеха в спецификации WCAG; Эти ссылки внедряются сценарием.
Официальное место публикации для понимания страниц в настоящее время является https://www.w3.org/wai/wcag21/understanding/. Этот контент обновляется по мере необходимости; и может быть автоматизирован.
Методы находятся в папке методов и сгруппированы по технологиям в субсоличики. Каждый метод представляет собой отдельный файл, который находится в формате HTML с обычной структурой элементов, классов и идентификаторов.
Шаблон техники показывает структуру методов. Основные разделы находятся в верхнем уровне <section> Элементы с конкретными идентификаторами: мета, применимость, описание, примеры, тесты, связанные с ним ресурсы. Описание и разделы тестов требуются; Рекомендуются разделы применимости и примеров; Связанные и ресурсы разделы являются необязательными. Мета -раздел обеспечивает контекст для техники во время авторизации, но удаляется для публикации. Название техники в элементе <h1> . Элементы с class="instructions" предоставляют информацию о заполнении шаблона. Они должны быть удалены по мере разработки техники, но если не удалить, будет игнорироваться генератором. Не копируйте class="instructions" на реальном контенте.
Методы могут использовать лист временного стиля, чтобы облегчить обзор черновиков. Этот лист стиля заменяется другими листами стиля и структурой для формальной публикации. Чтобы использовать этот лист стиля, добавьте <link rel="stylesheet" type="text/css" href="../../css/editors.css"/> к главе техники.
Методы могут включать изображения. Поместите файл изображения в папку img соответствующей технологии - означает все методы для технологии, которые имеют общий набор изображений. Используйте относительную ссылку для загрузки изображения. Большинство изображений должны быть загружены элементом <figure> и помечены <figcaption> , расположенным в нижней части рисунка. <figure> Элементы должны иметь атрибут id . Небольшие встроенные изображения могут быть загружены элементом <img> с подходящим alt -текстом.
Методы должны включать в себя краткие примеры кода, чтобы продемонстрировать, как создавать контент, который следует за методикой. Примеры кода должны быть легко читать, и, как правило, сами по себе не полным контентом. Более полные примеры могут быть приведены в качестве рабочих примеров (см. Ниже). Ссылка на рабочие примеры в нижней части каждого примера, в элементе <p class="working-example"> , содержащей относительную ссылку на ../../working-examples/{example-name}/ working-examples/{ example-name).
Перекрестные ссылки на другие методы могут быть предоставлены там, где полезны. Как правило, они должны быть предоставлены в разделе «Связанные методы», но могут быть предоставлены в другом месте. Используйте относительную ссылку для ссылки на технику, {Technique ID} если такая же технология, или ../{Technology}/{Technique ID} . Если метод все еще находится в стадии разработки и не имеет официального идентификатора, ссылайтесь на путь к файлу разработки. Если метод находится в разработке в другой ветви, используйте абсолютный URI для версии техники Rawgit.
Перекрестные ссылки на руководящие принципы и критерии успеха должны использовать относительный URI на страницу «Понимание» для этого элемента. Перекрестные ссылки на другие части руководящих принципов должны использовать абсолютный URI для руководящих принципов, опубликованных на странице W3C TR, URI, начиная с https://www.w3.org/TR/WCAG21/# . Обратите внимание, что ссылки на руководящие принципы или критерии успеха, с которыми связаны методы, добавляются генератором при публикации на основе информации в понимании документов, поэтому избыточные ссылки на них обычно не требуются или рекомендуются.
Общие приоритеты и процесс работы над методами поддерживаются в вики.
Новые методы должны использовать имя файла, которое получено из сокращенной версии названия техники. Редакторы назначат эту технику идентификатор и переименуют файл, когда он будет принят рабочей группой. Например, методика «с использованием атрибута ALT в элементе IMG для предоставления коротких текстовых альтернатив» может использовать «IMG-ALT-Short-Text-Alternative.html» в качестве имени файла. Редакторы назначат ему официальный идентификатор и переименуют файл, когда он будет принят рабочей группой.
Каждая новая техника должна быть создана в новой ветви. Настройка филиала и файла автоматизирована с помощью скрипта Create-Techniques.SH, который можно запустить с помощью Bash. Командная строка:
bash create-techniques.sh < technology > < filename > < type > " <title> "<technology> - это технологический каталог для техники<filename> - временное имя файла (без расширения) для техники<type> - это «техника» или «неудача»<title> - это название техники, заключенная в цитаты и избегая специальных символов с Это автоматизирует следующие шаги:
Как только методика филиала и файла настраиваются, заполните обзор контента и запроса:
Методы в репозитории являются простыми HTML -файлами с минимальным форматированием. Для публикации в проекте редакторов и местоположении W3C методы отформатируются процессом сборки, основанного на одновременном для шаблона и Cheerio для преобразования. Более подробную информацию, включая инструкции по предварительному просмотру локально, можно найти в процессе сборки.
Генератор собирает методы вместе как набор с форматированием и навигацией. Он обеспечивает соблюдение определенных структур, таких как упорядочение разделов верхнего уровня, описанные выше, и стандартизация заголовков. Он пытается обработать перекрестные ссылки, чтобы убедиться, что URI работают над публикацией. Одна из наиболее существенных ролей - заполнить раздел применимости ссылками на руководящие принципы или критерии успеха, с которыми относится метод. Информация для этого поступает из понимающих документов. Правильное использование шаблона метода важно для включения этой функции, и методы из-за необработанных методов могут привести к сбою генератора.
Устаревшие методы не должны быть удалены из репозитория. Вместо этого они могут быть отмечены с помощью переднего вещества YAML. Например:
---
obsoleteSince : 22
obsoleteMessage : |
This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2.
---obsoleteSince указывает на самую раннюю версию WCAG 2, когда методика устарела (это может быть установлено на 20 , если он должен быть эффективно устарел для всех версий, например, для методов, включающих устаревшие элементы HTML)obsoleteMessage указывает сообщение, которое будет отображаться в разделе Abt The Technique В тех случаях, когда целые технологии устарели (например, Flash и Silverlight), эти свойства также могут быть указаны на уровне подкаталога Technique, например, через techniques/flash/flash.11tydata.json . Обратите внимание, что этот случай специально требует формата JSON, так как это потребляется как на один, так и дополнительный код в процессе сборки, используемых для сбора данных методов.
Информативные документы генерируются из одних и тех же исходных файлов как для WCAG 2.2, так и для 2.1, так как большая часть их содержания согласована между ними. (Сами руководящие принципы по-прежнему поддерживаются в отдельных ветвях, например, WCAG-2.1 , для целей поддержания проектов отдельных редакторов.)
При создании информативных документов для более старых версий критерии успеха обновляют критерии успеха, которые характерны для новых версий, и, в свою очередь, любые методы, которые связаны исключительно с этими критериями.
Есть несколько случаев, когда контент может потребоваться для обслуживания конкретной версии, объясняется в этом разделе.
Примечание. Это применимо только в рамках techniques и understanding папок ( не guidelines ).
В тех случаях, когда точный номер версии должен отображаться в информативных документах, вставьте {{ versionDecimal }} . Это будет заменено номером версии с децимальной точкой, например, 2.1 или 2.2.
В тех случаях, когда документ, относящийся к нескольким версиям, требует конкретного вызова об обновлении в более новой версии, class="wcagXY" может быть применен к элементу, окружающему рассматриваемую прозу (например, class="wcag22" для WCAG 2.2) Полем Это приведет к тому, что проза будет опущена из более ранних версий и отображается с префиксом «Новый в WCAG XY:» в применимых версиях.
Этот класс также может быть применен вместе с классом note , и в этом случае «(новый в WCAG XY)» будет добавлено к названию «Примечание» в применимых версиях, и примечание будет скрыто в более ранних версиях.
На момент написания (ноябрь 2024 г.) журнал изменений в индексе методов идентичен между WCAG 2,1 и 2,2. Они были разделены на отдельные специфики для версии, включающие в себя _includes/techniques/changelog/*.html для будущей защиты в поддержку создания нескольких версий информативных документов из одного и того же филиала.
Примерами в методах должны быть краткие простые для выполнения образцов кода того, как метод используется в содержании. Поэтому примеры должны сосредоточиться на конкретных функциях, которые описывает техника, и не включать связанный контент, такой как стиль, сценарий, окружающий веб -контент и т. Д.
Часто желательно предоставить более полные примеры, которые показывают технику в действии, не вмешиваясь в основной технический документ. Эти примеры также показывают полный код, необходимый для работы техники, включая полный стиль и файлы сценариев, изображения, код страницы и т. Д. техника.
Рабочие примеры хранятся в каталоге working-examples репозитория. Каждый пример находится в своем собственном подкаталоге, чтобы содержать несколько файлов, которые могут потребоваться, чтобы заставить пример работать. В некоторых случаях несколько рабочих примеров будут делиться общими ресурсами; Они хранятся в соответствующей подсчете каталога рабочей промежутки, например, working-examples/css , working-examples/img , working-examples/script . Ссылаться на эти общие ресурсы, когда они доступны; В противном случае поместите ресурсы в каталог рабочих примеров, используя подкатарии для организации, когда это необходимо.
Чтобы создать рабочий пример:
example- префикса и которая в противном случае семантически идентифицирует пример, например, example-alt-attribute .working-examples/alt-attribute/ .index.html . В противном случае создайте подходящее имя файла.../css/example.css . Поместите другие ресурсы в том же каталоге, что и в основном примере, например, working-examples/alt-attribute/css/alt.css .https://rawgit.com/w3c/wcag/main/working-examples/alt-attribute/ . Редакторы будут обновлять ссылки, когда примеры будут одобрены.WCAG 2.2 готов к переводу. Чтобы перевести WCAG 2.2, следуйте инструкциям о том, как перевести WCAG 2.
