株式会社エムアールピーWebアクセシビリティ解説サイト

Webアクセシビリティを、実例で理解する

この資料は、Webアクセシビリティが「どんなものか」「どうして必要か」「具体的に何をすることか」を、実際に動く例を触りながら理解するためのものです。

アクセシビリティとは

年齢や障害、使っている道具や置かれた状況にかかわらず、同じ情報にたどり着き、同じ操作ができること。

「障害のある人への配慮」と説明されることが多いのですが、それだけではありません。 同じ困りごとが、恒久的に不自由な方だけでなく、けがや病気で一時的に不自由な方、 その場の状況で不自由になる方にも起こります。 どなたが何に困るのかを、下の表にまとめました。

一時的に不自由になる方もいます

同じ困りごとでも、理由はさまざまです
Webで困ること恒久的一時的状況的
画像や色だけの情報が伝わらない目が見えない白内障の手術後屋外で画面が反射している
動画や音声の内容が分からない耳が聞こえない中耳炎で聞こえにくい音を出せない場所にいる
音声入力が使えない発話に障害があるのどを痛めている騒がしい場所にいる
マウスの細かい操作ができない手や腕に障害がある腕を骨折している片手で子どもを抱いている

いちばん下の行をご覧ください。「マウスの細かい操作ができない」という同じ困りごとが、 手や腕に障害のある方にも、腕を骨折した方にも、片手で子どもを抱いている方にも起こります。 障害の有無で線を引ける話ではなく、どなたにも起こりうることです。 アクセシビリティは、その全員を取りこぼさないための設計です。

なぜ、取り組んだほうがよいのか

取り組む理由は、企業によってさまざまです。ご相談をいただく場面では、次の4つが挙がることが多くあります。

01 / 法対応

法制度の変化

2024.04 日本|改正障害者差別解消法 民間事業者にも、合理的配慮の提供が法的に義務づけられました。
2025.06 EU|欧州アクセシビリティ法 対象事業者への適用が始まりました。越境ECも対象になり得ます。
継続中 米国|ADA ウェブサイトを対象とした訴訟が、継続的に提起されています。

2024年4月に改正障害者差別解消法が施行され、これまで努力義務だった 民間事業者の「合理的配慮の提供」が法的義務になりました。 障害のある方から何らかの対応を求められたとき、過重な負担にならない範囲で 応じる必要があります。 ただし、Webアクセシビリティ対応そのものが義務づけられたわけではありません。 関係するのは「ウェブでしか申し込めない」「ウェブにしか情報がない」状態です。 配慮を求められたときに、応えられない状態になりやすい、という関係にあります。

02 / 機会損失

気づきにくい機会損失

アクセスログに、理由は一行も書かれていない
サイトを訪れた方に起きたこと アクセス解析に残る記録
文字が薄くて読めなかった直帰
申込ボタンがキーボードで押せなかったカート離脱
エラーの理由が分からなかったフォーム途中離脱
動画の内容が分からなかった再生完了率が低い

ご不便を感じた方が、お問い合わせをくださるとは限りません。多くの場合、何も伝えずに離れていきます。 そのため、アクセスログを見ても、原因までは分かりません。 数字には「直帰」「離脱」として残るだけで、その理由は見えないままです。 その結果、申し込みや問い合わせに至っていたはずの方を、 理由の分からないまま取りこぼし続けることになります。 原因が数字に表れないため改善の対象にも上がらず、 この損失は気づかれないまま積み上がっていきます。

03 / SEO・AI検索

SEO対策との共通点

同じ作業が、利用者にも検索エンジンにも効く
やること 人(支援技術)に効くこと 検索エンジン・生成AIに効くこと
見出しを h2・h3 で組む 見出しだけ拾って読み飛ばせる ページの構造を理解できる
画像に代替テキストを書く 画像が何かを音声で受け取れる 画像の内容を索引できる
ページタイトルを固有にする 開いた瞬間、どこにいるか分かる 検索結果に出る見出しになる
リンクを具体的な文言にする リンク一覧だけで行き先が分かる リンク先の内容を推測できる

