ウェブサイトには、利用者が情報や機能へアクセスするのを妨げる実装があります。「マウスを使わないとメニューを開けない」「拡大すると文字が重なる」「フォームのエラー箇所がわからない」といった例です。けがでマウスを扱いづらい人や、音を出せない場所で動画を見る人も同じ問題に直面します。
ウェブアクセシビリティーは、ウェブサイト制作やフロントエンド開発で欠かせないテーマです。HTML、CSS、JavaScriptの設計と実装が、情報や機能を利用できる人の範囲を左右します。
この記事では、ウェブ制作で押さえておきたい規格、国内制度、実装時の確認項目を紹介します。
ウェブアクセシビリティーとは
W3CのWeb Accessibility Initiative(WAI)によると、ウェブアクセシビリティーとは、障害のある人がウェブの情報や機能を利用できるように設計・開発することです。
利用者は、スクリーンリーダー、キーボード、音声入力、画面拡大などを組み合わせます。スクリーンリーダーは画面の文字やHTMLの構造を音声などに変換します。字幕やキーボード操作のように、同じ情報へ複数の方法で到達できる設計が必要です。
国際的な基準はWCAG 2.2
ウェブコンテンツの国際的な基準は、W3Cの「Web Content Accessibility Guidelines」(WCAG)です。最新版は「WCAG 2.2」です。日本語訳も公開されています。WCAGは次の4原則で構成されています。
- 知覚可能:画像の代替テキストや動画の字幕など、情報を別の方法でも受け取れる
- 操作可能:キーボードなど、異なる入力方法でもすべての機能を操作できる
- 理解可能:ページの構造や入力方法、エラーの内容がわかる
- 堅牢:ブラウザーや支援技術が内容と状態を正しく解釈できる
達成基準にはA、AA、AAAの3段階があります。AAに適合するには、AとAAの達成基準をページ全体と一連の操作で満たす必要があります。自動検査の点数だけで適合は決まりません。WCAG 2.2では、次の点も確認します。
- 固定ヘッダーやダイアログが、キーボードフォーカスのある要素を隠していないか
- タップやクリックの対象に、十分な大きさや間隔があるか
達成方法は、W3Cの『How to Meet WCAG 2.2』で確認できます。
日本で参照される規格と法律
現行の日本産業規格はJIS X 8341-3:2016
日本では「JIS X 8341-3:2016」が現行の日本産業規格です。2016年に発行され、2008年のWCAG 2.0を基準にしています。現在は、WCAG 2.2に合わせたJISの改正が検討されています。新しいサイトでは、現行JISとWCAG 2.2のA・AAを基準にします。
「JISに準拠」と表明するには、対象範囲を定めて試験し、結果を公開します。表記方法は、ウェブアクセシビリティ基盤委員会(WAIC)の『対応度表記ガイドライン』で確認できます。
方針と試験結果の公開例
方針の公開状況は、WAICの実態調査をはじめ、複数の調査で確認されています。2022年4月の調査では、すべての都道府県と政令指定都市が方針を公開していました。2026年度の民間調査では、調査対象となった上場企業34社のうち18社(53%)が方針を公開しています。
実際の公開内容は、次のサイトが参考になります。
- 公的機関:東京都港区のウェブアクセシビリティー方針では、公式ホームページ全体を対象に適合レベルAAの維持を掲げ、年度ごとの試験結果と対象外のコンテンツを公開しています。
- 一般企業:Chatworkは、対象範囲と目標レベルに加えて、企画から検証までの対応フローと試験結果を公開しています。
合理的配慮と環境の整備は別の取り組み
2024年4月から、事業者にも合理的配慮の提供が義務付けられました。サイトを事前に改善する「環境の整備」は努力義務です。たとえば、フォームをキーボードで送信できるようにする対応が該当します。
利用者からフォームを操作できないと申し出があった場合は、メールなど別の方法を用意します。利用者の状況に合わせた個別対応が「合理的配慮」です。民間サイト全体へのJISやWCAG適合は、一律の法的義務ではありません。
制作で最初に確認したいこと
企画と要件定義
目標とする基準、対象範囲、担当者、確認時期を要件定義で決めます。問い合わせフォームの送信、入力エラー、メニューを開いた状態なども確認対象です。公開後の問い合わせ先と改善方法も用意します。
コンテンツとデザイン
次の項目をデザインレビューと入稿ルールに含めます。
- ページの内容がわかるタイトルと見出しを順序立てて付ける
- リンク先やボタンの動作が、表示された文言からわかるようにする
- 情報を伝える画像には文脈に合う代替テキストを用意し、装飾画像は読み上げ対象から外す
- 色や位置だけで状態を示さず、文字や形も組み合わせる
- 文字とUIのコントラスト、拡大時のレイアウト、フォーカスの見やすさを確認する
- フォームにはラベルと入力条件を示し、エラーの場所と直し方を具体的に伝える
代替テキストは、画像の掲載目的と周囲の文章から内容を決めます。本文と同じ説明を繰り返さず、装飾画像は読み上げ対象から外すといいでしょう。
HTMLとWAI-ARIA
操作には<button>タグ、ページ遷移にはhref属性をもつ<a>タグを使います。入力欄は<label>タグと関連付けます。クリック処理を付けた<div>タグでは、ボタンの意味やキーボード操作が伝わりません。
WAI-ARIAは、HTMLで表せない役割や状態を支援技術へ伝える仕様です。操作やフォーカス移動は別に実装します。ARIA Authoring Practices Guideを参考に、必要な情報だけを補います。
自動検査と人による確認を組み合わせる
Chrome DevToolsのLighthouseで自動検査できます。[Lighthouse]パネルで[Accessibility]を選び、検査を実行します。代替テキストの欠落やコントラスト不足が結果に表示されます。
Lighthouseでは、代替テキストの内容や操作順、説明のわかりやすさまでは判定できません。続けて、次の項目を手動で確認します。
- Tabキーで操作し、フォーカスの位置と順番を確認する
- 日常的な表示確認として、ブラウザーを75%と150%に変更し、レイアウトの崩れを確認する
- スクリーンリーダーで見出し、フォーム、メニューを確認する
確認方法はW3Cの『Easy Checks』や、デジタル庁の『ウェブアクセシビリティ導入ガイドブック』も参考になります。
アクセシビリティーオーバーレイの問題点
アクセシビリティーオーバーレイは、既存サイトにJavaScriptを追加し、表示や読み上げを自動で変える製品です。文字拡大、配色変更、読み上げなどの操作メニューを追加するものもあります。
アクセシビリティーオーバーレイには、支援技術との干渉や、誤ったラベル・代替テキストの自動生成など、さまざまな問題が指摘されています。積極的な導入はオススメしません。HTML、CSS、JavaScriptの改善を優先しましょう。詳しくは、サイト『オーバーレイ ファクトシート』をご覧ください。
まとめ
WAI-ARIAは、ウェブアクセシビリティーを支える技術の1つです。基本になるのは、目的に合ったHTML要素を選び、CSSで読みやすさを保ち、JavaScriptの操作と状態を支援技術にも伝えることです。ウェブアクセシビリティーを特別な追加機能ではなく、フロントエンド実装の品質として扱いましょう。
ICS MEDIAではウェブアクセシビリティーを重視しており、他にも多くの記事を用意しています。次の記事もぜひご覧ください!
※この記事が公開されたのは9年前ですが、先月8月に内容をメンテナンスしています。


