はじめに
Webサイトを作るとき、見た目の美しさや動きの滑らかさに気を取られて、つい後回しにしてしまうのが「アクセシビリティ」です。しかし、Webを利用する人は決して一様ではありません。視力が低い方、色の区別がつきにくい方、マウス操作が難しく キーボードだけで操作する方、スクリーンリーダーを使って情報を「聴く」方など、さまざまな背景を持つ人たちが同じサイトにアクセスしています。
アクセシビリティ対応とは、こうした多様なユーザーが等しく情報にアクセスし、機能を利用できるようにするための取り組みです。特別な人のための特別な対応、というよりも「誰にとっても使いやすいものを作る」という考え方に近いものです。実際、適切に実装されたアクセシビリティは、スマートフォンを目を凝らさず操作したい人など、障害の有無に関わらず多くの人の使い心地を向上させます。
こうした取り組みの基準となるのが、国内の JIS X 8341-3、国際的な WCAG(Web Content Accessibility Guidelines)というガイドラインです。最近は企業や自治体のサイトでも準拠を求められる場面が増えてきました。
ただ、ガイドラインを一から読み込むのは大変です。この記事では細かいルールの解説は最小限にして、「実際のコーディングでどう書けばいいか」を中心に、コード例とあわせて紹介していきます。
WCAGの4原則(POUR)
WCAGでは、アクセシビリティを「4つの原則」で整理しています。それぞれの英語の頭文字を取って「POUR(プア)」と呼ばれることもあります。この記事で紹介する個々のテクニックも、すべてこの4原則のどこかに紐づいています。
Perceivable(知覚可能)
情報やUIのパーツが、どんな感覚(視覚・聴覚など)を使っていても伝わるようにすること。たとえば画像に代替テキストをつけるのは、画像が見えない人にも内容を伝えるための対応です。
Operable(操作可能)
すべての機能が、マウスだけでなくキーボードなど様々な手段でも操作できること。ボタンにフォーカスが当たるか、Tabキーだけで一通りの操作が完結するか、といった点が関わってきます。
Understandable(理解可能)
情報や操作方法が、誰にとっても分かりやすいこと。エラーメッセージが具体的か、フォームの入力ルールが事前に示されているか、といった点が関わってきます。
Robust(堅牢性)
様々なブラウザや支援技術(スクリーンリーダーなど)で、コンテンツが問題なく解釈されること。正しいHTMLの書き方をすることが、ここに直結します。
では、実際のコードでどう実現するか。一つずつ見ていきます。
アクセシビリティ対応の基本
POURの4原則を実現するための方法は数多くありますが、優先度が高く、コストをかけずに実装できるものから紹介します。
セマンティックHTMLを使う
divタグやspanタグで全てを組むのではなく、意味に応じた要素を使います。
12345<nav>...</nav><main>...</main><button onclick="...">送信</button>1234<div class="nav">...</div><div onclick="...">送信</div>画像にalt属性をつける
1234<img src="chart.png" alt="2025年度の売上推移グラフ、前年比15%増"><img src="decoration.png" alt=""> <!-- 装飾目的なら空にする -->見出しの階層を正しく保つ
h1→h2→h3と論理的な順序にし、見た目のためだけに見出しレベルを飛ばさないようにします。
フォームのlabelとinputを紐付ける
placeholderだけをラベル代わりにするのはNGです。
1234<label for="email">メールアドレス</label><input type="email" id="email" name="email">lang属性を設定する
123<html lang="ja">- ・フォーカスがどこにあるか視覚的に分かるか(フォーカスリングが見えるか)
- ・操作したい要素すべてにTabで到達できるか
- ・モーダルを開いた後、フォーカスがモーダル内に留まるか
- ・想定外の場所にフォーカスが飛ばないか
ボタンやリンクはネイティブのタグを使う
divタグのonclickをやめてbuttonタグやaタグに置き換えるだけで、多くの問題が解消されます
画像にalt属性をつける
装飾画像はalt=””、意味のある画像には内容が伝わるテキストを記述してください
キーボードだけで一度操作してみる
実装後に5分でもキーボード操作を試すだけで、気づける問題は多くあります
実際のサンプルページ
ここまでPOURの4原則、簡単な対応方法を紹介してきましたが、文章だけではまだ少しイメージしづらい部分もあったかもしれません。「知覚可能」「操作可能」といった言葉も、実際に触れてみることで初めて実感を持って理解できることが多いものです。
そこで、この記事で扱うカルーセル・アコーディオン・タブ・モーダル・フォームなどを実装したサンプルページを先にご紹介します。マウスを使わず、Tabキーとキーボードだけで一通り操作してみてください。フォーカスの移動を、ぜひ体感してみてください。
実際に触ってみると、「なぜこう実装するのか」「何を確認すればよいのか」も見えてきます。次の章では、こうした対応が正しく機能しているかを確認するための具体的な方法を紹介していきます。
確認方法
実装したアクセシビリティ対応は、見た目が整っているだけでは「正しく機能している」とは言えません。実際に支援技術や別の操作方法で確認することが欠かせません。
スクリーンリーダーでの確認
代表的なスクリーンリーダーには、Mac標準の VoiceOver、Windows用の無料ツール NVDA があります。
実際に画面を見ずに、読み上げだけでページの内容や操作方法が理解できるかを確認します。見出しジャンプやフォームの読み上げ、ボタンが「ボタン」として認識されているかなど、文章だけでは気づきにくい問題が見えてきます。
自動チェックツール
すべてを目視や音声で確認するのは時間がかかるため、まずは自動チェックツールでひと通り検出するのが効率的です。
axe DevTools: ブラウザの拡張機能。コントラスト不足やalt未設定など、コードレベルの問題を検出
Lighthouse: Chrome DevToolsに標準搭載。アクセシビリティスコアと改善項目を一覧表示
miChecker(エムアイチェッカー): 総務省が公開している国内向けのチェックツール。JIS X 8341-3への準拠状況を確認したい場合に向いており、ページ単位で詳細なチェック結果レポートを出力できる
axe DevTools や Lighthouse は開発中にブラウザ上で手軽に確認するのに向いていますが、miChecker は JIS規格の達成基準に沿った形式でレポートが出るため、納品時のチェックや社内での基準確認に使われることが多いツールです。用途に応じて使い分けるとよいでしょう。
ただし自動ツールが検出できるのは、機械的に判定できる項目(コントラスト比、alt属性の有無など)に限られます。「文脈に合った代替テキストか」「操作の意味が分かりやすいか」のような部分は、人の目と手での確認が必要です。
キーボードのみでの操作確認
マウスを使わず、Tab・Shift+Tab・Enter・Spaceキーだけでページを最後まで操作してみます。
先ほどのサンプルページも、ぜひこのチェックリストを見ながら試してみてください。
この確認だけでも、見た目のチェックでは気づけない問題が多く見つかります。
まとめ
ここまで、WCAGの4原則(POUR)や実際のサンプルページでの体感、スクリーンリーダー・自動チェックツール・キーボード操作による確認方法まで一通り紹介してきました。すべてを一度に完璧にするのは難しいので、まずは次の3つから始めてみてください。
アクセシビリティ対応は、特別な人のためだけの対応ではありません。誰にとっても使いやすいサイトを作るための、基本的な品質の一部として捉えていくのがよいのではないでしょうか。
完璧を目指して身構える必要はなく、「今日のコーディングで一つだけ意識する」くらいの小さな一歩で十分です。その積み重ねが、結果として多くの人にとって使いやすいサイトにつながっていきます。
