資料４－２　X8341-3技術解説（ワーキング・ドラフト）

資料４－２

X8341-3技術解説（ワーキング・ドラフト）

X 8341-3：2004 高齢者・障害者等配慮設計指針－情報通信における機器，ソフトウェア及びサービス－第３部：ウェブコンテンツ技術解説 Working Draft 2.11
この技術解説は作成中のものであり、5月末日まで改変される可能性があります。

＜作成＞日本規格協会情報技術標準化研究センター　アクセシビリティ国際標準化に関する調査研究開発委員会（ＷＧ2）

目次
1. はじめに
2. 目的
3. 記述方針
4. 技術解説の使い方
5. JIS X8341-3 第5章 "開発・制作に関する個別要件” に関する解説
5.1 規格や仕様への準拠
5.1.a 規格・仕様・文法への準拠
5.1.b アクセシブルなオブジェクトの使用
5.2 構造及び表示スタイル
5.2.a 文書構造のマークアップ
5.2.b　構造と表示スタイルの分離
5.2.c データテーブルの適切なマークアップ
5.2.d レイアウトテーブルの禁止
5.2.e　識別可能なページタイトル
5.2.f フレームの多様の禁止
5.2.g 階層構造とサイトマップの提示
5.3 操作及び入力
5.3 a 非デバイス依存
5.3 b 入力欄のわかりやすさ
5.3 c 入力時間制限
5.3 d 制限時間の延長・解除
5.3 e ページの自動更新、移動の禁止
5.3 f 一貫性のある基本操作部の提供
5.3 g リンクの識別と操作
5.3 h ナビゲーションスキップ
5.3 i 誤操作の復帰
5.4 非テキスト情報
5.4 a 画像の代替テキスト
5.4 b ハイパリンク画像の代替テキスト
5.4 c 音声の代替
5.4 d 動画の字幕と状況解説
5.4 e　オブジェクトの代替形式
5.5 色及び形
5.5 a 色のみに依存する情報提示
5.5 b 形・位置のみに依存する情報提示
5.5.c 背景色と前景色のコントラストと配色
5.6 文字
5.6.a 文字サイズの変更
5.6.b フォントの読みやすさ
5.6.c フォント色
5.7 音
5.7.a 音の自動再生の禁止
5.7.b 利用者による音量調整
5.8 速度
5.8 a 変化する画像・テキスト
5.8 b 早い周期の点滅禁止
5.9 言語
5.9.a 自然言語の指定
5.9.b 外国語の多用禁止
5.9 c省略語、専門用語、流行語、俗語の多用禁止
5.9 d　読みの難しいと考えられる言葉の多用禁止
5.9 e　単語途中のホワイトスペースの禁止
5.9.f 図記号とイラストレーション
6. 情報アクセシビリティの確保・向上に関する全般的要件
6.1企画・制作に関する要件（JIS X 8341-3:6.1）
6.2保守及び運用に関する要件（JIS X 8341-3:6.2）
6.3検証に関する要件（JIS X 8341-3:6.3） 89
6.4フィードバックに関する要件（JIS X 8341-3:6.4）
6.5サポートに関する要件（JIS X 8341-3:6.5）
7. 要素別索引
7.1 メタ要素
7.2 基本構造要素
7.3 リスト
7.4 テキスト構造マークアップ
7.5 テキスト修飾マークアップ
7.6 リンク
7.7 フォーム
7.8 テーブル
7.9 フレーム
7.10 画像とイメージマップ
7.11 オブジェクト
7.12 スタイルシート
Appendix 1 アクセシブルなMacromedia Flash を作成するためのテクニック
Appendix 2 アクセシブルな Adobe PDF を作成するためのテクニック
（参考資料：html4.01 elements list）

1. はじめに
　「高齢者・障害者等配慮設計指針－情報通信における機器，ソフトウェア及びサービス－第３部：ウェブコンテンツ - JIS X8341-3:2004」は2004年6月に公示、出版されたウェブコンテンツのアクセシビリティガイドラインである。このJISは、ウェブコンテンツをどのように制作すればよりアクセシブルなものにすることができるかをウェブの開発・制作者の立場でまとめたもので、多くの例示によってその具体的な実現方法の例を示し、使いやすいガイドラインを目指して作成されたものである。しかし、JISは頻繁に改定されるべきでないとの考え方から、規定はできるだけ技術に依存しないように記述されている。また、規格発効後、日本規格協会を通じていくつかの質問や意見が寄せられた。それらの疑問に答えることもこの技術解説の目的のひとつである。そこで、本体規格を技術に即した視点からよりわかりやすくし、JIS X8341-3:2004の正しい理解を促進するために技術解説を策定することとなった。この文書は、日本規格協会情報技術標準化研究センター（INSTAC）に平成16年度に設置された、情報アクセシビリティの国際標準化委員会ウェブアクセシビリティ国際規格調査研究部会（WG2）において作成された。
　なお、この技術解説はJIS X8341-3:2004を補足するものであり、規格ではないことに注意されたい。

2. 目的
本体規格を技術に即した視点からよりわかりやすくし、JIS X8341-3:2004の正しい理解を促進するために
⇒この文章少し直す。
この技術解説は、JIS X8341-3:2004 の第5章及び第6章を対象に、その内容の技術的背景を明らかにする。その実現方法の例を技術に即して具体的に示すことを目的としている。

3. 記述方針
次の点を明確にして記述した。
a) ハイパテキストマーク付け言語(HTML、XHTML)、及び段階的スタイルシート(CSS)のバージョンを明確にして、ウェブコンテンツの製作現場でJIS X8341-3:2004を用いようとしたときに、どのようなテクニックが利用可能かを示す。
b) 規格票を理解するうえで誤解なく、正しく理解できるようにするための情報を提供する。
c) 可能な場合には、チェック方法を示す。
d) 可能な限り具体的な例示をおこなう。
なお、この技術解説は規格票を理解し運用するための参考であって、規格ではない。また、本書の各々の技術解説は規格票の示す基準を満たそうとするときに用いることができる技術を例示的に列挙したものであって、それらを用いて開発されたウェブコンテンツがJIS X8341-3:2004に準拠していることを保障するものではない。

4. 技術解説の使い方
　この技術解説では，JIS X-8341-3の第5章，第6章の要件を「背景と問題点」「関連する要素」「関連項目」「技術解説」「ソリューション」「注意事項」に分けて解説している。
・背景と問題点
その要件に関連して高齢者や障害のある人々がどのような問題に遭遇する可能性があるか，またその背景となる技術について解説する。
・関連する要素、属性及び宣言
HTML，XHTMLの関連する要素、属性宣言で、関連するものを列挙している。
・関連項目
同時に参照して欲しい要件を列挙してある。
・技術解説
用件を理解するための補足的な解説を記述している。JIS本文には書かれていない技術的な背景や数値などを含む。
・ソリューション
この要件を満たすための技術的な方法を示している。この中から一つ，あるいは複数の手法を選択する。
・注意事項
関連する注意事項が記載してある。

また，付録として「用語索引」「要素索引」を用意した。

5. JIS X8341-3 第5章 "開発・制作に関する個別要件” に関する解説
5.1 規格や仕様への準拠
5.1.a 規格・仕様・文法への準拠
ウェブコンテンツは，関連する技術の規格や仕様,および文法に準拠して作成しなければならない。( 対応：JIS X8341-3:5.1 a)

背景と問題点
　一般によく使われているブラウザでは、HTMLなどの文法に厳密に準拠していなくても、文法のエラーを自動的に回避して表示する機能を持っている場合がある。しかし、このような文法解釈の自動的な修正機能はウェブブラウザに依存した機能であり、あらゆる環境で有効である保証はない。音声ブラウザやスクリーンリーダーなどの高齢者障害者支援技術は、これらの問題のあるHTMLを一般的なブラウザと同等に解釈できるとは限らない。また、アクセシビリティチェックツールは文法が正しくないと、判断を誤ってしまう可能性がある。したがって、アクセシビリティの改善を行う前提条件として仕様や文法に正しく則ってコンテンツが作成されている必要があるのである。

関連する要素、属性及び宣言
meta
DOCTYPE宣言
注　DOCTYPE宣言はHTMLの要素ではなく、文書型宣言である。

関連項目

技術解説　HTML、CSSなどのウェブコンテンツを記述するための言語やソースコード、技術は、W3C、ISO、又はJISが定めた規格、あるいは勧告に準拠することを求める。ただし、このガイドラインはW3CのWCAGに準拠することを求めているわけではなく、一般的な文法等の使用に準拠することをもとめている点に注意が必要である。あくまでも、一般的な技術の仕様や文法についていっているのであって、アクセシビリティに関する基準については、X8341-3:2004を用いる。準拠すべき規格、勧告の代表的なものを以下に示す。この中から、利用している技術だけを選択して、準拠しているかどうかを確認すべきである。

* HTML 4.01 Specification
W3C Recommendation （1999年12月24日）
http://www.w3.org/TR/1999/REC-html401-19991224
> JIS TR X0033: ハイパテキストマーク付け言語（HTML）4.0
この標準情報（TR）は，HTML 4.0 Specification W3C Recommendation, revised on 24-Apr-1998を翻訳し，技術的内容を変更することなく作成されたもので、TR X0033:2000に，HTML 4.01Specification W3C Recommendationとの差分が，技術的内容を変更することなく附属書１として追加されている。
* XHTML? 1.0 The Extensible HyperText Markup Language (Second Edition)
A Reformulation of HTML 4 in XML 1.0
W3C Recommendation （2000年1月26日、2002年8月1日に改定）
http://www.w3.org/TR/xhtml1/
* XHTML? 1.1 - Module-based XHTML
W3C Recommendation （2001年5月31日）
http://www.w3.org/TR/2001/REC-xhtml11-20010531
* Modularization of XHTML?
W3C Recommendation （2001年4月10日）
http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410
> JIS TR X0080:2003 XHTML 1.1 ? モジュールに基づくXHTML
この標準情報は、XHTML? 1.1 - Module-based XHTML W3C Recommendation （2001年5月31日）と一致している。
* Cascading Style Sheets, level 2 revision 1
CSS 2.1 Specification
W3C Candidate Recommendation 2004年2月25日
http://www.w3.org/TR/2004/CR-CSS21-20040225
> JIS TR X 0032:2000 段階スタイルシート水準２（CSS2）
この標準情報は、Cascading Style Sheets, level 2 CSS2 Specification W3C Recommendation （1998年5月12日）と一致している。
* Synchronized Multimedia Integration Language (SMIL 2.0) - [Second Edition]　（2005年1月7日）
http://www.w3.org/TR/2005/REC-SMIL2-20050107/
> JIS TR X0093:2003 同期化マルチメディア統合言語（SMIL2.0）
Synchronized Multimedia Integration Language (SMIL 2.0) W3C Recommendation （2001年8月7日）が，この標準情報(TR)と一致している。
* Scalable Vector Graphics (SVG) 1.1 Specification
W3C Recommendation （2003年１月１４日）
http://www.w3.org/TR/2003/REC-SVG11-20030114/

これら以外の規格、勧告、技術を用いる場合にもできる限りそれらの仕様に合致するよう開発するとよい。
　XHTMLなどXMLを基本にした仕様の場合、その文法はDOCTYPE宣言によって示されたDTDで指定されるが、その場合ローカルなDTDを指定することは好ましくない。ウェブブラウザや高齢者障害者支援技術がDTDを正しく解釈する能力を持っているとは限らず、プログラムによって固定的な解釈をおこなう可能性があるからである。したがって、やむをえない事情がある場合を除いて、上記のマーク付け言語などで定義されたDTDをそのまま使うほうが良い。
　本ガイドラインは、必ずしも最新の仕様を用いることを要求してはいない。例えば、段階的スタイルシートに現時点で最新のCSS2.1 を使うことを要求しているわけではない。最新の規格、勧告、または仕様を用いることは好ましいが、それらをウェブブラウザや高齢者障害者支援技術が正しく解釈、処理できない場合には、かえって混乱を招くこともあるからである。
　また、マーク付け言語の仕様において本ガイドラインを用いる場合に、Strict な要素だけを用いるべきか、あるいは Transitional な要素を用いても良いと考えるべきかと迷う場合があるかもしれない。本ガイドラインでは、仕様に準拠することだけを求めていると考えることができるので、StrictでもTransitionalでも許容するというのが原則だ。しかし、一般的にTransitionalな要素の中には、アクセシビリティの観点から見て好ましくない要素が残されており、Strictな要素だけを用いたほうがアクセシブルなページを容易に開発できることが分かっている。したがって、Transitionalを用いる場合にも、Strictを基準として用いて、やむをえない場合だけTransitionalな要素を使うようにするとよい。
　文字コードの指定を正しくおこなうことも重要である。HTML文書でマーク付けされた文字コードの指定と、実際に用いた文字コードが一致しないと、利用者の環境によっては文字化けをおこしてしまう。この問題も、高齢者・障害者だけでなく、広く一般の利用者が混乱する原因となるので、注意が必要である。

