現場で使える！Webアクセシビリティ対応の実践チェックリスト

以前もウェブアクセシビリティに関する記事を執筆しました。法改正の背景や「合理的配慮」とはなにか？なぜ対応が必要か？など、詳しくまとめているので、あわせてご覧ください。

この記事ではより実務に即したチェックリスト形式での解説を行います。設計・実装・運用フェーズでの具体的な配慮ポイントにフォーカスしています。

ウェブアクセシビリティの定義を再確認

アクセシビリティとは、障害の有無にかかわらず、すべてのユーザーが利用できる状態を指します。Web業界では「WCAG（Web Content Accessibility Guidelines）」を基準とするのが一般的です。

• 最新基準：WCAG 2.2（2023年12月正式勧告）
• 法的背景：改正障害者差別解消法（2024年4月施行）

ウェブアクセシビリティの4原則

WCAGは大きく以下の4つの原則から構成されています。

• 知覚可能
  • 見える・聞こえる
• 操作可能
  • マウスやキーボード、スマホなどで操作ができる
• 理解可能
  • 簡潔な言葉で分かりやすく説明されている
• 堅牢（けんろう）
  • Webページが長く使い続けられる状態を維持できている

これらの原則を守ることで「すべての人々」がウェブサイトを不自由なく利用できるようになります。

…前置きが長くなりましたが！ここからは上記の4原則をもとに、弊社の基本的なチェックリストをご紹介します。実際のプロジェクトにおいては、より詳細なものを用意して、WCAGの基準に適合するかを対象ページごとに確認します。

現場の制作者向けですので詳細な解説や図解はありませんが、「こういった配慮が必要なんだな」くらいの感じで、デザイナーや開発者以外にも読んでもらえると嬉しいです！

制作・実装現場で使える詳細チェックリスト

情報設計・デザイン

情報設計やデザインの段階で配慮が必要な点も多いです。プロジェクトの比較的早い段階から、適切な設計を行うことが大切です。

• ナビゲーションの設計が適切
  • どのページへも問題なくたどり着ける
  • リンクテキストと遷移先の矛盾がない
• 文書構造が適切
  • h1をはじめとした見出し構造が適切に設計されているか
  • ディスクリプションの設定に問題がないか
• カラーコントラストが適切
  • テキストと背景のコントラスト比が4.5:1以上あるか
  • UI要素とその背景のコントラスト比が3:1以上あるか
• 情報の伝達を色に依存しない
  • 色の情報でしか判断できないデザインは避ける
• 文字の読みやすさに配慮されている
  • 文字サイズが十分な可読性を持っているか
  • 行間の設定、1行あたりの文字数を適切に設定しているか
• リンクテキストが文脈なしでも意味を持っている
  • 「詳しくはこちら」などでは不十分。「○○について詳しく」など明示する
  • URLのみのリンクなどは避ける
• アイコンを適切に使用する
  • 一般的に使用される、わかりやすい形状のアイコンを使う
  • アイコンのみのボタンはラベルを付けられるか検討する
  • ラベルが付けられない場合、aria-label="検索"など適切な読み上げ用のラベルを提供する

HTML

アクセシビリティ対応において重要な部分を担うのがHTMLのマークアップです。デザイン（設計）された情報を適切な文書構造として整理する必要があります。

• 画像にalt属性を正しく設定している
  • 情報を持つ画像には必須
  • 情報を持たない装飾画像にはalt=""を設定
• 見出し要素（h1〜h6）が適切に設定されている
  • h1要素は必須
  • h1要素は1ページに1つが推奨
  • h1要素の次にh3要素など、見出しの順番をスキップしない
• リスト要素（ul）を適切に使用する
  • 連続した内容のリストは、同じ<ul>…</ul>内に記載する
    • レイアウト上で左右（あるいは上下）に分かれていても、連続した内容はひとつのul要素内にまとめる
  • Gridレイアウトで連続する内容の場合、それがリストとして適切かは慎重に判断する
    • むやみにul要素を濫用しない
• リンクはa要素、ボタンはbutton要素を使用する
  • URLが変更されるリンクはa要素
  • フォームの送信ボタンや、ポップアップなどを開く汎用的なボタンはbutton要素
