『WCAG』から独自のガイドラインを作った理由　必要な視点は「誰のどんな不便につながるか」

2020年4月に一般公開した「freeeアクセシビリティ・ガイドライン」

中根雅文氏：今日一番参考にしていただけるのではないかなと思うところは、この後のデモの部分だと思います。ということで、ここも短めにいこうと思います。

今ちょっと伊原さんから話してもらいましたが、実際にチェックを進めていく時とか、あるいはその改善に取り組んでいった時に、具体的に何をやればいいのかは「アクセシビリティこれまでずっとやってきたよ」という人たちはある程度やるべきことも見えるだろうし「ガイドライン使えばいいよ」とか、そういう話になると思います。

一方でアクセシビリティを聞いたことはある、やったほうがいいような気はするけど、じゃあ何からやればいいんだろう、具体的にどういうことをやればきちんとなるんだろうみたいな、経験としてあまり知らない人たちにとっては、やっぱり具体的なインストラクションや情報が必要になってくるわけです。

アクセシビリティ改善に取り組もうと思ったことがある方は、けっこう日々感じていらっしゃるんじゃないかと思います。

さっきもちょっと出ていましたが、「freeeアクセシビリティー・ガイドライン」というものがあります。社内的に「こんな感じかな」という状態になったのが2020年の初めですかね。「もうちょっとこれを世の中の厳しい目に晒して、フィードバックをいただいてよくしよう」みたいなことを含めて考えて、一般公開したのが2020年4月の終わりです。

以前は経験知を集結した「俺のアクセシビリティチェック」を活用

ということで、2020年の初めよりも前は、独自のガイドラインがない状態でした。その時はどうなってたかというと、経験知を集めてぎゅっとした社内では「俺のアクセシビリティチェック」と呼ばれていたドキュメントがありました。こういう時にはこうするといいよとか、こうするとこういう問題がわかるよみたいなことが、比較的きちんと体系立てて書かれたドキュメントがあったんですね。

主に伊原さんからこれまでどうやってきたかとか、知り合いの他社の人からどんなことをやってきたのか話を聞いて、それを参考に作ったドキュメントがありました。

これを見せて「こういう感じなんでちょっとよろしく」という感じでした。技術的な背景や、バックグラウンドや、アクセシビリティ的なことについてある程度知ってる人にとっては「ああなるほど」という内容だったと思うのですが、これまであまりやってこなかった人は「とはいえ」みたいな状態になってしまうわけです。

そのチェックのやり方だったり、なんでそういうことが必要なのかだったり、そういうところの記述の部分が、項目によっては具体性にけっこうバラつきがあって、「もっと体系化した文章が必要だよね」と言っていました。

効率的なチェックには「誰のどんな不便につながるか」の視点が大事

「効果的なチェックのために」ということで。できたものをチェックをする、あるいは作ってる途中のものをチェックをする。その目的は、問題を見つけてそれを改善するというサイクルを回すことにあるのですが、その問題が「誰」の「どんな不便」につながるのかをきちんと理解していないと、結局本質的な意味で問題を解決することにつながらないと思います。

例えば「画像にきちんと説明をつけましょう」「IMG要素にALT属性をつけましょう」と言った場合「つければいいんでしょ」と、意味のないテキストを入れたとしてもそれはつけたことにはなるわけです。

だけど、きちんと「どういう人の、どういう不便を解消するためにつけるのか」を意識していれば、自ずとそこに入れるべきテキストは「こうしたほうがいいんじゃないか」「ああしたほうがいいんじゃないか」と考えるようになるわけです。

なので、それぞれのチェックがどういう問題で、その問題が誰のどういう不便につながっているのかを理解したうえで実施されないと、やっぱり効果的な改善プロセスはなかなか生まれないだろうと考えました。

超有名文書は分量が多く読んで理解するのが大変

例えば視覚に障害がある人が画像を見えない不便につながっていて、だからこういうことに気をつけて、きちんと画像には説明をつけましょう。その方法はIMG要素にALTをつけることです、みたいなことは、実はこの『Web Content Accessibility Guidelines』という超有名文書に全部書かれてるはずなんです。

ガイドライン本体はけっこう抽象的な話が多くて「そこからすべてを読み取れ」というのはけっこうムチャな話だと思います。それに付属する『Understanding Web Content　Accessibility Guidelines』という、長大なドキュメントがあって、最近は翻訳チームががんばっているみたいでけっこう最新版に追従していて、本家の英語版よりもちょっと遅れたタイミングで日本語版があるドキュメントなのですが、分量が多いし、なかなか難しいんですよね。1つの説明でいろいろなことを網羅しようとしていて、じっくり読み込めば「なるほど」と言えるようなことがいっぱい書いてあるのですが、なかなか読むのも大変です。

単純に「『WCAG（Web Content Accessibility Guidelines）』と、それから『Understanding WCAG（Web Content　Accessibility Guidelines）』を読んで理解してね」と言えればものすごく楽ですが、そうはいきません。なかなかそうはいかないぞということがあります。

ということで、『Understanding WCAG』も分量が多いし、ガイドライン本体も文章がわかりにくい。そもそもWCAGそのものが、ある意味内容に対してアクセシビリティが低いんじゃないかとずっと思っていました。

実は僕は今のJIS X 8341:3、2016年版の時の原案作成委員会にいて、『WCAG』の翻訳も散々やったのですが、とにかく訳すのも大変だし、訳したものを理解するのも「これで本当に理解できるんだろうか」の連続だったので、これを特にこれまでアクセシビリティに馴染みがなかった人に渡して「理解して」というのは無理だなと常に感じていました。