ソリューション次の方法を選択して、あるいは組み合わせて用いる。

1) 使用する言語の明確化
制作、開発に当たっては、使用するHTML等のバージョンをあらかじめ決定しておき、それらを用いることを制作担当者、開発担当者に徹底するとともに、正しい文法や仕様で記述できるよう教育する。また、このことがアクセシビリティの確保・向上に役立つことを理解させる。

2) DTDの定義
HTML、XHTML 、XML においては DOCTYPE宣言を用いてDTDを定義する。
例1 HTML4.01 Strict を用いる場合
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
例2 HTML4.01 Transitionalを用いる場合
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
例3 XHTML1.0 Strictを用いる場合
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
この例にないローカルなDTDを用いる場合は、代表的な高齢者障害者支援技術によって利用可能なことを確認する必要がある。

3) 文法の妥当性
DTD宣言の内容にしたがって文法が妥当(valid)であるかどうかを確認する。確認の方法には、文法チェッカーを用いる方法とオーサリングツールに内蔵されたチェッカーを用いる方法とがある。オーサリングツールのチェッカーを用いる場合には、そのチェッカーがチェック可能な言語や仕様を確認しておく必要がある。
例1 W3CのMarkup Validation Service を用いる。
http://validator.w3.org/
例2 W3C CSS 検証サービスを用いる。
http://jigsaw.w3.org/css-validator/
例3 市販のオーサリングツールを用いて文法を点検する。

4) 文字コード
文字コードの宣言と実際に記述した文字コードが一致することを確認する。
⇒JIS X0208:1997 「附属書1（規定）シフト符号化表現」を参照してもいい
例1 言語コードは、meta要素を用いて head 内で次のように定義する。
<meta http-equiv="Content-Type" content="text/html; charset=EUC-jp">
<meta http-equiv="Content-Type" content="text/html; charset=iso-2022-jp">
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

5) 機種依存文字
機種依存文字や携帯電話で用いられる絵文字（携帯端末用コードでよく使われるもの）が用いられていると、音声ブラウザ等で正しく読み上げられないばかりでなく、一般的なウェブブラウザでも正しく表示されないことがある。これらは、アクセシビリティというよりはむしろユーザビリティにおける問題と考えられるが、高齢者などが混乱することが考えられるため、配慮が必要である。機種依存文字は”丸付き文字”、“ローマ数字”、“単位記号”及び“外字”などがある。図1に機種依存しない文字の例を示す。
例1 機種依存しない文字の例(ISO-2022-JP) （ここに機種依存でない文字、JISコード番号のリストを入れる）
注意事項規格、または勧告等にウェブブラウザが対応できていない場合がある。また、一般的なウェブブラウザは対応していても、高齢者障害者支援技術が未対応の場合もある。例えば、XForms 、SVGはアクセシビリティの確保・向上には有効な技術だが、対応が進んでいない。したがって、これらの技術を使う場合には、それがたとえ標準規格や勧告であっても、一般的なウェブブラウザで正しく表示され、代表的な高齢者障害者支援技術を用いて利用可能であることを確認しておく必要がある。

5.1.b アクセシブルなオブジェクトの使用
ウェブコンテンツには、アクセス可能なオブジェクトなどの技術を使うことが望ましい。(対応：JIS X8341-3:5.1 b)

背景と問題点
HTMLやスタイルシート以外に、動画、音声、アニメーションのためのプラグインなど、多様なオブジェクトがウェブコンテンツの一部に用いられつつある。特に、サイトの重要な情報や基本的な操作のためのメニューなどに、非HTMLの技術を用いられていてアクセシブルでないと、そのサイト全体が利用できず致命的な問題となることがある。

関連する要素、属性及び宣言
object applet script noscript embed noembed

関連項目
なし

技術解説
文書構造を視覚的に示すために、書体、サイズ、色、行間、背景色などの表示上の表現は CSS （段階的スタイルシート）で記述する。
HTMLでは文書構造をただしく記述し、スタイルシートが利用できないブラウザや、利用者が意図的にスタイルシートを無効にしたり、利用者独自のスタイルシートを設定したりしている場合でも、文書構造が最低限の内容が正しく伝わり、理解できるようにしておく必要がある。そのためにも、 JIS X8341-3: 5.2 a を守ることが必要になってくる。

ソリューション
次の方法を選択して、あるいは組み合わせて用いる。

1) 見出し要素 <h?> の書式変更にスタイルシートを用いる
見出し要素は、ブラウザによって異なるが、大抵は<h1>が大きい文字で、<h6>に行くにしたがって、小さい文字になっていく。また、少し広めの改行幅で改行される。
しかし、ページの構成上、文字書式（字体・大きさ）や改行幅などを変更したい場合がある。その場合はCSSを利用して書式設定を行うことができる。
例1) すべての見出しを標準の1.5倍の文字の大きさで太文字にする
<style type="text/css">
h1,h2,h3,h4,h5,h6{
font-size:1.5em;
font-weight:bold;
}
</style>

例2) 見出し１を中央ぞろえで表示し、見出し２から６の文字色と背景色をつける。
h1{
font-size:1.5em;
font-weight:bold;
text-align:center;
}
h2,h3,h4,h5,h6{
font-size:1.5em;
font-weight:bold;
color:#ffffff;
background-color:#00ff00;
}

例3) どうしても画像を見出しにしなければいけない場合、余白をゼロにして画像と画像の間に余白ができないようにする。
<style type="text/css">
h1{
font-size:1.5em;
font-weight:bold;
margin-top:0;
margin-bottom:0;
}
</style>
<h1><img src="title.gif" alt="私のホームページ"></h1>
<img src="line.gif" alt="">

2) リスト要素の書式変更にスタイルシートを用いる
リスト要素は、各項目の先頭に点や丸などの記号、または数字をつけて表示される。
しかし、点や丸などの記号を変更したり、数字の始まりを変更したりしたい場合がある。その場合は、CSSを利用して書式設定を行うことができる。
例1) 箇条書きの記号を画像に変更する。
<style type="text/css">
ul.disc{list-style-type:disc;}
ul.circle{list-style-type:circle;}
ul.square{list-style-type:square;}
ul.myface{list-style-image:url(myface.jpg)}
</style>
<ul class="myface">
…
</ul>

例2) 箇条書き全体のインデント（左余白）を半分にする。
ul{
margin-left:0.5em;
padding-left:0.5em;
}

例3) 箇条書きの改行幅や箇条書き記号との間隔などを変更する。
li{
margin-bottom:1em;
line-height:1.5em;
padding-left:2em;
}

例4) 箇条書きの文字書式を変更する（ LI 要素または UL 要素に設定することができる）。
li{
font-size:1.5em;
font-weight:bold;
color:#00ff00;
}

ul{
font-size:1.5em;
font-weight:bold;
color:#00ff00;
}

3) 段落やブロックレベルでの書式変更 (P要素 DIV要素) にスタイルシートを用いる
各段落において、字下げしたり、右寄せをしたりしたい場合がある。その場合は、CSSを利用して書式設定を行うことができる。

例1) 段落(P)を字下げする場合
p{
margin-left:2em;
}

例2）ある特定の範囲を字下げする場合
<div style="margin-left:4pm">
.....
</div>

例3) ある範囲を右寄せする場合
<div style="text-align:right">
.....
</div>

例 4) 字間や行間を調節する場合
<p style="letter-spacing:0.25em;line-height:1.5em;">
…
</p>

4) 文字書式の書式変更にスタイルシートを用いる
段落の中で特定の箇所を強調する場合がある。その場合は、CSSを利用して書式設定を行うことができる。
例1) ある箇所を強調したい場合
<em> … </em>
<strong> … </strong>
<span style="text-decoration: underline;"> … </span>
<span style="font-style:italic;"> … </span>
注意： <span> 要素で文字書式を変更する場合は、まず論理的要素が利用可能かどうかを検証し、どうしても難しい場合に利用する。

例2) ある箇所について論理的強調を視覚的に変化させたい場合
<em style=”color:green”> … </em>
<strong style=”color:red;font-size:2em”> … </strong>

例3) ある範囲を中央そろえにしたい場合
<div style=” text-align:center”>
…
</div>

例4) フォントサイズを調整する
<span style=”font-size:1.5em”> … </span>

例5) 取り消し線を入れる
<del> … </del>
<del style="text-decoration:line-through"> … </del>
<span style="text-decoration:line-through"> … </span>
注意：取り消し線の場合、大抵の音声ブラウザでは、取り消腺があることを知らせないため、通常に書いてあるとおりに読み上げるので、ブラウザが対応するまでは利用しないほうが無難である。

例6) 字間を調節する場合

<span style="letter-spacing:2em">日時</span>：2月14日<br>

集合場所：駅前噴水広場<br>

<span style="letter-spacing:0.5em">目的地</span>：高尾山<br>

<span style=" letter-spacing:0.5em">雨プロ</span>：博物館<br>

<!?字間を-0.3文字分に縮める設定 -->
<h1 style="letter-spacing:-0.3em">ネットサーフィンを始めましょう</h1>

5) JIS X8341-3: 5.2 aを遵守し、文書構造を正しく記述する。
JIS X8341-3: 5.2 aを遵守し、文書構造を正しく記述することで、CSSによって指定している書式や表示スタイルがなくなった場合やユーザーによってCSSが変更された場合でも、最低限の基本的な情報をユーザーに伝えることができるようになっているはずである。

6) CSSによる表示位置の指定を行う場合は、HTMLの記述の順番が理解できる順番で配置するように記述する。
CSSによる表示位置の指定をむやみに多用することは避けるべきである。それは、CSSが有効である場合と無効である場合で表示される順番が異なる可能性があるからである。
もし表示位置の指定をする場合は、CSSが無効になった場合のことを考慮し、HTMLの記述する順番どおりに表示しても、最低限の基本的な情報をユーザーに伝えることができるようになっているようにするべきである。

例 CSSで直接表示位置を指定している場合の表示例
<html>
<head>
<title>
CSSでの位置指定
</title>
</head>
<body>
<style type="text/css">
div.1{
position:absolute;
top:60px;
left:100px;
}
div.2{
position:absolute;
top:78px;
left:100px;
}
div.3{
position:absolute;
top:96px;
left:100px;
}
div.4{
position:absolute;
top:114px;
left:100px;
}
p.ranking{
position:absolute;
top:60px;
left:20px;
}
</style>
<body>
<h1>今週の血液型ランキング</h1>
<p class="ranking">
第一位:<br>
第二位:<br>
第三位:<br>
第四位:<br>
</p>
<div class="2">Ａ型</div>
<div class="3">Ｂ型</div>
<div class="4">ＡＢ型</div>
<div class="1">Ｏ型</div>

</body>
</html>

（画面あり：CSSが適応されている場合と適応されていない場合の表示例）

7) テーブルの見出しTH要素の書式の変更（自動的に太文字になるのを抑制する）
<style type="text/css">
th{
font-weight:normal;
}
</style>

5.2.c データテーブルの適切なマークアップ
表は、わかりやすい表題を明示し、できる限り簡単な構造にして、適切なマーク付けによってその構造を明示しなければならない。(JIS X8341-3: 5.2 c)

背景と問題点
新聞や雑誌などに載っているテレビ番組表やカレンダーのように、行と列の位置関係に情報の意味があるような場合がある。たとえばテレビ番組表の場合は、行と列の位置関係に時間とテレビ局の情報が関連付けられているし、カレンダーの場合は、曜日や第何週目かといった情報が関連付けられている。
このような表のデータは、視覚的に確認する場合非常に便利であるが、音声読み上げで情報を理解しようとすると非常に困難である。音声ブラウザ上から順番に読み上げていくだけだからだ。たとえばカレンダーの場合、曜日を一通り読み上げて、次に１から３０まで読み上げるという状態になり、曜日と日付の対応や、第何週目かといった情報を理解することが困難である。

関連する要素、属性及び宣言
table, hd, th, caption, style, scope, headres, id, summary,

関連項目
5.2 b 構造と表示スタイルの分離(CSS)

技術解説
音声ブラウザの中には「テーブル読み上げモード」があり、位置情報と一緒に読み上げる機能が用意されている。これを活用するためには、あらかじめ行と列の見出しなど、表の構造を明示しておかなければならない。
「テーブル読み上げモード」は、表全体を眺めることはできず、1つの操作では、現在の読み上げ一にあたるセルの中身だけであるため、表の全体の情報を知るためには、表の中のたくさんのセルを上下左右に、まるで迷路のように動き回る必要がある。このとき、セルが結合されていたりすると、利用者が表の中での位置を見失ってしまい、セルからセルへの移動が非常に困難になる場合がある。そのため、表は必要以上にセル結合せず、単純な構造にする。
どうしても、セル結合なので、表の構造が複雑になってしまう場合は、id headers scope などの属性で、セルの関係性を示しておく。
また、その表に対する表題や概要を記述することで、すばやくその表を理解したり、重要度を判断したりする助けとなる。

