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



3 件のコメント:

なべ さんのコメント...

記憶が定かではないのですが,覚えている範囲でコメントします:

元々この概念は,どのようなUAを想定してWCAG 2.0を策定するかという議論から出てきていて,WCAG 2.0策定WGでは,最初はUAAG 1.0を満たすUAを想定してWCAG 2.0を書く方向で進んでいました.しかし,UAAG 1.0を満たすUAなんて存在しないじゃないかという話になりました.Webアクセシビリティの構成要素でいうところの制作者,制作ツール,コンテンツ,UA,ユーザのチェーンが全てつながらなければWebアクセシビリティが完成しないので,制作者用のガイドラインからUAの機能問題を切り離すために”アクセシビリティサポーテッド”(最初は違う呼び方をしていたと思うけど忘れました)という考え方を導入したのだと記憶しています.そして,そうしないと,WCAG 2.0は実装可能な仕様なのかというW3Cの基準を満たせなかったと思います.

だからこのBlogに書いてある議論は,UAのアクセシビリティ機能を向上させよう!という主張に進むべきだと思います.(JISを用いてコンテンツを作ったり試験したりしている人たちの困難さはよくわかりますが,このコメントではその話は横に置いておきます.)

WCAG 2.0を使う側が,WCAG 2.0(JIS X 8341-3:2010)を聖書のように無批判で使うのではなく,一番大事なところである達成基準を勝手に変えたりつまみ食いしたりしないようにして,このガイドラインを上手に利用するのが正しい使用法だと思っています.アクセシビリティには唯一の正解も100点満点もないですし,Web技術や利用形態はすさまじい速度で変化していますから.

蛇足です:我々もずいぶん前にUAの機能調査をしたし,UAがWeb要素をどう表現すべきかについても私のところでは継続的に研究しています.

今のUAは,急速に進むアプリ化とスマホの時代においつくのに一生懸命で,アクセシビリティがおいついていないのが残念です.同時に,タッチパネルは視覚障害者には使えないと思っていたけれど,画面の或る場所にダイレクトに到達できる利点があることがわかったり,音声利用が珍しいものではなくなってきたり,ジェスチャIFが取り入れられる兆しがあったり,今の流れの中でいかにしてアクセシビリティを確保し向上させるかを,広い視野で考えていかなければならないと思っています.

以上,つれづれなるままにコメントしてみました.:-)

ume3jan さんのコメント...

なべさん、コメントありがとうございます。

書いてくださったこと、自分でも記憶が戻ってきました。そうでした。そして、今さらですけれど、あのころ「アクセシビリティ・サポーテッド」に何か居心地の悪さを感じていたのを、スケジュールや、その他のいろいろの理由でフタをしていた自分を思い出しました。たぶんなべさんも意識されているように、UAAG が WCAG のこの居心地の悪さをカバーする大事なドキュメントですよね。支援技術と UA には間違いなく進歩してほしいと思っています。また、それを使いこなせるスキルを持った人にも増えてほしいと思ってます。

このブログをきっかけにいろいろな人が議論してくれています。WCAG/JIS の世界で何をどうしていけばいいかという議論とともに、そこを超えたところにある話もフリーハンドでしたいと思うのです。

ume3jan さんのコメント...

http://togetter.com/li/643724


kazuhito さんのまとめも貼っておきます。