ウェブアクセシビリティ
導入ガイドブック
Introduction to
Web Accessibility

2023年1月20日発行

このガイドブックは古い版です。
ウェブページから最新版をご確認ください。

https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook

﻿. ﻿

page Aウェブアクセシビリティ導入ガイドブックとは

ウェブサイトで発信される情報、ウェブサービスとして提供される情報システム
は、インターネットとブラウザがあれば時間と場所を問わず利用することができ便利です。また、ユーザーが、見やすい・使いやすい方法を選んで使うことができる、柔軟性の高い媒体でもあります。

インターネットを使った情報発信ができるようになったことで、情報へのアクセ

スのしやすさ、つまりアクセシビリティは格段に高まりました。その上で、コンテンツの作り方や実装方法を工夫すると、さらに多くの人が多様な状況でウェブサイトや情報を使えるようになります。発信者側が想像していなかった手段や場所で使われるかもしれません。

このガイドブックでは、ウェブサイトやウェブサービス（情報システム）におけるア

クセシビリティ、つまりウェブアクセシビリティについて全く知らない、触れたことがない方々が、業務としてウェブアクセシビリティの改善に取り組むにあた
り必要な知識を、ゼロから解説しています。

行政官、デザイナー、エンジニア等の様々な背景を持つ人が利用されることを期待し、専門用語を極力使わず、重要な概念にはイラストをつけるよう心がけました。デジタル庁の業務内で得られた知見やノウハウを元に、行政機関の方にとってサポートとなる内容を記載しているのも特徴のひとつです。

本ガイドブックが、優しいサービスのつくり手になる一助となればと思います。

page 1

CONTENTS

ウェブアクセシビリティ導入ガイドブックとは

1

ガイドブックの目的
1.1
1.2
1.3
1.4
1.5

2
3

................................................................................................................................................

1................................................................................................................................................................................

4

背景と課題 .................................................................................................................................................................... 4
ガイドブックで達成したいこと ........................................................................................................................ 5

記述範囲と構成 ........................................................................................................................................................ 6

対象読者 ......................................................................................................................................................................... 7

利用と配布 .................................................................................................................................................................... 7

ウェブアクセシビリティの基礎
2.1
2.2
2.3

...........................................................................................................................................

ウェブアクセシビリティとは ............................................................................................................................. 8

ウェブアクセシビリティのガイドラインと規格 ................................................................................. 13
JIS 規格に対応したウェブサイトを作る ............................................................................................... 17

ウェブアクセシビリティで達成すべきこと
3.1
3.2
3.3
3.4

8

....................................................................................................

21

必ず達成しなければならないもの .......................................................................................................... 21
基本的に達成すべきこと ................................................................................................................................. 24
状況に応じて確認すべきこと ...................................................................................................................... 32
よく検討して導入すべきこと . ....................................................................................................................... 35

page 2

CONTENTS

4
5
6

ウェブアクセシビリティの実践プロセス
4.1
4.2

こんな時は

5.2

広報活動でのウェブを使った情報発信 . ............................................................................................... 45

6.2
6.3

50

よくある質問 ............................................................................................................................................................. 50
問い合わせ先 ........................................................................................................................................................... 51.................................................................................................................................................................................................................................

6.1

36

情報システムにおけるサービス開発 ...................................................................................................... 36...........................................................................................................................................................................................................

5.1

付録

........................................................................................................

52

改訂履歴 ...................................................................................................................................................................... 52
リンク集 ....................................................................................................................................................................... 52
参考文献 ...................................................................................................................................................................... 55

page 3

1

ガイドブックの目的

このガイドブックは、ウェブアクセシビリティに初めて取り組もうとしている行政官の方や事業者向けに、

ウェブアクセシビリティの考え方や概要、取り組み方のポイントを解説するための資料です。何をどう取り組めばいいのか、どうやって調達に組み込めばいいのか、委託事業者との円滑なコミュニケーション、意思決定のポイントがわかるようになることを目的としています。

1.1

背景と課題
「アクセシビリティ」や「ウェブアクセシビリティ」という言葉は日本語にない言葉です。馴染みのない人が多く、言葉の意味、向上させるための方法、どのような効果があるかもあまり知られていません。そのせいか、
まったく言葉も知らなかった人が「ウェブアクセシビリティを改善して」と言われても、何をすればよいか手がかりすら見つけられない場合もあります。

また、ウェブアクセシビリティには、参照できる規格がありますが、複数の規格とガイドラインをそれぞれ確認しないと利用できない複雑な構造になっています。ガイドラインの文書自体も非常に専門的な内容となっているため、正しく理解することが難しく、適切に判断できるようになるには時間がかかります。

本来、省庁や自治体の情報システムやウェブを通じた情報発信は公共性を求められるため、できる限り多くのユーザーがシステムを使ったり情報を取得できるようにする必要があります。一般的な民間の情報システム
やウェブサイトよりも高いレベルのウェブアクセシビリティの確保を達成しなければならないのですが、知識が追いつかない結果、わからないままに前例を踏襲し、現在は間違っている対応の実施、不要な対応をしてしまうことがあります。未経験で関わるには、ハードルがとても高い状況になっているのです。まとめると次の
通りです。
●
●
●

そもそもアクセシビリティの意味や、取り組むメリットがわからない
規格が複雑で、実際に何をすればいいのかわからない
理解の有無に関わらず、求められるレベルが高い

デジタル庁は 2021 年 9 月に発足しましたが、発足準備の段階からウェブアクセシビリティの専門家チームを組成し、デジタル庁の情報発信やサービス開発におけるウェブアクセシビリティの達成に取り組んできました。
本ガイドブックにはデジタル庁で発生した具体的な事例に基づく、行政機関のウェブアクセシビリティ向上へ

1. ガイドブックの目的

page 4

の取り組みに役立つノウハウを多数盛り込んでいます。本ガイドブックでは、広報・サービス開発等を担務し、ウェブアクセシビリティの改善に取り組まなければならない職員が、何も知識がないところからウェブアクセ
シビリティに取り組み、調達・受託事業者との適切なコミュニケーションができるようになることを目指しています。

また、今後は民間セクターにおいても、法改正によって法的な根拠を伴ってウェブアクセシビリティを向上できるようになります。今までは自助努力でウェブアクセシビリティの向上や改善を行っていた方々も、より強力に推進できます。そのため、多くの方に読んでもらえるようにデジタル庁のウェブサイトで公開することにしました。

初めてウェブアクセシビリティの向上と対応に関わる方が、少しでも理解を深め、よりよい方法で行えるよ

うになることを願っています。

1.2

ガイドブックで達成したいこと
デジタル庁のミッション「誰一人取り残されない、人に優しいデジタル化を。」
デジタル庁は「誰一人取り残されない、人に優しいデジタル化を。」をミッションに掲げています。誰一人取り残されないデジタル化を目指すために、デジタル庁のウェブサイトや情報システム（アプリやウェブサービス）
が、視覚に障害がある人、怪我をして一時的に手が使えなくなった人など、様々な状況にいるユーザーが、音声読み上げや点字ディスプレイなどの多様な使い方で利用することができて、サービスを受けられる状態にしたいと考えています。

ウェブアクセシビリティの重要性は年を追うごとに増しています。デジタル技術の進展によって、これまではできなかったことができるようになりました。例えば、画像認識技術、音声認識技術が様々なシーンで使われるようになり、簡単な操作で音声読み上げができるスマートフォン、アクセシビリティへの対応を強化した

OS も普及しています。視覚障害や聴覚障害がある人を取り巻く情報環境や支援技術は劇的に進化しています。
しかし、OS やハードウェアが使いやすくなっても、そこで実行されるアプリ、コンテンツやサービスが「様々な人にとって使いやすい」状態で提供されていなければ、せっかくの技術を活かすことができません。本ガイドブックを出発点として、行政、受託事業者がウェブアクセシビリティに対する理解を深め、具体的に実践し、ウェブアクセシビリティ向上の取り組みが進むことを願っています。

1. ガイドブックの目的

page 5

図1.1 ﻿﻿デジタル庁のミッションに基づいた本ガイドブックで達成したいこと

1.3

記述範囲と構成
本ガイドブックは、ガイドブックの目的、ウェブアクセシビリティの基礎、ウェブアクセシビリティで達成すべきこと、ウェブアクセシビリティの実践プロセス、の 4 章で構成されています。最初から体系的に読んでいただくことをお勧めしますが、どの章から読み始めても自然と必要な知識にたどり着くように配慮していますので、興味がある章から自由に読んでいただくことができます。

図1.2 ﻿ガイドブックの構成

なお、本資料は、基礎を理解するためのわかりやすさを重視しています。そのため、記載の厳密な正確性や網羅性を担保していません。

ウェブアクセシビリティの規格である JIS﻿X﻿8341-3:2016 の正確な記述内容や、規格への準拠を試験する方法を確認したい場合は、本資料を読んだ後、情報通信アクセス協議会ウェブアクセシビリティ基盤委員会（WAIC）
が公開している「JIS X 8341-3:2016 試験実施ガイドライン」（参考文献 1）などを参照する必要があります。

本ガイドブックでは、今読んでいる本文とは別に、JIS の各基準をわかりやすく一言で説明した表を Microsoft﻿

Excel 形式で提供する予定です。同様に正確性や網羅性は担保されていませんが、「この基準はどういうことだ
ろう？」と思ったときにお役立てください。

1. ガイドブックの目的

page 6

1.4

対象読者
本資料は、情報システム（特にインタラクティブ・システム）の開発と、ウェブを通じた情報発信のふたつの領域

で、ウェブアクセシビリティの向上に取り組む初心者の方が最初に読むことを想定して作成されたガイドブッ
クです。主な対象読者は以下の通りです。

1. 行政手続・申請等のデジタル化、情報システム開発プロジェクトの行政担当者
2. 外部に向けた情報発信、キャンペーン等を担当する行政の広報担当者

3. 上記のプロジェクトを受託する事業者の方（PM、デザイナー、エンジニア等）
4. ウェブアクセシビリティに取り組みたい民間事業者

1.5

利用と配布
本ガイドブックは、内容の正確性や網羅性について保証することができません。本ガイドブックの内容について、デジタル庁以外の組織の方へのサポートも行うことができません。予めご了承ください。

本ガイドブックに掲載・発信している情報（以下「コンテンツ」といいます。）の著作権は、特記されていない限

りデジタル庁に帰属し、権利表記の記載がない限り「政府標準利用規約（第 2.0 版）」に準拠した利用条件の下で、利用することができます。「政府標準利用規約（第 2.0 版）」と互換性のある「CC﻿BY﻿4.0（クリエイティブ・コモンズ・
ライセンス表示 4.0﻿国際）」により利用することもできます。

1. ガイドブックの目的

page 7

2

ウェブアクセシビリティの基礎

2.1

ウェブアクセシビリティとはアクセシビリティは万人のためのもの
アクセシビリティと聞くと、障害者の方向けの対応をすることというイメージを持つ人が多いかもしれません。しかし、老眼で文字が読みにくくなることもアクセシビリティの問題ですし、地方の人にとって東京にある府省庁が発行する情報にアクセスしづらいことも、アクセシビリティの問題です。

「アクセシビリティ」という単語は、Access（近づく、アクセスする）と Ability（能力、〜できること）に分けることができます。「近づくことができる」「アクセスできること」という意味から派生して、「（製品やサービスを）利用できること、またはその到達度」という意味でも使われます。テレビやラジオ、ウェブといったメディアが登場する度に、いろいろな人にとって情報のアクセシビリティは高まってきました。