ソリューション
次の方法を選択して、あるいは組み合わせて用いる。

1) 表の見出しセルには th を利用する
表の見出し、たとえば、テレビ番組表であれば、時間帯やテレビ局名が記述されているセルには、th 要素を利用する。th 要素を利用する。 th 要素を利用すると、字体が太字等に変更されてしまう場合がある。字体を変更したい場合は、CSSを利用する。

2) セル結合が本当に必要かどうか検討する。

3) セルの結合などで、複雑な構造のためth のみでは十分に表の構造を表現できない場合は、 scope headers, id 属性を利用する

4) 表題をつけるには caption 要素を利用する
caption要素で表と表題を構造的に関連付けする。表題は、その表がどんな表であるか明確にわかるようなものにする。

5) 表を理解するうえで必要な概要や構造に関する情報を summary 属性として記述する
summary 属性には、表の理解の助けとなるような情報、たとえば、何を伝えようとしている表なのかといった概要や、表の大きさ、行や列に関する情報などを記述しておくと、表を理解するうえで大きな助けとなる。

5.2.d レイアウトテーブルの禁止
表組みの要素をレイアウトのために使わないことが望ましい。(JIS X8341-3: 5.2 d)

背景と問題点
現在table 要素（表組み）を利用して視覚的な画面※レイアウト※を行っているWebページが多い。これは、※CSS※が無かった時代から、一般的に利用されてきた、視覚的な画面レイアウト手法であった。しかし、表組みで、視覚的な画面レイアウトを行うと、製作者が意図した画面表示の順番と、音声ブラウザが読み上げる順序が異なる場合があるため、音声ブラウザでは、正しく情報を理解できない可能性がある。

関連する要素、属性及び宣言
table, td, th

関連項目
5.2 b 構造と表示スタイルの分離(CSS)

技術解説
レイアウトはCSSを利用することが望ましいが、表を利用して画面レイアウトする場合は、音声ブラウザが読み上げる順番を常に意識して記述していくことが必要である。音声ブラウザは、一般的にHTMLに記述されている順番に読み上げる。そのため表組みの場合は、1行目の左から右へ、2行目の左から右へ、3行目の左から右へ、・・・そして最終行の左から右へと読み上げていく。さらに、このような順番で読み上げても、内容が理解できるようにする必要がある。さらに、セル結合などをさせた表の場合は、無意識のうちに思い込んでいる順序と、まったく異なる場合がある。また、テーブルの構造を表すような要素たとえば th などを利用してしまうと、音声ブラウザなどの支援技術が間違った解釈をしてしまい、ユーザーに正しく情報が伝わらないことがある。

ソリューション
次の方法を選択して、あるいは組み合わせて用いる。

1)表組みによるレイアウトにおける音声ブラウザの読み上げ順番を配慮する
次のいくつかの表は、音声ブラウザがどのような順番で読み上げるかを示したものである。この読み上げ順序を考慮しながら、表組みによるレイアウトを行う。
（異なった表組み例を９パターン掲載）

2) CSSを使ったレイアウト
表組みを利用せずに、CSSを利用して表示位置を調整することもできる。HTMLでは、音声ブラウザの読み上げ順序に配慮した形で記述し、CSSで表示レイアウトを指定する。

5.2.e　識別可能なページタイトル
ページのタイトルには、利用者がページの内容を識別できる名称を付けなければならない。(JIS X8341-3: 5.2 e)

背景と問題点
ページの※タイトル※は、そのページの概要を理解したり、目的のページかどうか判断したりするのに利用されることが多い。またページを保存したり、※ブックマーク※やお気に入りに登録したりする場合に、ページのタイトルがその名前として利用される。このページのタイトルが記述されていなかったり、ページの内容と異なっていたり、あるいは、複数のページにまったく同じタイトルが記述されていると、開いたページが本当に目的のページかどうか、すぐに判断できなかったりする場合がある。また、せっかくブックマークに保存して後から参照しようとしても、タイトルがわかりやすくないと、ブックマークそのものが、見つけ出せなくなってしまう場合がある。

関連する要素、属性及び宣言
title

関連項目
なし

技術解説
多くの音声ブラウザなどは、最初にページのタイトルを読み上げてから、内容を読み上げる。もし、ページのタイトルが適切でないときや、記述されていない場合、そのページを上から下まで全部読み上げてみないと、そのページが目的のページかどうかの判断ができないことがある。音声ブラウザに限らず、同じようなデザインの場合、同様の問題が発生する可能性がある。このような問題を避けるために、ページのタイトルにそのページの概要がわかるような固有のタイトルを記述する。
さらに、目的のページを探すために、ページを進めたり、戻ったりしている場合、それぞれに内容を表す固有のタイトルが記述されていることで、ページを移動している範囲や現在地が確認しやすくなる。

ソリューション
次の方法を選択して、あるいは組み合わせて用いる。

1) サイトを設計するときにタイトルの付け方の指針を決める。
ホームページやサイトを設計するときに、あらかじめ同一タイトルが存在しないようタイトルの付け方を決める。

2) 利用者が経験する可能性のあるページのパス（流れ）の中で同一タイトルがないか確認する。
音声ブラウザを利用者はページが移動したかどうかを確認するときに最初に確認するのが、ページタイトルである。そのため同一のタイトルであるとページの移動が確認できない場合がある。最低限、利用者が経験する可能性のあるページのパス（流れ）の中で同一タイトルがないか確認する必要がある。

3) ページの内容を最も端的に表す単語やフレーズを利用する。
単にサイト名等だけでなく、ページの内容を端的に表す単語やフレーズを含めることで、利用者の必要かどうかの判断を助けることになる。

4)長い文字列にならないようにする。
これはブラウザによって表示しきれない部分は省略されることを考慮するためである。また、音声でタイトル情報を聞く場合、あまり長いとタイトルを聞くだけで時間がかかってしまう場合がある。

5) サイト名など同じ文字列を入れる必要がある場合は、タイトル文字列の最後に入れるようにする。
小さいが画面でタイトルの後半が省略されてしまう場合、先頭の同じ文字列（サイト名）などしか見えず、結果的にユーザーにとっては同じタイトルしか見えないという事態を避けることができる。また、音声ブラウザを利用する場合も、最初の段階でタイトルの違いがわかるため、効率よく情報を得ることができる。

例)
目次 ? HTML4.01の基礎講座
P要素 - HTML4.01の基礎講座
BODY要素 - HTML4.01の基礎講座
DIV要素 - HTML4.01の基礎講座

4) サイト名など必ず同じ文字列をタイトルの最初に入れる場合は、なるべく最初の文字列は、省略するなど長くならないようにし、その文字列の後は必ず固有のタイトルを付ける。
例)
HTML4.01の基礎講座 ? 目次
HTMLの基礎 - P要素
HTMLの基礎 - BODY要素
HTMLの基礎 - DIV要素

5) どうしても同じタイトルになってしまう場合は、数字などを入れるなど、ページの推移がわかるようにする。
例1)
（同じタイトルでも、違いをもたせた例）
ウェブアクセシビリティ（指針）
ウェブアクセシビリティ（解説）
ウェブアクセシビリティ（事例）

例2)
HTML4.01の基礎講座 - 目次1
HTML4.01の基礎講座 - 目次2
HTML4.01の基礎講座 - 目次3

例2)
HTML4.01の基礎講座 - 目次1/5
HTML4.01の基礎講座 - 目次2/5
HTML4.01の基礎講座 - 目次3/5

5.2.f フレームの多様の禁止
フレームは、必要以上に用いないことが望ましい。使用するときは、各フレームの役割が明確になるように配慮しなければならない。(JIS X8341-3: 5.2 f)

背景と問題点
フレームは適切な場面で利用すれば、有効な表現手段となる。ただし、音声ブラウザでは、それぞれのフレームを切り替えないと全体が確認できない場合もあるため注意が必要である。また、フレーム切り替えに、キーボード操作をしている場合、切り替え操作が煩雑になる可能性がある。

関連する要素、属性及び宣言
frameset, frame, noframes, iframe, link

関連項目
なし

技術解説
音声ブラウザによっては、1度に確認できる範囲が１つのフレームに限られ、キーボード操作により、次のフレームまたは、前のフレームといった具合にその都度切り替えながらでないと、全体が確認できない場合がある。そのため、複雑なフレーム構成になっていると、ページ構成が理解できない場合がある。さらに、支援技術によってはフレームに対応していない場合もある。
また、リンクをクリックしたときに、別のフレームに内容が表示されている場合、音声ブラウザによっては、別のフレームに新しいページが開いたことがわからないため、目的の情報が獲られない場合や、次の操作ができなくなってしまう場合も考えられる。
したがって、フレームを利用する場合は、本当にふさわしいかどうか、検討する必要がある。フレームを利用する場合は、各フレームの役割を明確に記述することが大切である。

ソリューション
次の方法を選択して、あるいは組み合わせて用いる。

1) フレームの利用が本当に必要かどうか検討する。
サイトロゴやバナー広告のためだけのフレーム基本的に作成しないほうがよい。特にXHTML1.1では、フレームは廃止されているため、どうしても必要な場合は内部フレーム (iframe) 要素や、link要素の利用もあわせて検討する。

2) frame 要素には title 属性を用いて各フレームの役割を記述する。さらに、参照先のHTMLファイルにも title要素を用いてフレームの役割を記述する。
Title属性を記述することで、音声ブラウザなどの支援技術がユーザーにそのタイトルの情報を示してくれる。また、タイトルを付けることで、おのずと不要なフレームを見分けることができるかもしれない。不要なフレームは省略し、できるだけ少なくする。

3) フレームの参照先HTMLがフレームであるような構造は避ける
frameset の src で指定されたファイルが、さらにフレームであるようなページは、音声ブラウザを利用するユーザによっては、非常に複雑な階層構造の中を移動することになるため避ける。

4) noframes 要素には、フレーム未対応のブラウザで表示した場合でも最低限の情報やナビゲーションを記述する。
noframes 要素は必ず記述するようにする。さらに、noframes 要素の内容は、「フレーム対応のブラウザーをご利用ください」といった内容であってはならない。必ずフレームが利用できない場合のことを考慮した最低限の内容を記述する。最低限フレームへのリンクやナビゲーションなどを記述する。

5.2.g 階層構造とサイトマップの提示
閲覧しているページがウェブサイトの構造のどこに位置しているか把握できるように、階層などの構造を示した情報を提供することが望ましい。(JIS X8341-3: 5.2 g)

背景と問題点
ページを閲覧していて、次から次へとページを移動していったり、目的のページを探すために、ページを戻ったり進んだりしていくと今現在のページが、サイトの中のどのあたりに位置するのか、わからなくなる場合があったり、作業の中断などによってそれまでの作業があいまいになって、現在位置や作業目的がわからなくなる場合がある。または、作業をやり直すために、スタート地点や基準となる場所へ戻りたい場合、ブラウザの戻る機能を利用しても、なかなか適切な場所に戻れないことがある。

関連する要素、属性及び宣言
なし

関連項目
なし

技術解説
Webの閲覧者がページの中で迷子にならないように、あるいは迷子になっても適切な場所からやり直せるようにする必要がある。特に他のサイトから直接リンクされているようなページの場合、そのサイトのトップページへリンクがあると有効である。また、※ナビゲーションバー※や※パンくずリスト※の採用、あるいはサイトマップを作成して、どのページからも参照できるようにするとよい。

ソリューション
次の方法を選択して、あるいは組み合わせて用いる。

1) トップページおよび、後方、前方へのリンク
各ページには、最低限トップページのリンクを設定することで、いつでもサイトの先頭に戻ってやり直すことができる。また、前のページや次のページがある場合は、後方または前方へのページに移動するリンクを設定する。

2) サイトマップ
サイト全体の構造を現すサイトマップを作成して、各ページのわかりやすいところへリンクを設定しておく。目立たないところにリンクを設定すると、サイトマップは利用されないので注意が必要である。

3) ナビゲーションバーやパンくずリスト
サイト全体が複雑な場合やより快適なナビゲーションを提供する場合は、ナビゲーションバーの採用や、いわゆるパンくずリストなどのナビゲーションの採用を検討する。

5.3 操作及び入力
5.3 a 非デバイス依存
ウェブコンテンツは，特定の単一のデバイスによる操作に依存せず，少なくともキーボードによってすべての操作が可能でなければならない。

