WCAG 2.0 と Webシステム

昨日のWeb Accessibility Advent Calendar 2014-12月22日記事で SawadaStdDesign さんが、素晴らしい？ブルースを歌われたので、David の WCAG 2.0 Theme Song に合わせて踊った映像を披露します。

ええ、嘘です。でも、WCAG 2.0 ＝ JIS X8341-3:201X についてもう一度考えたいと思うのです。

HTML 5.0 が今年の10月に勧告になりました。CSSのレベル3モジュールも勧告化こそまちまちですが、ブラウザの実装はどんどん進んで、あまり気にしないで使っている人が多いことでしょう。Webテクノロジーの進化スピードの速さには目が回ります。

（目が回ったので、お茶淹れて休憩しました）

（休憩した後通常に仕事に戻ってしまい、この続きを25日に書いています。2日遅れになってしまいました。）

続けます。

ええと、WCAG 2.0 の最大の特徴はなにか？と聞かれたらこう答えます。

「WCAG 2.0 は技術非依存です。人間の特性、つまりは障害や高齢者の特性から書いてありますから、ある程度は技術に即してはいますが、それでも長く使えるガイドラインなんですよ。抽象的になってるってことです。難しい？ええ、みなまで言わないでください。そのために、コンサルタントって商売があるわけで・・・・」

たしかに、技術に依存しないということは大事です。だから、「alt 属性」ではなく「代替テキスト」、「動画と音声メディア」ではなく「時間の経過に伴って変化するメディア」、「h1-6、table、label」ではなく「情報及び関係性」、title要素ではなく「ページタイトル」・・・というわけです。この書き方は美しい、というか苦肉の策でありました。実際、WCAG 2.0 の後に、HTML 5.0 が勧告されましたが、WCAG 2.0 はびくともしません。HTML に依存しないからです。

Web技術の取捨選択と進歩が市場と実装で進んでいくのに対して、アクセシビリティは社会の合意で進んでいきます。合意を作るには多くの時間を要しますし、Web技術の進化に合わせて変えていくのは現実的ではない。だから、こういう風に WCAG 2.0 を作るしかなかったのだと思うのです。誰かの思いつきでこうなったのではなく、周到に考えられて今があるというわけです。それに、堅牢なガイドラインがあれば公共や企業はそれを採用して仕事ができますし、ビジネスも広がります。WCAG 2.0 の中心を担っていた人たちの仕事ぶりを垣間見た立場からしても、その忍耐力は頭が下がるものでした。世界中からくるコメントにすべて答えて、解決していったのですから。

さあ、確かにこれは仕方がなかった。でも、WCAG 2.0 の想定を超えるほどにWebは進化しているという気がします。

というのも、Webは急速にアプリケーションに近付いている。通常のWebサイトでさえ、jQuery や Bootstrap や、場合によっては AngularJS なんかも入り始めている。そんな状態で、WCAG 2.0 は持ちこたえられるのでしょうか。

たとえば URL がほとんど1つしかないような Web サイトのようなシステム、あるいはURLのパラメータやログインによる状態遷移で複雑に表情を変えるようなWebで、今のようなガイドラインをうまく適用できるのでしょうか。WCAG 2.0 にはひとつだけ、このような操作の流れを意識した記述があります。"Conformance Requirements （適合要件）" という項に書いてあります。

3. 一連のプロセス: ウェブページがプロセスを提示する一連の流れのウェブページ群（つまり、利用者がある目的を達成するために完了させる必要のある一連の手順）に含まれる場合、そのプロセス中のすべてのウェブページが指定したレベル又はそれ以上のレベルで適合している（もし、プロセス中のウェブページが特定のレベル又はそれ以上のレベルに適合していない場合、そのレベルに適合できない）。

ここが、今どんどん広がっている。ページという単位でものを考えることができなくなってきています。どこを切り取っても、一連のプロセスがある。そして、プロセス全体で評価するとなると、もはやチェッカーのようなものは評価作業のごく一部でしかなくなってしまっているのです。これは、僕の仕事の悩みでもあります。

この問題への答えを僕は持っていますが、書きません。これからの Web アクセシビリティがどう進むべきか、考えてみてほしいから。

アクセシブルなWeb制作者チェックリスト

このチェックリストは、Webアクセシビリティを実装する人がアクセシビリティを正しく理解しているかどうかを判定するためのチェックリスト試案です。これだけのことにYesと言えるかどうかで、Webアクセシビリティのかなりの部分をカバーできるのではと思うのですが、どうでしょうか。

共通