ウェブはアクセシブル
ウェブアクセシビリティは、利用者の障害の有無やその程度、年齢や利用環境にかかわらず、ウェブで提供されている情報やサービスを利用できること、またはその到達度を意味しています。様々なユーザーが、いろ
いろなデバイスや環境からウェブにアクセスすることが当たり前になっている今、ウェブの利用方法の多様化に応えるアプローチのひとつがウェブアクセシビリティともいえます。

一般的に「ウェブアクセシビリティが担保できている」状態とは、具体的に次のような状態になることが望まれます。

2. ウェブアクセシビリティの基礎

page 8

●●●●

目が見えなくても情報が伝わる・操作できること
キーボードだけで操作できること

一部の色が区別できなくても情報が欠けないこと

音声コンテンツや動画コンテンツでは、音声が聞こえなくても何を話しているかわかること

ウェブはアクセシビリティを担保しやすいメディアです。なぜなら、ウェブは最終的なアウトプットの形を変えることができるからです。HTML などの中間言語で記述された情報を、ブラウザなどのソフトウェアが人間が解釈できる情報（の表現方法）に変換してユーザーに情報を伝えています（これは通常のウェブブラウザでも同じです）。このため、映像や紙媒体と違って、ユーザーが情報を閲覧する方法を選択することができます。提供者の想定通りの見た目で閲覧したり、文字や色を変えて閲覧したり、合成音声で読み上げたりというように、自分の好きな方法を選択しやすいのです。

また、インターネットやウェブで使われる技術は、そもそもの開発思想として、誰でも使えること＝アクセ

シビリティを念頭に設計されています。HTTP、HTML、CSS などウェブの根幹となる技術を開発したティム・
バーナーズ・リーはこのような言葉を残しています（参考文献 2）。

The power of the Web is in its universality.
Access by everyone regardless of
disability is an essential aspect.
ウェブの持つパワーはそのユニバーサル性にある。

障害の有無に関係なく、誰もがアクセスできることがウェブの本質なのである。

ウェブアクセシビリティの恩恵を受ける人は日本だけで少なくとも428万人以上
ウェブアクセシビリティを確保することで、障害のある人や高齢者、色覚特性のある人など多くの人がウェブを介して情報を入手したり、デジタルサービスを利用できるようになります。厚生労働省の調査では、平成

28 年の時点で身体障害者手帳の所持者が 428.7 万人（参考文献 3）となっており、この人数は年々増加しています。

図2.1 ﻿﻿障害の種類別の身体障害者手帳所持者数（平成28年）

2. ウェブアクセシビリティの基礎

page 9

具体的には次のような人々がいます。

視覚障害のある人

全盲の方はスクリーンリーダー（画面読み上げソフト）、点字ディスプレイなどを使用しています。弱視・ロービジョンの方（人数としてはこちらのほうが多い）は、文字拡大、画面拡大、色反転などの機能を使用しています。弱視・ロービジョンの方も、スクリーンリーダーを併用することがあります。

聴覚障害のある人

ひと口に聴覚障害といっても、両耳ともまったく聞こえない「全ろう」の人もいれば、少し聴力がある「難聴」の人もいて、障害の程度にはグラデーションがあります。音声情報を利用できない、または利用しづらいので、映像コンテンツを視聴するときは、手話、字幕といった視覚情報によって情報を得ています。また近年では音声の文字起こしソフトを補助的に使っている人もいます。

視覚と聴覚の両方に障害のある人

盲ろうと聞くと、ヘレン・ケラーを思い起こす方も多いかもしれません。視覚情報と聴覚情報の両方を利用できない、または利用しづらい状況にあります。他者とのコミュニケー

ションには指点字（ゆびてんじ）や触手話（しょくしゅわ）を用います。点字を利用できる人
は点字ディスプレイを使って情報を得ることができますが、点字を利用できない人が情報を得ることは現在の技術をもってしても非常に困難です。

上肢障害のある人

手に麻痺や不随意運動などがあって、マウスやキーボードを十分に動かせない方です。ス

イッチ等の操作しやすい代替デバイスを用いて、操作を行います。顔や目の動きを認識するソフトを使ったり、口を使って操作を行う人もいます。

発達障害や学習障害のある人、知的障害がある人

いずれも大きくは脳の機能に起因した障害です。症状の現れ方は人によって様々です。発達障害は主に自閉症、アスペルガー症候群などの障害のこと。学習障害とは全般的な知的機能には障害がないのに、読み書きや計算など特定のことをするのが難しい障害のことです。人によって多様な認知の特性、障害としての現れ方があります。

色覚特性がある人

特定の色を見分けるのが難しい、あるいは全く見分けられない方がいます。例えば赤色と緑色の区別をつけることが難しい、といった具合です。日本人男性の 20 人に 1 人は色覚特性があると言われているくらい、色覚特性は身近な性質です。

2. ウェブアクセシビリティの基礎

page 10

高齢の人

高齢のユーザーもウェブアクセシビリティの恩恵を受けます。加齢によって視力や聴力が低下したり、指先の細かい動きが難しくなったりしますが、ウェブアクセシビリティを確保していれば、高齢の利用者にとっても使いやすいウェブサイトやウェブサービスになる可能性が高いのです。

一時的に障害がある状態の人

さらに、次のような場合も、「一時的または状況的な障害のある状態」と考え、ウェブア

クセシビリティの対象として考慮の対象とします。ご経験のある方も多いことでしょう。
●●●

電車内で動画を見たいのにイヤホンを忘れた
眼鏡を忘れてきたので目が疲れやすい
利き手を怪我してマウスが使えない

よくある誤解ウェブサイトやウェブサービスのアクセシビリティ向上を行うときに誤解しやすいことが 2 点あります。

1 点目は、文字サイズ拡大ボタンやカラーテーマ変更ボタンのようなユーザー補助のための機能を設置すれば、アクセシビリティが向上できると勘違いすることです。

機能自体は有用な場合もありますが、実際に文字を大きくしてサイトを閲覧する必要があるユーザーや、色を変更してサイトを閲覧するユーザーは、特定のサイトだけではなくすべてのサイトで同じ状態になっていることを望みます。そのため、ユーザーが使っているパソコンやスマートフォンなど、デバイス（その OS）が提供している設定項目を調整してカスタマイズしていることが多く、特定のサイトに付加された機能を積極的に使いたいわけではないのです。

また、ユーザー補助機能は、コントラスト比の強調や文字サイズの変更といった「目で見える」部分に関する機能が追加される場合が多いため、例えば「スクリーンリーダーで情報を読み上げるのに用いられる、画像の代替テキストがない」といった、視覚障害がある人にとっての問題は解決されません。

そのため、ウェブサイトや情報システムにユーザー補助の機能を付けるよりも前に、ユーザーがそれぞれのデバイスの設定機能で変更しようとしている文字サイズや色変更に対応できるような実装や、読み上げて意味が伝わるようにコンテンツを作成すること、操作がきちんとできるように実装することを優先すべきです。

2 点目は、ウェブアクセシビリティの自動チェックツールを使ってページやサイト全体をチェックして改修することだけがアクセシビリティ向上の方法であると勘違いされていることです。

チェックツール自体は短時間で大量のページをチェックすることができるため、とても有用なものです。しかし、ウェブアクセシビリティを向上させるための要素には、ウェブページやウェブサイトの内容自体に対する検証や、人が目視で確認しないと良し悪しが判断できないものが多く含まれています。実例を挙げましょう。
ウェブアクセシビリティのチェック項目の 1 つに「ウェブページの言語設定」がありますが、言語が設定されていないことはチェックツールで判別できても、どの言語を選ぶのがよいかは人が確認しないとわかりません。
また、画像に代替テキストが付与されていることは機械でチェックできても、それが適切なテキストかどうか
は機械は判断できません。

2. ウェブアクセシビリティの基礎

page 11

チェックツールで見つけられる問題は、ウェブアクセシビリティの問題の 2 割から 3 割程度です。ウェブア

クセシビリティは基本的に「人がチェックする必要がある」と考えましょう。

図2.2 ﻿﻿ウェブアクセシビリティのよくある誤解と正しい考え方

アクセシビリティとユーザビリティ「アクセシビリティ」と「ユーザビリティ」はどちらも外来語ですし、インターネットの普及にあわせて使われるようになった歴史の浅い言葉です。

説明の順序が逆になりますが、「ユーザビリティ」は「特定のユーザが特定の利用状況において、システム、製品又はサービスを利用する際に、効果、効率及び満足を伴って特定の目標を達成する度合い」です。これは ISO﻿
9241-11 という規格の中で定義されており、「特定の〜」という言葉が重ねて使われていることからわかるように、かなり限定された条件下での「有用性」を表す言葉です。「特定の」と条件を重ねていることには意味があります。この定義は「どんなシーンで、誰が、何を目的として、どのように使うのか想定しなければ使いやすいシステムは実現しない」と言っているのです。

一方、アクセシビリティは規格や文章の中それぞれで定義されることはありますが、一般的に広く使われている共通の説明はなく、「障害者・高齢者を含むユーザーのアクセスしやすさ」と説明されることが多いように思われます。あえて規格を参照するならば、JIS﻿X﻿8341-1
において「様々な能力を持つ最も幅広い層の人々に対する製品、サービス、環境又は施設（のインタラクティ
ブシステム）のユーザビリティ」と定義されていることなどから「あらゆる人のユーザビリティ」という言い方をすることもあります。

ですから、アクセシビリティとユーザビリティは明確に区分できるものではありません。お互いの言葉や概念、基本理念は重複している部分もあります。ユー
ザビリティを高めることがアクセシビリティを高める

ことになりますし、その逆も然りです。「どんなシーン
で、誰が、何を目的として、どのように使うのか」はウェブアクセシビリティの向上においても欠かすことのできない考え方です。

それぞれの言葉の関係性は、情報アーキテクチャの開拓者として知られるピーター・モービル氏が「UX ハニカム」という UX（ユーザーエクスペリエンス）を構成す

2. ウェブアクセシビリティの基礎

図2.3 ﻿﻿User﻿Experience﻿Design,﻿Peter﻿Morville

http://semanticstudios.com/user_experience_design/

page 12

る要素として整理した図が有名です。日本では、坂本貴史氏が評価軸ごとにピラミッド状に再構成した図もよく参照されます。

図2.4 ﻿﻿Evaluation﻿method﻿of﻿UX﻿“The﻿User﻿Experience﻿Honeycomb” ,﻿坂本貴史

https://bookslope.jp/blog/2012/07/evaluationuxhoneycomb.html

2.2

ウェブアクセシビリティのガイドラインと規格
ウェブアクセシビリティは、HTML などのインターネット技術を前提としたアクセシビリティのことを指しています。通信インフラ、ソフトウェア、ハードウェアそれぞれの技術の更新が非常に早いのが特徴です。

そして、アクセシビリティは多くの障害特性や利用状況を把握して向上・対応する必要があります。視覚、聴覚などの感覚障害、上肢障害、認知障害といった 1 つでも把握の難しい利用状況を網羅して把握しなければいけません。

そのため、技術のキャッチアップと利用状況をそれぞれ個別に確認して対応するのではなく、網羅的に確認された上で体系立てられたガイドラインを使います。ウェブアクセシビリティの向上がガイドライン対応と言われることが多いのはそのためです。