背景と問題点
　全盲の利用者はマウスポインタが見えないためマウスを利用できない。また弱視の利用者や加齢により視力低下した利用者はマウスポインタが見づらいため，マウスではなくキーボードを利用することがある。
また、肢体不自由者や加齢により手の震える利用者は，正確にマウスポインタを制御することが難しい，また筋力の低下した利用者は大きくマウスを動かすことが難しいため，マウスではなくキーボードを利用することがある。多くの支援技術はOSのキーボードショートカットやキーボード操作のエミュレーションによって自動的な処理を行っているので，キーボードで操作できないコンテンツは利用しづらい，あるいはできないことがある。
関連する要素、属性及び宣言
tablindex，accesskey，onClick，onDblClick，onMousedown，onMouseup，onMouseover，onMouseout，onDragDrop，onChange

関連項目
5.2 a，5.3 f，5.4 a，5.4 b，5.4 e

技術解説
「キーボードによってすべての操作が可能」というのは，コンテンツが提供している機能やサービスなどをキーボードだけで操作できることを求めており，画面上の個々のオブジェクト（アイコンやボタン）すべてを操作可能であることを意味していない。すなわち，キーボードで操作できないボタンをの代わりとなるプルダウンメニューを用意して，同等の機能を提供する方法も許容されている。キーボードアクセスが可能で、Scriptに依存しない（ページ移動のための）プルダウンメニューの作り方は以下のサイトが参考になる。
　Project UDON：http://alfasado.net/udon/accesible_html20/03.html

ソリューション
1) 全てのリンク及び入力項目は，理にかなった順序で移動できるようにする。
　通常は要素に tabindex 属性を付記しなくてもフォーカスは表示の順序と一致するが，スクリプトを用いる場合や，テキストフィールドやラジオボックスなどが多いフォーム、スタイルシートを用いて表示位置を制御している場合などには，フォーカスが適切な順序で移動しない場合がある。そのような場合には、タブキーによる移動順序が、表示順や操作手順に対応していることを確認する。
・画面スクロールは「上矢印」「下矢印」キーで，フォーカスの移動は「Tab」キーで行うなどキーと動作は一貫させる。
　tabindex属性で，Tabキーによる移動順序を設定できる。
　　　<要素名 tabindex=n>
　　　Tabキーを押した時に tabindex で指定した数値の小さなもの順にフォーカスが移動する。
　　　accesskey属性で，リンクへの移動，ボタンの押下，入力フォームへのフォーカス移動などを行うことができる。Windows の「ファイル(F)」のF と同じような働きをする。
　　　　<要素名 accesskey="t">
この例ではリンクボタンに T のキーを割り当てている。詳細の動作はOSやブラウザに依る。
　・フォーカスの存在するリンクやコマンドは，「Enter」キーを押すまで，実行しない。
2)次に示すJavaScript のイベントハンドラはプルダウンメニューに使用されることが多いが，マウスでの操作を前提にしているため，キーボードでの操作の可否に注意する。
onClick，onDblClick，onMousedown，onMouseup，onMouseover，onMouseout，onDragDrop，onChange
例えば，onMouseoverだけで，メニューを表示する場合，キーボードの利用者は，メニュー内のリンクを選択できないことがある。
　・附属書1図14は，決定ボタン(<input type=“button”>)を加え、そのボタンのonClick属性でページ変更のJavaScriptを指定している。ドロップダウンコントロールに限らず、ラジオボタンなど他のフォーム要素でも注意が必要である。
　・附属書1図15は，ドロップダウンコントロール(<select>)のonChange属性で、ページ変更のJavaScriptを指定しているためである。

3)キーボードだけで操作できるアクセシブルなオブジェクト（プラグイン）を使用する。できない場合はHTMLによる代替形式を提供する。
代表的なオブジェクトであるMacromedia Flash とAdobe PDFを利用する場合には、下記のアクセシビリティ関連サイトの情報を利用し，よりアクセシブルな配慮を行う。Flash MX 2004 からはデフォルトの状態で，Tabキーによるフォーカスが可能になっている。また、Acrobat 6.0およびAdobe Reader 6.0以降のバージョンには，メニューやツールバーを選択･操作できるショートカットキーが提供されている。

注意事項
なし

※keyword※
キーボード，全盲，肢体不自由

5.3 b 入力欄のわかりやすさ
入力欄を使用するときは，何を入力すればよいかを理解しやすく示し，操作しやすいよう配慮しなければならない。

背景と問題点
・本項目は，理解（認知）と操作（入力）の2つの観点での配慮を求めたものである。
・加齢により認知・理解力の低下した利用者や，操作に不慣れな初心者にとって，コントロールに説明がないと何を意味しているのかわからず，またコントロールが複数個ある場合，どれとどれを入力すべきかわかりにくい。
・入力欄の後ろにラベルが書かれていると，音声ブラウザを使用している全盲の利用者はどこに入力すれば前後関係がわかりにくい（5.3 b）図6,7,9,10,12,13）。さらに,ラベルと入力欄が離れて書かれていると，拡大表示ソフトを使用している弱視の利用者はその両方を拡大しながら見ることが難しい。

関連する要素、属性及び宣言
label，fieldset，legend

関連する要素、属性及び宣言

関連項目

技術解説
・本項目は，“利用者の意図や予期に反して”新しいページが開くことを禁止するものであり，利用者が意図的に新しいページを開くことを禁止しているわけではない。たとえば，(1)ヘルプページを別ページとして新たに開きたい，(2)数値を比較対照したい，などの場合，複数ページを開くことは，操作を容易にしたり理解しやすくできるので有効である。
・ウェブコンテンツの表示や操作の都合上，別ページを開くことが必要な場合は，あらかじめ新しいページが開くことを告知する。なお，指定したページのURLが更新した場合は利用者に告知せず新しいページを開いても良い。

ソリューション
1)リンクのある文字列上でマウスの右クリック操作し「新しいウィンドウで開く」を選択すれば，利用者は自分の意思で，そのページを新しいウィンドウで開くことができる。したがって, ページには新しいウィンドウを開くことを目的として，a要素もしくは，area要素の target属性は，_blank，_new を指定しない。
2)あらかじめリンク元で新しいウィンドウが開くことを明示する方法としては，
・「ニュース (新しいウィンドウで表示)」などと表記する
・新しいページが開くことを示す図記号を付記する
などがある。（JIS 5.3e）例2.）
3)やむをえず更新する場合は，あらかじめそのことを告知しておく。
例：「このページは15分ごとに最新情報を更新します」などとする。
4)リダイレクトすることが利用者の利便性に供与する場合は，告知は必ずしも必要ではない。
例：ウェブサイトのURLが変更（移動）になった場合のサーバによるリダイレクト。
参考：WCAGではリダイレクトの要する時間を0秒としている。
5)情報がその性質的に時々刻々に変化するもので，最新情報を提供することが利用者の利便性に供与するものはリフレッシュする際に，毎回告知する必要はない。
例：気象情報，株価情報。

注意事項
なし

※keyword※
ページ，更新，移動

5.3　操作及び入力（JIS X 8341-3:5.3）
5.3 f 一貫性のある基本操作部の提供
ウェブサイト内においては，位置，表示スタイル及び表記に一貫性のある基本操作部を提供することが望ましい。

背景と問題点
・基本操作部（ページ共通のナビゲーションバー，「トップページ」「サイトマップ」などへのリンク，およびページ内リンクなど）がページごとに異なると，利用者は新しいページを参照するたびに，基本操作の方法を理解しなおさなければならない。特に，加齢により認知・理解力が低下した利用者や視力低下による画面を見にくい利用者は，その理解に時間がかかる。
・音声ブラウザの利用者は，同じ操作部であれば読み飛ばすことができるが，毎回操作部を最初から読まなければならなくなる。
・キーボードやマウスの操作が難しい筋力低下，麻ひ（痺），手の震え，不随意運動のある利用者は，ページ送りボタンなどが同じ位置に表示されていないと，操作に時間がかかる。　

関連する要素、属性及び宣言

関連項目

技術解説　画像に代替テキストを提供することで、その画像が伝えている情報は、視覚系ブラウザで画面に表示されるだけでなく、音声あるいは点字などに変換することが可能になる。また、画像を非表示にしている視覚系ブラウザあるいは画像を表示しないテキストブラウザなどでは、画像を表示できないかわりに代替テキストをその画面に表示することができる。
Web ページに画像を用いることで視覚的な訴求力を高めることができるが、同時にその画像を見ることができない利用者のために代替テキストを記述することで、その画像が伝えている情報をより多くの利用者に伝えることができるようになる。

ソリューション次の方法を選択して、あるいは組み合わせて用いる。
ポイントとなるのは以下の2点である。
(1) 必ずimg要素にはalt属性をつけること。
(2) 画像が用いられている意図や目的に応じて、代替テキストを簡潔に記述すること。ただし、その画像が情報を伝えていない場合は、alt属性を空（alt=””）にすること。
その画像を使用する目的あるいはその画像がページで果たしている役割、前後および周囲との文脈により、以下から適切な方法を用いて、画像の代替テキストを記述する。なお、W3Cが公開している(X)HTMLの勧告（仕様）によれば代替テキストが不要な画像のimg要素にもalt属性は必須であり、代替テキストが不要であることを示すためにもalt属性を空（alt=””）にしなくてはならない。

1) img 要素のalt 属性値に代替テキストを記述する
画像が伝えている情報を簡潔にテキストで記述する。
例1 画像の代替テキストを、img要素のalt属性に記述する。
<img src=”image.gif” width=”250” height=”100” alt=”日本工業規格”>

2) alt 属性値を空（alt=””）にする
代替テキストが不要な場合は、alt属性値を空（alt=""）にする。また、その画像の周囲にあるテキストで説明している場合も同様である。
例1 以下に挙げるような画像は、img要素のalt属性を空（alt=""）にする。
・スペーサー画像（レイアウトのために使用する透明のGIF画像）
・装飾だけを目的にした画像
<img src=”spacer.gif” width=”1” height=”10” alt=””>

3) その画像の周囲にあるテキストを代替テキストとする
例1 画像の周囲にあるテキストが画像の内容を説明している場合、あるいは画像の周囲に説明するテキストを置く場合は、繰り返しを避けるためにalt属性を空（alt=""）にする。
<img src=”picture.gif” width=”300” height=”150” alt=””>
<p>（･･･画像の内容を説明しているテキスト･･･）</p>

4) 代替情報としてデータテーブルを提供する
数値データを円グラフあるいは棒グラフなどの画像にして提供する場合は、そのグラフが伝えている数値データの内容をアクセシブルなデータテーブルであわせて提供する。
例1 img要素のalt属性には代替テキストとして、グラフがあることを記述する。
<img src=”graph.gif” width=”250” height=”200” alt=”棒グラフ：過去10年間における利用者人口の推移”>
<table>
<caption>表1.　過去10年間の利用者人口推移</caption>
<tr>
<th></th>
……………

5) 別ページに代替テキストを記述する
alt属性値に記述する代替テキストが長くなってしまう場合には、別に説明ページを設けてlongdesc属性でリンクを提供する。また、longdesc属性をサポートしていないユーザーエージェントのために、画像のすぐ近くに同じ説明ページへのリンクをあわせて提供する必要がある。
例1 img要素のlongdesc属性で説明ページのURLを指定する。あわせて、longdesc属性の代替手段として、同じリンク先を指定したテキストリンクを画像のすぐそばに置く。
<img src=”diagram.gif” width=”250” height=”200” alt=”図：日本規格協会の組織図” longdesc=”detail.html”>
<a href=”detail.html”>組織図の詳細</a>

注意事項画像の代替テキストは、その画像の用途あるいは目的、役割などにより、ある程度パターン化できるが、実際には前後の文脈や周囲にあるテキストなどにより、ケースバイケースであることが少なくない。重要なのは、その画像を画面で見ることのできない利用者にも同等の情報が伝わることであり、ここで挙げているソリューション以外にもその方法は考えられる。何のために代替テキストを提供するのかをふまえて、適宜その提供の方法を検討する必要がある。

※keyword※ 代替テキスト、alt属性、longdesc属性

5.4 非テキスト情報（JIS X 8341-3:5.4）
5.4 b ハイパリンク画像の代替テキスト
ハイパリンク画像には，ハイパリンク先の内容が予測できるテキストなどの代替情報を提供しなければならない。( 対応：JIS X8341-3:5.4 b)

背景と問題点
　視覚障害のため音声ブラウザなどを用い音声によって情報を得ている場合がある。その場合，音声ブラウザなどは，ハイパリンク画像（リンクを設定している画像）を音声化できないので，代わりに代替情報（テキスト）を読み上げる。したがって，代替情報がないと利用者はハイパリンク先を識別・理解することができない。