アクセシビリティ対応は、そのままSEO対策になります。 見出しを正しい順序で組む、画像に代替テキストを付ける、リンクの文言を具体的にする。 いずれも、支援技術がページの内容を読み取るための作業であると同時に、 検索エンジンがページの構造と意味を理解するための作業でもあります。 機械にページを正しく伝えるという点で、目的が一致しているためです。 生成AIに引用されやすくページを整えることを GEO(生成エンジン最適化)と呼びますが、 やることはSEOとほぼ同じです。 ただし、キーボード操作やフォーカス表示は検索順位には効きません。重なるのは上の表の範囲です。 それでも、SEO施策として通した予算が、そのままアクセシビリティ対応の前進になります。 逆に、アクセシビリティ対応として実施した内容が、検索流入の改善として数字に表れることもあります。 どちらか一方のために使った費用が、二重に効く領域です。

04 / 企業価値

企業価値への影響

掲げた言葉は、同じサイトの上で確かめられる
サイトに書いてあること 同じサイトで起きていること
「誰ひとり取り残さないサービスを」 申込フォームが、キーボードだけでは送信できない
「多様な人材が活躍できる会社です」 採用ページの動画に、字幕がついていない
「わかりやすい情報発信を心がけます」 重要なお知らせが、薄いグレーの文字で読めない

掲げた言葉と実際のサイトが食い違っていると、それは同じページの上で確かめられてしまいます。 応募者も、取引先も、ESGの評価機関も、見るのは同じサイトです。 理念が実装まで届いていないことは、企業姿勢そのものへの疑問につながり、 ブランドや企業価値を損なう要因になります。 反対に、言葉どおりに実装されていれば、統合報告書や採用広報で語る内容を、 自社サイトそのもので裏づけられます。 アクセシビリティは、掲げた価値観を第三者が検証できる数少ない領域です。 対応していること自体が、企業価値を支える材料になります。

何を満たせばよいのか

アクセシビリティの基準にはいくつかの体系があります。国際的なガイドラインが WCAG、日本国内の規格が JIS X 8341-3、行政の手引きとして デジタル庁のガイドブックがあります。 ただし JIS X 8341-3 は、WCAG の内容をそのまま国内規格にしたものです (2016年版は WCAG 2.0 と同一。現在、WCAG 2.2 に合わせた改正が進められています)。 デジタル庁のガイドブックも WCAG を土台にしています。 まずは WCAG に沿えば、いずれの要求にも重なります。

WCAG には A・AA・AAA の3段階があります。目標に据えるのは AA です。 A だけでは実務上の使いやすさに届かず、AAA はすべてのページで満たすことを 前提とした水準ではないためです。WCAG 自身も、サイト全体で AAA を満たすことを 方針として求めるのは推奨できないと述べています。 法令や公共調達で参照されるのも AA の水準です。 まず AA を満たし、無理なく達成できるものだけ AAA を加えるのが現実的な進め方です。

4つの原則

WCAG(Web Content Accessibility Guidelines)は、 頭文字をとって POUR と呼ばれる4つの原則で組み立てられています。細かい基準は多数ありますが、根っこはこの4つです。

Perceivable

情報を、目で見る以外の方法でも受け取れます。画像に代替テキストがあり、動画に字幕があり、文字が背景から十分に浮き上がっています。

→ 対比デモで見る
Operable

マウスが使えなくても操作できます。キーボードだけで全機能に到達でき、いま自分がどこにいるかが見え、勝手に動くものは止められます。

→ 対比デモで見る
Understandable

何が起きているか分かります。エラーの理由と直し方が示され、必須項目が色以外でも伝わり、同じ操作は同じ場所にあります。

→ 対比デモで見る
Robust

さまざまな環境で正しく動きます。スクリーンリーダー、音声入力、拡大表示、古い端末。特定のブラウザや操作方法を前提にしません。

→ 対比デモで見る

まず押さえたい4項目

デジタル庁のガイドブックでは、この4つを「非干渉」と呼んでいます。 満たしていないと、そのページの他の部分にすらたどり着けなくなるためです。 まずはここから対応いただくことをおすすめします。

01

音声を自動で再生しない

3秒を超えて自動再生する音声には、止める手段が必要です。 読み上げソフトの音声と重なると、利用者はどちらも聞き取れなくなります

WCAG 1.4.2 音声の制御

02

操作の行き止まりを作らない

キーボード操作で、一度入ったら抜け出せない場所を作らないこと。 モーダルダイアログでいちばん起きやすい問題です。