ここでは世界で標準的に使われているガイドラインの WCAG と、その一致規格の JIS 規格について説明します。

WCAGWeb﻿Content﻿Accessibility﻿Guidelines、略称 WCAG と呼ばれます。インターネットの各種規格を策定・勧告している W3C（World﻿Wide﻿Web﻿Consortium）という団体が勧告しているガイドラインです。1999 年に 1.0、
2008
年に 2.0 が勧告され、2022 年 11 月現在は「2.1」というバージョンが勧告されています。

そして、2012 年に国際規格の ISO から WCAG﻿2.0 と内容が全く同じ「一致規格」として ISO/IEC﻿40500:2012

が出されました。この動きによって WCAG を規格として使うことができるようになりました。

WCAG 2.0

WCAG﻿2.0 は、「知覚可能」「操作可能」「理解可能」「堅牢（robust）」の 4 つの原則と、ウェブアクセシビリティを向上させるための目標にあたる 12 のガイドラインで構成されています。さらに、ガイドラインを細分化した61 の達成基準があります。

WCAG﻿2.0 はテスト容易性（Testability）を大きく向上させたことと、技術変化に対応するために文書構成を変

2. ウェブアクセシビリティの基礎

page 13

えたことが WCAG﻿1.0 との大きな違いです。そのため、「原則」「ガイドライン」「達成基準」は技術・デバイスの変化や進化に対応するため、技術仕様に依存しない抽象的な内容になっています。技術仕様に関する内容は「WCAG﻿2.0﻿解説書」と「WCAG﻿2.0﻿達成方法集」に書かれています。技術仕様に関する文書をガイドライン本体に含めないことにより更新頻度を上げることができ、ウェブの技術変化に柔軟に対応しています。

原文は W3C が誰でも参照できる形で公開しています。加えて、日本では WAIC が日本語訳を作成し公開して

います。
●
●

Web Content Accessibility Guidelines（WCAG）2.0

Web Content Accessibility Guidelines（WCAG）2.0（日本語訳）

WCAG 2.1

WCAG﻿2.1 は 2018 年に勧告された WCAG﻿2.0 の改訂版です。WCAG﻿2.0 が勧告された 2008 年にはまだ一般的ではなかったスマートフォンなどのモバイル端末（タッチデバイス）への対応、弱視への対応、認知・学習障害への対応などが盛り込まれています。日本ではまだ JIS の一致規格が WCAG﻿2.0 から更新されていないため一般的ではありませんが、一部の国では基準に取り込まれています。
●●

Web Content Accessibility Guidelines（WCAG）2.1

Web Content Accessibility Guidelines（WCAG）2.1（日本語訳）

WCAG 2.2

WCAG﻿2.2 は WCAG﻿2.1 の改訂版で、2022 年 11 月現在は 2023 年初頭に勧告が予定されている新しいガイドラインです。フォーカス枠、認証方法、ヘルプリンクなど、現在のウェブサービスで使われているナビゲーショ
ンに対応した達成基準が追加される予定です。
●

What's New in WCAG 2.2 Draft ｜ Web Accessibility Initiative（WAI）｜ W3C

なお、ISO/IEC 40500:2012 は WCAG 2.2 の内容で更新されることが周知されています。

JIS X 8341-3
JIS﻿X﻿8341-3 は正式名称を「高齢者・障害者等配慮設計指針－情報通信における機器，ソフトウェア及びサー

ビス－第 3 部：ウェブコンテンツ」と言います。ウェブサイトのアクセシビリティに関する JIS 規格と捉えられることが多いですが、ウェブブラウザを使うアプリケーションやシステムにも関係します。

2004 年に一般的なアクセシビリティの課題に加えて日本語固有の課題を解消するための要件が盛り込まれた JIS﻿X﻿8341-3:2004 が発行されました。そして、2010 年に WCAG﻿2.0 の内容を取り込む形で大きく改定され、2016 年には WCAG﻿2.0 と ISO/IEC﻿40500:2012 と全く同一内容の一致規格として改定されました。それが JIS﻿X﻿
8341-3:2016 という規格です。

そのため、WCAG﻿2.0 と ISO/IEC﻿40500:2012 と JIS﻿X﻿8341-3:2016 は全く同一の一致規格となっています。それぞれのガイドラインと規格が一致規格になったことにより、ウェブアクセシビリティのチェック方法やツールを共通化できることに加え、言語ごとに違うガイドラインや規格を使う必要がなくなりました。

2. ウェブアクセシビリティの基礎

page 14

JIS X 8341-3:2016

JIS X 8341-3:2016 は、2022 年 11 月現在で最新のウェブアクセシビリティに関する JIS 規格です。
●

JIS﻿X﻿8341-3:2016﻿高齢者・障害者等配慮設計指針―情報通信における機器，ソフトウェア及びサービス―第３部：ウェブコンテンツ｜日本規格協会﻿JSA﻿Group﻿Webdesk

WCAG﻿2.0 と一致規格のため、上述の通り WCAG﻿2.0 のチェックツールを使うことができたり、英語を含む海外の情報が豊富なことが特徴です。しかし、2 点注意が必要です。
1 点目は、JIS X 8341-3:2016 は単体で完結していない点です。

WCAG﻿2.0 は「原則」「ガイドライン」「達成基準」の 3 つの文書群で構成されていますが、JIS﻿X﻿8341-3:2016に含まれるのは「原則」「ガイドライン」と「達成基準」の一部です。「達成基準」の詳細な解説と「達成方法」は含まれていません。

そのため、ウェブアクセシビリティが JIS﻿X﻿8341-3:2016 に準拠していることを確認するためには、必ずWCAG﻿2.0 の達成基準と達成方法を理解する必要があります。規格票の附属書にチェックリストがあるため誤解しやすいですが、規格票だけでウェブアクセシビリティをチェックすると不完全なチェック内容になりますのでご注意ください。

達成基準の詳細な解説や事例については「Understanding﻿WCAG﻿2.0」（日本語訳は「WCAG﻿2.0﻿解説書」）を、また達成方法については「Techniques﻿for﻿WCAG﻿2.0」（日本語訳は「WCAG﻿2.0﻿達成方法集」）をそれぞれ参照してください。

2 点目は、対応度の表記に独自の表記を使う点です。

JIS﻿X﻿8341-3:2016 は、JIS 規格に従った試験と適合性の表明をすることで適合要件を満たすことができます

が、それを行うためには第三者に試験を行ってもらったり、「供給者適合宣言書」と言われる書類を作成したりする必要があります。

しかし、一度試験を行えばその後は同じ手順で同じ製品を作り続けられる工場製品とは異なり、ウェブサイ

トや情報システムは日々改修と更新が行われてその都度ウェブアクセシビリティの試験を行う必要があるため、適合要件を満たすための工数や期間が過剰になります。

そこで、JIS﻿X﻿8341-3:2016 の試験は、JIS の「附属書﻿JB）『試験方法』
﻿」とあわせて WAIC が作成した「試験実施ガイドライン」を参照しながら行うことで、試験の信頼性を保ちつつ妥当な工数で試験を行うことができます。そしてその試験方法は広く一般的に使われています。また、試験結果や対応度の表明には「対応度表記ガ
イドライン」で定義された方法を使うことができます。
●

2. ウェブアクセシビリティの基礎

ウェブコンテンツの JIS X 8341-3:2016 対応度表記ガイドライン

page 15

多くの行政サービス・ウェブサイトの調達時は、JIS﻿X﻿8341-3:2016 と対応度表記ガイドラインを参照してどの程度まで対応するかを定め、調達を行います。調達仕様書にも明確に定義しておく必要があります。

図2.5 ﻿﻿ウェブアクセシビリティのガイドラインと規格の関係

他によく参照される基準等の考え方
みんなの公共サイト運用ガイドライン

みんなの公共サイト運用ガイドライン（2016 年版）

は、公的機関がウェブアクセシビリティの確保・維持・向上に取り組む際の支援を目的として作成された手順書で、JIS﻿X﻿8341-3:2016 に対応しています。ただし、技術仕様・ツール・開発フローは日々新しくなっていますので、その時々の状況に合わせた仕様やツールを使うことを推奨します。

情報アクセシビリティ自己評価様式

現在、企業が自社で開発する ICT 機器・サービスについて情報アクセシビリティ基準を満たしているかを自己評価する様式の書式整備が進められていますが、ウェブアクセシビリティにおいては技術基準に JIS﻿X﻿83413:2016 の達成基準が取り込まれています。

2. ウェブアクセシビリティの基礎

page 16

2.3

JIS 規格に対応したウェブサイトを作る
調達するサービスで対応する度合いを決める
JIS﻿X﻿8341-3:2016 の対応度を示す方法には、「準拠」「一部準拠」「配慮」の 3 つの方法があります。これは前述した通り JIS 規格に基づいた表記方法ではなく、WAIC が独自に定義した表記方法です。
●●●「準拠」は、試験を行って達成基準すべてを満たしている場合に使えます。公開するときは試験結果を合わせて公開します。
「一部準拠」は、達成基準の一部を満たしている場合に使えます。一部準拠の場合は追加で今後の対応方
針を記載します。
「配慮」は、試験の実施と公開の有無は問いません。

なお、いずれの場合も「ウェブアクセシビリティ方針」を作成して、提示または公開する必要があります。詳

しくは WAIC が公開している「ウェブコンテンツの JIS X 8341-3:2016 対応度表記ガイドライン」をご参照ください。

図2.6 ﻿﻿JIS﻿X﻿8341-3:2016の対応度と表記の条件

ウェブアクセシビリティ方針を定める
JIS﻿X﻿8341-3:2016 の対応度を表記するためには「ウェブアクセシビリティ方針」を作成する必要があります。

大まかに言うと 2 つのことを決める必要があります。

対象となる範囲を定める

ウェブサイトのどこを対象にするかを決めます。ドメインかサブドメインで決めるのが一般的です。ウェブ

サイトの一部を方針の対象から外す場合には、対象外となるページを第三者が理解できるように、サブドメイ
ンやディレクトリを指定したり、一覧を掲載するなどする必要があります。

2. ウェブアクセシビリティの基礎

page 17

目標とする適合レベルを定める

JIS﻿X﻿8341-3:2016 で定義されている適合レベル「A、AA、AAA」のどのレベルに適合するかを選択します。
「みんなの公共サイト運用ガイドライン」では AA に適合させることが推奨されており、他国の法律やポリシーでもAA に適合させることを推奨しているため、原則 AA に適合させることを目標とします。

加えて、目標を達成する期限や担当部署名、把握している問題点などを記載すると親切です。WAIC が公開しているウェブアクセシビリティ方針策定ガイドラインに多くのサンプルが掲載されていますので、そちらを参考にすると、策定しやすいでしょう。なお、ウェブアクセシビリティ方針を決めると試験の作業難易度と作業
ボリュームが把握できたり、コンテンツの情報保障に必要な情報の把握ができますので、要件定義時に決めることを推奨します。

図2.7 ﻿﻿ウェブアクセシビリティ方針で決めること

ウェブアクセシビリティの試験を行う
ウェブアクセシビリティ方針を定めることができたら、試験を行って対応度を確認します。

例えば、JIS﻿X﻿8341-3:2016 の適合レベル AA に準拠していることを試験で確認するためには、適合レベル A の達成基準 25 個と適合レベル AA の達成基準 13 個の中から、開発したサイトやサービスで適用対象となる達成基準を選び、それぞれの達成基準が適合しているかをひとつひとつ確認します。