関連する要素、属性及び宣言
img, area, input

関連項目

技術解説　リンク画像のimg要素にalt属性がないと、音声ブラウザなどではそのリンク先に指定しているURI（a要素のhref属性値）がそのまま読み上げられてしまう。また、画像を表示できないブラウザでは何も表示されないため、利用者はリンクであることは認識できてもそのリンク先は全く分からない。
　また、イメージマップを使用する際には、マップ内のリンク領域を定義できない場合を除いて、クライアントサイド・イメージマップを用いる。その際、イメージマップそのものを説明する代替テキストと、マップ内の各リンク領域の代替テキストとをあわせて記述する必要がある。
　どうしてもサーバサイド・イメージマップを使用するしかない場合だが、サーバサイド・イメージマップは利用者がマウスを操作できることが前提となる。マウスを操作できない利用者のために、マップ内に設定されている全てのリンクの代替手段となるテキストリンクをマップ画像のすぐそばに置かなければならない。

ソリューション次の方法を選択して、あるいは組み合わせて用いる。
どの方法を用いるにしても、リンク画像の代替テキストは、テキストリンクと同様に、その部分だけでリンク先の内容が分かるように記述する必要がある。

1) img 要素のalt 属性値に代替テキストを記述する
その部分だけでリンク先の内容が分かるように記述する。
例1 リンク画像の代替テキストを、img要素のalt属性に記述する。
<a href=”about.html”>
<img src=”image.gif” width=”150” height=”25” alt=”会社概要”>
</a>

2) alt 属性値を空（alt=””）にする
リンク画像のすぐそばに同じリンク先へのテキストリンクがある場合は、繰り返しを避けるために、リンク画像のalt属性値を空（alt=""）にする。
例1 img要素のalt属性を空（alt=""）にする。
<a href=”about.html”>
<img src=”image.gif” width=”200” height=”50” alt=””>
</a><br>
<a href=”about.html>会社概要</a>

3) クライアントサイド・イメージマップのarea要素のalt属性に代替テキストを記述する
例1 マップ内のリンク領域の代替テキストを、area要素のalt属性に記述する。

<map name="menu">
<area shape=rect coords="0，0，60，90" alt="食品" href="../syokuhin.html">
<area shape=rect coords="60，0，120，90" alt="雑貨" href="../zakka.html">
<area shape=rect coords="120，0，180，90" alt="ギフト" href="../gift.html">
</map>
例2 イメージマップ全体の代替テキストを、img要素のalt属性に記述する。
<img src="map.gif" usemap="#menu" alt="メニュー一覧">

4) サーバサイド・イメージマップの代替手段としてテキストリンクを提供する
サーバサイド・イメージマップに設定してある全てのリンクと同じリンク先へのテキストリンクをマップ画像のすぐそばに置く。
例1 イメージマップ画像のalt属性に代替テキストを記述し、あわせて代替手段となるテキストリンクをすぐそばに置く。
<a href="cgi-bin/worldmap/database">
<img src="map.gif" alt="世界地図" ISMAP>
</a>
<br>
<a href="asia.html">アジア</a>|<a href="europe.html">ヨーロッパ</a>|……………

5) フォームのボタン画像は、input要素のalt属性に代替テキストを記述する
フォームのボタンを画像にする際には、そのinput要素にalt属性をつけて、ボタンの操作結果をあらわす代替テキストを記述します。
例1 リンク画像の代替テキストを、img要素のalt属性に記述する。
<input type="image" value="送信" src="images/submit.gif" name="submit" alt="送信">

注意事項リンク画像の代替テキストは、そのリンク画像の用途あるいは目的、役割などにより、ある程度パターン化できるが、実際には前後の文脈や周囲にあるテキストなどにより、ケースバイケースであることが少なくない。重要なのは、その画像を画面で見ることのできない利用者にもそのリンク先の内容が分かるようなラベル（文言）を代替テキストとして記述することである。

※keyword※　代替テキスト、alt属性、イメージマップ、クライアントサイド・イメージマップ、サーバサイド・イメージマップ

5.4 非テキスト情報（JIS X 8341-3:5.4）
5.4 c 音声の代替
ウェブコンテンツの内容を理解・操作するのに必要な音声情報には、聴覚を用いなくても理解できるテキストなどの代替情報を提供しなければならない。( 対応：JIS X8341-3:5.4 c)

背景と問題点
　聴覚障害があるとき，音だけで情報を提供していると提供されていることが認識できず，その内容も理解できない。音声情報は、利用者が聴覚を用いることでその情報を得ることができる。しかし、聴覚に障害があったり、PCの音声出力をオフにしていたり、周囲が騒がしい環境で利用していたりすると、その情報を全くあるいはほとんど得ることができない。

関連する要素、属性及び宣言
object

関連項目

技術解説　
音声で提供する情報には代替テキストを提供して、利用者が聴覚を用いなくてもその内容を理解できるようにする必要がある。
警告音などを用いる際は、その音が聞こえなくても分かるように、代替テキストなどにより画面で視覚的にもその情報を伝える。

ソリューション次の方法を選択して、あるいは組み合わせて用いる。

1) 音声情報の代替テキストを提供する
音声情報が聞こえなくても、同じ情報が視覚的に伝わるようにする。
例1 音声の再生に合わせて、画面に代替テキストも表示する。JIS X 8341-3:2004 規格書P12より引用。
（図あり：テキスト情報を併用した例と併用しない例の比較した画面図）

※keyword※　代替テキスト、音、音声

5.4 非テキスト情報（JIS X 8341-3:5.4）
5.4 d 動画の字幕と状況解説
動画など時間によって変化する非テキスト情報には、字幕又は状況解説などの手段によって、同期した代替情報を提供することが望ましい。同期して代替情報が提供できない場合には、内容についての説明を何らかの形で提供しなければならない。( 対応：JIS X8341-3:5.4 d)

背景と問題点
　聴覚障害がある場合，音によって情報を提供していると提供されていることが認識できず，その内容も理解できない。
視覚障害がある場合，どのような映像が表示されているのか理解できないことがあるために，内容を理解できない場合がある。
認知又は記憶に障害がある場合，字幕，状況説明などがあると繰返し見たりすることによって，内容を理解しやすくなる場合がある。

関連する要素、属性及び宣言
object

関連項目

技術解説　音声付の動画には、画面で視覚的に伝えている情報と音声で聴覚的に伝えている情報とがあり、それぞれに代替情報を提供する必要がある。
　まず、画面で視覚的に伝えている情報については、音声による補足説明を副音声で提供し、主音声と重ならないように同期させるのがベストだが、実際には困難なケースが多い。そこで、これが困難な場合は、音声や点字に変換できるように、主音声を書き起こしたテキストおよび補足説明となる代替テキスト（副音声の原稿にもなるテキスト）を何らかの手段で提供する。テキスト情報になっていれば、音声あるいは点字に変換することができるので、視覚に障害があっても画面で伝えられている情報を得ることができる。
　次に、音声で聴覚的に伝えている情報については、キャプション（字幕）を提供し、画面上で同期させるのがベストだが、これもやはり困難なケースが少なくない。そこで、これが困難な場合は、キャプションと同じ要領で代替テキストを書き起こして別ページで提供するなど、音声を聞くことができない利用者にも同等の情報が伝わるようにする。テキスト情報になっていれば、それを点字に変換することができるので、例えば視覚と聴覚の両方に障害があっても、利用者はその情報を得ることができる。

ソリューション次の方法を選択して、あるいは組み合わせて用いる。

1) 画面で視覚的に伝えている情報を同期させた副音声で提供する
副音声で、登場人物の表情および動作、背景、画面上の文字などを、主音声と重ならないように提供する。
例1 以下の [ ]部分を副音声のナレーションとして録音し、画面と同期させる。
シンバ「それっ！」
[シンバは外へ駆け出して行き、両親が後に続きます。サラビはやさしく微笑みながら、シンバを父の方へ行くようにと促します。２頭は並んで座りながら、黄金に輝く日の出を見つめています。]
ムファサ「見なさい、シンバ。太陽が輝かせているのは、私たちの王国だ。」
シンバ「ほんとだ！」

2) 画面で視覚的に伝えている情報を代替テキストで提供する
登場人物の表情および動作、背景、画面上の文字などを、副音声ではなく、代替テキストとして提供する。
例1 登場人物のセリフおよび[ ]部分の補足説明を代替テキストとして別ページなどで提供する。
シンバ「それっ！」
[シンバは外へ駆け出して行き、両親が後に続きます。サラビはやさしく微笑みながら、シンバを父の方へ行くようにと促します。２頭は並んで座りながら、黄金に輝く日の出を見つめています。]
ムファサ「見なさい、シンバ。太陽が輝かせているのは、私たちの王国だ。」
シンバ「ほんとだ！」

3) 音声で聴覚的に伝えている情報を同期させたキャプション（字幕）で提供する
登場人物のセリフ、効果音などをテキストに書き起こして、同期したキャプションとして画面上で提供する。
例1　登場人物のセリフ以外の音もキャプションとして提供する。
＊「E.T.」のあるシーンに対する字幕。電話のベルが３回鳴った後、声が聞こえる場面。
[電話の呼出音が鳴る]
[呼出音]
[呼出音]
「もしもし？」
関連情報
SMIL 1.0 仕様書（日本語訳）
http://www.doraneko.org/misc/smil10/19980615/Overview.html
QuickTime と SMIL
http://www.apple.com/jp/quicktime/tools_tips/tutorials/qtsmil.html
マイクロソフト - PC マルチメディアのキャプションとオーディオの説明
http://www.microsoft.com/japan/msdn/accessibility/general/ATG_CCandAudioDesc.asp
マクロメディア - Macromedia Flash MX 2004 によるアクセシブルコンテンツの作成 : キャプションと字幕
http://www.macromedia.com/jp/macromedia/accessibility/features/flash/captions.html

4) 音声で聴覚的に伝えている情報を代替テキストで提供する
登場人物のセリフ、効果音などをテキストに書き起こして、代替テキストとして提供する。これをトランスクリプトとよぶが、このトランスクリプトへのリンクは目立つところに配置すべきである。
例1　登場人物のセリフ以外の音も代替テキストとして記述する。この代替テキストは、
＊「E.T.」のあるシーンに対する字幕。電話のベルが３回鳴った後、声が聞こえる場面。
[電話の呼出音が鳴る]
[呼出音]
[呼出音]
「もしもし？」

※keyword※　動画、音声、代替テキスト、キャプション、字幕、副音声、トランスクリプト

5.4 非テキスト情報（JIS X 8341-3:5.4）
5.4 e　オブジェクトの代替形式
アクセス可能ではないオブジェクト、プログラムなどには、利用者がその内容を的確に理解し操作できるようにテキストなどの代替情報を提供しなければならない。また、アクセス可能なオブジェクト又はプログラムに対しても、内容を説明するテキストなどを提供することが望ましい。( 対応：JIS X8341-3:5.4 e)

背景と問題点
　オブジェクトあるいはプログラムをアクセシブルでないと、そのオブジェクトあるいはプログラムが提供している情報および機能を利用できない場合がある。また、特定のプラグインを用いる場合には、そのプラグインをサポートしていない環境では、やはりユーザーは情報および機能を利用することができない。

関連する要素、属性及び宣言
object, script, a

関連項目

技術解説　5.1 b) にあるように、オブジェクトあるいはプログラムを使用する際は、それ自体をアクセシブルにするよう最大限につとめなくてはならない。そして、プラグインについても同様である。しかし、どうしてもこれらをアクセシブルにできない場合には、利用者が同等の内容を理解してその情報およびサービスを利用できるように代替情報を提供する必要がある。
　また、オブジェクト、プログラム、あるいはプラグインがアクセシブルであっても、あわせてテキストなどの代替情報を提供することで、利用者は好きなほうを選択することができるようになり、その利便性が向上する。

ソリューション次の方法を選択して、あるいは組み合わせて用いる。

1) object要素の代替テキスト
object 要素には代替テキストを提供する。代替テキストは、オブジェクトのもつ情報と同等の内容を提供するか、もしくはそのオブジェクトを用いることができない場合の代替手段に関する情報を提供する。
例1 <object classid="java:Press.class" width="500" height="500">
　　 <object data="Pressure.mpeg" type="video/mpeg">
　　<object data="Pressure.gif" type="image/gif">
　As temperature increases, the molecules in the balloon...
　　</object>
　　</object>
</object>

2) script 要素があるとき、noscript要素を使って script が使えないときにも、アクセスできること
例1 ＜script type="text/javascript"> メニューのためのスクリプトが書いてある </script>
<noscript><a href=”altmenu.html”>メニューのページを開く</a></noscript>