具体的にWCAGはどう難解なのか、簡単に例として挙げたのが次のスライドです。SCはSuccess Criteriaで達成基準ですね。このSC1.1.1の冒頭の書き出しの部分だけです。「利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されている」そしてその後に「ただし、何とか」みたいなことがズラーっと続きます。

これ、すごく抽象的な書き方ですよね。非テキストコンテンツとか、テキストによる代替とか。用語の定義がWCAGの最後のほうでされていて、その用語の定義の中に書いてある説明の中にも、また別のところで定義されている用語が使われていたり、読んで理解しようとすると大変なんですね。

だけど、ここに書いてありますが、こと画像に関して言えば「画像には代替テキストつけましょうね」と言いたいだけなんです。「言いたいだけ」というのも乱暴でちょっと嘘なのですが、でも基本はそうなんですね。さらに噛み砕いて言うと「IMG要素にはALT属性つけましょうね」という、それを実現させたいがための達成基準なんですよ。

とは言いつつ、実はこの1.1.1はすごくカバー範囲が広いです。ここに「非テキストコンテンツは画像だけではない」と書いてあって、次のスライドにいくと、カバーするのは画像だけではないということで、WCAG2.1の達成基準とfreeeのガイドラインの対応表が実はガイドラインの中にあります。

そこを見ると、達成基準1.1.1に対応するのは7のガイドラインになっているんですね。具体的には画像に関するもの、フォームに関するもの、画像化されたテキストに関するもの、アイコンに関するもの、あとは何だっけかな、音声コンテンツかな、とかそういう感じの多岐にわたるものを実はこの1.1.1がカバーしています。きちんと読めば書いてあるのですが、1つの項目からそれを全部読み取るのは、なかなか難しいです。

今、WebにはhtmlとJavaScriptとCSSが主なテクノロジーとして使われていますが、これがそうじゃなくなった時にも概念としてきちんとアクセシビリティが実現できるように、概念部分をきちんと書こうという基本的な方針があると思うのですが、その結果としてすごく抽象的な書き方になってしまってるわけです。

今はhtml、CSS、JSを中心に、一部にSVGとかを使っているので、技術に特化した具体的な説明がないと、やっぱりわかりづらいよねというところがあるなと思います。

『WCAG』がわかりづらいんだったら、ちょっとわかりやすいようにしましょうということで、独自ガイドラインを作りましょうとなって作りました。

独自ガイドラインはやるべきことを明確にすることを目指した

独自ガイドラインは、扱うコンテンツの種類によって具体的にやるべきことを明確にすることを目指しました。さっきも言ったような、画像、フォーム、音声、動画、コンテンツ、テキスト、ページ全体、それらをそれぞれカテゴリ分けをして、そういったコンテンツに関してどういうことを気をつければいいのか調べながら作れるものを目指してみました。

それから、いろいろなガイドラインが満たされているかどうかを確認する方法が明示されていないと確認のしようがないよねということで、チェックを作りました。そのチェックの方法をまとめたものがチェックリストです。

さっきも言いましたが、ガイドラインが誰のどんな問題の解消につながるのかという情報や、1回読めばだいたいわかるけど、1回も読まずにチェックをするのはちょっと厳しいよねという背景の情報を、参考情報として各ガイドラインやチェックとリンクするようにしています。

なので、さっきの「画像にALT」だと、画像というカテゴリがあって、その中に画像の説明のセクションがあって、その中にいくつかのガイドラインがあります。画像の説明をつけると全般に関する解説が参考情報として別ページに書いてあって、そこにリンクが貼ってあるという構造になっています。

実際に実務としてチェックをしたいという人たちにももちろん使ってもらいたいのですが、そもそも何のためにやるのかを知りたい方にとっても役立つ情報を提供できればいいなという思いで作っています。

ということで、ガイドラインとチェックリストができました。ガイドラインの使い方と書いてあるのですが、作ろうとしているコンテンツの内容に合ったカテゴリのガイドラインを確認します。

例えば、画像に関する注意点ってなんだっけ？　であれば画像のカテゴリを見ます。そもそもなんで必要なんだっけ？　というところであれば参考情報を見ます。じゃあ具体的に、これが本当にこのガイドラインを満たしてるのかな？　という時は、チェックの方法を確認して、それをやってもらいます。このような手順で利用してもらうことを想定しています。

フィルターや独自のメニューを追加したチェックリスト

チェックリストの使い方です。チェックリストは、さっきもちょっと紹介してもらったのですが、すべてのチェック項目をまとめたhtmlのページと、それをまとめたGoogleスプレッドシートを最近社外向けにも公開しました。社内ではこれを使ってやっています。

チェック項目ごとに、どのタイミングでやるべきチェックなのかを分けています。設計時に確認すること、実装時に確認すること、それから動作確認時、うちの会社の場合だとQAですね、品質管理の段階でやることに分けています。

スプレッドシートでいうと「対象」というカラムがあって、それで絞り込みができるようにしてあります。Google Drive上でこのスプレッドシートのコピーを作っていただくと、フィルターや、フィルターを簡単にかけられる独自のメニューを追加しているので、こういったものを利用して、実際にチェックに活用してもらえるとうれしいなと思っています。（※取材当時　現在は使用が変更されている）

僕からお話ししたかったのは、こういったかたちで世にあるガイドラインを、いかに噛み砕いてわかりやすくするかがけっこう重要になると感じた結果として、こういったものを作りましたというところでした。

世の厳しい目に晒されてガイドラインを改善したいという思いはあるのですが、それと同時に、同じようなところで困ってる人たちにもぜひそのまま活用してもらいたいと思っています。クリエイティブコモンズのライセンスで公開していますので、必要があれば、独自の変更も加えて、どんどん使ってもらいたいと思っています。

ということで、ここまで僕からのお話でした。