→ このページのデモで確かめる

WCAG 2.1.2 キーボードトラップなし

03

激しい点滅を避ける

1秒に3回を超える点滅は、光感受性発作を誘発する危険があります。 アニメーション、動画、広告バナーが対象です。

WCAG 2.3.1 / 2.3.2 閃光

04

自動で切り替わるものを止められるようにする

カルーセル、スライドショー、自動更新。動き続けるものが画面にあると、 他の場所の操作や閲覧そのものが妨げられます。

→ このページのデモで確かめる

WCAG 2.2.2 一時停止、停止、非表示

対比デモ|見え方と読み上げ

どのサイトにも必ず出てくる8項目です。ひとつずつ「悪い例」と「良い例」を切り替えて、何が変わるかをご確認ください。

画像の代替テキスト

WCAG 1.1.1

画像が見えない方に、その画像が何を伝えているかを文字で渡す仕組みです。切り替えても絵は変わりません。変わるのは、下の「スクリーンリーダーの読み上げ」です。

alt 属性がありません。ファイル名 graph_2024_fix2.png がそのまま読まれます。

スクリーンリーダーの読み上げ

コードを見る
<img src="graph_2024_fix2.png">
← alt がない。ファイル名が読み上げられる

見出しの構造

WCAG 1.3.1

見た目が大きい文字と、見出しとして意味づけられた文字は、まったく別のものです。

サービスの特長

当社のサービスには3つの特長があります。

1. 導入がはやい

最短2週間で運用を開始できます。

読み上げソフトが拾える見出し一覧:
見出しが見つかりません
スクリーンリーダーの読み上げ

コードを見る
<div style="font-size:24px;font-weight:bold">
  サービスの特長
</div>
← 見た目は見出し。機械には「単なる文字」

色だけで情報を伝えない

WCAG 1.4.1

赤と緑の区別がつきにくい方は珍しくありません。下の「見え方」を切り替えて、同じ画面がどう見えるかをご確認ください。

見え方
東日本西日本海外1期2期3期4期

凡例を色の四角だけで示しています。「見え方」で「1型(P型)」「2型(D型)」を選ぶと、どの線がどの地域か分からなくなります。

スクリーンリーダーの読み上げ

コードを見る
<!-- 凡例を色の四角だけで示す -->
<span class="legend" style="background:#1a7f37"></span> 東日本
<polyline stroke="#1a7f37" />

文字と背景のコントラスト

WCAG 1.4.3

「おしゃれに見えるから」と薄くしたグレーは、多くの方にとって読めない文字になります。

ご利用にあたっての注意事項

お申し込み後のキャンセルは、開始日の7日前まで承ります。それ以降のキャンセルには所定の手数料がかかります。

※ 表示価格はすべて税込です。

つまみを動かすと、上の注意事項の濃さが変わります。

薄い濃い
2.6:1
大きい文字なら 3:1 本文なら 4.5:1 さらに上なら 7:1

つまみで変わるのは濃さだけで、文字の大きさは変わりません。 上の3つは、WCAG が定める基準値です。「大きい文字」とは 24px 以上、 または 18.66px 以上の太字を指します。

初期値は、実際のサイトでよく見かける「薄いグレーの文字」です。

