アクセシビリティを知ってみたい！
アクセシビリティを知りたい！！！
フロントエンドのプログラマをしていると、アクセシビリティという言葉を聞くと思います。
ただ、アクセシビリティが実際にどんなものか、どのようなことをしないとならないかはよくわからない、ということがあるのではないでしょうか。
自分がそんな人間だったので、アクセシビリティについて調べてみました。
アクセシビリティとは
アクセシビリティを Wikipedia で調べると、なんだか難しそうな定義が書いています。
wikipedia:アクセセシビリティ
要約すると、「障害の有無かかかわらず、どんな人でも使えるようにしましょう」です。
例えば目が見えない方であれば、点字などを配置することで文字から取れる情報を同様に取得できるようにしたり、高齢者の方でも操作等が可能であるようにする、といったことです。
Web におけるアクセシビリティ
Web におけるアクセシビリィについても Wikipedia では言及しています。さすがですね。
こちらで WCAG という単語が出てきます。
この WCAG というのは Web Content Accessibility Guidelines の略で、W3C によって策定されています。
ここからはこの WCAG について読み解いていきたいと思います。
WCAG とは
WCAG はアクセシビリティにも記載しているように、様々な障害のある人にとってもコンテンツをアクセシブルにするためのガイドラインで、現在のバージョンは 2.0 です。
ガイドラインは 4 つの原則で作られています。
- 知覚可能 - 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
- 操作可能 - ユーザインタフェース コンポーネント及びナビゲーションは操作可能でなければならない。
- 理解可能 - 情報及びユーザインタフェースの操作は理解可能でなければならない。
- 堅牢 (robust) - コンテンツは、支援技術を含む様々なユーザエージェントが確実に解釈できるように十分に堅牢 (robust) でなければならない。
この 4 つの原則のもとに、詳細化されたガイドラインが敷かれています。
1. 知覚可能
ガイドラインは 4 つです。
- テキストによる代替: すべての非テキストコンテンツには、拡大印刷、点字、音声、シンボル、平易な言葉などの利用者が必要とする形式に変換できるように、テキストによる代替を提供すること。
- 時間依存メディア: 時間依存メディアには代替コンテンツを提供すること。
- 適応可能: 情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。
- 判別可能: コンテンツを、利用者にとって見やすく、聞きやすいものにすること。これには、前景と背景を区別することも含む
代替テキストが一番わかりやすい例になるかと思います。
例えばトグルボタンのようなボタン。視覚に問題のないユーザーにとってはそのボタンがどのような役割を果たすか、なんとなく画面を眺めれば分かるかと思いますが、視覚に問題のあるユーザーはそのボタンの意図を読み取れません。
ボタンに何を目的としたボタンかの説明を入れることで、視覚に問題があるユーザーでもスクリーンリーダーなどを使ってそのボタンの意味を取ることができるようになります。
このように利用者に依存せずに知覚が可能となることを目標としているのが 1 つめの原則になると思います。
2. 操作可能
ガイドラインは 4 つです。
- キーボード操作可能: すべての機能をキーボードから利用できるようにすること。
- 十分な時間: 利用者がコンテンツを読み、使用するために十分な時間を提供すること。
- 発作の防止: 発作を引き起こすようなコンテンツを設計しないこと。
- ナビゲーション可能: 利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。
2 つ目の十分な時間というものが普段あまり意識されないかなと思います。
制限時間のあるコンテンツを制限時間をユーザーが解除することができたり、また、制限時間の調整ができたりするというものです。
予約システムなどでいうと、予約はリアルタイムで埋まっていくので制限を設けたくなるところですが、それも制御する必要があるのはなかなか難しいかなと思います。
3. 理解可能
ガイドラインは 3 つです。
- 読みやすさ: テキストのコンテンツを読みやすく理解可能にすること。
- 予測可能: ウェブページの表示や挙動を予測可能にすること。
- 入力支援: 利用者の間違いを防ぎ、修正を支援すること。
3 つ目の入力支援が一番簡単に想像のつく例になりそうです。
たとえば入力のエラーなどの時に、どこがエラーで、どのようなエラーかまでを説明します。
さらに深いところまでいくと、修正方法の代案なども表示する必要が出て来ます。
4. 堅牢 (robust)
ガイドラインは 1 つです。
- 互換性: 現在及び将来の、支援技術を含むユーザエージェントとの互換性を最大化すること。
まずは簡単なところで構文解析。
マークアップがちゃんと構造化されているか、HTML 標準の構造になっているかが求められます。
加えてユーザーインターフェースについて、role などが適切に与えられているかが求められます。いわゆる WAI-ARIA というものです。
普段は意識しないタグになるので、なかなか知識がなかったりで大変な箇所になりそうです。
WCAG はわかった。では我々は何をすれば？
ここまでは WCAG について説明しました。じゃ具体的にどう実装すればいいの？というところを感じるかと思いますが、ここがめっちゃめちゃ難しいところで、言語化はされているものの、実装の例が WCAG では挙げられていません。
こうしてくれ、とは言ってくれるものの、どうしたら OK までは提示してくれないのです。なんとまぁ難しいこと！
ですが安心してください。うちの会社はこうしているよ、という提示を、しかも日本語でしてくれているものがあります。それが Ameba さんのアクセシビリティガイドラインです。
Ameba Accessibility Guidelines
実装のサンプルもですが、リンターの設定なども提案してくれているので、かなり有用になるかなと思います。
が、このガイドラインが完全下どうかでいうと、こちらについては Ameba さんが自社ブランドでこうするべきというラインです。
また、私はアクセシビリティの専門家でないので、こちらが完全に WCAG の水準を厳密に超えているかは保証できませんので、そこだけはご了承ください。
終わりに アクセシビリティの定量的側面と定性的側面について
アクセシビリティはここまで読んでいただいてきたと思いますが、なかなか難しい課題です。
WCAG にガイドラインはあれど実装のサンプルがないのは、一概に実装だけが課題でないというところも実はあります。
アクセシビリティでは機械的に計測できる箇所もあります。実際にアクセシビリティの問題を計測してくれるライブラリも存在します。
ですが、この機械的な計測箇所だけで全てが解決するかというとそうではありません。たとえばスクリーンリーダーの読み込みについて機械的には問題がなくとも、もし読み上げで全く違う言葉を読んでいたら意味がないです。
また、そもそも文章が適切かなどの箇所についてはまだ機械では測れないところがあります。
このように、正しいか、満たしているかがただの数字的に測れる訳でもないのが難しいところで、アクセシビリティを全て満たすとなればそういったところまでの理解が必要となるので簡単には行かないというところが奥深さであり難しさかと思います。
とはいえ、多くの人間が使う web アプリという中では切っても切れないものですし、自分の作るアプリをどんな人間でも使えるようにするというのは素晴らしいことだと思うので、今後も少しづつ学びたいなと思いました。
Discussion