資料をダウンロード

お問い合わせ

無料トライアルから始める

パートナー制度

【Web制作会社必見！】ウェブアクセシビリティ対応方法まとめ｜制作会社が押さえるべき15のチェック項目と合意形成の考え方

schedule

2026/9/1

person

この記事を書いた人：コニカミノルタジャパン株式会社ウェブアクセシビリティサポートチーム

近年、Web制作の現場においてクライアントからウェブアクセシビリティの対応を求められるケースが増加しています。

しかし、ディレクターやコーダーの方々の中には、

「具体的にどのようなウェブアクセシビリティの対応方法をとればよいのか」

「アクセシビリティのチェック方法はどのように進めればよいのか」

と、作業内容や基準の把握に悩まれている方も少なくありません。

本記事では、Web制作会社が実務で押さえるべき15のチェック項目や、無料で活用できるLighthouseやaxe DevToolsの使い方、そしてクライアントとの合意形成の考え方について客観的に解説します。

コニカミノルタジャパンでは、あらゆるウェブアクセシビリティ対応の案件をサポートしており、これまでWeb制作会社様へのご支援実績も多数ございます。

「自社のリソースだけでは対応が難しい」

「専門的な知見が必要」

とお悩みの場合は、ぜひお気軽にご相談ください。

ウェブアクセシビリティ対応に関するお問い合わせはこちら

クライアントが求める「アクセシビリティ対応」の正体 — WCAGとJIS X 8341-3の関係
実務ですぐに着手しやすい15のチェック項目
画像の代替テキスト(alt属性)の書き方
色のコントラスト比の基準と確認方法
キーボードだけで操作できるか
見出し構造とランドマークの正しいマークアップ
フォームのラベルとエラー表示
動画・アニメーション・自動再生コンテンツの扱い
無料で使える2つのチェックツールと使い方
Lighthouse — 導入方法とアクセシビリティスコアの見方
axe DevTools — 導入方法と検出結果の読み方
自動チェックツールの限界 — 人の目による確認が必要な理由
「どこまでやれば対応完了か」— クライアントとの合意形成の考え方
チェック作業を制作ワークフローに組み込む方法
よくある質問(Q&A形式で4問)
【コニカミノルタ独自開発のウェブアクセシビリティ対応ツールのご案内】

クライアントが求める「アクセシビリティ対応」の正体 — WCAGとJIS X 8341-3の関係

ウェブアクセシビリティの対応方法を理解するためには、まず基準となるガイドラインと規格の関係性を知ることが重要です。

世界的なウェブアクセシビリティのガイドラインとして、W3C（ウェブ技術の標準化団体）が勧告している「WCAG（Web Content Accessibility Guidelines）」があります。WCAGには「2.0」「2.1」などのバージョンがあり、最新版として「WCAG 2.2」が公開されています。

一方、日本国内における情報アクセシビリティの国家規格が「JIS X 8341-3:2016」です。
このJIS規格は、国際規格（ISO/IEC 40500:2012）であるWCAG 2.0の内容と一致しています。

つまり、日本の公的機関や企業が求める「JIS規格への対応」とは、実質的に「WCAG 2.0の達成基準を満たすこと」を指します。
これらの規格には「レベルA」「レベルAA」「レベルAAA」の3段階の適合レベルが定められています。

総務省の「みんなの公共サイト運用ガイドライン」では、国や地方公共団体などの公的機関に対し、JIS X 8341-3:2016の適合レベルAAに準拠することが求められています。

実務ですぐに着手しやすい15のチェック項目

ウェブサイトの設計や実装において、WCAGおよびJIS X 8341-3:2016の達成基準を満たすための具体的なチェック項目を整理します。実務で比較的着手しやすい6つのテーマから、15のチェック項目を紹介します。

画像の代替テキスト(alt属性)の書き方

1. 意味を持つ画像への代替テキスト付与

写真やグラフ、イラストなど、情報を示す画像には、画像が伝えている情報や役割を表す代替テキストを alt 属性として記述します。画像がリンクとして機能する場合は、リンク先を示す内容を代替テキストに設定します。
（例）<img src="chart.jpg" alt="2025年度の売上は前年比120%増加を示すグラフ">

2. 装飾画像の代替テキストの処理

意味を持たない装飾目的の画像の場合、スクリーンリーダー（音声読み上げソフト）に無視させるために、代替テキストは空（alt=""）に設定します。

3. 文字画像の回避

