2014年3月17日

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

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

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

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

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

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

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