ウェブ制作に関わる人に役立つ
ウェブアクセシビリティーの基本

はてなブックマークへ投稿
66
Xへポスト
117
URLをコピー
共有

ウェブサイトには、利用者が情報や機能へアクセスするのを妨げる実装があります。「マウスを使わないとメニューを開けない」「拡大すると文字が重なる」「フォームのエラー箇所がわからない」といった例です。けがでマウスを扱いづらい人や、音を出せない場所で動画を見る人も同じ問題に直面します。

ウェブアクセシビリティーは、ウェブサイト制作やフロントエンド開発で欠かせないテーマです。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では、代替テキストの内容や操作順、説明のわかりやすさまでは判定できません。続けて、次の項目を手動で確認します。

  1. Tabキーで操作し、フォーカスの位置と順番を確認する
  2. 日常的な表示確認として、ブラウザーを75%と150%に変更し、レイアウトの崩れを確認する
  3. スクリーンリーダーで見出し、フォーム、メニューを確認する

確認方法はW3Cの『Easy Checks』や、デジタル庁の『ウェブアクセシビリティ導入ガイドブック』も参考になります。

アクセシビリティーオーバーレイの問題点

アクセシビリティーオーバーレイは、既存サイトにJavaScriptを追加し、表示や読み上げを自動で変える製品です。文字拡大、配色変更、読み上げなどの操作メニューを追加するものもあります。

アクセシビリティーオーバーレイには、支援技術との干渉や、誤ったラベル・代替テキストの自動生成など、さまざまな問題が指摘されています。積極的な導入はオススメしません。HTML、CSS、JavaScriptの改善を優先しましょう。詳しくは、サイト『オーバーレイ ファクトシート』をご覧ください。

まとめ

WAI-ARIAは、ウェブアクセシビリティーを支える技術の1つです。基本になるのは、目的に合ったHTML要素を選び、CSSで読みやすさを保ち、JavaScriptの操作と状態を支援技術にも伝えることです。ウェブアクセシビリティーを特別な追加機能ではなく、フロントエンド実装の品質として扱いましょう。

ICS MEDIAではウェブアクセシビリティーを重視しており、他にも多くの記事を用意しています。次の記事もぜひご覧ください!

※この記事が公開されたのは9年前ですが、先月8月に内容をメンテナンスしています。

Google検索でICS MEDIAの記事を見つけやすくしよう

優先するソースに追加すると、GoogleのトップニュースやAI検索でICS MEDIAの記事が表示されやすくなります。

Googleで優先するソースとして追加
SNSでシェアしよう
シェアいただくと、サイト運営の励みになります!
はてなブックマークへ投稿
Xへポスト
URLをコピー
共有
新着記事のお知らせuseStateとuseEffectだけじゃもったいない! ユーザー体験を改善するReactの便利機能