• 1. Web標準を理解している。
• 2. セマンティックな HTML の記述法方法を理解している。
• 3. 情報の構造をHTMLで、「見た目」のデザインをCSSで記述し、分離する方法を理解している。
• 4. 画像などの非テキストコンテンツがスクリーンリーダでどのように扱われるかを理解している。
• 5. キーボードだけでWebページをナビゲーションする方法を理解している。
• 6. フォームの要素とラベルの関連付けを理解している。
• 7. スクリーンリーダでWebサイトを利用する方法を理解している。
• 8. フォーカスを理解している。
• 9. レイアウトテーブルとデータテーブルの違い、扱い方を理解している。
• 10. 色のコントラスト比を確認する方法を理解している。

JavaScriptを利用する場合

• 11. DOMを理解している。

該当するコンテンツがある場合

• 12. 点滅や動きのあるコンテンツに対する対処方法を理解している。
• 13. 動画や音声に対するアクセシビリティの要求を理解している。
• 14. 光過敏性発作の危険性を理解している。

アクセシビリティ・サポーテッドの功罪

WCAG2.0とJIS X8341-3:2010 で Web アクセシビリティを考える上で重要な考え方として、アクセシビリティ・サポーテッド(accessibility-supported) という概念が導入されています。これは、噛み砕いて言うと次のような考え方です。

「Webアクセシビリティを実現するためには様々な方法がある。しかし、それを支援技術がサポートしてないと意味がないし利用可能にならない。だから、支援技術がサポートしている技術を使ってやりなさい」

これは、障害のある人が実際にWebを使ううえではとても重要な考え方です。つまり、技術のことだけを見ているのではなくて、実際のユーザの現状を把握しておかないと意味がないということです。そのため、Webアクセシビリティ基盤委員会(WAIC)では、アクセシビリティ・サポーテッド（AS）情報  というのを支援技術やブラウザを使って丁寧に調べて、それを公開しています。素晴らしい仕事だと思います。

ただ、実際にそれを見てみるとどうでしょう。7.1.1.1 非テキストコンテンツに関する達成基準 (等級A) を見ても、「要注意」や「達成不可能」が並んでいます。JIS や WCAG の詳細なドキュメントを読んで調べても、結局使える方法は限られてくるというのがわかるでしょう。たとえば、table 要素の見出しセルとデータセルの関連付けを見ても、スクリーンリーダの対応はまちまちで、古いバージョンだとほとんど利用できない。form だって label で関連付けても読まないスクリーンリーダを使っている方が、まだまだいるのだろうと思えるのです。

JIS X8341-4:2010 の試験をやってみると、ここが大きなネックになってきます。人によって見方が違って意見が合わないということもよくあります。私自身も、「厳し目に見る」時と「やや甘めに見る」というさじ加減が存在します。対応するクリーンリーダーを JAWS や NVDA だけにすれば楽になるのですが、そういうわけにもいかないジレンマに陥ってしまうのです。

アクセシビリティ・サポーテッドは障害者がWebにアクセスする権利を何とか守ろうとして編み出された考え方です。しかし一方で、実際にWebを作ろうとすると、何が正解か、ということについて大きな悩みも生み出しているのです。

もしこの概念がなく、支援技術のサポートの有無と関係なく技術的な側面だけで決めたとしたらどうでしょうか？使えない人が確かに出てくるでしょう。しかし、Web制作でやるべきことは極めて明確になり、それをサポートしないのは支援技術のバグであると言うこともできます。たとえば、labelの関連づけなどは、読まないスクリーンリーダのほうが悪いと言ってしまってもいいはずです。

このように、アクセシビリティの基準には「今最低限やるべきだし、技術的に明確でやればできるはず」のレベルと「こういう仕組みを取り入れて支援技術のサポートが広がるともっと使いやすくなる」という2つの側面が共存してグレーゾーンを作ってしまっているのです。

今日的な課題として、さらにWebアクセシビリティを進めるためには、HTMLにおけるアクセシビリティはこうあるべしという姿を技術的に明確な形にすることが、望まれているのではないかと思うのです。「支援技術がサポートすべきことはこういうことである」ということも明確にすべきです。支援技術の遅れのツケをコンテンツが引き受け続け、過去の「遺産」との互換性にばかり目をとらわれていると、Web技術の果てしない進歩にとてもじゃないけれど追い付かない。

Webアクセシビリティを純粋に技術的でこうあるべしという未来的なモデルと、現実に対応する現実モデルに分離して考えることが必要です。そして、その未来モデルに向かって支援技術とコンテンツが両輪になって進んでいく道を示すべきです。