• フォームのラベルが適切に設定されている
  • label要素が各input要素に関連付けられている
  • プレースホルダーはラベルとして使用しない
• ラジオボタンやチェックボックスを適切にグループ化している
  • fieldset要素やlegend要素を使用して、スクリーンリーダーによる読み上げにも対応する

CSS

主に視覚的な補助やビジュアル表現のために使用するCSSですが、下記のようにスクリーンリーダーでの読み上げやキーボード操作など、「知覚・操作」が困難にならないような配慮が必要です。

• display: none;やvisibility: hidden;を読み上げが必要な要素に指定しない
  • スクリーンリーダーで読み上げられない問題がある
  • 視覚的に非表示でもスクリーンリーダーで読み上げたい要素には、visually-hiddenクラスなどの利用を検討する
• フォーカスリング（フォーカスインジケーター）が可視化されている
  • フォーカスリングが表示されないとキーボード操作が困難になる
  • reset系のCSSで無効化しないようにする
• アニメーションの無効化を設定している
  • 動きに敏感なユーザーの不快感を軽減する
  • ユーザー設定（prefers-reduced-motion）に対応している

JavaScript

Webサイトにおいて、ユーザーが操作することで画面が変化するようなUIは一般的です。その際に画面の変化の状態を伝えるように適切に実装を行う必要があります。

• ユーザーの操作によって状態が変化するUIでWAI-ARIAが適切に設定されている
  • 開閉メニューのaria-expandedやaria-controlsなど
  • 対象となる主な要素
    • ハンバーガーメニュー
    • アコーディオン
    • モーダルダイアログ（ポップアップ）
    • カルーセル（スライダー）
    • タブ
• アンカーリンクの実装が適切に設定されている
  • スクロール移動したあと、URLからハッシュ値（#section1など）を消さない
  • キーボード操作でフォーカスの位置が移動している
• URLのパラメーター変更によってタイトルが適切に変更される
  • ?category=newsや?category=eventのようにURLが変更されると、titleをそれぞれ独自のものに変更する必要がある

その他チェック項目

その他にも、考慮する点は多くあります。以下のようにあらゆる状況でユーザーが問題なくウェブサイトを閲覧できるかを確認してください。

• キーボード操作で全コンテンツにアクセスが可能
  • TabキーやEnter/Spaceキーを使って動作を確認する
• テキストを拡大（200%）してもレイアウトが崩れない
  • 画面サイズやデバイスの種類に応じてレイアウトを変えたり、em単位の設計が重要
• 自動再生コンテンツが停止可能
  • 再生・停止のコントロールがないとユーザーにストレスを与える
• スクリーンリーダーでの読み上げ順序が自然である
  • 見た目とDOMの順番が異なると混乱の原因になる

以上が、基本的におさえておきたいチェック項目になります。冒頭でもご紹介しましたが、「ウェブアクセシビリティの4原則」を意識しながら、プロジェクトの進行中にもその観点をもって意識的に作業すると良いかもしれません。

アクセシビリティのチェックに使えるツールをご紹介

最終的には人間による目視や操作によるチェックが欠かせませんが、より効率的に作業を行うためにも、自動チェックツールを活用しましょう。デザイン・コーディングなどの工程で、ツールによるチェックで早めに問題が分かれば、すぐに対応できます。

ツール名	用途
axe DevTools	ブラウザ上でWCAG違反箇所を自動検出
Lighthouse	Chrome開発者ツールに搭載、アクセシビリティスコア可視化
WAVE	ページ単位で色覚・構造チェックが可能
Contrast Checker	コントラスト比のチェックが可能

まとめ：運用まで見据えたアクセシビリティ対応を

ウェブアクセシビリティは、デザイン制作やHTMLの実装だけでは完結しません。CMSによるコンテンツの更新や、新しいUI追加のたびに「継続的にチェックできる仕組み」が必要です。

2025年以降は、ウェブアクセシビリティ対応の有無が企業イメージやコンプライアンス評価にも直結します。現場のチェックリストとして、この記事をぜひご活用ください。

参考文献・出典

• WCAG 2.2（W3C公式）
• WebAIM: WCAG Checklist
• Deque University: Web Accessibility Checklist (2023)
• 改正障害者差別解消法（内閣府）