wcag
1.0.0
请使用此分支作为拉力请求的目标，直到2016年7月10日。
该存储库用于为WCAG 2开发内容，以及相关的理解文档和技术。
@@完成
另请参阅：WCAG 2样式指南
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元素告诉脚本这是一个术语，并引起特殊的样式和链接功能。要链接到一个术语，请使用无href属性的<a>元素；如果链接文本与术语相同，则将正确生成链接。例如，如果页面上有一个术语<dfn>web page</dfn> ，则<a>web page</a>将导致正确的链接。
如果链接文本与规范术语（例如“ Web Pages”（请注意复数）具有不同的形式，则可以提供有关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每个理解页面的文件，称为指南中的成功标准文件文件填充了提供预期结构的模板。将模板结构放在适当的位置，并在各节中添加适当的内容。 class =“指令”的元素提供有关该部分中要包含的内容的指导；您可以根据需要删除这些元素，但不必删除这些元素。示例的模板提出了一个子弹列表或一系列子段，请选择其中一种方法，然后从模板中删除另一个方法。技术的模板包括“情况”的子段，如果不需要，请删除该包装部分。
从WCAG规范中的相关成功标准中引用了了解文件；这些链接由脚本发布。
当前，正式理解页面的出版物位置是https://www.w3.org/wai/wcag21/understanding/。根据需要更新此内容；并可以自动化。
技术在技术文件夹中，并通过技术将其分组为子文件夹。每种技术都是一个独立的文件，该文件的格式为HTML格式，具有常规的元素，类和ID结构。
该技术模板显示了技术的结构。主要部分位于具有特定ID的顶级<部分>元素中：元，适用性，描述，示例，测试，相关，资源。需要描述和测试部分；建议使用适用性和示例部分；相关和资源部分是可选的。元部分提供了在创作过程中的技术的上下文，但被删除以供出版。该技术的标题在<h1>元素中。具有class="instructions"元素提供有关填充模板的信息。应在开发技术时将它们删除，但如果不删除，则会被发电机忽略。请勿在真实内容上复制class="instructions" 。
技术可以使用临时样式表来促进草稿的审查。此样式表被其他样式表和正式出版的结构所取代。要使用此样式表，请添加<link rel="stylesheet" type="text/css" href="../../css/editors.css"/>到技术的头部。
技术可以包括图像。将图像文件放在相关技术的img文件夹中 - 意味着技术的所有技术共享一组通用图像。使用相对链接加载图像。大多数图像应加载<figure>元素，并用位于图底部的<figcaption>标记。 <figure>元素必须具有id属性。小型内联图像可以加载带有合适alt文本的<img>元素。
技术应包括简短的代码示例，以演示如何撰写该技术的内容。代码示例应该易于阅读，通常本身不会完成内容。可以提供更完整的示例作为工作示例（见下文）。链接到每个示例底部的工作示例，在a <p class="working-example">元素中，包含一个相对链接到../../working-examples/{example-name}/ example-name }/。
可以在有用的地方提供对其他技术的交叉引用。通常，应该在“相关技术”部分中提供它们，但可以在其他地方提供。如果使用相同的技术，则使用相对链接来引用技术， {Technique ID} ，或../{Technology}/{Technique ID}否则。如果该技术仍在开发中并且没有正式ID，请参考开发文件的路径。如果该技术正在另一个分支中开发，请使用该技术的Rabgit版本使用绝对的URI。
对准则和成功标准的交叉引用应使用相对的URI来了解该项目的理解页面。指南的其他部分的交叉引用应对W3C TR页面上发布的指南使用绝对URI，这是一个以https://www.w3.org/TR/WCAG21/#开头的URI。请注意，基于理解文档中的信息，生成器在发布时添加了与哪些技术相关的指南或成功标准的引用，因此通常不需要或建议与这些文档的冗余链接。
维基（Wiki）维持了从事技术工作的一般优先事项和过程。
新技术应使用从技术标题缩短版本中得出的文件名。编辑人员将在工作组接受时将技术分配给ID并重命名。例如，一种技术“使用IMG元素上的Alt属性来提供简短的文本替代方案”可能会使用“ IMG-Alt-Short-text-Alternatives.html”作为文件名。编辑人员将在工作组接受时将其分配一个正式ID，并将其重命名。
每种新技术都应在新分支中创建。分支和文件的设置是通过create-techniques.sh脚本自动化的，可以使用bash运行。命令行是：
bash create-techniques.sh < technology > < filename > < type > " <title> "<technology>是该技术的技术目录<filename>是该技术的临时文件名（无扩展）<type>是“技术”或“失败”<title>是该技术的标题，用引号封闭并用逃脱特殊字符这将自动以下步骤：
一旦设置了技术分支和文件，请填充内容并请求评论：
存储库中的技术是普通的HTML文件，其格式最少。为了出版到编辑的草稿和W3C位置，基于高架的构建过程，用于模板和Cheerio进行转换。更多详细信息，包括用于本地预览的说明，可以在“构建过程”回复中找到。
发电机将技术作为套件一起编译为具有格式和导航的套件。它执行某些结构，例如上述上述顶级部分和标准化标题。它试图处理交叉参考链接，以确保URI在出版时工作。最重要的角色之一是用该技术与之相关的指南或成功标准的参考填充适用性部分。此信息来自理解文件。正确使用技术模板对于启用此功能很重要，并且MAL形成技术可能会导致发电机失败。
过时的技术不应从存储库中删除。取而代之的是，可以使用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指示要在此技术部分中显示的消息如果整个技术已过时（例如闪光灯和银灯），则这些属性也可以在技术子目录级别上指定，例如通过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中的new in wcag xy：”中的前缀显示。
此类也可以与note类一起应用，在这种情况下，“（WCAG XY中的新）”将附加到适用版本中的“ Note”标题上，并且该注释将隐藏在早期版本中。
在撰写本文时（2024年11月），WCAG 2.1和2.2之间的变更日志相同。这些已被分为单独的版本特定于_includes/techniques/changelog/*.html以支持从同一分支机构构建多个版本的信息文档。
技术中的示例应为简短的易于征用的代码示例，介绍该技术在内容中的使用方式。因此，示例应重点介绍该技术描述的特定功能，而不包括相关内容，例如样式，脚本，周围的Web内容等。
通常希望提供更全面的示例，这些示例显示了行动中的技术，而不会干扰主技术文档。这些示例还显示了使该技术运行所需的完整代码，包括完整的样式和脚本文件，图像，页面代码等。通常，这些“工作示例”在主示例的底部引用，其中包括在主示例的底部技术。
工作示例存储在存储库的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/ ://rawgit.com/w3c/wcag/main/main/working-examples/alt-attribute/。批准示例后，编辑将更新链接。WCAG 2.2已准备好翻译。要翻译WCAG 2.2，请遵循有关如何翻译WCAG 2的说明。