そのときに、それぞれの達成基準に適合しているか直接確認するよりも、達成基準に含まれる「達成方法」と「失敗例」を使って判断するという簡単で確実にできる方法を推奨します。達成基準それぞれの達成方法はWCAG 2.0 解説書で確認できます。

確認をするときは、WAIC が公開している JIS X 8341-3:2016 試験実施ガイドラインからダウンロードできる

Excel ファイル「実装チェックリスト」を使って確認すると効率的に作業を進められます。

この作業を、サイトの全ページかサンプリングした数十ページに対して行うことが、JIS に基づくウェブア

クセシビリティの試験です。また、パソコン、スマートフォンなどデバイスごとに異なる UI を提供している場
合はそれぞれのデバイスで確認する必要があります。

2. ウェブアクセシビリティの基礎

page 18図2.8 ﻿﻿ウェブアクセシビリティの試験

正式な試験には時間がかかる

ウェブアクセシビリティの試験は、数百個のチェックリストを 1 つ 1 つ確認するというとても手間のかかる作業です。そして、それを対象ページ数とデバイス数だけ繰り返す必要があります。そのため、100 ページ程度のサイトで正式な試験を行うと 1 ヶ月弱（改修対応まで含めると 2 ヶ月から 3 ヶ月）はかかります。試験を外部試験機関に委託した場合、その費用は 50

万円程度から 100 万円程度まで、システムの規模に応じて必要となります。

チェックツールの機械チェックに頼り切らない

総務省から提供されている miChecker や Deque﻿Systems がオープンソースで公開している axe-core などウェブアクセシビリティのチェックツールがありますが、ツールで機械的に確認できるのは達成基準の 2 割から 3 割程度にとどまります。また、ツールによっては開発から時間も経過し、最新のウェブテクノロジーを採用して実装されたページのテストが困難な場合もあります。このため、試験は必ず人が目視による確認やキーボードのみの操作、ス
クリーンリーダーなどの支援技術を用いた確認をする必要があります。詳細な試験の進め方
は、WAIC が公開している JIS X 8341-3:2016 試験実施ガイドラインをご参照ください。

公開2週間前にテストでは遅いので開発マイルストーンに段階的試験を組み込む

ウェブサイトやウェブサービスがすべて完成してから試験を行うと、改修に多大な工数がかかったり、改修すること自体が困難な問題が見つかったりします。よって、アクセシビリ

ティが不完全な状態でリリースせざるを得なかったり、リリース延期になる場合もあります。
マイルストーンの途中でウェブアクセシビリティに関するコミュニケーションを取っておくと、受託した事業者がウェブアクセシビリティに配慮した実装の経験がどれくらいあるか確認し、対応を行いやすくなります。

2. ウェブアクセシビリティの基礎

page 19

そのため、「情報設計時」「デザインテンプレート完成時」「結合テスト時」など、開発フェーズの途中で複数回試験を行うことを推奨します。開発フェーズに行う試験は、見出しレベルが飛んでいないかを確認したり、ス

クリーンリーダーで複雑な UI を一通り操作できるかを確認したり、文字のコントラストが低そうな箇所をツールで確認したりという簡易的な内容でも構いません。なお、開発中の試験については 4 章で紹介しています。

ウェブアクセシビリティの試験結果を公開する
試験結果を集計して対応度を出します。すべてのページですべての達成基準に適合していれば「準拠」、どれか 1 つでも達成基準に適合していない場合は「一部準拠」となります。100 点満点でたとえると 100 点が「準拠」、
1 点から 99 点が「一部準拠」となります。このように、対応度を準拠にすることはとても難しいため、目指す

べきではありますが必ず達成させることを目的にしないほうがよいです。一部準拠であっても、どこに問題があっていつまでに対応できるかを示すことで、ユーザーはそれ以外の箇所を見たり操作できます。

また、準拠を目指すために、達成基準を満たすことができないページやコンテンツを対象外にしたり削除することは止めてください。本末転倒です。一部準拠であることを公開した上で問題を改善し、次の試験までに達成度合いを高められるようにしてください。

なお、JIS﻿X﻿8341-3:2016 の達成基準の一部に「非干渉」と呼ばれる達成基準があります。非干渉の達成基準に適合できないページは一部のコンテンツ以外にアクセスできないユーザーがいる状態のため、リリース前に必ず改修してください。なお、非干渉については 3 章の「非干渉の達成基準」で説明していますのでそちらをご参照ください。

2. ウェブアクセシビリティの基礎

page 20

3

ウェブアクセシビリティで達成すべきこと

この章では、ウェブアクセシビリティを担保する上で達成すべきことを「必ず達成しなければならないもの」「基本的に達成すべきこと」「状況に応じて確認すべきこと」「よく検討して導入すべきこと」の順番で説明します。
文中で「1.4.2 ｜音声の制御」のように記載されている箇所は、WCAG﻿2.0（JIS﻿X﻿8341-3:2016）の達成基準を示しています。詳しくはデジタル庁ウェブサイトのウェブアクセシビリティのページをご覧ください。

3.1

必ず達成しなければならないもの（

重大）

どんなサービスやコンテンツを公開する場合であっても、これだけは必ず達成する必要がある達成基準があります。実現できていない場合、利用者がウェブページやウェブサイト内を移動したり、コンテンツを理解することが極めて難しくなります。また、利用者を発作の危険性にさらしてしまう可能性があります。

非干渉の達成基準
JIS﻿X﻿8341-3:2016 の中では、必ず達成しなければいけない達成基準は「利用者がウェブページの他の部分へアクセスすることを妨げていない」状態であるということから「非干渉」という言葉を使っています。逆の言い方をすると、非干渉の達成基準に適合できていない場合は適合できていないコンテンツや実装方法が、他の部分へのアクセスを妨げている状態になっています。

JIS X 8341-3:2016 では「非干渉」の達成基準は 4 つあります。1 つずつ確認していきましょう。

3. ウェブアクセシビリティで達成すべきこと

page 21

重大

自動再生はさせない
音声を自動再生することや強制的に再生させることは避けましょう。また、自動再生する音声は 3 秒以内に収めましょう。自動再生が 3 秒以上続く場合はユーザーが止められるようにする必要があります。

図3.1 ﻿﻿音声の流れるページや動画広告などで自動再生する場合は、一時停止またはミュートボタンをつける

WCAG 2.0

重大達成基準：［﻿1.4.2｜音声の制御﻿］

袋小路に陥らせない
キーボード操作だけで利用しているときに、一度フォーカスしたら抜け出せないコンテンツを作らないようにしましょう。たとえばモーダルダイアログのようなフォーカスを制限するコンテンツで起きやすいです。

図3.2 ﻿﻿ダイアログ内にフォーカス可能な閉じるボタンを置くことで、キーボードで閉じられるようにする

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿2.1.2 ｜キーボードトラップなし﻿］page 22

重大

光の点滅は危険光の点滅を繰り返すと、光感受性発作等を誘発しやすくなります。1 秒に 3 回以上点滅するコンテンツを作ってはいけません。（これは適合レベル AAA﻿達成基準 2.3.2 の説明ですが、非干渉の達成基準 2.3.1 は適合判断が難しいため、達成基準 2.3.2 に適合させることを推奨します）

図3.3 ﻿﻿アニメーションや映像などのコンテンツで、1秒に3回以上点滅させない

WCAG 2.0

重大達成基準：［﻿2.3.1 ｜ 3 回の閃光、又は閾値以下﻿］［﻿2.3.2 ｜ 3 回の閃光﻿］

自動でコンテンツを切り変えない
スライドショーや自動で切り替わるコンテンツなどがある場合は、一時停止、非表示、停止の機能を設置する必要があります。画面上に動き続けるコンテンツがあると、他の箇所の操作や閲覧を妨げられるユーザーがいるためです。
SHOP

○○○

○○○○○○○○○○○○○○○○○

図3.4 ﻿﻿自動で切り替わるカルーセルだが、一時停止できる

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿2.2.2 ｜一時停止、停止、非表示﻿］

page 23

3.2

基本的に達成すべきこと（

必須）「非干渉」ほどではありませんが、満たしていないとコンテンツが十分に伝わらない、あるいは操作が不完全にしかできない達成基準があります。これらの達成基準は優先して対応してください。

必須

ロゴ・写真・イラストなどの画像が指し示している情報を代替テキストとして付与する「代替テキスト」とは、写真やイラスト、グラフなど主に画像で提供される情報と「同等の役割を果たすテキスト」のことです。「代替内容」なので、画像の代わりにその文字を置いてみても違和感がな
い内容であることが望まれます。
●
●

●
●

画像がリンクの場合、代替テキストはリンク先を示す内容にします

グラフや図表など、ある意味を示す場合はその要約を記述します。ただし、隣接するテキストに内容（の要約）がある場合は何のグラフ・図表なのかが示されていれば構いません
文字イメージ（ロゴマークや見出しなど）を表現している場合、同じ文字を記述します
装飾や意味を持たない画像の代替テキストは空にします

代替テキストの長さは仕様や規格では制限がありませんが、スクリーンリーダーの可読性を考慮して 80 字を目安にしましょう。図に大量の文字が含まれている場合は本文に書き起こすなど、図自体を変更できないか検討します。また、代替テキストは図の文脈で内容と量が変わりますが、「模式図」のように図を見ないと内容がわからないテキストは避けましょう。

図3.5 ﻿﻿alt 属性で代替テキストを指定し、図表を文章で説明

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿1.1.1 ｜非テキストコンテンツ﻿］page 24

必須

キーボード操作だけで、サービスのすべての機能にアクセスすることができるようにする●●

キーボード操作時に、フォーカスインジケーター（選択中の要素を枠線等で囲んで示すこと）が表示されるようにしましょうキーボード操作時に、フォーカス・入力がキャンセルされたり、フォーカス・入力した瞬間に何かが勝手に動作することがないようにしましょう  

WCAG 2.0

達成基準：［﻿2.1.1 ｜キーボード操作﻿］［﻿2.4.3 ｜フォーカス順序﻿］［﻿2.4.7 ｜フォーカスの可視化﻿］［﻿3.2.1 ｜フォーカス時﻿］［﻿3.2.2 ｜入力時﻿］必須

操作に制限時間を設けてはいけない
閲覧や入力の操作に、制限時間を設けてはいけません。設ける必要がある場合は以下のいずれかの回避手段を設けてください。
●●●●

制限時間があること、またそれを延長・解除できることをユーザーに事前通知する
入力フォームのセッション時間をユーザーが延長するか無制限にできる

ページ上のスクリプトで制御されている入力フォームの制限時間をユーザーが延長できる
自動的に進むコンテンツをユーザーが一時停止できる

図3.7 ﻿﻿入力フォームに制限時間がある場合は事前に警告し、簡単に延長できるようにする

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿2.2.1 ｜タイミング調整可能﻿］［﻿2.2.2 ｜一時停止、停止、非表示﻿］

page 25

必須

赤字・太字・下線・拡大などの表現のみで情報を伝えてはいけない●●

赤字など、色の違いだけで情報を伝えてはいけません

太字、『右の写真』『丸いボタン』など、位置や形の違いだけで情報を伝えてはいけません

図3.8 ﻿﻿色だけで必須項目を表現しない。
「必須」ラベルのように、色以外の手がかりでも必須項目を判別できるようにする

WCAG 2.0