情報を伝えるために、文字を含んだ画像（文字画像）を使用することは可能な限り避け、技術的に実現可能な場合はテキストで表現することが求められます。テキストであれば、利用者の環境に合わせてサイズや色を変更しやすいためです。

色のコントラスト比の基準と確認方法

4. テキストのコントラスト比の確保

文字を読みやすくするため、文字色と背景色の間には十分なコントラスト比が必要です。WCAGのレベルAAでは、太字でない18ポイント（24px）未満のテキストは「4.5:1以上」、大きなテキスト（太字の14ポイント以上、または18ポイント以上）は「3:1以上」のコントラスト比を確保することが基準とされています。

5. 色だけに頼らない情報伝達

「赤字の箇所は入力必須です」といったように、色の違いだけで情報を伝えてはいけません。色の違いだけでは情報を判別しづらい場合でも情報を正しく理解できるよう、「必須」というテキストラベルを併記するなど、色以外の視覚的な手がかりを提供します。

キーボードだけで操作できるか

6. キーボード操作の確保

マウスを使わずに、Tabキーなどのキーボード操作だけで、リンクやボタンといったすべての機能にアクセスし、操作できるように実装します。

7. フォーカスの可視化

キーボードで操作している際、現在どの要素が選択されているか（フォーカスされているか）が視覚的にわかるように、フォーカスインジケーター（枠線など）を表示させる必要があります。

8. キーボードトラップの防止

キーボードで操作している際に、特定のコンテンツ（モーダルダイアログなど）からフォーカスが抜け出せなくなる「キーボードトラップ」が発生しないように設計します。

見出し構造とランドマークの正しいマークアップ

9. 適切な見出しレベルの使用

見た目の文字を大きくするためや強調するために見出し要素を用いるのではなく、文書の論理的な構造を示すために <h1> から <h6> までの見出しタグを適切な順序で使用します。見出しを空要素にすることも避けてください。

10. セマンティックなマークアップ

リストには <ul> や <ol>、ナビゲーションには <nav> といった適切なHTML要素を用いて、プログラムによる解釈が可能なセマンティックな構造を提供します。これにより、スクリーンリーダー利用者がページのアウトラインを把握しやすくなります。

フォームのラベルとエラー表示

11. コントロールとラベルの関連付け

入力フォームにおいて、どの入力欄が何を示すのかを明確にするため、<label> 要素を用いてテキストとフォームコントロール（テキストボックスやラジオボタンなど）を関連付けます。

12. エラー箇所の明示

入力エラーが発生した際には、色が変化するだけでなく、エラーが起きた箇所をテキストで明示して適切な説明を提供します。

13. エラー修正の提案

入力形式（半角・全角など）や文字数の制限がある場合は、利用者が入力する前に説明するか、エラー時に具体的な修正方法（例：「半角数字で入力してください」など）を提示します。

動画・アニメーション・自動再生コンテンツの扱い

14. 動きの停止・一時停止

自動的に動く、点滅する、またはスクロールするコンテンツ（カルーセルなど）が3秒より長く続く場合は、利用者が任意で「一時停止、停止、または非表示」にできる機能を提供します。

15. 音声・映像の代替コンテンツの提供

会話の内容や重要な効果音などが伝わるように、映像コンテンツにはキャプション（字幕）や音声解説などの代替情報を提供します。また、自動再生される音声は利用者が停止できるようにします。

無料で使える2つのチェックツールと使い方

ウェブアクセシビリティの対応状況を確認するために、制作現場で広く利用されている2つの無料ツール（Lighthouseとaxe DevTools）の導入方法と使い方を解説します。

Lighthouse — 導入方法とアクセシビリティスコアの見方

Lighthouseの導入方法

Lighthouseは、Google Chromeブラウザのデベロッパーツールに標準で搭載されているオープンソースの自動化ツールです。特別なインストール作業は不要で、Chromeでチェックしたいページを開き、デベロッパーツールを起動します（Windows：Ctrl + Shift + I / macOS：Command + Option + I、または右クリックして「検証」を選択）。デベロッパーツールの「Lighthouse」のタブを選択することで利用できます。

アクセシビリティスコアの見方

Lighthouseを実行すると、パフォーマンスやSEOといった項目とともに「ユーザー補助（アクセシビリティ）」のスコアが0から100の数値（下記画像）で算出されます。

この監査では、コントラスト比の不足、alt 属性の抜け漏れ、フォームのラベル欠落など、機械的に検出可能な問題がリストアップされます。開発初期や日々の更新時のスピーディーな一次チェックとして活用できます。