3) プラグインの最新バージョンをダウンロードできるページへのリンクを提供する
プラグインを使用する際は、その最新バージョンをダウンロードできるページへのリンクを提供する。
例1 Adobe Player（PDF閲覧）の場合：
<a href=http://www.adobe.co.jp/products/acrobat/readstep2.html”>
<img src=”images/get_adobe_reader.gif” width=”88” height=”31”
alt=”Adobe Readerのダウンロード”>
</a>

例2 Flash Playerの場合：
<a href=http://www.macromedia.com/jp/go/getflashplayer_jp/">
<img src=” images/get_flash_player.gif” width=”88” height=”31”
alt=” Macromedia Flash Playerのダウンロード”>
</a>

例3 Windows Media Playerの場合：
<a href="http://www.microsoft.com/japan/windows/windowsmedia/download/">
<img　src="http://www.microsoft.com/windows/windowsmedia/images/
Download_88x31_static.gif" width="88" height="31"
alt="Windows Media Playerのダウンロード">
</a>

例4 QuickTimeの場合：
<a href=" http://www.apple.com/jp/quicktime/download/">
QuickTimeのダウンロード
</a>

※keword※　オブジェクト、スクリプト、PDF、Flash

5.5 色及び形
5.5 a 色のみに依存する情報提示
ウェブコンテンツの内容を理解・操作するのに必要な情報は、色だけに依存して提供してはならない。( 対応：JIS X8341-3:5.5 a)

背景と問題点
　ある情報を強調したり、他との差異を明確にしたりするために、文字色を変えるなどして色を用いることは視覚的により分かりやすく情報を伝えることができるという点ではとても有用である（例：必須項目のみ赤字で示す、新商品名のみ赤字で示す、など）。また、グラフなどでは複数の色を用いてデータを示す場合がある。
　しかし、色を用いて情報を提供する場合、それらの色が識別できない場合でも情報が伝わるようにしなければならない。たとえば、音声読み上げソフトでは文字の色までは読み上げないため、利用者は文字の色だけで伝えられている情報が理解できない。また、色覚に特性のある利用者がその文字やグラフの色を識別できずに理解できないこともある。さらに、モノクロで印刷した場合には色は全て破棄されるため、特定の色で情報が表現されていると利用者はその色が識別できずに理解できない。

関連する要素、属性及び宣言
img, color, bgcolor

関連項目

技術解説　テキストの文字色で情報を示す場合は、あわせてテキストでも情報を提供する（例：「赤字の項目名（必須）」、「赤字の商品名（新商品）」、など）。そうすることで、音声読み上げソフトでも情報が伝わり、その色が識別できない場合でも情報が伝わるようになる。
　また、グラフで複数の色を用いる際には、凡例だけではなく、引込み線を用いるなどして色が識別できなくても情報が伝わるようにする。
　以下の手段を用いて、色が識別できなくても情報が伝わるかどうかを確認するとよい。
　　・グレースケールに変換してみる
　　・モノクロ印刷してみる
　　・音声ブラウザあるいはスクリーンリーダーで読み上げてみる

ソリューション次の方法を選択して、あるいは組み合わせて用いる。

1) 文字の色だけでなくテキストの補足情報を提供する
たとえば、文字色で情報を示す場合は、あわせてテキストでも情報を提供する。
例1 <p class=”required”>名前<em>（必須）</em></p>
　　ｐ.required { color : red }

2)グラフでは凡例だけでなく引込み線を用いて情報を提供する
例1 JIS X 8341-3:2004 規格書P13より引用。
（グラフの表示で、領域を色だけで区別している例と引き出し線を付けた例を掲載）

※keyword※　色、文字色、グレースケール、モノクロ印刷、引込み線

5.5 色及び形（JIS X 8341-3:5.5）
5.5 b 形・位置のみに依存する情報提示
ウェブコンテンツの内容を理解・操作するのに必要な情報は、形又は位置だけに依存して提供してはならない。( 対応：JIS X8341-3:5.5 b)

背景と問題点
　表組みなどで用いられる「○」「△」「×」といった記号文字は、視覚的により分かりやすく情報を伝えることができるという点ではとても有用である。
　しかし、これらの記号文字は音声ブラウザやスクリーンリーダーでは意図したとおりに読み上げられないことがあるため、音声読み上げでは情報が伝わらないことがある。
　また、「左のボタン」「右のボタン」というように、位置だけで示した情報も音声読み上げでは伝わらないため、利用者は画面上の位置が把握できず、操作することができない。

関連する要素、属性及び宣言

関連項目

技術解説　「○」「△」「×」などの記号文字で情報を提供する場合は、音声読み上げでもその情報が正しく読み上げられるように、テキストによる補足情報を提供する、あるいは記号文字を画像にしてその意味を代替テキストで提供する。
　また、「左のボタン」「右のボタン」だけではなく、「左の送信ボタン」、「右のキャンセルボタン」というように、位置が把握できなくてもどのボタンかが伝わるようにしなければならない。その際、ボタン自体にも「送信」「キャンセル」といったラベルをつけておく必要がある。

ソリューション次の方法を選択して、あるいは組み合わせて用いる。

1) 「○」「△」「×」などの記号文字による情報にはテキストによる補足情報を提供する。
「○」「△」「×」「－」などの記号文字の直後に、テキストでその記号文字が伝えている意味を補足する。
例1 「○（あり）」、「×（なし）」「○（対応）」、「－（非対応）」「○（開館日）」、「△（午前のみ開館）」、「×（休館日）」

2) 「○」「△」「×」などの記号文字を画像にして、代替テキストによる補足情報を提供する。
「○」「△」「×」「－」などの記号文字を画像にして、それぞれの代替テキストにその記号文字が伝えている意味を記述する。
例1 <img src=”maru.gif” width=”20” height=”20” alt=”あり”> <img src=”batsu.gif” width=”20” height=”20” alt=”なし”>

3) 位置が把握できなくても操作できるように補足情報を提供する。
ボタン自体に「送信」「キャンセル」といったそのボタンの機能を示すラベルをつけ、「左のボタン」「右のボタン」ではなく、「左の送信ボタン」「右のキャンセルボタン」あるいは「送信ボタン」「キャンセルボタン」と表現する。

※ keyword※　形、位置、記号文字

5.5.c 背景色と前景色のコントラストと配色
画像などの背景色と前景色とには、十分なコントラストを取り、識別しやすい配色にすることが望ましい。

背景と問題点
文字の色とその背景の色，画像で表現された文字や記号，アイコンなどは背景色と前景色の間に十分なコントラストと配色における配慮がないと，見づらい，見えない利用者がいる。たとえば，弱視の人の場合，色のコントラストが十分でないと，色の差を識別できず表された情報を取得できないことがある。また，色覚障害のある人には，特定の色の識別が困難な場合がある。人間の色覚には，3色（赤，緑，青）の感覚受容体があり，それらの個々の色感覚が弱い場合と，まったく感覚がない場合がある。最も代表的なものは，第1色覚（赤）の障害である。

関連する要素、属性及び宣言
img object font
スタイルシートの色に関するプロパティすべて

関連する要素、属性及び宣言

関連項目

ソリューション次の方法を選択して、あるいは組み合わせて用いる。

1) フォントサイズを小さくしすぎない
　スタイルシートのfont-size、fontプロパティで xx-small、x-small を用いない。また、0.8emあるいは80%以下のサイズを指定しない。

2) フォントを指定するときは、できるだけゴシック系のフォントを選択する。
　ゴシック系の日本語フォントには、マイクロソフトウィンドウズに搭載された「MS ゴシック」「MS Pゴシック」、マッキントッシュに搭載された「Osaka」などがある。欧文では、「sans-serif」がよく用いられる。

3) フォントスタイル等を制御する場合には、見易さに配慮する。
スタイルシートのfont-style、font-stretch、font-size-adjust、font-weight、line-height、text-decoration、letter-spacing、word-spacing、text-shadowプロパティなどを用いてフォントのスタイルを調整したり、文字間や行間を制御したりする場合には、見易さへの配慮が必要である。

注意事項　フォントの大きさ、種類、書体に関する読みやすさは、色や利用者の使用しているコンピュータのモニタや照明環境などに左右されるため、明確な数値で評価することは難しい。しかし、一般論として小さな文字は読みづらく、太い文字、大きなもの字は読みやすい。また、明朝体よりもゴシック体のほうが読みやすいことが知られている。したがって、この要件を満たすための最もよい方法は、フォントを指定しないことである。

5.6 文字
5.6.c フォント色
フォントの色には、背景色などを考慮し見やすい色を指定することが望ましい。

背景と問題点
　フォントの色と背景色の組み合わせによっては、文字が読みづらくなることがある。たとえば、ある種の色覚障害のある人には、赤と緑の区別が難しい。また、一般的に白内障や加齢による視力の低下のある人、弱視の人は、コントラストの低い文字は読みづらい。
関連する要素、属性及び宣言

関連項目

技術解説
これらの問題に対処するには、色の組み合わせについての配慮が必要である。文字色と背景色の間に十分なコントラストをとることで、見やすくすることができる。なお、この問題に対応する最もよい方法は、フォントの色を指定せず、背景色も指定しないことである。当然ながら、画像化したテキストがない場合、フォントの色、背景色を指定していない場合には、この要件を配慮する必要がない。

（ここに色の識別と見易さに関する一般的な説明を加えるか、appendixを用意してそれを参照する「新編感覚・知覚心理学ハンドブック」が参考になりそう）

ソリューション次の方法を選択して、あるいは組み合わせて用いる。

1) 背景色を指定する場合には、フォントの色との組み合わせ、コントラストを評価する

2) スタイルシートを外した状態でも色の組み合わせ、コントラストに問題がないかどうかを評価する。

3) 文字を画像化するときは、文字と背景の色の組み合わせ、コントラストを評価する

4) 背景画像を使用しない

5) OSの機能や支援技術の提供する「ハイコントラスト表示」を用いた場合にも、色の組み合わせ、コントラストを評価する

注意事項

5.7 音
5.7.a 音の自動再生の禁止
自動的に音を再生しないことが望ましい。自動的に再生する場合には、再生していることを明示しなければならない。(JIS X8341-3: 5.7 a)

背景と問題点
ページを開いたときに※自動的※に※音※（音楽等）が流れると、意図しない出来事にユーザーが驚いてしまうことがある。たとえば、子供の寝ている横や、深夜の家族が寝ている横でページを参照しないといけないかもしれないし、あるいは静かな図書館などでページを利用しなければいけないことも考えられる。このような、静かな場所や静かにしないといけない場所でWeb閲覧をしている場合に、ページを開いたら、自動的に音が鳴り出したら困るだろう。そのような場合は、慌てて音量を下げたりする。しかし、聴覚障害の利用者の場合、音が出ていることに気づかず、音が再生され続けてしまい、寝ている子供を起こしてしまうといったことが起こってしまうかもしれない。音声ブラウザを利用している場合、読み上げの音声が音（音楽など）と重なって聞き取りづらくなる可能性がある。音量を下げようとすれば、本文の読み上げの音量も下がってしまい、そのページの閲覧が事実上できなくなってしまう。

関連する要素、属性及び宣言
bgsound, object, embed

関連項目

技術解説　バナー広告などのアニメーション画像では、背景の変化はなるべく緩やかにして、極端な色の変化を避ける。具体的には、複数の画像を順番に繰り返し表示する場合、画面ごとの明度、彩度および色相が大きく変わる画面を交互に点滅させ繰り返してはいけない。文字を変化または移動させる場合は、利用者が認識しやすいようにそのコントラスト輝度の変化および速度を緩やかにする。また、点滅させる際は、認識しやすいようにその速度を遅くするなどの配慮も必要である。
　また、スクロールや点滅といった動きのある表現は、利用者のコンテンツへの集中力をそぐため、できるかぎり避けるべきである。どうしてもこういった表現を用いる際には、一定時間経過後には静止させるなどの配慮が望まれる。
　なお、文字をスクロールさせるmarquee要素、文字を点滅させるblink要素は、いずれもW3Cの勧告（仕様）にはない規格外要素であり、これらを用いるべきではない。

ソリューション次の方法を選択して、あるいは組み合わせて用いる。

1) 複数の画像を順番に繰り返し表示する場合、画面ごとの明度、彩度および色相の変化を小さくする。
各画像の背景色および文字色の明度、彩度および色相の変化をできるかぎり小さくする。
例1
2) 文字を変化または移動させる場合は、そのコントラスト輝度の変化および速度を緩やかにする。
文字のコントラスト輝度の変化および移動の速度をできるかぎり緩やかにする。
例1
3) スクロールあるいは点滅させる場合は、その速度を遅くして、一定時間が経過したら静止させる。
文字がある場合は、利用者がその文字が読めるように点滅する間隔を十分に空ける。また、利用者がコンテンツに集中できるように、スクロールあるいは点滅が数回繰り返したら停止させる。
例1 たとえば、3回同じ動きを繰り返したら停止させる。