必須達成基準：［﻿1.3.1 ｜情報及び関係性﻿］［﻿1.3.3 ｜感覚的な特徴﻿］［﻿1.4.1 ｜色の使用﻿］スクリーンリーダーで順に読み上げたときに、意味が通じる順序になっている
目が見えている人はウェブサイトを斜め読みして欲しい情報を見つけることができますが、スクリーンリーダーの場合は、キーボードを使ってページの先頭から 1 つ 1 つリンクや文章をたどって内容を聞いていきます。このとき、文章の意味と読み上げ順序が整合していないと内容を正確に理解できなくなってしまいます。スクリーンリーダーは、HTML のソースに記載されている順、視覚的には左上から右下に向かって読み上げます。この順序を考慮してコンテンツやサービスを設計してください。

図3.9 ﻿﻿文字間隔の調整に空白文字（スペース）を使うと、スクリーンリーダーで正しく読み上げられないことがある

図3.10 ﻿﻿ボタンの前に同意事項が読み上げられないと何に同意するか分からない

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿1.3.1 ｜情報及び関係性﻿］［﻿1.3.2 ｜意味のある順序﻿］［﻿2.4.3 ｜フォーカス順序﻿］

page 26

必須

見出し要素だけで、セクションやブロックに含まれる要素を表現する
例えば、見出しが「リスト」だけではなんのリストかわかりません。
●
●

●
●
●

大見出し、中見出し、小見出し…となるように見出しレベルを適切に設定してください

NVDA で F7 キーを押して見出しリストを表示して、ページ中の見出しが過不足なく表示されていることを確認してください
Chrome の機能拡張の HTML5 Outliner を使って、HTML のアウトラインを確認してください
見出し要素を空にしないでください

強調や文字を大きくするために見出し要素を用いないでください

図3.11 ﻿﻿箇条書きの見出しが内容を表したものになっていないと、何が列挙されているかを推測するのが難しい

図3.12 ﻿﻿長い文章の途中に見出しが無いと、必要な部分だけ拾い読み

することが難しくなる。見出しがあると内容の推測をしやすくなり、スクリーンリーダーの見出し一覧機能を使って、読み飛ばすこともできる

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿1.3.1 ｜情報及び関係性﻿］［﻿2.4.6 ｜見出し及びラベル﻿］［﻿2.4.10 ｜セクション見出し﻿］page 27

必須

文字と背景の間に十分なコントラスト比を保つ
文字色と背景の間に、4.5:1 以上のコントラスト比がある（機械チェックによりある程度確認できる）必要があります。配色を決めるときに合わせて検討しましょう。
●●

4.5:1 以上のコントラスト比は、太字でないテキスト 22 ポイント（29px）未満、太字のテキスト
は 18 ポイント（24px）未満の場合の値です
大きいテキストでは 3:1 以上のコントラスト比である必要があります

図3.13 ﻿﻿背景色﻿#AAAAAA﻿の上に書かれた白い文字は、コントラスト比が﻿4.5:1﻿未満で、最低限のコントラストを満たしていない

WCAG 2.0

必須達成基準：［﻿1.4.3 ｜コントラスト（最低限）﻿］

テキストの拡大縮小をしても情報が読み取れる
画面拡大ソフトなどを使わずに、ブラウザの文字拡大機能だけで文字サイズを 200% まで変更できるようにしましょう。
●●

文字サイズなどが固定になっていない

コンテンツを 200% まで拡大したときに、文字が重なったり見切れないようにしましょう

図3.14 ﻿﻿スマートフォンでの拡大縮小を無効にする「user-scalable=no」は使用しない

図3.15 ﻿﻿文字の位置指定や折返し指定によっては、文字を拡大したとき重なって読めなくなってしまう

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿1.4.4 ｜テキストのサイズ変更﻿］page 28

必須

文字や文字コード、フォントに関する注意
●

●

●

●

現在の HTML では、文字コードとして UTF-8 を使うべきであるとされています。他の文字コー
ド（Shift_JIS など）は避け、UTF-8 を使用してください
Web フォントを使ってアイコンや UI を表現している場合、ユーザーがフォントの設定を変更していると、異なる文字として表示されます。注意して使いましょう

PDF から文字をコピーすると、見た目がそっくりな別の文字に置き換えられてしまう場合があります。これをそのままウェブページに掲載すると、スクリーンリーダーでは正確に読み上げられないことがあります。公開前に読み上げの確認を行うなど注意しましょう「*（アスタリスク）」「※（こめじるし）」などの記号はスクリーンリーダーとその設定によっては読み上げられません。確認しながら使いましょう。必須項目の印に記号を使っている場合は「必須」など読み上げられる文字に変更することも検討しましょう

WCAG 2.0

必須達成基準：［﻿3.3.2 ｜ラベル又は説明﻿］［﻿4.1.1 ｜構文解析﻿］［﻿4.1.2 ｜名前（name）
・役割（role）及び値（value）﻿］ページの内容を示すタイトルを適切に表現する●●●「内容｜サイト名」とすると判別が容易です

複数のページでページタイトルが重複しないようにしましょう

ページタイトルとそのページの大見出し（H1）が揃っていると、ユーザーはより安心してページを利用できます図3.16 ﻿﻿各ページのタイトルが同一だと、サイト内検索などでページタイトルが並んだ際に内容の判別が難しくなる

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿2.4.2 ｜ページタイトル﻿］page 29

必須

リンクを適切に表現する●●

リンクがどこへのリンクなのか、単体で、または前後の文脈から簡単に理解できるようにしてください
リンク先が、PDF なのか外部ウィンドウを開くのか、事前に理解できるようにしてください

図3.17 ﻿﻿リンクの文言が同一だと、スクリーンリーダーのリンク一覧で判別が難しくなる。リンク先の内容がわかるように表現する

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿2.4.4 ｜リンクの目的﻿］page 30

必須

ナビゲーションに一貫性をもたせる●

ナビゲーション要素が、毎回同じ順序、表記で実装されているようにしてください

図3.18 ﻿﻿ページによってグローバルナビゲーションの位置が異なると、ページ切り替えの度にナビゲーションを探さなくてはならない。また、ナビゲーション内の表記がページごとに揺れていると迷わせることになる

WCAG 2.0

必須達成基準：［﻿3.2.3 ｜﻿一貫したナビゲーション﻿］

同じ機能には、同じラベルや説明をつける●●

同じ機能を複数のページで提供する場合は、同じラベル、説明で提供されているようにしてく
ださい
ボタン要素などのコンポーネント、アイコン、リンクなどに一貫性を持たせてください

図3.19 ﻿﻿同じ役割のボタンのアイコンとラベルがページによって異なるのは一貫性がない

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿3.2.4 ｜﻿一貫した識別性﻿］

page 31

3.3

状況に応じて確認すべきこと（

個別対応

）

サイトや情報システムによっては無いこともあるコンテンツや確認事項です。コンテンツやシステムに応じて確認してください。JIS﻿X﻿8341-3:2016 の試験では「非適用」という言葉を使います。

個別対応

入力フォームを様々な使い方でも使えるようにする
●
●

●
●
●
●
●

ラベルとフォームコントロールは関連付けてください

入力形式（全角・半角など）、文字数、使用できる文字の制限などでエラーが起きる場合は、ユー
ザーが入力する前に説明してください
エラーが起きたときに、エラーが起きた箇所を明示して適切な説明をしてください
入力エラーはスクリーンリーダーで読み上げられるようにしてください
エラーの回避方法は具体的に示してください

必要に応じて、一連のフォームコントロールをグループ化してください

法律に関わる操作や金融取引などに関する入力フォームでは、入力エラーのチェック、入力内
容の確認、送信の取り消しをできるように設計してください

図3.20 ﻿﻿NG 例は各フォームコントロールにラベルが無く、文字を入力すると項目を見分けにくい。また、全角・半角文字の指定

や、字数制限について書かれておらず、エラーになる前に気づけない

WCAG 2.0

達成基準：［﻿1.3.1 ｜情報及び関係性﻿］［﻿3.3.1 ｜エラーの特定﻿］［﻿3.3.2 ｜ラベル又は説明﻿］［﻿3.3.3 ｜エラー修正の提案﻿］［﻿3.3.4 ｜エラー回避（法的、金融、データ）
﻿］3. ウェブアクセシビリティで達成すべきこと

page 32

個別対応

音声・映像コンテンツに代替コンテンツを付与する
●
●
●
●
●
●

前後のテキスト、プレイヤーのラベルなどから、音声、映像コンテンツの存在や種別を認知できる
3 秒以上のコンテンツでは、自動再生を行わないプレイヤーを用いて、一時停止、停止することができるプレイヤーを操作した後でも他のコンテンツにアクセスできる

会話の内容や重要な効果音などが伝わるようなキャプション（字幕）を提供する

登場人物の動作や表情、場面の移り変わりなど視覚的な情報を音声で伝える「音声解説」を提供
する

図3.21 ﻿﻿映像や音声にはキャプション（字幕）をつける

WCAG 2.0

達成基準：［﻿1.2.2﻿｜キャプション（収録済）］［﻿1.2.3 ｜音声解説、又はメディアに対する代替（収録済）］［﻿1.2.4｜キャプション（ライブ）﻿］［﻿1.2.5﻿｜音声解説（収録済）］［﻿1.4.2｜音声の制御﻿］［﻿2.1.2｜キーボードトラップなし﻿］個別対応

動的コンテンツをユーザーが操作できるようにする●

アニメーション、スライドショーなどのコンテンツでは、一時停止、停止、非表示にすることができる

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿2.2.2 ｜一時停止、停止、非表示﻿］

page 33

個別対応

コンテンツの変化がスクリーンリーダーにも分かるようにする
●

●
●
●
●
●
●

●

検索結果の読み込み、ページネーションなどの画面の一部の変更がスクリーンリーダーで読み上げられる
チェックボックス、ラジオボタンのオンオフが読み上げられるタブが操作できる箇所であることがわかって操作できるモーダルを開く場合、押下すると、当該モーダルの内容にフォーカスが移る
モーダルを閉じて戻るという挙動が、読み上げたときに自然と理解できるモーダルを閉じる場合、元のコンテンツの位置にフォーカスが戻る

トースト・スナックバーなど画面にロックしないポップアップも読み上げを行う（「入力内容を送信しました」など）

フォーカスされている場合、ポップアップを自動的に閉じない

図3.22 ﻿﻿モーダルを開くと、キーボード操作のフォーカスはモーダルに移り、モーダルを閉じるとフォーカスは元のコンテンツに戻る

WCAG 2.0

3. ウェブアクセシビリティで達成すべきこと

達成基準：［﻿2.2.1 ｜タイミング調整可能﻿］

page 34

3.4

導入に慎重な検討が必要（

非推奨）

使い方や使う場所によって、アクセシビリティを向上できなかったり、逆にアクセシビリティを損ねる技術や実装方法があります。それぞれの機能や効果をよく理解した上で導入してください。

非推奨

アクセシビリティ・オーバーレイなどのプラグインの利用は非推奨
アクセシビリティ・オーバーレイは、ウェブサイトやウェブシステムにスクリプトを追加すること

で、アクセシブルな状態にする仕組みです。JavaScript で実装されていることがほとんどです。

ただ、これらのプラグインやソフトウェアで実現できると謳われている機能は、OS の支援技術、アプリの支援技術、ブラウザの機能拡張でほぼすべて実現可能です。サイトで実装する必要性は極めて低いものなのです。また、次のような最も対応が必要な課題に対応することができません。
●
●