axe DevTools — 導入方法と検出結果の読み方

axe DevToolsの導入方法

axe DevToolsは、Deque Systems社が開発したアクセシビリティチェックエンジン（axe-core）を利用したブラウザ拡張機能です。Chromeウェブストアなどから拡張機能をブラウザに追加し、デベロッパーツールから「axe DevTools」のタブを開くことでチェックを実行できます。

検出結果の読み方

スキャンを実行すると、ページ内のアクセシビリティの問題が検出され、その詳細や対象となるHTMLソースコード、そしてWCAGのどの達成基準に関連するかが表示されます。具体的な修正のヒントも提示されるため、コーダーがソースコードを修正する際の実務的なガイドとして機能します。

自動チェックツールの限界 — 人の目による確認が必要な理由

Lighthouseやaxe DevToolsといった自動チェックツールは、HTMLの構文エラーや属性の抜け漏れを素早く発見するのに非常に有用です。しかし、デジタル庁の「ウェブアクセシビリティ導入ガイドブック」でも言及されている通り、チェックツールで見つけられる問題は、ウェブアクセシビリティの問題の2割から3割程度とされています。

たとえば、「画像に alt 属性が存在するか」はツールで判定できますが、「その alt 属性のテキストが、前後の文脈に沿って画像の意味を正確に説明しているか」は、人が目視で判断する必要があります。また、キーボードのみで操作が可能か、スクリーンリーダーでの読み上げ順序が自然かといった項目も、実際に人が操作して確認しなければなりません。ツールで高得点が出たからといって「これだけやれば完璧」ではなく、人の目と手による確認と組み合わせることが不可欠です。

【無料簡易診断のご案内】

自動チェックツールの限界を補うための第一歩として、
「Webアクセシビリティ簡易診断セルフチェックシート（Excel）」を無料で配布しております。

Lighthouseのスコアに加え、担当者ご自身で目視確認できる10項目の手動チェック結果を組み合わせることで、自社サイトの総合的なアクセシビリティ得点を算出できます。
この記事で紹介したLighthouseでのチェック結果との併用に適しています。

「Webアクセシビリティ簡易診断セルフチェックシート」の無料ダウンロード

「どこまでやれば対応完了か」— クライアントとの合意形成の考え方

クライアントからアクセシビリティ対応を求められた際、「すべてのページを完全にAA準拠にする」ことを最初から目指そうとすると、膨大な工数と費用がかかりプロジェクトが頓挫してしまう恐れがあります。

ウェブアクセシビリティ基盤委員会（WAIC）の「対応度表記ガイドライン」では、JIS X 8341-3:2016への対応度を示す表記として「準拠」「一部準拠」「配慮」の3つが定義されています。

すべての達成基準を満たす「準拠」を目指すことが理想ですが、段階的に改善を進める場合は、対象範囲や試験結果、今後の改善方針などを公表しながら、その時点での対応状況を「一部準拠」として表記することができます。また、対象範囲についても、「今回はトップページと主要な手続きページのみを対象とする」といったようにページを絞ることも可能です。

制作に入る前に、クライアントに対して「今回はどの範囲のページを対象とし、どの適合レベル（一部準拠を含む）をゴールとするか」を明確に提示し、合意形成を図ることがトラブルを防ぐポイントとなります。

チェック作業を制作ワークフローに組み込む方法

アクセシビリティのチェックを納品直前のテスト工程だけで行おうとすると、手戻りのリスクが高まります。コントラスト比の不足や不適切なHTML構造が発覚した場合、デザインやマークアップを根本からやり直す必要が生じるためです。

手戻りを防ぐためには、以下のように制作フェーズごとに段階的な確認をワークフローに組み込むことが推奨されます。

要件定義・企画フェーズ： 対象とする範囲と目標とする適合レベル（AAなど）を決定し、ウェブアクセシビリティ方針を定めます。
デザインフェーズ： カラーコントラスト比の確認や、文字サイズが小さすぎないかの確認を行います。
実装・コーディングフェーズ： セマンティックなHTMLマークアップ、画像の代替テキストの適切な付与、キーボードフォーカスの制御などを行い、Lighthouseやaxe DevToolsで一次チェックを実施します。
テストフェーズ： 実際のブラウザ上でキーボード操作のみで一連のタスクが完了できるか、スクリーンリーダーでの読み上げが適切かを手動でテストし、必要に応じてJIS規格に基づく試験を実施します。