※keyword※　変化、移動、点滅、明度、彩度、色相、コントラスト輝度、速度

5.8 速度（JIS X 8341-3:5.8）
5.8 b 早い周期の点滅禁止
早い周期での画面の点滅を避けなければならない。( 対応：JIS X8341-3:5.8 b)

背景と問題点
　光の明滅によって光感受性発作（光源性てんかん）を誘発することがある。20 Hz の時間周波数（1秒間に20回）にピークがあり、特に赤と青とを交互に点滅させると、光感受性発作を誘発しやすい。利用者の安全性に関することなので最大限の配慮が必要である。

関連する要素、属性及び宣言
img object

関連項目

技術解説　画面全体を明滅させると、光感受性発作を誘発することがあるので使用しない。どうしても明滅させたい場合は、画面全体を1秒間に2回以上明滅させないようにして、特に、彩度の高い赤の明滅およびコントラストの強い画面の反転を避けなければならない。

⇒まず、点滅をやめることを書いたほうがいいのではないか？

　また、画面内で明滅する部分の領域は、できるだけ小さい範囲に留めるよう配慮するのがよい。しかし、たとえ画面の一部だとしても、中には弱視の利用者のように画面を拡大していることもあるので、できるかぎり画面の明滅は避けるべきである。
　また、画面全体を占めるような、しま、渦巻き、同心円といった規則的なパターン模様も画面の明滅の場合と同様の危険があるため、そういったページデザインも避けるべきである。
　なお、W3Cでは、この明滅に関する具体的な基準値に関して、「ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television　（ http://www.ofcom.org.uk/codes_guidelines/broadcasting/tv/vrs_code_notes/flsh_imgs/?a=87101 ）」
で定められている基準を WCAG 2.0 で採用することを検討している。

ソリューション次の方法を選択して、あるいは組み合わせて用いる。

1) 画面全体を1秒間に2回以上明滅させない。特に彩度の高い赤の明滅およびコントラストの強い画面の反転は避ける。
W3C の WCAG 1.0 では、チェックポイント7.1 で「１秒間に20回の点滅をピークとして、１秒間に4～59回(Hz)の点滅」、米国のリハビリテーション法508条では、「2～55ヘルツの周波数」（1秒間に2～55回）の点滅、を避けるようにとそれぞれ定めている。
例1

2) 画面の一部を明滅させるときは、1024×768ピクセルの画面解像度で355×268ピクセルの1/4以上を占める面積での明滅は避ける。
W3CのWCAG 2.0 で検討されている面積の基準です。ただし、弱視の利用者のように画面を拡大している場合がありますので、これ以上小さい面積でも上記a) とあわせて配慮すべきです。
例1　 JIS X 8341-3:2004 規格書P17より引用。
（図あり：小さな画面の点滅及び画面全体の点滅）

3) 画面全体を占めるような、しま、渦巻き、同心円といった規則的なパターン模様を使用しない。
画面の明滅と同様の危険性があるため、このような表現は避ける。
例1 JIS X 8341-3:2004 規格書P17より引用。
（図あり：しま模様、同心円）

※keyword※　明滅、光感受性発作、光源性てんかん、発作、てんかん、彩度、周波数、しま、渦巻き、同心円

5.9 言語
5.9.a 自然言語の指定
言語が指定できるときは、自然言語に対応した言語コードを記述しなければならない。
( 対応：JIS X8341-3:5.9 a)

背景と問題点
　自然言語の指定は、音声ブラウザが正しい言語辞書を用いて音声合成するために必要である。現在日本国内で使われている主な音声ブラウザやスクリーンリーダーは日本語にしか対応しないものが主流であるが、複数の言語を正しく合成できる環境が整備された際には、言語コードの指定によって複数の言語を用いて作成されたページを正しく読み上げることができるようになる。また、一般のウェブブラウザでも言語コードの指定が正しくされていないと、適切なフォントを用いて正しく表示できないことがある点に注意する。

関連する要素、属性及び宣言
html span

技術解説
言語コードは、各仕様にしたがって指定する。ブラウザが表示する際に使用する言語は、次の順序で解釈され表示される。
1) 要素のlang属性で指定された言語コード
2) その要素の親になる要素において、lang属性で指定された言語コード
3) HTTPのContent-Languageヘッダで指定された言語コード
4) ウェブブラウザのデフォルトの言語コード
したがって、HTMLでは html要素で言語コードを指定しておくのが最もよい方法である。

ソリューション
1) HTMLでは、html 要素にはlang 属性でデフォルトの言語を指定する。
例1 <html lang=”ja”>

2) XHTML1.0 では、lang 属性に加えてxml:lang属性を用いてデフォルトの言語を指定する。
例1 <html lang=”ja” xml:lang=”ja”>

3) XHTML1.1では、xml:lang属性を用いてデフォルトの言語を指定する。
例1 <html xml:lang=”ja”>

4) HTTPのContent-Languageヘッダにおける言語指定がコンテンツのデフォルト言語と一致すること。
このヘッダは、ウェブサーバーの設定により指定する。

5) HTML文書の途中で言語を切り替えたいときには、span 要素などで lang 属性を使って指定する。
例1 <span lang=”en”> English section of the document</span>

注意事項

なし

5.9.b 外国語の多用禁止
日本語のページでは、想定する利用者にとって理解しづらいと考えられる外国語は、多用しないことが望ましい。使用するときは、初めて記載する時に、解説しなければならない。
( 対応：JIS X8341-3:5.9 b)

背景と問題点
　高齢者や認知障害のある人の中には、外国語を理解できない人や、外国語が出てくることで理解が困難になる人がいる。

関連する要素、属性及び宣言
なし

技術解説
日本語のコンテンツの場合で、外国語を用いなくても情報が伝えられる場合には、日本語で記述すれば必要な情報を伝えることができるようになる。また、外国語を使わざるを得ない場合でも、その解説を提供することで内容の理解を促進することができる。規格本文の「想定する利用者にとって理解しづらいと考えられる外国語」のくだりは、あらゆるコンテンツで外国語の禁止を求めているわけではないことを意図している。たとえば、学術研究に関する文書や外国語教育に関するもの、またあらかじめ外国語を十分に理解できると思われる利用者を対象として想定したコンテンツでは、外国語の使用を妨げない。

ソリューション
1) 想定する利用者が幅広くあらゆる利用者を対象にしたいときは、外国語の使用を最低限にし、ページの最初に出現した箇所でその単語の意味あるいは説明を提供する。文章で用いる場合には、その日本語訳を併記するか、日本語訳へのリンクを提供する。

例1 <span lang=”en”>foreign language </span>(外国語)

2) 利用者が一定の外国語に関する知識を持っていると想定される場合は、そのレベルに合わせて理解の困難な言葉に限って説明を提供する。

注意事項

5.9 c省略語、専門用語、流行語、俗語の多用禁止
省略語、専門用語、流行語、俗語などの想定する利用者にとって理解しにくいと考えられる用語は、多用しないことが望ましい。使用するときは、初めて記載されるときに定義しなければならない。
( 対応：JIS X8341-3:5.9 c)

背景と問題点
省略語や専門用語などはそれを理解できない人がいるだけでなく、音声ブラウザなどでも正しく読み上げることができず理解できないことがある。

関連する要素、属性及び宣言
abbr acronym th td

技術解説
省略語、専門用語、流行語、俗語などを多用すると、利用者の記憶に負担をかけ文書を理解しづらくなる。また、これらの言葉はスクリーンリーダーで正しく読み上げられない可能性がある。
規格本文の「想定する利用者にとって理解しづらいと考えられる用語」のくだりは、あらゆるコンテンツでこれらの用語の使用を禁止しているわけではないことを意図している。たとえば、学術研究に関する文書や、あらかじめその用語を十分に理解できると思われる利用者を対象として想定したコンテンツでは、それらの用語の使用を妨げない。

ソリューション
1) 省略語が最初に出現した箇所で、abbr 要素またはacronym要素によって正式な名称等を明示する。
例1 <abbr title="Japanese Standards Association、日本規格協会">JSA</abbr>のサービスを利用する
（＠＠＠読み上げ要チェック＠＠＠）
（＠＠＠XHTMLもOKか要チェック＠＠＠）

2) tableのセルで省略語を定義する場合には、abbr 属性で指定する。
abbr 属性を指定できる要素は、th、tdのみである点に注意する。
例1 <th abbr=” JSA#”>日本規格協会</th>
（＠＠＠読み上げ要チェック＠＠＠）
（＠＠＠XHTMLもOKか要チェック＠＠＠）

3) 想定する利用者にとって専門用語、流行語、俗語がわかりにくいとおもわれる場合には、少なくとも初めて出現した箇所でその説明を提供する。
例1 <p><a name="return_netjunky" href="#netjunky">ネットジャンキー</a>だ。</p>
：
　　　　　　　：
<a name=” netjunky”>ネットジャンキーは、インターネットに熱中している人を指す言葉です<a>
<a href=” #return_netjunky”>本文に戻る</a>

（※梅垣注：HTML1.1 では name 属性ではなく id 属性なので、そのことを追記する）

4) 読みが難しいと思われる場合には、5.4のソリューションを併用する。

注意事項

なし

5.9 d　読みの難しいと考えられる言葉の多用禁止
想定する利用者にとって、読みの難しいと考えられる言葉（固有名詞など）は、多用しないことが望ましい。使用するときは、初めて記載されるときに読みを明示しなければならない。"
( 対応：JIS X8341-3:5.9 d)

背景と問題点
読みの難しい言葉とは、姓名、社名、地名などの固有名詞、難読語などがある。これらの言葉を用いていると、読み方がわからず混乱することがある。また、スクリーンリーダーで正しく読み上げられず意味が伝わらないことが考えられる。

関連する要素、属性及び宣言
ruby

技術解説
読み方が難しい言葉に読み方に関する読みを提供すると、文書が読みやすくなり、スクリーンリーダーでの読み上げも改善される可能性がある。

ソリューション
1) XHTML1.?では、rubyを用いて読みを示す
Ruby Annotation W3C Recommendation 31 May 2001 　http://www.w3.org/TR/ruby/を参照する。
例1 (改変するひつようあり)
<ruby xml:lang="ja">
<rbc>
<rb>斎</rb>
<rb>藤</rb>
<rb>信</rb>
<rb>男</rb>
</rbc>
<rtc class="reading">
<rt>さい</rt>
<rt>とう</rt>
<rt>のぶ</rt>
<rt>お</rt>
</rtc>
<rtc class="annotation">
<rt rbspan="4" xml:lang="en">W3C Associate Chairman</rt>
</rtc>
</ruby>

ただし、ruby は HTMLでは利用できない。また、主な日本の音声ブラウザでは ruby 要素を正しく扱うことができず、2度読み上げてしまう等の問題があるため、今後の音声ブラウザの対応状況を見極めてこのソリューションを使うべきである。

2) HTMLでは、カッコ書きなどで読みを示す。
例1 武者小路実篤（むしゃのこうじさねあつ）
注意事項

5.9 e　単語途中のホワイトスペースの禁止
表現のために単語の途中にスペース又は改行を入れてはならない。
( 対応：JIS X8341-3:5.9 e)

背景と問題点
　単語の途中にスペースや改行があると、スクリーンリーダーはそれを一つの単語として認識できず正しく音声合成することができない。
関連する要素、属性及び宣言
br
技術解説
　日本語を一時的に縦書き表記するために、単語の１文字づつをbr要素で強制的に改行したり、文字間隔を調整するためにスペース（全角スペースを含む）を挿入すると、スクリーンリーダーは正しくその単語を音声合成できず、利用者は理解できないことがある。

ソリューション
1) 縦書きが必要な場合は、スタイルシートで制御する。
ただし、現在の多くのブラウザでは縦書き表示を正しく表示できないことがあるので、正しく表示できるまでは2のソリューションをもちいる。
2) 縦書きが必要な箇所では、文字を画像化し、alt属性を付加する。
注意事項

5.9.f 図記号とイラストレーション
ウェブコンテンツは、文章だけでなく、分かりやすい図記号、イラストレーション、音声などを合わせて用いることが望ましい。
( 対応：JIS X8341-3:5.9 f)
背景と問題点
　知的な障害がある人がウェブページを使う場合だけでなく、一般の利用者が使う場合にも図記号やアイコン、イラストなどが適切だと使いやすく、認知的負担を軽減することができる。
関連する要素、属性及び宣言
img object
技術解説
　ウェブページを使いやすく、わかりやすくするためにはテキストだけでなく、目印となる統一的なアイコンや画像、わかりやすい図記号などが有効である。
ソリューション
1) テキストのみのウェブページを避け、分かりやすい図記号、イラストレーション、アイコンなどの視覚的な目印を与える。
2）報知音によってボタンをクリックしたことを知らせたり、適切な効果音によって操作を支援する。
注意事項
画像や音声は、視覚、聴覚障害のある人にとっては扱いにくい場合もあるので、その使い方には十分注意する必要がある。