非推奨

スクリーンリーダーが必要とする HTML の文書構造
代替コンテンツがない画像・動画

文字サイズの変更、読み上げプラグインの利用は非推奨
支援技術が必要なユーザーは、既に OS の支援技術、アプリの支援技術、ブラウザの機能拡張を使っていることが多いため、サイトで支援技術を提供すると過剰対応になってしまいます。また、ユーザーがサイトを閲覧するときに、サイトに支援技術の機能を実装してアクセシビリティを高めても、他のサイトでは使えないので効果は極めて限定的です。どのサイトも同様の支援技術を用いて閲覧できることを目指すべきです。

図3.23 ﻿﻿文字サイズ変更、配色変更、読み上げなどの、Web ページに埋め込むプラグインは非推奨

3. ウェブアクセシビリティで達成すべきこと

page 35

4

ウェブアクセシビリティの実践プロセス

アクセシビリティ対応は、誰かひとりが担当するものではありません。受発注のプロセスの中で、様々な担当者が役割を分担しながら進めることになります。開発した後で最後にチェックすればよい、とならないように、企画・調達段階からアクセシビリティ対応を意識して進めていきましょう。

この章では、よくあるパターンである（1）情報システムにおけるサービス開発と（2）広報活動でのウェブを使った情報発信について、それぞれにおけるアクセシビリティ対応のプロセスと担当者の主な役割を紹介します。

4.1

情報システムにおけるサービス開発
アプリ、ウェブサービスなどを企画・開発する場合には、ウェブアクセシビリティを当初から想定に入れて開発を進める必要があります。ウェブアクセシビリティ対応を行うには、サービスの開発過程でそれぞれ検討
するべきことがあるからです。まずやるべきは、調達するサービスで対応するウェブアクセシビリティの基準を決めることです。政府のシステム調達においては、JIS﻿X﻿8341-3:2016 の AA 準拠を目標に定めるのが標準的な対応です。しかし、2 章でも取り上げたように、この基準は 2016 年策定のもので、スマートフォン対応等を考慮にいれた場合、不十分な基準です。スマートフォンでサービスにアクセスするユーザーが過半数を占める

ことが多くなっていることを考えれば、WCAG﻿2.1 や 2.2 などのより新しい基準にも対応することを検討しておく必要があります。

基本的なプロセス
サービスを作るときの基本的なプロセスと、決めなければならないことの基本原理は、内閣官房情報通信技術（IT）総合戦略室が公開している「サービス設計 12 箇条」や「サービスデザイン実践ガイドブック（β版）」など、既存のガイドブックでも示されているものと同じです。つまり、最初に「Problem﻿Fit（課題の発見）」があり、次に「Solution﻿Fit（解決策の決定）」、さらに「Market﻿Fit（経済合理的か、運用できるか、社会への適合性があるか）」へと、小さい取り組みから大きな取り組みへと、反復的に課題解決を繰り返して、プロジェクトを成長させていくことが求められます。

それでは、省庁や自治体のサービス開発におけるアクセシビリティ対応をプロセスごとに紹介します。

4. ウェブアクセシビリティの実践プロセス

page 36図4.1 ﻿﻿サービス開発のプロセスとウェブアクセシビリティ対応

企画

目が見える人は画面全体を見渡して情報を処理できるのに対して、スクリーンリーダーを使う視覚障害のある人や点字ディスプレイを使う盲ろうの人は情報を逐次的にしか受け取ることができないため、一度に処理できる情報は限定的です。同様に聴覚障害がある人は字幕や手話通訳を追いながら映像を見ると得られる情報は制限されますし、学習障害や知的障害のある人も受け取る情報に差は生じます。このため、次のような適切なインストラクションデザイン、情報設計上の配慮が、より強く求められます。
●
●
●
●
●
●

サービスの全体像をわかりやすく提示する

カテゴリーや機能をできるだけシンプルに絞り込む

そのサービスを使う理由、メリット（利点）が明示されている
具体的な行動の成果が予測できる（予測した結果と合致する）

手順、必要なコスト（時間、場所の移動、費用等）が明快である
失敗やエラーを表すシグナルが明示されている

これらの項目を適切に課題・ソリューションとして収束させるためには、ユーザー像（誰が、いつ、どのような目的で、どのような頻度で、どのように、どの場所やシーンで用いるのか）を明確にしなければなりません。また、これらの課題を解決したサービスは、そのサービスを使う上での障害がない人にとっても、わかりやすく理解
しやすいものになります。ウェブアクセシビリティへの取り組みはそのサービスを使うすべての人にとっての「使いやすさ」を向上させる試みだと考えましょう。

企画段階では、ユーザー像や利用像、解決するべき課題、そしてこれらのスコープがどの程度明確に定まっているのかを検討する必要があります。既存のサービスが既にあるのであれば、ユーザーインタビューや定量
アンケート、アクセス解析結果等を用いて、調達開始前にある程度プロジェクトのフィジビリティを検証することができます。まったく新しいサービスを企画する場合であっても、どのようなユーザーにアプローチをするのか検討する必要があります。手元に十分な材料がないのであれば、調達は「課題の探索と解決案の検証」に絞ったもの、つまり MVP：Minimum﻿Viable﻿Product の定義に限定するのが理想的です。初年度は「企画検証」、
翌年度は「本実装」のように、段階的に調達を実施することを検討してください。

4. ウェブアクセシビリティの実践プロセス

page 37図4.2 ﻿﻿企画段階で考慮すること

また、企画にあたっては、次のような組織的な開発特有の事象にも配慮する必要があります。
●●●

関連して利用されるサービス・アプリがないか

サービスがどのようなデータ、他システムとの連携を必要とするか
法令・規約上の制約事項がないかそれぞれで、サービス企画の障害になりそうな要素があるのであれ

ば、企画段階で大まかな対応方針とマイルストーンを決定しておく必要があります。これらの要素は、ユーザビリティやアクセシビリティに大きく影響します。例えば、同じような目的を果たすために複数のアプリがあると、特に障害がない人であっても「どのサービスが最新で、何を使えば十分なのか」を利用者は十分に判断することができず、混乱が起こり、サポートコストやその後の改修コスト、移行コストを跳ね上げてしまうことになります。

では、「新型コロナワクチン接種証明書アプリ」のように、可及的速やかに提供することを求められているプロジェクトにおいては、この工程を無視できるのでしょうか。むしろその逆で、開発できる機能やインターフェースには限界がありますから、「ユーザー側の期待」と「現実的に提供できるライン」をより厳しく精査する必要があります。緊急性が求められるプロジェクトこそ、しっかりと企画段階での検証を行うことが求められるのです。

図4.3 ﻿﻿新型コロナワクチン接種証明書

アプリ

4. ウェブアクセシビリティの実践プロセス

page 38調達

サービス（システム）の開発スコープが定まったら、いよいよ調達です。調達においては、調達仕様書に記載するべきポイントは以下の通りです。
●

●

●

●

システム要求事項として、明確にユーザビリティ及びアクセシビリティに関連した機能要件・非機能要件を盛り込む業務仕様に、ユーザー像・利用像の明確化計画、解決策の導出計画、各フェーズでのテスト計画・実施を盛り込む

人員計画に、適切な人材（デザイナー、ウェブアクセシビリティの専門家）をアサインし、実効性の高いチー
ム体制を構築するよう求める

プロトタイピングツール、検証ツールを用意する必要がある場合、どのような機能要件を満たすツールを用いるべきか明示する

具体的な記載内容は「調達仕様書への記載」で詳しく解説します。

設計・実装

まずは「企画」でも述べたように「ユーザー像や利用像、解決するべき課題、そしてこれらのスコープ」を明確化すべきです。その上で、一般的には、設計・実装は次のような工程を経て開発されます。
1. アイディエーション（解決案の提示）
2. ワイヤーフレームの作成

3. ワイヤーフレームを用いたユーザビリティとアクセシビリティの検証

4. 詳細デザインの作成、詳細仕様の検討（デザイン上の UI コンポーネントの作成、ガイドライン化）
5. 静的な UI プロトタイプの実装

6. プロトタイプを用いたアクセシビリティテスト
7. テストを受けての仕様改修
8. 本実装9. 結合テストと並行したアクセシビリティの試験

テスト

スクリーンリーダー等を用いた最終的なテストは結合テストの段階にならなければできませんが、その時点で「初めてテストする」ことは絶対に避けなければなりません。モーダルウィンドウやポップアップメニュー等のアクセシビリティ対応は時間がかかりますし、デザインやコンテンツ構成を再検討しなければならなくなることもあります。一般的に、最終的なウェブアクセシビリティ試験には 1 ヶ月程度かかりますので、結合テス
トが始まってからのテストでは公開に間に合いません。テストは段階的に実施すべきです。では具体的に、どのように進めればよいでしょうか。

例えば設計・実装の初期段階でワイヤーフレームを作成しているタイミングでは、HTML 等が存在しないため、スクリーンリーダー等を用いて「実際に使えそうか」をテストすることはできません。ですが、ワイヤーフ
レームを用いて、この段階でテストや洗い出しの検討をしておくべきことがあります。

4. ウェブアクセシビリティの実践プロセス

page 39

●

●
●

●

全体の構成の明快さなど、インストラクションデザイン、情報設計上の配慮が十分できているか（企画の項目を参照）

情報の配置が、HTML 等で実装していく上で適切にマークアップできるデザインとなっているか

コントラスト比、文字サイズ等、ワイヤーフレームや UI プロトタイプの段階で検討できることが達成されているか
モーダル、ポップアップメニュー、カルーセル、ハンバーガーメニュー等の実装上配慮が必要な要素の洗い出しができているか

これらの要素は多面的な検討が必要になることも多く、ワイヤーフレームの次にあがってくる詳細なデザイ

ン（配色が終わり、各画面の差分や細かいパーツのデザインが仕上がった段階）でのテスト、さらに実際に簡易に操作できるプロトタイプを使ってのテストを繰り返す必要があります。

ワイヤーフレームやデザインの段階ではデザイナーが主体になって検討する必要がありますが、難しい場合

は専門家に相談するとなおよいです。

図4.4 ﻿﻿段階的にテストを繰り返す

サイトやサービスが精緻化されていく過程（ウェブサービスでは HTML を組み上げてみるなど）では、実際にブラウザやアプリで確認できる静的なプロトタイプを作ることを推奨します。具体的に操作を試して使用感を確認できますし、スクリーンリーダーを用いて読み上げ・操作をテストすることができます。

よくある誤解として「UI コンポーネントが適切にマークアップできていれば、アクセシビリティは満たせる」というものがありますが、UI コンポーネントを組み合わせたときに起きる問題もたくさんあるため、UI コン

ポーネントだけテストしても不十分です（もちろん、しないよりはしたほうが良いのは言うまでもありません）。静的なプロトタイプが用意できる場合、次のような項目の検証を行います。
●●●

4. ウェブアクセシビリティの実践プロセス

機械チェックの実施

全体の構造が、逐次読み上げ・操作をスクリーンリーダーで行った際に理解しやすいものになっているか
スクリーンリーダーで操作不能になる箇所の洗い出しと対応方針の確定

page 40

図4.5 ﻿﻿ブラウザやアプリで確認できるプロトタイプで検証する

データが取得・更新できる動的なプロトタイプや本実装されたシステムができてきたら、正式なウェブアク