自社の色で試す
コードを見る
.note { color: #b9c0bc; }  /* 1.9:1 */

キーボードでの操作

WCAG 2.1.1

見た目がボタンでも、div にクリックを付けただけのものはキーボードで押せません。

Tab キーで移動をお試しください。この「申し込む」には止まりません。

申し込む
スクリーンリーダーの読み上げ

コードを見る
<div class="btn" onclick="submit()">申し込む</div>
← Tab で止まらない/Enter で押せない/
   読み上げでボタンだと分からない

ページのタイトル

WCAG 2.4.2

タブを何枚も開いた状態、履歴、ブックマーク、検索結果。タイトルは想像以上に多くの場所で使われます。

株式会社◯◯|総合サイト 株式会社◯◯|総合サイト 株式会社◯◯|総合サイト

全ページ同じタイトル。どれが料金ページで、どれが問い合わせフォームか分かりません。

スクリーンリーダーの読み上げ(ページを開いた瞬間)

コードを見る
<title>株式会社◯◯|総合サイト</title>
← 全ページ共通のテンプレートのまま

フォーカスが見えるか

WCAG 2.4.7

キーボード操作中に「いま自分がどこにいるか」が見えないと、操作そのものが成立しません。

Tab キーで3つのボタンを順に移動してみてください。いまどこにいるか分かるでしょうか。

コードを見る
button:focus { outline: none; }
← 代わりを用意していない

対比デモ|フォーム

問い合わせ、資料請求、購入手続き。フォームは「売上に直結するのに、もっとも不具合が起きやすい」場所です。

入力欄のラベル

WCAG 1.3.1 / 3.3.2

プレースホルダーはラベルの代わりになりません。入力を始めた瞬間に消えるからです。

何か入力すると、その欄が何の欄だったか分からなくなります。実際にお試しください。

スクリーンリーダーの読み上げ

コードを見る
<input type="text" placeholder="お名前">
← 入力すると消える。ラベルの代わりにならない

必須項目の伝え方

WCAG 1.4.1 / 3.3.2

赤いアスタリスクだけ。これが必須を意味することは、実はどこにも書かれていません。

メールアドレス*
電話番号

アスタリスクの意味を説明する凡例がなく、色でしか目立たせていません。

スクリーンリーダーの読み上げ

コードを見る
<label>メールアドレス<span class="req">*</span></label>

入力の手間を減らす

WCAG 1.3.5

autocomplete 属性を付けるだけで、ブラウザや端末が保存済みの情報を提案できるようになります。

type は text のまま、autocomplete は off。スマホでも数字キーボードが出ません。

コードを見る
<input type="text" autocomplete="off">

同じ内容を二度入力させない

WCAG 3.3.7

WCAG 2.2 で新しく加わった基準です。一度入力した情報を、もう一度入力させないこと。

配送先住所:千葉県船橋市西船◯-◯-◯

貼り付けを禁止しているフォームだと、さらに負担が増えます。

コードを見る
<label>メールアドレス</label><input>
<label>メールアドレス(確認用)</label><input onpaste="return false">

エラーの伝え方

WCAG 3.3.1 / 3.3.3

送信ボタンをお試しください。エラーが出たとき、次に何をすればよいか分かるでしょうか。

メールアドレス

エラーは赤字だけ。読み上げソフトには何も伝わらず、どこが悪いかも書いていません。

スクリーンリーダーの読み上げ(送信直後)

コードを見る
<p class="error">入力内容に誤りがあります</p>
← 読み上げに通知されない/原因が書いていない

対比デモ|動きのあるUI

「凝ったUIはアクセシビリティと両立しない」と言われることがありますが、実際には作り方の問題です。 同じ見た目のまま、操作できるようにできます。

アコーディオン(開閉パネル)

WCAG 4.1.2

「いま開いているのか閉じているのか」を、見た目以外でも伝えられているか。

導入までどのくらいかかりますか?
途中で解約できますか?

Tab キーでは、この見出しに一度も止まりません。

スクリーンリーダーの読み上げ

コードを見る
<div class="acc-head" onclick="toggle()">質問</div>

タブ切り替え

WCAG 2.1.1 / 4.1.2

タブに入ったら、左右の矢印キーで移動できるのが標準的な操作です。

月額プラン 年額プラン 従量課金
月ごとのお支払いです。いつでも解約できます。

span で作られているため、Tab でも矢印キーでも移動できません。

スクリーンリーダーの読み上げ

コードを見る
<span class="tab" onclick="show(0)">月額プラン</span>

モーダルダイアログ

WCAG 2.1.2 / 2.4.3

開いたあと、Tab キーを何度か押してみてください。フォーカスがどこへ移るかが分かれ目です。

開いた状態で Tab を押すと、背後のページに抜けていきます。Esc でも閉じません。

お問い合わせ

ご相談内容をお聞かせください。

スクリーンリーダーの読み上げ(開いた瞬間)

コードを見る
<div class="modal" style="display:block"> … </div>
← フォーカスが背後に抜ける/Esc が効かない/
   開いたことが読み上げに伝わらない

押せる領域の大きさ

WCAG 2.5.8

WCAG 2.2 で加わった基準です。押す対象は 24×24 ピクセル以上を確保します。

ワイヤレスイヤホン A 1

20×20 ピクセル。しかも隣り合っています。指が震える方、大きな指、揺れる電車の中。押し間違えます。

コードを見る
.icon-btn { width: 20px; height: 20px; }

自社サイトの確認リスト

専門知識がなくても、いまブラウザを開けば確認できる10項目です。ひとつでも当てはまるなら、 同じ問題がサイト全体に広がっている可能性があります。

  1. マウスを使わず、キーボードだけでトップページから問い合わせ完了まで進めますか。Tab キーだけでお試しください。途中で止まる場所があれば、そこが行き止まりです。
  2. Tab キーで移動したとき、いまどこにいるか見えますか。枠線が出ないなら、outline を消したままになっています。
  3. 画像を右クリックせずに、その画像が何かを説明できますか。意味のある画像に代替テキストが入っているか、開発者ツールで確認します。
  4. 見出しは h1 から順に階層になっていますか。無料のスクリーンリーダー NVDA なら F7 キーで見出し一覧が出ます。そこに過不足なく並んでいるかで判定できます。
  5. 本文の文字は、明るい場所でも読めますか。薄いグレーの文字は、コントラスト比 4.5:1 を下回りがちです。
  6. リンクの文言が「こちら」「詳しくは」になっていませんか。リンクだけを抜き出して、行き先が分かるかどうかで判断します。
  7. エラーや状態を、色だけで伝えていませんか。画面を白黒にして、まだ意味が分かるかを確かめます。
  8. フォームの入力欄に、常に見えるラベルが付いていますか。プレースホルダーだけの欄は、入力を始めると何の欄か分からなくなります。
  9. 動画に字幕がありますか。音を出せない環境で見ている方も、字幕がなければ内容を受け取れません。
  10. 自動で動くカルーセルやバナーを、止められますか。止める手段がないものは、読み終える前に切り替わります。「まず、この4つ」に含まれる項目です。

よくある誤解

よかれと思って入れたものが、実は効いていないことがあります。

「文字サイズ変更」「読み上げ」ボタンを付ければ対応になる

デジタル庁はこれらのプラグインを非推奨としています。支援技術が必要な方は、 すでにOSやブラウザの機能を使っているためです。サイト独自の機能はそのサイトでしか使えず、 利用者にとっては他のサイトで役に立ちません

オーバーレイツールを入れれば解決する

スクリプトを1行足すだけで対応できる、と謳う製品があります。しかし HTMLの文書構造そのものや、代替テキストのない画像は、後から足すスクリプトでは直せません。 いちばん重要な課題が残ったままになります。

どうせやるなら最高ランクのAAAを目指すべき

AAAを目指すことは推奨されていません。AAAにはすべてのコンテンツで満たせない基準が含まれます。 まずAAに準拠し、可能なものだけAAAを足す。デジタル庁もこの順序を推奨しています。

対応するとデザインが犠牲になる

文字色を濃くする、div を button に置き換える、ラベルを入力欄に紐付ける。 このページで見てきた項目の多くは、見た目をほとんど変えずに直せます。 設計から見直す必要があるものと、そうでないものを分けて考えます。

改善の進め方

サイト全体をいきなり作り直す必要はありません。影響が大きく、直しやすいところから順に手を入れます。

STEP 1

現状を測る

自動チェックツールと人の目の両方で診断します。自動ツールだけでは判定できない項目が多く残るため、実際にキーボードと読み上げソフトで操作して確かめます。

STEP 2

優先順位をつける

問い合わせフォーム、購入手続き、応募フォーム。事業に直結する導線から着手します。件数ではなく「そこで止まると何を失うか」で並べ替えます。

STEP 3

直す

多くは CSS と HTML の修正で解決します。デザインを変えずに直せる項目と、設計から見直す項目を分けてご提示します。

STEP 4

戻らないようにする

直したあと、更新のたびに元に戻るのがいちばんの課題です。制作ルールとチェック手順を用意し、社内で運用できる状態にします。

自動チェックツールだけでは終わりません

ツールが検出できるのは、機械的に判定できる項目に限られます。「代替テキストが入っているか」は判定できても、 「その代替テキストが画像の内容を正しく説明しているか」は判定できません。読み上げの順序が意味として自然か、 エラーメッセージが直し方を伝えているかも同様です。

逆に言えば、自動チェックを通しただけで「対応済み」としているサイトには、まだ多くの課題が残っています。