データベースとアクセシビリティ

Webシステムの開発やアクセシビリティ評価を行っていると、よく問題になってくるのがデータベースです。多くの場合、アクセシビリティの評価はある程度システムが出来上がってから行われます。システムやデータベースの設計、実装はもう終わっている。そして、それに手を入れるのは難しい段階になっています。

パターン１

「この画像の代替テキスト『画像1』『画像2』はあんまりです、何とかなりませんか？」
「画像をDBで管理しているし、登録するシステムにも代替テキストを入れる項目がないので大改修になるんですよね」

パターン２

「この画像の代替テキストありません、何とかなりませんか？」
「このシステムは XXX というプラットフォーム上で作ってるのですけど、XXX にはそんな機能がないので、プラットフォームを直さねばならないです。そんなことできません。」

というようなこと。さらに言うと、「長い説明」が必要な画像でもあったら、さらに困難になります。

このような問題は、システムを設計するときにあらかじめ代替テキストについて考えていない、あるいは、開発のプラットフォームを選択するときにアクセシビリティへの対応具合を確認していない、というのが原因です。よく言われることですが、「アクセシビリティは企画段階から対応すべし」という原則を守らないことが、システム開発の最後の段階で響いてきて、開発の手戻り、コストを増大させる典型的な例でしょう。HTMLを修正すれば済む話ならば頑張ればできるのでしょうが、システムの変更となるとデバッグや機能試験などの工数も増える一方です。開発者の視点で見れば、できれば今からシステムを変更したくないというのは当然のことでしょう。納期も心配です。DBを変更するとなると簡単ではありません。代替テキストを保持できるフィールドを追加するだけで済む、というのは運の良いほうです。さまざまなコードに影響を及ぼして、別の場所に新たなバグを発生させてしまうということも十分にある話。

さて、そのような問題を解決するためにはどうすればいいのでしょうか。

1. システムがオリジナルの設計である場合、画像、動画、音声をDBで管理するときは、代替テキストやタイトルをつけられるようにDBを設計しておく。また、登録、管理画面で入力できるようにしておく。
2. プラットフォームを使う場合、そのプラットフォームがアクセシビリティに対応しているか確認しておく、場合によってはテストしておく。

というのが、その解決策です。プラットフォームを使うというのは現在のWebシステム開発では当然でしょうから、プラットフォームがどこまで対応できるかを見定めておくことが必要になります。

DBと関係しないところでも、プラットフォームが用意しているテンプレートやJavaScriptが悪さをすることも多いです。例えば、マウスでドラッグ＆ドロップしないと使えない、画面サイズを変更的できない、というのはよく経験することです。

プラットフォームにアクセシビリティ対応を追加するとなると、プラットフォームに手を入れることになります。しかし、そうするとプラットフォームのバージョンアップ時にまた変更とテストの工数がかかることになることを頭に入れておきましょう。

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

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

JIS X 8341-3:2010 「第三者によるコンテンツ」とは何か？

WCAG2.0 には、「部分適合に関する記述 － 第三者によるコンテンツ」、JIS X8341-3:2010 には、「8.1.3 第三者によるコンテンツにおける例外」という概念がある。注意深く読めば、JIS X8341-3:2010 の該当個所は、WCAG2.0 の箇所と同じであることはすぐわかる。細かい言い回しは JIS 流儀になっているものの、考え方は同じである。WCAG2.0では「部分適合」が可能であるという説明になっているのに対して、JISでは試験方法で説明されており、これは試験を行う時に第三者のコンテンツを例外的に除外してよいと言っているだけである。もちろん、除外してよいと書いてあるのだから試験結果がOKなら、該当する達成基準を満たしていると言ってもよいわけだ。

たとえば掲示板のようなシステムを作るとしよう。その掲示板システムはWebサイトを公開した時点では記事は投稿されていない。そこに絵文字のような記事が書かれるかもしれないし、アスタリスクを用いてテキストで棒グラフを書く人もあらわれるかもしれない。Webメールのようなシステムでも、どんなメールが届くかわからないのだから、対応のしようがないし、こういったシステムでコンテンツの内部にまでアクセシビリティを保証するのは無理だ。現実的ではない。

WCAG2.0やJIS X8341-3:2010 が想定していたのはこのようなシーンだった。しかし、Webはマッシュアップの時代になった。第三者のコンテンツばかりで構成されたWebサイトはもはや珍しくない。そんな時代にこの概念をどう理解すべきであろうか？