セシビリティの試験を実施します。試験と改修対応には、一般的に 1 ヶ月程度の時間が必要になります（事業者の習熟度に応じて変わります）。試験の具体的な実施方法は、JIS﻿X﻿8341-3:2016﻿の「附属書﻿JB）『試験方法』
﻿」やWAIC が公開している「JIS X 8341-3:2016 試験実施ガイドライン」（参考文献 1）などを参照して実施します。

調達仕様書への記載
情報システムやウェブサイトのウェブアクセシビリティを一定水準に保つために、調達時にウェブアクセシ

ビリティの基準・試験方法・結果の記載方法を定めて示すことで、受託事業者が作業の把握と求められる水準を理解しやすくなります。

ここでは、JIS X 8341-3:2016 を使った調達仕様書への記載方法について説明します。

適合レベルと対応度

特別な要件がない限り、次のような内容にしてください。このように記載することで、試験方法・試験結果・

実際のウェブアクセシビリティの状態がブレなくなります。

適合レベル及び対応度

JIS X 8341-3:2016 のレベル AA に準拠すること。

本仕様書における「準拠」という表記は、情報通信アクセス協議会ウェブアクセシビリティ基盤委員

会「ウェブコンテンツの﻿JIS﻿X﻿8341-3:2016﻿対応度表記ガイドライン﻿2016 年 3 月版」で定められた表記による。

さらに、可能であれば適合レベル AAA の以下 4 つの達成基準や、WCAG﻿2.1 の達成基準も目指せると良いでしょう。スマートフォン等の現在よく使われているデバイスを考慮した達成基準が追加されているためです。
●●●●

4. ウェブアクセシビリティの実践プロセス

WCAG 2.0

2.1.3 ｜キーボード（例外なし）の達成基準

WCAG 2.0

2.4.8 ｜現在位置の達成基準

WCAG 2.0
WCAG 2.0

2.3.2 ｜ 3 回のせん（閃）光の達成基準

3.2.5 ｜要求による状況の変化の達成基準

page 41

なお、特別な要件があって変更が必要な場合は、WAIC が公開している JIS X 8341-3:2016 対応発注ガイドラ

インを参照して、仕様の抜け漏れがないようにしてください。

納品物の規定JIS﻿X﻿8341-3:2016 を使う場合、以下 3 つの資料を作成して納品してもらうことで、行政官・受託事業者・ユー

ザーそれぞれがウェブアクセシビリティの状態を同じ基準で把握できます。
●●●

ウェブアクセシビリティ方針
実装チェックリスト

ウェブアクセシビリティ検証結果

それぞれ解説します。

ウェブアクセシビリティ方針

JIS﻿X﻿8341-3:2016 では、ウェブアクセシビリティ方針を定めることを推奨しています。ウェブアクセシビリ

ティ方針には最低限必要な項目として「対応範囲」と「適合レベル」の 2 つの項目がありますが、この 2 つを決めることでアクセシビリティにおける難易度と試験の作業量が決まります。

また、ウェブアクセシビリティ方針は公開することで情報システムやウェブサービスを使う利用者からもウェブアクセシビリティの状態がわかります。

なお、ウェブアクセシビリティ方針は、可能な限り企画や開発を行う前に作成してください。

実装チェックリスト「ウェブアクセシビリティの試験を行う」の中で説明したリストです。実装チェックリストは公開しなくてよい中間資料ですが、納品物として納めてもらうか、検証結果を作成する前に発注者が確認することで試験結果の具体的な内容を把握することができます。

ウェブアクセシビリティ検証結果

ウェブアクセシビリティ検証結果は、ウェブアクセシビリティ方針と同様に公開を推奨されています。WAIC

が公開している対応度表記ガイドラインに則って書くことで、基準に法って試験がされていることが第三者にもわかるようになります。

なお、ここで大事なことは、試験を行った結果、満たせていない達成基準がある場合もその結果を率直に書くことです。

情報システムやウェブサイトのウェブアクセシビリティは、コンテンツや機能が増えれば増えるだけ達成基準を満たすことが難しくなります。また、情報システムもウェブサイトも常に更新し続けるものなので、試験結果が悪くなる場合もあります。現状を隠さず公開し、改修する計画を立てましょう。試験と改善を繰り返すことでウェブアクセシビリティのレベルを向上させることができます。

4. ウェブアクセシビリティの実践プロセス

page 42

納品物を作成するために必要な知識とスキル

WAIC が公開しているガイドラインを使って JIS﻿X﻿8341-3:2016 に則ったウェブアクセシビリティの試験を行

うには、特別な資格や免許は必要ありません。しかし、一定の知識は必要になります。試験直前に準備をするのではなく、予め準備することを強くお勧めします。
必要な知識とスキルは以下の通りです。
●●●●

JIS X 8341-3:2016 の理解

WCAG 2.0 の解説書と達成方法の理解

HTML、CSS、JavaScript の仕様の理解

スクリーンリーダー、拡大機能などの支援技術の理解と操作

加えて、以下の知識とスキルがあると、円滑にデザインや開発を進められるでしょう。
●●

ウェブページやサイトの実装経験

JavaScript のライブラリとフレームワークの理解

なお、WCAG﻿2.0 のすべての達成基準と達成方法を暗記するほど理解する必要はありませんが、達成方法を調べる方法と、試験で頻出する達成方法がすぐ思い浮かぶようになると、試験を効率良く進めることができます。

実装時の配慮とテスト
セマンティックな HTML にすることが大切

見出しやリストなど、HTML 語彙を適切に設計・設定しましょう。怠ると拾い読み、読み飛ばしなどができなくなったり、キーボードやスイッチコントロールの操作に支障をきたします。
●●

4. ウェブアクセシビリティの実践プロセス

だめな例：すべて div 要素で実装されているだめな例：セクションごとの見出しが適切に設定されていない。Google Chrome の拡張機能であるHeadingsMap によるアウトラインのチェックなどを行いましょう

page 43図4.6 ﻿﻿Google﻿Chrome の拡張機能の HeadingsMap を使ったアウトラインの確認

以下の実装は、何も対応をしないと引っかかるポイントです。必ずチェックしましょう。
●
●

●

●
●

アイコンは実装方法に関わらず代替テキストを設定できるようにしましょう

スクリプトでページを切り替える場合はスクリーンリーダーにも切り替わったことが伝わるようにしましょう

モーダル、ダイアログ、アコーディオン開閉、ハンバーガーメニューはキーボードでも操作できるようにした上で、スクリーンリーダーに UI の動作と状態が伝わるようにしましょう
動的な UI を使うときは、フォーカス位置の調整も必ず行いましょう

視覚的に隠している要素はスクリーンリーダーからも読み上げられないようにしましょう

機械チェックをしてみる

HTML を使ったウェブページやテンプレートがひととおり書けてきたら、機械的なチェックをしてみましょう。アクセシビリティチェックはページ単位で行うこととされていますが、コンポーネントベースの設計を行っている場合はコンポーネント単位でアクセシビリティを保証し、最終的にページ単位で保証するプロセスにな
ります。
●
●

Chrome Lighthouseaxe DevTools - Web Accessibility Testing

スマートフォンのアプリについては OS ベンダーがテストツールを提供しています。ウェブとアプリが併用されるシステムを開発する場合などに使うと有用です。
●●

4. ウェブアクセシビリティの実践プロセス

Accessibility Programming Guide for OS X: Testing for Accessibility on OS X

ユーザー補助検証ツールのスタートガイド - Android のユーザー補助機能 ヘルプ

page 44なお、最新のウェブテクノロジーへの対応、作業効率、レスポンシブウェブデザインの試験等の観点から、デ

ジタル庁ウェブアクセシビリティチームでは目視確認を中心に複数のツールを併用してチェックしています。

パソコンで読み上げ確認をしてみる

実際に読み上げ確認をしましょう。機械的チェックをして 100 点でも、モーダルウィンドウの開閉やコンテンツの入替、代替テキストの設定などは手動で確認する必要があります。主なスクリーンリーダーは以下の通りです。Mac をお使いの場合は VoiceOver などを使ってみることもできますが、NVDA 等に比べ機能が貧弱です。これらのスクリーンリーダーの中で、多くのユーザーに利用されているのは PC-Talker と NVDA です。
●●●

NVDA 日本語版
PC-Talker

NetReader Neo（PC-Talker に最適化されたブラウザ）

PC-Talker には、開発者向けのベータ版が提供されています。他に、アメリカで開発されているスクリーン

リーダーとして、JAWS があります。
●●

JAWS 2021 日本語版
JAWS（本家）

スマートフォンでの読み上げ確認

基本的には PC と同じ項目を確認しますが、操作方法が異なります。freee 株式会社が公開している、freee ア

クセシビリティ・ガイドラインには、操作方法も非常にわかりやすくまとめられています。

デジタル庁で想定しているスマートフォン向けのスクリーンリーダー環境は以下の通りです。
●
●

4.2

VoiceOver（iOS）

Talkback（Android）

広報活動でのウェブを使った情報発信
ホームページでの広報やプレスリリースなどで情報を発信する際にも、発信するコンテンツが適切に多様なユーザーに届けられるものになるよう配慮を行う必要があります。昨今の広報では、動画や SNS への投稿など、
多様な表現媒体・チャンネルを用いて広報発信を行うことが求められています。ウェブアクセシビリティ対応
を広報発信プロセスに適切に組み込んでおかないと、対応が煩雑になってしまったり、適切なクオリティを担保できず、政府・行政機関の情報発信に対する信頼性の低下を招くことになります。特に、災害等の生命・財産の危機に係る情報発信は、いつどんなときに起こるかわかりません。常日頃から適切な情報発信ができるよう、手話通訳や字幕作成等の外部の専門家の支援を受ける体制を整えておく必要があります。

4. ウェブアクセシビリティの実践プロセス

page 45基本的なプロセス
広報などで発信するときの基本的なプロセスとウェブアクセシビリティ対応は次の通りです。

原稿、発信手段のチェック

原稿を確認し、ウェブアクセシビリティ上の課題がありそうなポイントを確認したら、必要な対応と工数を見積ります。具体的には、以下の項目を確認します。
●
●
●
●
●

代替テキストの作成が必要になるイラスト、図表の洗い出し
イラスト、図表が複雑すぎるものになっていないか

PDF、スライド等の資料が適切なフォーマットになっているか

動画配信を予定している場合、字幕や手話通訳をつけることができるか
SNS で発信する場合、画像にどのような代替テキストを付与するか

細かい大量の文章が入った資料が原稿に含まれている場合は、まずは本文やテーブル等に組み直すことから検討しましょう。画像の代替テキストは 80 字程度を上限にするのが適切で、それ以上になると説明が困難になるためです。

原稿の修正、図表等の最適化、代替テキストの付与
●

●
●

●
●

複雑な図表が含まれる場合は、なるべくシンプルな表現に作図し直し、本文で書き改める形で対応できないか原課と調整を行います
PDF がスキャンされて画像化されたものになっている場合、元のデジタル資料をできる限り入手します

PDF に含まれるコンテンツの見出し、段落等が、適切にマークアップされているようにファイルを修正します
スライド資料の場合、適切な順序で読み上げられるようにテキストの読み上げ順序を調整します
PDF・スライド資料ともに、図表・画像が含まれる場合は代替テキストを付与します

具体的な代替テキストの記載例は、「3.2 基本的に達成すべきこと」を参照してください。

動画配信、ライブ配信等を行う場合

動画配信プラットフォームや動画編集ソフトによっては、音声認識技術を用いた字幕書き起こしと編集ができます。より万全を期すのであれば以下の対応をするとなおよいです。
●●

