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

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

パターン１

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

パターン２

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

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

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

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

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

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

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

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

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

35年前の感触と背中とアクセシビリティ

僕は52歳になりました。

今日が誕生日。家族が寝静まって仕事も終わりにして、カレンダーに穴を開けてひとりサイダー飲んで祝ってます。

そうか。あれから、もう35年も経ったのですね。

ずっと、アクセシビリティに関わる仕事ばかりしてきました。なぜそこに興味をもったのか、なぜアクセシビリティをやっているのかと聞いてくださる人はあまりいません。もしかしたら、猫背の真ん中に僕には見えない文字で「アクセシビリティ！このやろ！まじめにやらんかい！」などと書いてあって、そのインパクトが強すぎて聞こうと思われないのでしょうか。

うちのかみさんは「あなたはいつもしかめっ面で怖いオーラ出してるから声かけづらいんじゃないの？」といいますが、あなたのほうがよっぽど怖い、とは、口が裂けても言えません。


（これ、かみさんが読まないことをみんなで祈ってください）


京都のいなかの高校に通っていたころです。近くに有名な「与謝の海養護学校」という学校がありました。そこで開催される「交流会」のような催しに参加することになりました。そのあとの出来事が衝撃的で、実はほとんど記憶が飛んでいるのですが、いろいろな学校の合唱があったり、もしかすると吹奏楽の演奏もあったかもしれません。手品はなかったと思います。

ひととおり体育館での催しが終わった後、グランドに出て生徒同士の交流が始まりました。

すると、ひとりの養護学校の先生が、

「はい、あなたはこの子としっかり手をつないでてね」

と言って、ひとりの女の子と手をつながされ、その先生はさっさとどこかに行ってしまいました。

彼女は、重い知的障害のある、でっぷりと太った生徒でした。まったく表情がない。動こうともしない。鼻水垂らしながら僕の右手をしっかり握って、まるでぶら下がっているようでした。手を離さないようにと言われた手前、暑い季節じゃなかったのに、額に汗して「しっかり握っていよう」とだけ思っていました。しかし、17歳の未知体験です。障害の重いその子は少し怖い感じもするし、掌も汗びっしょり。つないだ手から少し鼓動のようなものを感じて、生きている「人」であるということは実感しますが、意思の疎通は全くなし。まるで暖かい石にくくりつけられたような、長くて気の遠くなるような時間でした。

そのあと、どうやってそれが終わって、どんなふうに家まで帰ったのか。全く覚えていません。それほど、あのころの僕には衝撃のできごとでした。でもどうしたことでしょうか。それからというもの、「障害」という文字が目に入ってくるし、ニュースにも敏感になっていきました。社会のありように目を開いていく青葉の季節だったのでしょう。障害のある人と出会ってしっかりと存在を意識した初体験です。

こんなできごとが、僕にとって障害を考える原体験になっています。10代の若さで理屈ではなく感じたこと、感触、温度、そういったものが僕を形づくり、そして35年後に向かってグイっと背中を押したのだと思うのです。

アクセシビリティを語るときに、技術の課題として議論してすませてしまうことが増えています。私自身がそうなっています。だけど、生きている人がいてくらしを営んで、そして、困っていたり苦しんでいたりするということ。ニンゲンが生きるということに直接かかわっているのだということ。そのことを、あの感触を、あの汗を忘れないようにしたいと思うのです。それが、アクセシビリティという技術が解決し、実現しようとしていることだからです。

実はもうひとつ、若かりしころの衝撃体験があります。それについてはどこかの飲み会ででも聞いてください。

そして最後に念を押しておきますが、決して僕のかみさんにはこの記事教えないでくださいね。


これは、Web Accessibility Advent Calendar 2013 のために書きました。

アクセシビリティってどゆこと？

”Accessibility: What does it all mean?” （アクセシビリティってどゆこと？）

Abilitynet のこの動画、すごくかっこいいだけでなくて、アクセシビリティをうまく表現してる。

くじ引きの時間

さあ、商店街の大売り出し、くじ引きの時間です。

1000枚の三角くじが箱に入っています。当たりは50枚入っていて、残りの950枚は外れです。たくさんいろんなものを買ってくじ引き券を40枚もらったので、40回のくじ引きができるとします。

しかし、しかし、なんと40回もくじ引きできたのに、1度も当たりませんでした。何ということでしょう！あまりに悔しいので1枚も当たらない確率を計算してみましょう。

まず1000枚のくじがありますので、そこから40枚のくじを選ぶ組み合わせの数は、1000C40 です。次に、外ればかり引く組み合わせはというと、950C40 です。

この2つの数を割り算すると、0.12 になりました。1000枚中に当たりが50枚ある時には、40回引いても1回も当たらないなんてことが12%の確率で起きるものなのです。残りの88%の確率では当たりを1枚以上引くはずです。

---

この計算、1000ページのウェブサイトにJIS X 8341-3:2010 を満たさないページが 50 ページあると仮定して、そのサイトの中から 40 ページをランダムにサンプリングしたときに、問題のあるページをひとつも発見できずに間違って「準拠」としてしまう確率と同じ計算なんです。

40ページサンプリングすれば、5%の問題ページを見過ごす確率は 10% 強

60ページサンプリングだと、同じ条件で問題を見過ごす確率は 4% です。このくらいの確率なら、そこそこいい線いってる気がしませんか？もちろん全ページチェックすれば問題を見過ごす可能性は0%になります。（実際には、チェックする人が見落とす可能性もあるのでゼロにはなりません）

40ページってそういうことらしいです。