ルールの構成

カタログにある145件のルールがどのように構成されているかを説明します。結果の意味を理解したり、目的のルールを探したりするのに役立ちます。抽象的な設計ではなく、ルールセットに実際にあるものをそのまま反映しています。

自動ルールと手動ルール

各ルールのtypeは2種類のどちらかです。違いは、ルールが何を判定できるかにあり、たまたまどの判定結果を報告するかではありません。

• automatic（自動）：ヒューリスティックも推測も使わず、決定論的に判定します。failを報告できます。それでもcantTellが出るのは次の場面です。実際の違反はあるものの、それだけでは対応するWCAG達成基準の不適合が確定しない場合（公開される名前・役割・値がそれでも保たれている、ARIAの作成者要件など）。ルールはベストプラクティスが守られていないことを決定論的に判定するが、達成基準を主張しておらず、見つけたものが誰の妨げにもならない可能性がある場合。ロールや要素はそのままの形で支援技術に届いているからです（ベストプラクティスとタグ付けされたaria-allowed-role、landmark-role-name-present）。そして、ルールが確認できるのは仕組みが存在することだけで、存在するものが実際に妥当かどうかは兄弟ルールの担当である場合（aria-required-childrenと、対になるaria-prohibited-children）。あるいは、ルールが推測なしには判定できないため、不合格にする代わりに確認を求める場合です。閉じたシャドウルート、エンジンが読み取れないElementInternals、読み取れないほど深く入れ子になったコンテンツから来ている可能性がある名前（*-name-presentルール）、間隔を広げると切れたり重なったりする可能性があるテキスト（text-spacing-content-loss）、ページのコンテンツ以外の要素を回転させる画面の向きのメディアブロック（css-orientation-lock）、比率を下回るプレースホルダーのうち色がページのものかブラウザーのものか判断できないものや、比率を下回る、コントロールの名前の代わりになっている1文字（contrast-minimum）、計算できない色やサイズ（コントラストのルール、target-size-minimum）がこれに当たります。例外を投げたルールも、安全策としてcantTellと報告されます。
• manual（手動）：人が判断しなければならないことを示します。ルールは、見つけたものが問題かどうかを判定できません。判定結果はcantTellかnotApplicableで、判断を必要としない答えが見つかった場合に限りpassになります。failになることはありません。landmark-uniqueは、名前が同じ2つのランドマークが問題かどうかを判定できません（内容が同一であればAPGはこれを認めています）。そのためこれはcantTellです。一方、「すべての名前が異なる」は事実なのでpassです。画像のテキスト代替が正確かどうかのように、見つけた対象のすべてについて人に判断を求めるルールがpassを報告することはありません。ヒューリスティックが手がかりを見つけた場合にだけ確認を求める手動ルールは、手がかりが見つからなければpassではなくnotApplicableを報告します。そのルールが適用されるのはヒューリスティックが指摘するものだけで、そこで何も見つからなくても、すべて問題ないことにはならないからです。image-redundant-altは画像の隣のテキストを繰り返す代替テキストを探しますが、見つからなくても代替テキストが正しいかどうかについては何もわかりません。form-control-label-quality、password-paste-enabled、scrollable-region-focusable、image-of-textも同じです。

ベストプラクティスとタグ付けされたルールは達成基準を主張しませんが、判定したもの自体がバリアである場合はfailを報告します。空の見出しは、中身のない見出しとして読み上げられます（empty-heading。W3CのACTルールも同じように報告します）。そのfailが示すのは、ルール自身の期待が満たされていないということであり、達成基準が満たされていないということではありません。WCAGの集約はこれを算入しません。見つけたものが誰の妨げにもならない可能性がある場合は、上で述べたとおり、代わりにcantTellを報告します。

手動ルールが報告するcantTellと自動ルールが報告するcantTellは、値は同じでも同じ出来事ではありません。自動ルールは判定を終えたうえで、見つけたものを伝えています。手動ルールは、その問いがそもそもマークアップからは判定できないことを伝えています。判定結果、重大度、確度の完全なリファレンスは結果とレポートを参照してください。どちらの場合も、coreのルールのcantTellは答え方を示し（howToCheck）、一部はページの手がかりがどちらを示しているかも示します（lean。出力スキーマを参照）。

ルールIDの構成

ルールIDはおおむね<family>-<intent>の形です。まずルールが対象とする要素や仕組み、次にそれについてどんな問いを立てるかを表します。いちばんわかりやすい例は画像の代替テキストのファミリー（WCAG 1.1.1）です。

• present：必要な仕組みが存在するかを確認します。通常は自動です。
• quality：適切さ、正しさ、意味があるかを確認します。常に手動です。
• decorative：純粋に装飾的なコンテンツが正しく扱われているかを確認します。常に手動です。

ルールが自動になりうるかは意図で決まります。「何かが存在するか」はマークアップだけで判定できることが多い一方、「それが良いか」はほぼ判定できません。各ルールのページにある関連するルールのリンクも同じ考え方によるものです。ファミリー（IDの最後の-区切りより前の部分）が共通するルールがそこにまとめられています。ルールセットにはimg以外にも、aria-*、contrast-*、dialog-*、iframe-*、label-*、link-*、list-*、landmark-*など数十のファミリーがあります。最新の一覧は自動生成されるカタログにあります。

1つのルールが複数のファミリーにまたがることはありません。各ルールは1種類の要素を対象に、それに適したヘルパーを使って問い合わせます。ルールセットが大まかなルール十数件ではなく、範囲の狭い145件のルールで構成されているのもそのためです。判定する内容、対象、カバーするWCAGのファセットのいずれかが異なる2つのチェックは、統合せずに別のルールとして保っています。そうすれば、具体的に何が見つかったのかを言うために、後から結果を解きほぐす必要がありません。

WCAGのファセット

WCAGの達成基準は、たいてい1つのルールが決定論的に判定できる範囲よりも大きなものです。内部では、各達成基準を名前付きの「ファセット（facet）」に分けています。達成基準1.1.1「非テキストコンテンツ」であれば、alt属性が存在するか、そのテキストに意味があるか、装飾的な画像が正しくnullとしてマークされているか、といったものです。1つのルールは1つ以上のファセットに対応し、同じ達成基準の異なるファセットを複数のルールが分担するのが一般的です。上のimg-altファミリーが1.1.1に対して行っているのがまさにこれです。

これは複合ルール（WCAG達成基準の集約）の結果を読むときに重要になります。複合ルールが合格になるのは、そのルールが達成基準の求めることをすべて確認する場合だけで、そうなっている複合ルールはまだありません。そのため、ある達成基準に対する自動チェックがすべて問題なしだった場合、その複合ルールは?can't tell、つまり一部のみ確認になります。ルールがカバーするファセットは満たされており、残りは人が確認します。3つの層（アトミックルール、ファセット、複合ルール）と、複合ルールの判定結果が実際にどう計算されるかについては適合性を参照してください。