6. 情報アクセシビリティの確保・向上に関する全般的要件
　ウェブサイトのアクセシビリティを向上させるためには，企画，設計，政策および運用までの幅広い工程での配慮が重要である。各工程での配慮事項の一部を以下に説明する。
（1）企画工程では，特定のプラグイン（JavaScript，Javaアプレット，Flash，PDFほか）などの利用が情報を表現する上で必要かどうかを検討し，使う場合には，それが使えない利用者に対して同等の情報を提示できるよう検討する必要がある。また，要素技術レベルの流れ作業的なアクセシビリティ対応に陥らないよう，利用者の心身特性や利用環境を理解することが重要である。
（2）設計工程では，ウェブサイト全体が分かりやすい構造になっているか，利用者の記憶に頼らず操作ができるか，認知面での配慮が必要である。また，サイト全体で共通に使用するテンプレートなどもアクセシビリティを考慮して設計する必要がある。
（3）制作工程では，制作者のスキルに依存せず，またチェック漏れを少なくするために，ウェブガイドラインを元にしたチェックリストを作成する。また，チェックツールを用いると文法チェックが効果的に行える。
（4）運用工程では，利用者から寄せられるウェブサイトへの要望や改善提案などは定期的に収集し，ページレベルで対応できるものは反映を行うことが必要である。

6.1企画・制作に関する要件（JIS X 8341-3:6.1）
ウェブコンテンツの情報アクセシビリティが容易に維持できるよう企画・制作しなければならない。
ウェブコンテンツを自動的に生成するプログラムには，アクセス可能なウェブコンテンツを生成する機能を装備する。

背景と問題点
　ウェブコンテンツの制作段階で，各ページ単位でアクセシビリティの対策を考えても，サイト全体のアクセシビリティを均一に保つことは困難である。また，効率的にすべてのアクセシビリティの要件を満たすことが難しくなる。また，後工程にいくほど個々のページをアクセシビリティ対応することになるので,コストもかかる。
　効率的かつ効果的に実施するには，企画・制作工程などウェブサイト構築の早い段階で，アクセシビリティの配慮を検討する。企画工程では，サイト全体で共通とするアクセシビリティの方針を定め，できるだけ早いうちに具体的に反映する。
　これにより，個々の工程ごとの単発的な対応でなく，サイト全体で共通のナビゲーションやフォーマットをアクセシブルにできる。
　利用者情報などをデータベースで管理する場合には，データが集積すればするほどアクセシビリティ対応を後付するのは難しくなる。
　電子商取引のような利用者の入力に対応して，ウェブページを自動的に生成するようなウェブプログラムを有するウェブサイトの場合は，生成されたコンテンツもアクセシビリティの用件を満たすように，自動生成を行うプログラムにアクセシビリティ機能を装備することが重要である。
　こうした取組みを実現するために，ウェブサイトの関係者全員がアクセシビリティについて正しく理解することにより，効率的かつ効果的に対処できる。
　サイト制作を外注する場合，最初のサイト構築は外注先が行っても，情報更新など運用は発注元が行う場合がある。その際，サイト全体を運用しやすいように企画段階から考慮しておかないと，アクセシビリティを維持することが難しくなる。

関連項目
なし

技術解説
・ウェブサイトの情報アクセシビリティが人や組織によらず容易に維持できるよう，デザインガイドラインを作成し，その中でアクセシビリティを実現・管理する方法を具体的に記述する。
・画像情報をデータベースで管理する場合には，入力時に画像データとともにテキスト入力欄を付記して登録するようにしておくと，alt属性として活用できる。
・ CMS (Content Management System) など，ウェブコンテンツを自動的に管理，生成するソフトウェアを採用する場合は，アクセシビリティの維持，管理を効率的に行えるものを採用する。例えば，コンテンツを登録する画面で，アクセシビリティ・チェック機能を利用できるソフトウェアを採用する。
・サイト全体で共通に使用するフォーマット（画面デザイン・HTMLテンプレートなど）を制作する場合は，アクセシビリティについて考慮し，制作する。
・自動的にアクセシビリティを確保できるような編集ツールが存在する場合は，その使用を制作者に義務づけるか，アクセシビリティのチェックツールが存在する場合は，その使用を制作者に義務づける。
・ウェブサイトにおけるアクセシビリティに関する基本的な考え方，方針，具体的な推進方法などを日付や作成部門名／作成者を付記して文書化し，ウェブサイトの関係者全員が参照できるようにする。
・ウェブサイトの関係者が，アクセシビリティに関する教育を受講する。
・サイト制作を外注する場合，発注元もアクセシビリティの基本的な用件を学び，企画段階から参画すると，サイト全体の構造などを理解しやすく，アクセシビリティに対応できるだけでなく，運用しやすいウェブサイトが構築できる。
・ウェブサイトを新規制作する場合は，サイト全体をアクセシブルなものにすべきであるが，既存のサイトを修正する場合には，利用者に閲覧されやすい上位階層から下位階層へ，情報の重要度が高いものから低いものへ，またアクセス数の高いものから低いものへ，など優先度の高いものからアクセシビリティ対応を行う。

6.2保守及び運用に関する要件（JIS X 8341-3:6.2）
ウェブコンテンツを保守及び運用するときは，情報アクセシビリティの品質を確保し，向上させなければならない。
　
背景と問題点
ウェブコンテンツの保守及び運用工程で，アクセシビリティを考慮せずに情報を追加・削除・更新してしまうと，サイト構築時にはアクセシビリティに配慮されていても，次第にサイト全体がアクセシブルでなくなってしまう。これは，(1)アクセシビリティを維持しにくいサイト構造・ページ構成である，(2)保守，運用担当者のアクセシビリティに対する理解やスキルが不足している（人事異動などで手法やノウハウが継承されないことも含む），(3)アクセシビリティ維持のための予算や工数などが確保できていない，などさまざまな原因がある。

関連項目
なし

技術解説
・ウェブサイトの情報アクセシビリティが人や組織によらず容易に維持できるよう，保守及び運用のためのアクセシビリティチェック項目を検討し，チェックリストとして明文化する。
・ウェブサイトにおけるアクセシビリティに関する基本的な考え方，方針，具体的な推進方法などを日付や作成部門名／作成者を付記して文書化し，ウェブサイトの関係者全員が参照できるようにする。
・保守及び運用作業において，アクセシビリティが確保しにくい場合は，ウェブサイトの企画・制作部門と連携し，より効率的に確実にアクセシビリティを確保できるようにする。
・アクセシビリティのチェックツールが存在する場合は，それを日々の作業で励行する。
・ウェブサイトの関係者が，アクセシビリティに関する教育を受講する。

6.3検証に関する要件（JIS X 8341-3:6.3）　
ウェブコンテンツの企画・制作を行う者は，ウェブコンテンツがこの規格の要件を満たしていることを検証しなければならない。

背景と問題点
　サイト全体で共通に使用するフォーマット (画面デザイン・HTMLテンプレートなど) を制作する場合，そのフォーマットでアクセシビリティを確保する。そうでないと，各ページの制作段階で，個別に対応する必要が生じ，場合によっては，大きな修正作業が発生してしまうことになる。
　企画・制作・保守・運用のすべての工程で，アクセシビリティの評価，検証を行うことで，効率的にアクセシビリティを実現できる。

関連項目
なし

技術解説
・評価・検証作業を効率的に実施するため，高齢者・障害者支援技術，チェックツールを適宜組み合わせて，利用するとよい。
・評価・検証作業を複数人で実施する場合は，アクセシビリティを一定のレベルにそろえるため，検証方法を定期的に調整し，チェックリストなどを作成する。また，チェックリストは，適宜，更新しておく。
・各工程に適した評価・検証手法を選択する。
(1)企画工程
　評価できるウェブコンテンツがないので「質問法」が中心になる。
(2)設計工程
　機能仕様書，ユーザインタフェース仕様書などを「洞察法」で評価できる。
(3)詳細設計段階
　評価用のプロトタイプ，β版，公開版ができれば，「洞察法」に加え，「観察法」，「実験的方法」が可能になる。
質問法（ヒヤリング）には，1.質問紙調査(アンケート調査)，2.インタビュー/グループインタビュー，3.個人面接　などがある。
洞察法には，1.ヒューリスティック評価，2.認知的ウォークスルー　などがある。
観察法には，1.行動観察，2.ユーザタスク分析　などがある。
実験的方法には，1.パフォーマンステスト，2.プロトコール解析　などがある。
・チェックツールと人手による評価・検証手法を併用し，効率良く確実にアクセシビリティを向上させる。
(1)アクセシビリティ専用チェックツールとして，以下のものがある。
　・WebInspector（富士通）　http://design.fujitsu.com/jp/universal/assistance/
　・Web Accessibility Toolbar（インフォアクシア）　http://www.infoaxia.com/tools/wat/index.html
　・aDesigner（日本IBM）　http://www.research.ibm.com/trl/projects/acc_tech/adesigner.htm
　・LIFT for Macromedia Dreamweaver（ソシオメディア）　http://www.sociomedia.co.jp/lift/
　・ウェブヘルパーASP（アライド・ブレインズ）　http://www.aao.ne.jp/author/webhelper/index.html
　例：alt属性の有無など，HTMLファイルの記述を機械的に確認するときに効果的である。
　参考：HTML文法チェックツール (「Another HTML-lint」など) でもチェック可能な項目がある。
(2)人手による評価・検証手法として，以下のようなものがある。
　・グレースケールで表示しても，内容が伝わるか確認する。
解説：ウェブの画面を画像データとして保存し，画像編集ソフトなどでグレースケールに変換する。これにより，明度の違いだけで内容が把握できることを確認する。
・文字色と背景色の組み合わせをチェックする。
・キーボードのみで操作ができるか確認する。特に次の4つのポイントでチェックする。
1.「上矢印」「下矢印」キーによる画面スクロールが可能か。
2.「Tab」キーによるキーボード・フォーカスの移動が可能か。全てのリンク及び入力項目に，正しい順序で移動できるようにする。
3.リンクやコマンドは，「Enter」キーで実行できるか。フォーカスの移動ではなく，「Enter」キーを押すまで，実行しない。
・音声ブラウザを使用し，正しく読み上げられるか確認する。
　解説：alt属性の内容の適切さなど，チェッカーツールで判定できない問題を確認するとき，効果的である。
・ブラウザの設定を変更し，内容が伝えられることを確認する。
1.グラフィックス表示をオフにし，代替表示されるalt属性のテキストだけで情報が伝えられるか。
2.サウンド出力をオフにし，重要な情報を伝えられるか。
3.スタイルシートをオフにし，ページが読めるか。
4.画面表示を白黒反転などさせてページが読めるか。
　参考：Microsoft Windows の場合，[コントロールパネル] の[ユーザー補助]の[画面]で[ハイコントラスト]を選択する。

6.4フィードバックに関する要件（JIS X 8341-3:6.4）
ウェブコンテンツの企画・制作を行う者は，利用者の意見を収集する窓口を用意し，利用者からの意見をウェブコンテンツの情報アクセシビリティの確保・向上に活かさなければならない。
　
背景と問題点
　ウェブサイトは，情報を追加，削除，更新しながら常に変化していくものである。
　更新時のウェブサイトの情報が見やすく，わかりやすく，操作しやすいかウェブサイト提供者側でチェックするとともに，利用者からの意見や要望などを広く収集する必要がある。
　さらに企画・制作の工程でそれらに的確に対応できる体制・手法などを確保しておく必要がある。

関連項目
なし

技術解説
・利用者が，ウェブサイトの管理者へ容易に意見，要望，質問ができるようにする。
・利用者から収集した意見を，関係者が適切に把握し，効率的かつ効果的に対処できるようにする。
・利用者の様々な状況に合わせ，電子メール，ウェブのフォーム，電話，ファックスなど，複数の意見収集窓口を用意する。

6.5サポートに関する要件（JIS X 8341-3:6.5）　
利用者とコミュニケーションが取れるよう，問い合わせ先をウェブコンテンツ上の分かりやすい位置に明示しなくてはならない。
　
背景と問題点
　ウェブサイトは，情報を追加，削除，更新しながら常に変化していくものである。
　更新時のウェブサイトの情報が見やすく，わかりやすく，操作しやすいかウェブサイト提供者側でチェックするとともに，利用者からの意見や要望などを広く収集する必要がある。
　それには，利用者が容易に問い合わせできるようその方法をウェブサイトに明示にすることは重要である。