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.2などのWCAG 2.1、「22」で導入されたコンテンツに使用されます。
成功基準マネージャーは、候補者の成功基準を準備し、ガイドラインドキュメントに含める準備ができています。成功基準を準備するには、次の手順に従ってください。
#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}ディレクトリ、1パーセルのディレクトリに含めます。
< dt > < dfn id =" dfn-{shortname} " > {Term} </ dfn > </ dt >
< dd > {Definition} </ dd > dfn要素は、これが用語であることをスクリプトに伝え、特別なスタイリングとリンク機能を引き起こします。用語にリンクするには、 href属性なしで<a>要素を使用します。リンクテキストが用語と同じ場合、リンクは正しく生成されます。たとえば、ページに用語<dfn>web page</dfn>がある場合、 <a>web page</a>の形式のリンクが適切なリンクになります。
リンクテキストに、標準的な用語などとは異なる形式がある場合、「Webページ」（複数形に注意してください）、 data-lt属性の用語定義に関するヒントを提供できます。この例では、用語を<dfn data-lt="web pages">web page</dfn> 。この用語の複数の代替名は、リーディング<dfn data-lt="web pages|page|pages">web page</dfn>またはトレーリングスペースがないパイプ文字で区切ることができます。
成功基準ごとに1つの理解ファイルとインデックスがあります。
understanding/index.htmlインデックスページ、個々の理解ページが利用可能になったときに個々の理解ページへの参照を追加する必要がありますunderstanding/{version}/*.html理解ページごとにファイル。ガイドラインの成功基準ファイルと同じ名前ファイルには、予想される構造を提供するテンプレートが入力されています。テンプレート構造を所定の位置に置いたままにし、セクション内に適切なコンテンツを追加します。 class = "命令"の要素は、そのセクションに含めるコンテンツに関するガイダンスを提供します。必要に応じてこれらの要素を削除できますが、必要はありません。例のテンプレートは、弾丸リストまたは一連のサブセクションのいずれかを提案し、それらのアプローチのいずれかを選択し、テンプレートから他のアプローチを削除します。テクニックのテンプレートには、「状況」のサブセクションが含まれています。必要でない場合は、そのラッパーセクションを削除します。
ファイルの理解は、WCAG仕様の関連する成功基準から参照されます。これらのリンクはスクリプトによって提出されます。
ページを理解するための正式な出版場所は、現在https://www.w3.org/wai/wcag21/understanding/です。このコンテンツは必要に応じて更新されます。自動化される場合があります。
テクニックはTechniquesフォルダーにあり、テクノロジーによってサブフォルダーにグループ化されています。各手法は、要素、クラス、IDの通常の構造を備えたHTML形式のスタンドアロンファイルです。
テクニックテンプレートは、テクニックの構造を示しています。メインセクションは、特定のIDを備えたトップレベル<section>要素にあります：メタ、適用性、説明、例、テスト、関連、リソース。説明とテストのセクションが必要です。適用可能性と例セクションをお勧めします。関連するセクションとリソースセクションはオプションです。メタセクションは、オーサリング中の手法のコンテキストを提供しますが、公開のために削除されます。手法のタイトルは<h1>要素にあります。 class="instructions"の要素は、テンプレートの居住に関する情報を提供します。手法が開発されると削除する必要がありますが、削除されない場合は、発電機によって無視されます。実際のコンテンツにclass="instructions"をコピーしないでください。
テクニックは、ドラフトのレビューを容易にするために、一時的なスタイルシートを使用できます。このスタイルシートは、正式な出版のために他のスタイルシートと構造に置き換えられます。このスタイルシートを使用するには、 <link rel="stylesheet" type="text/css" href="../../css/editors.css"/>テクニックのヘッドに追加します。
技術には画像を含めることができます。画像ファイルを関連するテクノロジーのimgフォルダーに配置します。つまり、テクノロジーのすべてのテクニックが共通の画像セットを共有しています。相対リンクを使用して画像を読み込みます。ほとんどの画像には、 <figure>要素をロードし、図の下部に配置された<figcaption>でラベル付けする必要があります。 <figure>要素にはid属性が必要です。小さなインライン画像には、適切なaltテキストを備えた<img>要素がロードされる場合があります。
手法には、手法に続くコンテンツを作成する方法を示すための簡単なコード例を含める必要があります。コードの例は読みやすく、通常はそれ自体でコンテンツを完成させないはずです。より完全な例を作業例として提供できます（以下を参照）。各例の下部にある作業例へのリンク、 ../../working-examples/{example-name}/ <p class="working-example">要素。
便利な場合は、他の手法への相互参照が提供される場合があります。通常、それらは「関連する手法」セクションで提供されるべきですが、他の場所で提供できます。相対リンクを使用して、テクニックを参照し、 {Technique ID}同じテクノロジーの場合、または../{Technology}/{Technique ID}参照してください。手法がまだ開発中で、正式なIDがない場合は、開発ファイルへのパスを参照してください。テクニックが別のブランチで開発中の場合は、テクニックのロウギットバージョンに絶対的なURIを使用します。
ガイドラインと成功基準への相互参照は、そのアイテムの理解ページに相対的なURIを使用する必要があります。ガイドラインの他の部分への相互参照は、W3C TRページで公開https://www.w3.org/TR/WCAG21/#れているガイドラインに絶対URIを使用する必要があります。ガイドラインまたは成功基準への参照は、理解文書の情報に基づいて出版時にジェネレーターによってテクニックに関連する成功基準が追加されているため、それらへの冗長リンクは通常必要または助言されていません。
技術に取り組むための一般的な優先事項とプロセスは、Wikiで維持されています。
新しい手法では、Techniqueタイトルの短縮バージョンから派生したファイル名を使用する必要があります。編集者は、手法をIDに割り当て、ワーキンググループが受け入れたときにファイルの名前を変更します。たとえば、「IMG要素のALT属性を使用して短いテキストの代替案を提供する」手法は、「IMG-Alt-Short-Text-Alternatives.html」をファイル名として使用する場合があります。編集者は、ワーキンググループが受け入れたときに、正式なIDを割り当て、ファイルの名前を変更します。
それぞれの新しい手法は、新しいブランチに作成する必要があります。ブランチとファイルのセットアップは、Bashで実行できるCreate-Techniques.shスクリプトを介して自動化されます。コマンドラインは次のとおりです。
bash create-techniques.sh < technology > < filename > < type > " <title> "<technology>は、テクニックのテクノロジーディレクトリです<filename>は、テクニックの一時的なファイル名（拡張機能なし）です<type>は「テクニック」または「失敗」です<title>は、引用に囲まれ、で特殊文字を逃れるテクニックのタイトルですこれにより、次の手順が自動化されます。
テクニックブランチとファイルがセットアップされたら、コンテンツとリクエストレビューを作成します。
リポジトリの手法は、最小限のフォーマットを備えたプレーンHTMLファイルです。編集者のドラフトとW3Cの場所に公開されるために、テクニックは、テンプレートのためにEleventyとTheerioに基づくビルドプロセスによってフォーマットされます。ローカルでプレビューするための指示を含む詳細は、ビルドプロセスREADMEをご覧ください。
ジェネレーターは、フォーマットとナビゲーションを備えたスイートとしてテクニックをまとめます。上記のトップレベルのセクションの順序付けや標準化の見出しなど、特定の構造を実施します。クロス参照リンクを処理して、URIが公開時に動作することを確認しようとします。最も重要な役割の1つは、手法が関連するガイドラインまたは成功基準への参照を適用可能性セクションに埋めることです。この情報は、理解文書に由来しています。この機能を有効にするためには、テクニックテンプレートを適切に使用することが重要であり、Mal-Formed Techniqueが発電機を失敗させる可能性があります。
廃止された手法をリポジトリから削除しないでください。代わりに、それらはYAMLフロントマッターを使用してマークすることができます。例えば：
---
obsoleteSince : 22
obsoleteMessage : |
This failure relates to 4.1.1: Parsing, which was removed as of WCAG 2.2.
---obsoleteSince 、手法が時代遅れになったときのWCAG 2の最古のバージョンを示しています（これは、すべてのバージョンで効果的に廃止される必要がある場合は20に設定される場合があります。obsoleteMessage 、この手法セクションに表示されるメッセージを示しますテクノロジー全体が時代遅れ（FlashやSilverlightなど）が廃止されている場合、これらのプロパティは、 techniques/flash/flash.11tydata.jsonなどのテクニックサブディレクトリレベルでも指定できます。このケースはJSON形式が特に必要であることに注意してください。これは、テクニックデータの組み立てに使用されるビルドプロセスの110と追加のコードの両方によって消費されるためです。
コンテンツのほとんどはそれらの間で一貫しているため、WCAG 2.2と2.1の両方のソースファイルから有益なドキュメントが生成されます。 （ガイドライン自体は、個別の編集者のドラフトを維持するために、 WCAG-2.1などの別々のブランチで引き続き維持されています。）
古いバージョン向けの有益なドキュメントを構築する場合、ビルドシステムは、新しいバージョンに固有の成功基準をプルーネし、その結果、それらの基準にのみ関連する手法があります。
このセクションで説明した、コンテンツが特定のバージョンに対応する必要がある場合がある場合があります。
注：これは、 techniquesとunderstandingフォルダー（ guidelinesではなく）内でのみ適用されます。
有益なドキュメント内に正確なバージョン番号を表示する必要がある場合、 {{ versionDecimal }}を挿入します。これは、2.1または2.2の小数点付けバージョン番号に置き換えられます。
複数のバージョンに関連するドキュメントが新しいバージョンでの更新に関する特定の呼び出しを必要とする場合、 class="wcagXY" 、問題の散文を取り巻く要素に適用できます（例えば、wcag 2.2のclass="wcag22" ） 。これにより、散文は以前のバージョンから省略され、該当するバージョンで「wcag xy：new in wcag xy：」というプレフィックスが表示されます。
このクラスは、 noteクラスと並んで適用することもできます。この場合、「（WCAG XYの新）」は該当するバージョンに「ノート」タイトルに追加され、メモは以前のバージョンに隠されます。
執筆時点（2024年11月）では、Techniques Indexの変更ログは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/working-examples/alt-attribute/。編集者は、例が承認されたときにリンクを更新します。WCAG 2.2は翻訳の準備ができています。 WCAG 2.2を翻訳するには、WCAG 2の翻訳方法の指示に従ってください。