マッシュアップで何かのコードをWebに埋め込む場合、そこにはコンテンツが含まれると同時にUIも含まれる。たとえば、Youtube のビデオをページに組み込めば、ビデオそのものだけだはなく、Youtubeのビデオを再生し操作するためのUIも組み込まれることになる。ここで問題になるのが、UI、そしてビデオ本体が第三者コンテンツとして例外扱いできるかどうかだ。

思い出してもらいたいのだけれど、WCAG2.0やJIS X8341-3:2010 には例外扱いする方法が記されている。1つ目はこれだ。

a) 試験は，分かる範囲で実施することができる。第三者によるコンテンツが監視されていて，2 営業日以内に修正される（適合していないコンテンツが削除されるか，適合するように修正される。）場合には，その第三者によるコンテンツにおいて問題があったとしても，そのウェブページは適合しているとみなすことができる。ただし，適合していないコンテンツを監視・修正できない場合には，適合しているとはいえない。

これは、第三者コンテンツを監視して2営業日以内に修正することを求めている。この対応が本来求められるスタイルだろうけれど、容易ではないというのは明らかだ。いきおい、2つ目の方法に進むことになる。

b) 特定された部分を除外して試験を行ってもよい。そのような場合，8.3 に従って，“ウェブページ全体としては試験していないが，次の第三者によるコンテンツを除いてアクセシビリティ達成等級X で試験を行った。”というような例外事項の記述を行うことができる。ただし，このような例外が認められるのは，次のすべての条件を満たす場合に限る。
1) コンテンツ制作者が監視・修正できるコンテンツではない。
2) 利用者が識別できるように，例外を適用する箇所が明確に説明されている。

こちらはどうか。2） の識別できるようにするというのは、該当するページで箇所を明確に説明しておけばいいだけだから問題はないだろう。問題は、「コンテンツ制作者が監視・修正できるコンテンツではない」といえるかどうかだ。

まず、コンテンツの問題。

たとえば、全く知らない人が作成したビデオをWebページに掲載する場合には、それは第三者のコンテンツであると言える。しかし、それは固定されたある特定のビデオであり、そのビデオがWCAGやJISを満たすかどうかは検証（試験）可能である。したがって、このような場合には第三者の例外は当てはまらない。一方、キーワードを用いてランダムにビデオが再生されるシステムならどうだろう。これは、何が起こるか予測不可能で第三者の例外にするのがふさわしい。もちろん、自分で作成してYoutubにアップロードしたビデオは第三者ですらない。

次に、UIの問題だ。たとえば、Youtubeのビデオを再生するUIがWCAGやJISを満たさないと仮定しよう。確かに、UIのコードは第三者から与えられたものである。しかし、それは検証（試験）可能だから除外する理由にはならないと考えるべきだろう。Youtubeを再生する別のソリューションを利用することも可能だし、新たに開発して提供することさえ技術的には可能だからだ。選択肢がないわけではない。

JIS X8341-3:2010 の「8.1.3 第三者によるコンテンツにおける例外」とは、一言でいえば「第三者が提供するために試験できない、あるいは試験しても変化してしまう」コンテンツを試験の対象から外してもよいと言っているだけである。今だったら、「第三者のコンテンツなのでどうなるかわからないし試験もできない場合の例外」とでもタイトルをつけたに違いない内容だ。

どうも最近、「第三者のものは除外できる」という誤った理解が進んでいる気がする。たとえば、あるサイトには次のような記述がある（名誉のために、あえて伏す）

JIS X 8341-3 8.1.3（第三者によるコンテンツにおける例外）

• 修正用データが無いコンテンツ
• 添付ファイル（PDFファイル等の添付ファイルに関しては運用の事情により等級Aを満たすことに努めることとする）
• Googleマップを使用しているページ

これらはどれも試験の例外にはそぐわない。

もちろん、当面の策としてそういったややこしいページを除外して 取り組みやすいところからJIS X8341-3:2010 対応を始めるということは現実的な選択で、それを責めるつもりはない。けれど、「第三者によるコンテンツにおける例外」は本来、試験結果に付すべきものであって、ここで例示したようなものは、JIS X8341-3:2010 「6.1 企画」で述べられたウェブアクセシビリティ方針に属することではないかと思う。

Webアクセシビリティチェッカーの現状

W3CにWebアクセシビリティチェッカーの一覧ページがあるので、久しぶりに覗いてみたがどうも更新されている気配がありません。そこで、リストの中から有名どころを抜き出して、現状がどうなっているか調べてみることにしました。（ただし、色チェッカー、文法チェッカー、日本のものは除く）

Complete List of Web Accessibility Evaluation Tools
http://www.w3.org/WAI/RC/tools/complete