WCAGに心折られて不死鳥のごとく復活した男の話
この記事はミツエーリンクス Advent Calendar 2020 - Adventarの9日目の記事です。
WCAGとは
本記事は、Web Content Accessibility Guidelines（以下「WCAG」）を一度読んでから、その難解さに心が折れた、もしくは、今なお折れ続けている方にお贈りします。Webアクセシビリティ品質を向上/改善するための手引き（ガイドライン）となるWCAGですが、本記事をお読みの皆さまは、WCAGの難解さに一度や二度は挫折したことのある方がいらっしゃるかなと思います。私はWCAGで初めてアクセシビリティに触れたので、13回ほど折れました。アクセシビリティの向上/改善を始めるにあたって、まず立ちはだかるのがWCAGを理解することの難しさだと思います。その書きっぷりがイイ感じに頭に入ってこないようになっているからです（個人の感想です）。そんなWCAGに心を折られた方に向けて、WCAGを理解するうえで個人的に役立ったなと思う方法を、今回の記事を通して3つご紹介できればと思います。
1つ目：デザイニングWebアクセシビリティ
WCAGが理解できるようになる方法の1つ目は、株式会社ボーンデジタルから発売されているデザイニングWebアクセシビリティを読むというものです。よくあるアクセシビリティの問題が非常に多くの例を用いて紹介されており、アクセシビリティという言葉に馴染みのない方でも理解やすい内容となっています。これからアクセシビリティ向上/改善をしていこうという方には、ぜひとも読んでいただきたい一冊になります。一方で、1点注意すべきは、この書籍は「WCAG 2.0」をもとにして書かれており、2020年12月現在で勧告されているのは「WCAG 2.1」となっているため、必ずしも最新の情報が記載されているわけではないということです。とはいえ、最初のステップとして理解をしていくには、非常に価値のある書籍になります。
2つ目：チェックツールを使い実際のWebサイトで発生している問題を把握する
WCAGが理解できるようになる方法の2つ目として、チェックツールを使い実際のWebサイトでどのような問題が発生しているのかを把握する方法をご紹介します。皆さまは、WCAG 2.1の達成基準がいくつ存在するかご存知でしょうか。実は、WCAG 2.1の達成基準は78個もあります。一方で、WCAGを理解するときに、この78個もの達成基準を1つ1つ暗記して覚えることが必要かというと、そうではありません。（暗記することができれば、それはそれで凄いことですが）達成基準の1つ1つを完璧に覚えることよりも、実際にWebサイト上で発生している問題を通してユーザーへの影響などの理解を深めていくことが、WCAGを知るうえで重要となります。
問題を把握するためのツール「axe」
Webサイトで発生しているアクセシビリティの問題を把握する方法はいくつかありますが、この記事では「WCAG 2.1」をもとにした複数の達成基準ごとに問題を把握できるaxeをご紹介します。axeは、Chromeの拡張機能としてインストールすることができ、インストール後は開発者ツールの中から使用できます。
「分析する」というボタンを押すと、自動的にアクセシビリティの問題を検出しレポートしてくれます。
レポートでは、問題の影響度合いや、達成基準ごとに問題がどれくらい発生しているのか、どのような問題なのかを説明したり、問題となっているソースを示していたりと、アクセシビリティの問題がかなり詳細に把握できるようになっています。実際に運用しているWebサイトや普段からよく使うWebサイトで発生しているアクセシビリティの問題であれば、それがどのような問題なのかをイメージしやすくなると思います。
3つ目：WCAG 2.1 解説書を読む
WCAGが理解できるようになる方法の最後にご紹介するのは、意外と知られていない（と個人的に思っている）WCAG 2.1 解説書を読むことです。少し理解が難しいWCAG 2.1の達成基準に遭遇した場合は、この文書を読むことをおすすめします。私は、この解説書に何度も救われました。WCAG 2.1解説書とは、ウェブアクセシビリティ基盤委員会（WAIC）がUnderstanding WCAG 2.1のドラフトを翻訳し公開している文書のことです。WCAG 2.1解説書に記載されている内容は下記になります。
- WCAG 2.1 に書かれている達成基準
- その達成基準の意図
- メリット (その達成基準が、どのように障害のある利用者の役に立つのか)
- 事例
- 関連リソース
- その達成基準の十分な達成方法及び達成方法の組み合わせ
- この達成基準の失敗例
- その達成基準を満たすための要求を超えているが、一部のあるいはすべてのコンテンツをさらにアクセシブルにするために用いることのできる参考達成方法。参考達成方法を使用することで、宣言する適合レベルに影響を及ぼすことはない。
- この達成基準における重要な用語 (WCAG 2.1 の用語集から引用)
この内容を見ただけでも、WCAG 2.1解説書の凄さがお分かりいただけると思います。WCAG 2.1を見てもよくわからなかったという方にとっては、まさに感動を覚えるほどの内容が記載されています。個人的に助かった内容としては「達成基準の意図」です。下記に「達成基準の意図」の例を1つ挙げます。
達成基準の意図の例
WCAG 2.1から追加された達成基準に2.1.4 文字キーのショートカットというものがあります。この達成基準の内容は下記になります。
文字 (大文字と小文字を含む)、句読点、数字、又は記号のみを使用したキーボードショートカットがコンテンツに実装されている場合、少なくとも次のいずれかを満たしている:
- 解除
- ショートカットを解除するメカニズムが利用できる
- 再割り当て
- 一つ以上の非印字文字 (例えば Ctrl や Alt など) を使用するようにショートカットを再割り当てするメカニズムが利用できる
- フォーカス中にのみ有効化
- ユーザインタフェース コンポーネントのキーボードショートカットは、そのコンポーネントがフォーカスをもっているときのみ有効になる。
この内容を見て、達成基準の意図や実現方法、発生しうる問題などが理解できる方は、すでに一定以上の知識をお持ちだと思います。ある程度の知識や知見が無ければ、内容を理解することは難しいと思います。一方で、この達成基準の解説書「達成基準 2.1.4: 文字キーのショートカットを理解する」を見てみると、とても分かりやすい例示とともに解説されています。ここでは、個人的にわかりやすいと感じた箇所を2つ引用して紹介します。
1つ目です。下記の箇所では「音声入力の利用者や誤ってキーを押す傾向にあるキーボード利用者」という例を挙げることで、どのようなユーザーに影響があるのかがイメージしやすくなっています。
- 意図
- 文字キーのショートカットは、多くのキーボード利用者にはうまく機能するが、(入力手段がひとつずつの文字列である) 音声入力の利用者や、誤ってキーを押す傾向にあるキーボード利用者にとっては不適切かつ、いら立たしい。その結果、利用者は単一の文字キー又は二つ以上の連続した文字キーで構成されたショートカットを解除又は再設定できるようにしなければならない。
続いて2つ目です。下記の箇所では、音声入力の利用者が単一キーのショートカットが有効になっているときに「Hey Kim」と話しかけられた状況を想定しています。この状況で、文字キーのショートカットを無効にすることができなければ、意図しないショートカットが機能してしまうという問題が例示されています。
単一文字キーをコントロールとして用いるのは多くのキーボード利用者にとって適切かつ効率的かもしれないが、音声入力の利用者にとって単一キーのショートカットは悲惨なものである。これは、単一キーのみがコマンドを実行するために使用されると、カーソルフォーカスが誤った位置にあると、発話された単語が単一キーコマンドの連発となる可能性があるためである。
例えば、移動 ("k")、アーカイブ ("y")、メッセージをミュート ("m") する一般的なキーボードショートカットを使用しているウェブメールアプリケーションの主ウィンドウ内にカーソルフォーカスがあり、他の人がオフィスに入室して "Hey Kim" と言ったのを音声入力の利用者のマイクが拾った場合、「y」は現在のメッセージをアーカイブする。「k」はひとつ下の会話に移動し、「m」はメッセージ又はスレッドをミュートする。
ここで紹介したように、WCAG 2.1 解説書が達成基準を理解するのに役立つ理由の1つとしては、ユーザーのイメージや、実際にどのような問題が起こるのかが想像しやすくなることにあると思います。この文書の存在を知らなかったという方は、ぜひWCAG 2.1 解説書へアクセスしてみてください。理解が難しかった問題や達成基準が非常にわかりやすく解説されているはずです。
まとめ
今回の記事では、簡単ではありますがWCAGが理解できるようになる方法を3つご紹介しました。アクセシビリティを向上/改善したいけれど、WCAGが難しくて理解ができないという方の一助となれれば幸いです。