書き起こしを字幕として提供する
手話通訳を手配する

情報を伝達するという意味では、書き起こした文章を、動画が掲載されているページに併置する対応が現実的な場合もあります。この場合は時差が発生するため、書き起こし文が後日掲載されることをページ上に明示する必要があります。

4. ウェブアクセシビリティの実践プロセス

page 46

ライブ配信の場合は、音声認識技術を用いた字幕の書き起こしの誤記を、その場でリアルタイムで修正していくことができるサービスを採用することが増えています。手話通訳がわかりやすい人もいれば、書き起こしがわかりやすい人もいます。できるだけ多様な情報伝達手段を用意することが好ましいといえるでしょう。

図4.7 ﻿﻿広報活動での情報発信プロセスとウェブアクセシビリティ対応

広報、プレスリリースなどで情報を発信するときの原則
以下の項目の詳細は「3.2﻿基本的に達成すべきこと」「3.3﻿状況に応じて確認すべきこと」に記載している内容を確認してください。
●
●
●
●
●
●
●

ロゴ・写真・イラストなどの画像に、その画像が指し示している情報を代替テキストとして指定する
音声にキャプションを、動画にキャプションと音声解説を追加する

赤字・太字・下線・拡大のみによる一部強調などを用いてはいけない
見出しだけで、セクションやブロックに含まれる情報を表現する
文字と背景の間に十分なコントラスト比を保つ
リンクを適切に表現する

音声・映像コンテンツに代替コンテンツを付与する

情報発信する場合、これらに加えて、次のようなコンテンツへの対応が必要です。

4. ウェブアクセシビリティの実践プロセス

page 47

イラストの修正会議で使われた PowerPoint のスライド資料をウェブサイトに掲載してほしいという場合がよくあります。

しかし、会議で使う資料はスライドの中に必要な情報を網羅して書かれている場合が多く、そのままウェブサ
イトに載せるには情報が多すぎて何を読み取ればよいかわからなくなります。そのため、スライド資料で何を伝えるかを整理した上で、資料の図を簡略化したり分割する必要があります。

図4.8 ﻿﻿スライド資料の内容はウェブサイト用に簡略化・分割する

PDF の構造化

ウェブページではなく PDF を使って情報発信したいという場合もあります。その場合は、HTML と同じように様々な利用方法で利用できるアクセシビリティの高い PDF を作る必要があります。
●
●
●
●
●

見出し、リスト、外部リンクなどの情報を追加できるタグを追加する
画像に代替テキストを付与する

文書と画像の読み上げ順が正しくなるよう画像にアンカーを追加する
目次から該当文書に移動するリンクを追加する
言語設定、文書名などのプロパティを設定する

アクセシビリティの高い PDF を作る方法はいくつかあります。そして、作成した PDF を検証するには Acrobat﻿

Pro を使います。詳しくは以下のページを参照してください。
●

Microsoft Word / Microsoft PowerPoint●●

Adobe Acrobat Pro●

4. ウェブアクセシビリティの実践プロセス

アクセシビリティの高い PDF ファイルを作成する
アクセシビリティ対応の PDF の作成および検証

page 48

●

Adobe InDesign●

アクセシビリティに対応した PDF の作成

なお、PDF のアクセシビリティを上げるのはとても難しくノウハウも少ないため、可能な限り HTML を使い、ウェブページとして情報発信するよう心がけてください。

代替テキストの付与

写真、イラストなど画像を使う

場合は画像の代替となる代替テキ
ストを付与してください。ウェブ

ページやブログはもちろんですが、Twitter、Facebook、Instagram な
どの SNS でも画像に代替テキス
トを付与できます。

図4.9 ﻿﻿Twitter の代替テキスト機能

4. ウェブアクセシビリティの実践プロセス

page 49

5

こんな時は

5.1

よくある質問Q
A

﻿スクリーンリーダーの読み間違いに対応する必要はありますか。
特別な対応をする必要はありません。スクリーンリーダーは、一文字ずつ文字を確認する機能がありますし、読み間違いには一定のパターンがあるので前後の文脈から推測が可能です。ただし政務三役の名前のように、人名等を正確に伝えたい場合は、人名にそのままカッコ書きを続ける形式で、よみがなを補足することができます。

QA﻿

JIS X 8341-3:2016の適合レベル AAA に準拠する必要はありますか。
WCAG﻿2.0﻿解説書の中でも解説されている通り、コンテンツの中には適合レベル AAA の達成基準をすべて満たすことができないものもあるため、AAA 準拠を目指すことは推奨されていません。また、適合度レベル AAA の達成基準すべてを満たしたとしても AA や A の達成基準を満たせていない場合は、「AA﻿一部準拠」や「A﻿一部準拠」となります。

﻿

そのため、まずは適合レベル AA に準拠することを目標にして、可能であれば AAA の達成基準を数個追加して試験することを推奨します。

QA﻿JIS X 8341-3:2016の規格票は必要でしょうか。
お手元に用意することを強く推奨します。

JIS﻿X﻿8341-3:2016 は WCAG﻿2.0 と一致基準なので、達成基準に書いている内容は同一です。しかし、用語集や参考文献が書かれている附属書は規格票にしか付属していません。特に「附属書 JA（参考）ウェブアクセシビリティの確保・維持・向上のプロセスに関する推奨事項」「附属書﻿JB（参考）試験方法」は JIS を使った試験には必須の書類です。

5. こんな時はpage 50

QA

﻿

シングルページアプリケーション（SPA）の開発で気をつけることはありますか。
「シングルページアプリケーション（SPA）」は、ページ内のコンテンツを動的に更新してページの切り替えを表現する実装方法です。SPA を使う場合は「WAI-ARIA」という技術仕様を元に実装し、ペー

ジ全体やページの一部の切り替えなどの変化をスクリーンリーダーが認識できるようにしてください。
これは、スクリーンリーダーはウェブページが切り替わるタイミングで、ページの読み上げを先頭から読み上げる仕様になっているためです。WAI-ARIA は W3C で策定している技術仕様で、MDN﻿Web﻿
Docs に詳細な解説が書かれています。
●

Q
A

﻿

WAI-ARIA の基本 - ウェブ開発を学ぶ｜ MDN

見た目は問題ないのにコントラスト比が低い色の組み合わせがあります。
どうしたらよいでしょうか。
「オレンジ背景に白文字」や「青背景に白文字」は見た目の印象と異なって、コントラスト比が低く出る場合があります。この場合はコントラスト比の数字を優先して配色を調整することで、コントラスト比が基準値以上になるようにしてください。なお、「コントラスト比」を算出する計算アルゴリズ

ムでは、一部の組み合わせでコントラスト比が低く算出されることが認識されていて、WCAG の次のバージョンである WCAG3.0 では計算アルゴリズムが変更される予定です。

QA﻿

ボタンの UI でコントラスト比が低いことが指摘されましたが、サイトのブランドカラーなので変更できません。どうしたらよいでしょうか。
ブランドカラーに文字が重なる UI を使わないようにするか、ブランドカラーの配色方法を調整したり、コントラスト比の高い代替色を用意することでコントラスト比が基準値以上になるようにしてください。文字サイズやウィンドウ幅は、ユーザー側で調整しやすいですが、色の組み合わせはユー
ザーが調整しにくい部分です。そのため、予め色の組み合わせでコントラスト比を保つようにしてく
ださい。

5.2

問い合わせ先デジタル庁ウェブサイトのご意見・ご要望ページからお問合せください。

5. こんな時はpage 51

6

付録

6.1

改訂履歴
2022 年 3 月 11 日﻿
2022 年 12 月 5 日﻿

デジタル庁内向けにガイドブックをアルファ版として公開しました。
ガイドブックをベータ版として一般公開しました。

2022 年 12 月 12 日﻿ ガイドブックを一部改訂しました。
2023 年 1 月 20 日﻿

6.2

ガイドブックを一部改訂しました。

リンク集
ウェブアクセシビリティに関するツールや情報は、多くがインターネットで公開されています。

規格
WCAG
●

Web Content Accessibility Guidelines（WCAG）2.0

●
●

●

●

WCAG 2.0 解説書

WCAG 2.0 達成方法集

Web Content Accessibility Guidelines（WCAG）2.1

●
●

6. 付録

Techniques for WCAG 2.0

Web Content Accessibility Guidelines（WCAG）2.0（日本語訳）●●

Understanding WCAG 2.0

Understanding WCAG 2.1
Techniques for WCAG 2.1

page 52

●Web Content Accessibility Guidelines（WCAG）2.1（日本語訳）●●●

WCAG 2.1 解説書

WCAG 2.1 達成方法集

What's New in WCAG 2.2 Draft | Web Accessibility Initiative（WAI）| W3C

JIS X 8341-3:2016●

JIS X 8341-3:2016 高齢者・障害者等配慮設計指針―情報通信における機器，ソフトウェア及びサービス―第３部：ウェブコンテンツ | 日本規格協会 JSA Group Webdesk

ガイドライン
JIS X 8341-3:2016
●
●
●
●
●

総務省
●
●

ウェブアクセシビリティ基盤委員会 | Web Accessibility Infrastructure Committee (WAIC)
JIS X 8341-3:2016 解説

ウェブアクセシビリティ方針策定ガイドライン

ウェブコンテンツの JIS X 8341-3:2016 対応度表記ガイドライン
JIS X 8341-3:2016 試験実施ガイドライン

みんなの公共サイト運用ガイドライン（2016 年版）
情報アクセシビリティ自己評価様式

UX デザイン・HCD●●●●

人間中心設計専門家とは | 認定制度 | HCD-Net

認定専門家を目指す方 | JES 一般社団法人 日本人間工学会
User Experience Design-Japan Ergonomics Society-Evaluation method of UX “The User Experience Honeycomb” | blog / bookslope

スクリーンリーダー
Windows●

PC-Talker

●

●

NVDA

●

●

6. 付録

ベータサイトNVDA 日本語版

ナレーター

page 53

Mac●

VoiceOver●

VoiceOver（注意：Mac と iOS の VoiceOver は名前は一緒ですが機能が異なります）●

TalkBack

iOS（iPhone）
Android

チェックツール●

axe-core（axe-core は、Deque Systems が開発したアクセシビリティチェックのエンジンです。様々な製品に使われています。）
●
●
●

●
●
●

Lighthouseaxe-dev

PowerCMS X

WAVE
WAIV

miChecker

ブラウザの機能拡張●●●

HTML5Outliner

Alt & Meta viewer
HeadingsMap

コントラストチェッカー●●

Contrast（Mac）

Color Contrast Checker（Windows/Mac）

色覚シミュレーション●

Sim Daltonism（Mac）

オーサリングツール
Microsoft Word / Microsoft PowerPoint●

アクセシビリティの高い PDF ファイルを作成する●

アクセシビリティ対応の PDF の作成および検証●

アクセシビリティに対応した PDF の作成

Adobe Acrobat Pro
Adobe InDesign

6. 付録

page 546.3

参考文献
1. 情報通信アクセス協議会ウェブアクセシビリティ基盤委員会（WAIC）「JIS X 8341-3:2016 試験実施ガイ
ドライン」https://waic.jp/docs/jis2016/test-guidelines/202012/

2. Accessibility: https://www.w3.org/standards/webdesign/accessibility
3. 厚労省「平成 28 年度生活のしづらさ調査」結果概要より

6. 付録

page 55