WCAG 2.1 を読んで超短縮してまとめたものです
Abstract
WCAG とは
Web Content Accessibility Guidelines の略
このガイドラインには、ウェブコンテンツをよりアクセシブルにするための推奨事項が載っている
なぜ WCAG があるのか
このガイドラインに従うと、利用者――いわゆる障害がある人、そしてそれ以外の人――がより使いやすいウェブコンテンツにできる
Introduction
WCAG 2 のレイヤー
原則
ウェブアクセシビリティの土台となる 4 原則
- 知覚可能
- 操作可能
- 理解可能
- 堅牢
ガイドライン
原則の下に 13 のガイドラインがある
コンテンツ制作者が取り組むべき基本的な目標を提供する
これは検証可能ではない（全体的な枠組みや全般的な目的を提供するもの）
達成基準
各ガイドラインに設けられている、検証可能な基準
A, AA, AAA の三つの適合レベルが定義されている
達成方法（十分な達成方法及び参考達成方法）
達成方法は参考情報
以下の二種類がある
- 十分な達成方法：達成基準を満たす（と W3C が考えている）もの
- 参考達成方法：個々の達成基準の要件を上回るもの
原文では、十分な達成方法は「Sufficient Techniques」、参考達成方法は「Advisory Techniques」なので、こちらで考えたほうがわかりやすい
関連文書
WCAG 2.1 を理解して実践するための解説書
Glossary
- アクセシビリティサポーテッド
- 以下 2 つともを満たす状態
- 利用者の支援技術でサポートされている
- そのウェブコンテンツ技術には、アクセシビリティ サポーテッドで、利用者が利用できるユーザエージェントがなければならない
- 要するに「スクリーンリーダーを初めとした支援技術で使えること」と解釈していい
- 理論上動くけど、実際はどの支援技術でも実装されてないことがあって、それはアクセシビリティサポーテッドではない
- 以下 2 つともを満たす状態
所感
達成基準を満たせばガイドラインを満たしたと言えるので、達成基準ごとにテストすれば OK
達成方法（十分な、参考の両方）を満たしたからといって、達成基準を満たしているとは言えない（あくまで参考情報のため）
と言いつつ、実際は達成方法が成されているかどうかをテストしてしまっていいはず
あくまでテストの基準自体は達成基準にあるが、コンテンツ実装側としては「この達成方法で実装しているので、達成基準を満たしている」としていい
新規にコンテンツを作るときは「この達成基準はこの達成方法で満たす」と決めておくのがいい
既存コンテンツをテストするときは、十分な達成方法を上から舐めていって該当してるか確かめるのが良さそう
直接達成基準が満たせているか確かめるのは難しそう
いずれにしろ「理解する」を読んでテストするのが良さそうで、単純なテスト項目に落とし込むのが難しそうな気がする
達成方法をすべてテスト項目にしてしまえばいいが、テスト項目数がめちゃくちゃ多くなるし、テストを実施するかの条件ができてしまうため
ちなみに
- JIS になっているのは 2.0
- 最新は 2.1
- 2.2 が準備中
- 3.0 も準備中で、正式名称が W3C Accessibility Guidelines に変更される（予定）
