- 制作
- 更新日:
Webアクセシビリティが一般的になってきた昨今。
どのように対応していけばいいかお悩みの方も多いと思います。
そこでWCAG2.1のガイドラインに照らし合わせて、実際の対応方法についていくつか確認してみましょう。
アクセシビリティとは?
まずは基礎をおさらいしましょう。
アクセシビリティ(Accessibility)とは
- アクセス:access:接近
- アビリティ:ability:能力
2つをかけ合わせた造語です。
略称として「a11y」(aとyの間に11文字あるため)と省略して表記することがあります。
その中でもWebに特化したアクセシビリティを「Webアクセシビリティ」といいます。
一昔前まで、アクセシビリティは障がい者・高齢者向けの施策と言われていた時代が長くありました。
その代表的な例としては
- ヘッダー部分に文字の大きさを変更するボタンの設置
- 事前収録された音声情報リンクの設置
- 背景色の変更
といったものです。
現在では上記のようなものをWebサイトに設置することをWebアクセシビリティと呼ぶことはありません。
なぜならこれらはOSのもつ機能で十分補完可能だからです。
真のWebアクセシビリティは
「Webサイトが提供する様々なサービスや情報に誰もがアクセスしやすくすること」
をさします。
- メガネを忘れてしまった
- 利き手を怪我してしまった
- 直射日光で画面が反射してしまった
- 忙しくてじっくり読んでいる暇がない
- 検索エンジンにサイトクロールされない
など我々の身近な事象においてアクセス不能な事態が起きたときでも、サービスや情報にアクセスできるようにしなければなりません。
どんな対策をしていけばいいの?
Webアクセシビリティの本質を理解するにはWCAG2.1のガイドラインを閲覧することをおすすめします。
ガイドラインを見たとき「文字の多さ」に慄いてしまうかもしれません。
そこでどんな施工をおこなうものであるのか、ガイドラインを少し噛み砕いてみます。
- 非干渉であること
- こちらの意思に従わせようとサイト内で指図・妨害しないこと
- 全体に関わること
- Webサイトを作る一番大きな枠組みの対応をおこなうこと
- 動画・音声に関わること
- テキストで表すことのできる状態にすること
- テキストに関わること
- わかりにくい言葉を使わないこと
- 画像にかかわること
- どんな画像であるかわかるようにすること
- 制限時間
- 時間制限のあるコンテンツに>注意すること
- 色
- コントラスト比を確保すること
- フォーム
- ユーザーが迷わず操作できるようにすること
といったものがあります。
これらをガイドラインでは4つの大カテゴリにわけ下記のように表しています。
- 知覚可能(ちかくかのう)
- 操作可能(そうさかのう)
- 理解可能(りかいかのう)
- 堅牢(けんろう)
大カテゴリの中には中カテゴリがあります
- 知覚可能
- テキストによる代替
- 時間依存メディア
- 適応可能
- 判別可能
- 操作可能
- キーボード操作可能
- 十分な時間
- 発作の防止
- ナビゲーション可能
- 理解可能
- 読みやすさ
- 予測可能
- 入力支援
- 堅牢
- 互換性
中カテゴリ内には個別の対応方法が記述されています。
個々の対応方法は3段階でレベル分けされており、対応の難易度が低い順に
- A(シングルエー)
- AA(ダブルエー)
- AAA(トリプルエー)
となっています。
ガイドラインの大まかな概要は上記のとおりです。
具体的にどんな対応をしていくの?
ガイドラインの全容を把握したところで、実際にどのように対応をしていけばよいかを確認してみましょう。
具体的な対応方法や失敗例もガイドラインに記載されていますが、ガイドラインの「A(シングルエー)」からいくつか抜粋し一部をカンタンに解説します。
正確な対応方法はWCAG2.1のガイドラインをご確認ください。
1. 知覚可能 1.1 テキストによる代替 1.1.1 非テキストコンテンツ(A)
- 対応例
-
- 意味のある<img>要素、<area>要素、<input type=”image”>要素にalt属性を入れる
- 注意
-
- 装飾目的の<img>要素にalt属性は入れない その場合alt=””と空要素にする
- 意味のないalt属性をいれない
- 解説
- テキストを含む画像は画像内のテキストをaltに含めましょう。
1. 知覚可能 1.2 時間依存メディア 1.2.1 音声のみ及び映像のみ(収録済)(A)
- 対応例
-
- 音声のみのデータであれば、音声をテキスト化したデータを用意し、音声データの直後にテキストデータを用意する
- 映像のみのデータ(特に説明形式の映像)であれば、映像の動きを説明するテキストを用意し、映像の直後にテキストデータを用意する
- 注意
-
- 音声のみでも映像のみでも用意しているコンテンツ以上の情報をテキストとして提供しないこと
- 解説
- テレビの音声解説を参考にしてみましょう。
テキストデータの掲載は、リンク形式でも直接記載でもかまいません。
1. 知覚可能 1.3 適応可能 1.3.1 意味のある順序(A)
- 対応例
-
- HTMLを意味のある順序で記述する
- CSSを切ったときに正しい順序で表示されるようにする
- 注意
-
- コンテンツの読み上げ順序が変わらないようにする
- 見た目に依存するあまり、HTMLのマークアップ順序とは大きく異なる順序になるようなCSSをもちいない
- 解説
- 見た目にとらわれすぎるあまりHTMLの本質を見失わないようにしましょう。
1. 知覚可能 1.4 判別可能 1.4.1 色の使用(A)
- 対応例
-
- グラフなどは色と一緒に模様をもちいて表現し凡例を用意する
- 入力が「必須」であることを伝える場合は「テキスト+色」で伝える
- モノクロ表示だけで情報が正しく伝わっているか確認する
- 注意
-
- 色の違いで情報を伝えないこと
- NG例)「赤い文字は必須です」「Yesの場合は◯色、Noの場合は◯色を選択してください」
- 色の違いで情報を伝えないこと
2. 操作可能 2.1 キーボード操作可能 2.1.1 キーボード(A)
- 対応例
-
- マウスを使わずにキーボードだけでWebサイトの閲覧ができるようにする
- フォーカスがどこにあたっているかわかるようにする
- 注意
-
- マウス操作だけで実行する機能にしないこと
- <a>以外の要素にリンク機能をもたせないこと
- 解説
- ブラウザで閲覧するときTabキーを使ってサイト閲覧をしてみましょう。
2. 操作可能 2.2 十分な時間 2.2.1 タイミング調整可能(A)
- 対応例
-
- 制限時間のあるコンテンツを利用する前に制限時間を解除できるようにする
- 制限時間のあるコンテンツを利用する前に制限時間を基本設定の10倍以上に設定できるようにする
- 制限時間が来る前に警告をしてユーザーの簡単な操作で時間を10倍以上延長できるようにする
- 注意
-
- オークションなどのリアルタイムのイベントはこの対応は除外できる
- 制限時間を延長することでコンテンツの動作が無効になる場合もこの対応は除外できる
- 制限時間の基本設定が20時間よりも長い場合この対応は除外できる
- 解説
- 入力フォームでセキュリティのためと称して、制限時間を超えるとログアウトされたりTOPページへ戻されるサイトを見かけます。
このような対応をおこないたい場合は対応例の通りに実装しましょう。
2. 操作可能 2.3 発作の防止 2.3.1 3回の閃光、又は閾値以下(A)
- 対応例
-
- 1秒間に3回を超える閃光(点滅)を放たないようにする
- 人間が光の刺激に対して最も敏感である彩度の高い赤色は特に注意する
- 注意
-
- 閃光と点滅は同じ意味で捉えられることがある
- たとえ1pxでも1秒間に3回を超える閃光や点滅を放たないようにする
- 動画内の稲妻やカメラのフラッシュは特に注意しましょう
- 解説
-
- 閃光は発作が起きやすくなるため、使わないようにしましょう。
点滅は短時間であれば許容されていますが、停止できるようにしましょう。
- 閃光は発作が起きやすくなるため、使わないようにしましょう。
2. 操作可能 2.4 ナビゲーション可能 2.4.2 ページタイトル(A)
- 対応例
-
- <title>タグにはそのページの内容を示すページタイトルをつけましょう
- 注意
-
- コンテンツを特定していないページタイトルをつけてはいけません
- NG例)「無題ドキュメント」「新しいページ1」等
- コンテンツを特定していないページタイトルをつけてはいけません
- 解説
- SEOと連携してページタイトルを決定すると良い結果になりやすいですが、やりすぎないように注意しましょう。
3. 理解可能 3.1 読みやすさ 3.1.1 ページの言語(A)
- 対応例
-
- <html>タグにlang属性を入れる
- 注意
-
- その文書の初期設定言語を特定するもの
- 日本で制作され、ページ内に英語のコンテンツが含まれているがコンテンツの殆どが日本語の場合lang属性はja(日本語)にする
- 解説
- そのサイトのメインユーザーはどの言語をメインに使う方なのかを考えましょう。
3. 理解可能 3.2 予測可能 3.2.1 フォーカス時(A)
- 対応例
-
- コンポーネントがフォーカスを受け取ったときに内容を変えない
- コンポーネントがフォーカスを受け取ったときにページ遷移させない
- コンポーネントがフォーカスを受け取ったときにフォームを自動で送信しない
- 注意
-
- コンテキストの変化を起こすトリガーはfocusではなくactivateにする
- 解説
- フォーカスでコンテンツに変化を起こさせるのではなく、ユーザーのアクション(スペースキー押下など)で変化を起こさせるようにしましょう。
3. 理解可能 3.3 入力支援 3.3.1 エラーの特定(A)
- 対応例
-
- フォームで未入力の箇所や入力ミスを指摘する場合は「どの箇所が」「どういうエラーであるか」をはっきり明示する
- 注意
-
- 「入力エラーです」「この項目は必須です」というテキスト表示や「エラー箇所に色や印がつくだけ」というエラー表示は情報として不十分
- 解説
- MAツール(マーケティングオートメーションツール)を使用している場合、MAツール側の仕様で、エラー文が1つしか登録できない場合が多いです。
その場合は「お名前を入力してください」など、できる範囲で明示的なエラー文の設定をおこないましょう。
4. 堅牢 4.1 互換性 4.1.1 構文解析(A)
- 対応例
-
- HTMLの開始タグと終了タグをきちんと対にして入れる
- HTMLの使用に準じて入れ子構造にする
- 同じページ内に同じid名を2つ以上指定しない
- 1つのタグ内に同じ属性を2回以上記述しない
- コーディング後にLintチェックをかけエラーを修正する
- 注意
-
- マークアップ言語によって適切な構文をもちいること
まとめ
Webアクセシビリティをしっかり対応しようとするととても大変だと思ってしまいがちですが、Webサイトを作る際やWebサイトを更新する際に、少し意識するだけでほとんど網羅できてしまいます。
ここで紹介したこと以外にも対応できることとしては
- aria属性を追加する
- スクリプトによって適切な実装方法を提供する
などがありますが
このような応用編で解決しようとせず、まずは基本をしっかり抑えることが重要です。
日常生活において、エスカレーターやエレベーターが我々の生活にとって使いやすいものであるように、使いやすいWebサイトは、誰にとってもどんな状況になっても使いやすくアクセスしやすいサイトになります。
明日の自分たちのためにも今からできることをしっかり始めていきましょう
この記事はDigital Identity Creative Div. Advent Calendar 2022 2日目の記事です。
広告運用やSEO、解析・Web製作など、当社はWebに関わるベストソリューションをご提供しています。お悩み・ご相談も受け付けておりますので下記のボタンからお気軽にご連絡ください。
自社サイトのウェブアクセシビリティ状況、診断してみませんか?
株式会社デジタルアイデンティティでは、ウェブアクセシビリティ診断サービスを提供しています。
2024年4月、障害者差別解消法の改正施行に伴い、2024年6月から一般企業にも「合理的配慮」が義務化されています。
これに伴い、努力義務である「環境の整備」に含まれるウェブアクセシビリティについても、対応を進める企業が増えています。
こんなお悩みはありませんか?
- どこからウェブアクセシビリティ対応に手をつければ良いかわからない…
- 今のサイトで問題のあるページを一覧化して欲しい…
- ウェブアクセシビリティの具体的な改善方法を知りたい…
WCAG2.2に準拠した診断項目・達成基準で、問題のあるページをリスト化してページ単位で問題点をリストアップ。
課題点が明確になるので、具体的な改善アクションに繋げることができます。
また、診断後の改善作業を弊社にワンストップでご依頼いただくことも可能です!
ぜひお気軽にご相談ください!