resources/ja/criterions.yml
criterions:
1-1-1: &c1-1-1
code: 1-1-1
name: 非テキストコンテンツ
guideline: *g1-1
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/text-equiv-all.html
url_as: http://waic.jp/docs/as/info/201406/7.1.1.1.html
summary: |
利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されている。
doc: |
「非テキストコンテンツ」というのは、端的には画像、動画、音声です。またフォームの入力欄も非テキストコンテンツです。本達成基準では、こういった非テキストコンテンツを知覚できない利用者に対しての対応を求めています。非テキストコンテンツを知覚できない利用者の例は、画像、動画であれば、視覚障害者（全盲、ロービジョン、高齢者）。音声であれば、聴覚障害者があたります。こういった利用者に向けて、非テキストコンテンツには、非テキストコンテンツを理解あるいは識別できる代替テキストを付与してください。
収録済みの動画の場合は、[1.2.1]、[1.2.2]、[1.2.3]、[1.2.4]、[1.2.5]、[1.2.6]、[1.2.7]、[1.2.8]を参照してください。
ライブ動画の場合は、[1.2.4]を参照してください。
収録済みの音声の場合は、[1.2.1]、[1.2.8]を参照してください。
ライブ音声の場合は、[1.2.9]を参照してください。
入力欄などのフォームの部品に関しては、[1.3.1]、[2.4.6]、[3.3.2]を参照してください。
画像の場合は、本項目を参照してください。
画像の代替テキストはaltと呼ばれるHTMLの属性値を用いて設定します。
画像化された文字（文字画像）であれば、原則、画像と一致するaltを付与してください。あわせて、本当にその文字を画像化すべきか、よく吟味してください。
装飾目的の画像の場合、altを空することで、支援技術がこの画像を無視できるようになります。この場合でも<code><img src="" alt=""></code>とするようにして、<code><img src=""></code>というように、alt属性値そのものを省略しないようにしてください。なおHTML5以降においては、alt省略の例外がありますが、この例外を適用するためには、HTML5以降の仕様をよく理解した上で適用してください。
<code>alt=" "</code>など空白文字をaltにいれておくと、スクリーンリーダごとに対応が異なるので、装飾目的の画像の場合は、空白文字でなく空文字にするほうがベターです。全角空白や&nbsp;は、空白文字の扱いにすらならないので、これらの文字のみでaltとするのは避けてください。
ちなみに、<code>role="presentation"</code>というように、装飾目的であることを属性値で明示すると、このアクセシビリティチェッカーのチェック時に警告が出なくなりますが、決して<code>role="presentation"</code>の濫用を推奨するものではありません。
なお装飾目的の画像については、CSSで背景として設定することも有効ですが、逆に意味のある画像をCSSの背景画像にしないように注意してください[F3]。
低速回線環境の利用者が、画像表示をオフにしていることがあります。適切なaltは、「画像をあえて表示するかどうか」の判断にもなるので、なるべく丁寧にいれてください。
画像が存在するが、付近に画像と重複する文字列がある場合、altを省略することが有効な場合があります（Aさんの画像があり、その付近に「Aさん」と書いてあるような場合、「Aさん」あるいは「Aさんの画像」といったaltは省略したほうが、スクリーンリーダには読みやすい場合があります）。
「画像化された文字」と「画像」の判別をつけやすくするため、「写真：XX」というように接頭辞をつけたり「XXの写真」というように説明的なaltを心がけると良いです。たとえば「和菓子」というaltは、「『和菓子』という文字を画像化」したのか、「和菓子の写真」なのか判断を悩ませることがあります。
グラフやチャートの画像など複雑な情報を提供している画像については、それが何のグラフやチャートであるかを説明したaltをつけてください（例：「6月、7月、8月の売上のグラフ」）。複雑な情報を提供している画像は、まず、その画像を識別できるようにしておくこと必要があります。その上で、付近にtableでマークアップした表や画像の内容を詳述するようにしましょう。
画像が、リンクやボタンなどの操作の対象である場合は、さらに注意が必要です。丁寧なaltを心がけてください。画像をリンクの操作対象としている場合は、[2.4.4]を参照し、リンクの目的を明記するようにしてください。
Google Mapの場合、視覚障害者が扱うことは難しいのですが、すくなくともiframeのtitle属性で「Google Map」と説明をしておくとよいでしょう。
地図の画像には、とりあえず識別できるように「XXの地図」というaltをつけましょう。ただし付近にテキストによる経路説明等があれば、このaltは空にしても致命的なバリアではないでしょう。付近に経路説明等がなく、しかも地図の画像であることを明示していなければ、ひとに尋ねることもできないので、確実にバリアなので修正しましょう。
なにかの器具の操作の仕方を説明するgifアニメーションは、「器具の操作方法を説明するアニメーション」というような代替テキストをあてることで、画像を識別できるようにした上で、本文で機能を詳述すれば、本達成基準を満たします。
なお「CAPTCHA」「試験目的の画像」など、altには、いくつかの例外があります。くわしくは1.1.1の解説書を呼んでください。
1-2-1: &c1-2-1
code: 1-2-1
name: 音声のみ及び映像のみ (収録済)
guideline: *g1-2
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/media-equiv-av-only-alt.html
summary: |
収録済の音声しか含まないメディア及び収録済の映像しか含まないメディアについての配慮。
doc: |
視覚障害のある利用者は、映像から情報を知覚できません。
聴覚障害のある利用者は、音声から情報を知覚できません。
こういった場合、テキストデータを用意することで、それぞれの利用者が、映像や音声で提供されている情報を得ることができるようになります。
講演の収録音声などは、書き起こしテキストを用意することで、「同等の情報」を提供していると言えるようになります。テキスト起こしをする際、「聴衆のざわめき」「（笑い）」など、なるべく詳述する必要があります。
音声のない映像のテキスト起こしをする際は、画面で起こっていることを、なるべく詳述する必要があります。可能であれば、画面で何が起こっているかの音声解説による説明があると、なおよいでしょう[1.2.5]。
1-2-2: &c1-2-2
code: 1-2-2
name: キャプション (収録済)
guideline: *g1-2
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/media-equiv-captions.html
summary: |
同期したメディア（e.g. 音声を伴った映像）に含まれているすべての収録済の音声コンテンツに対して、キャプションが提供されている。
doc: |
聴覚障害者は映像の中で音声を取得できません。画面の進行に合わせて音声を文字化した情報提供や手話通訳が必要になります。
「キャプション」は、映画字幕のように話者の発話内容だけを表したものを意味しません。誰が話しているのか、どんな効果音が鳴ったのか、など映像を理解するために必要な情報を、画面の状況にあわせて（同期して）提示したものを指します。つまり映画字幕のようなものがあるだけでは、本達成基準は達成できません。
ちなみに「クローズドキャプション」は、表示非表示を切り替えられるキャプションで、「オープンキャプション」は、動画内に画像化された文字として表示されるキャプションを意味します（ニュース番組等のテロップを想像すると良いでしょう）。
1-2-3: &c1-2-3
code: 1-2-3
name: 音声解説、又はメディアに対する代替 (収録済)
guideline: *g1-2
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/media-equiv-audio-desc.html
url_as: http://waic.jp/docs/as/info/201406/7.1.2.3.html
summary: |
同期したメディアに含まれている収録済の映像コンテンツに対して、時間依存メディアに対する代替コンテンツ又は音声解説が提供されている。
doc: |
視覚障害者は映像の中で視覚的に提供されている情報を知覚できません。映像を理解するためには、映像の内容を書き起こしたテキストまたは音声解説（副音声）が必要です。
講演の収録映像などは、書き起こしテキストを用意するとよいでしょう。テキスト起こしをする際、「聴衆のざわめき」「（笑い）」など、視覚障害者が、映像を理解するのに必要な情報は詳述する必要があります。話者の発話のみの単純な書き起こしテキストを用意しただけでは、本達成基準は適合となりません。
書き起こしテキストを用意しない場合は、画面で何が起こっているかの音声解説による説明をいれてください。この音声解説も、視覚障害者が動画を理解するために、誰が話しているのかなど、詳述することを求められます。
本達成基準を適合とするためには、上記のどちらかを満たす必要があります。
1-2-4: &c1-2-4
code: 1-2-4
name: キャプション (ライブ)
guideline: *g1-2
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/media-equiv-real-time-captions.html
summary: |
同期したメディアに含まれているすべてのライブの音声コンテンツに対してキャプションが提供されている。
doc: |
聴覚障害者は映像の中で音声を取得できません。画面の進行に合わせて音声を文字化した情報提供や手話通訳が必要になります。
本達成基準ではライブ映像へのキャプション付与を義務付けています。キャプションに関しては、[1.2.2]を参照してください。
1-2-5: &c1-2-5
code: 1-2-5
name: 音声解説 (収録済)
guideline: *g1-2
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/media-equiv-audio-desc-only.html
summary: |
同期したメディアに含まれているすべての収録済の映像コンテンツに対して、音声解説が提供されている。
doc: |
視覚障害者は映像の中で視覚的に提供されている情報を知覚できません。映像を理解するためには、映像の内容を書き起こしたテキストまたは音声解説（副音声）が必要です。
[1.2.3]では、書き起こしテキストか音声解説のいずれかを用意すれば、達成となりますが、本達成基準を満たすためには、収録済みのすべての映像コンテンツに対して、音声解説の付与を義務付けています。これは、できるだけ書き起こしテキストからでなく、映像そのもののアクセシビリティを確保する観点からと考えられます。
1-2-6: &c1-2-6
code: 1-2-6
name: 手話 (収録済)
guideline: *g1-2
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/media-equiv-sign.html
summary: |
同期したメディアに含まれているすべての収録済の音声コンテンツに対して、手話通訳が提供されている。
doc: |
聴覚障害者は映像の中の音声を取得できません。画面の進行に合わせて音声を文字化した情報提供や手話通訳が必要になります。
本達成基準では、収録済みの映像に対して、キャプションだけでなく、手話通訳の付与を求めます。手話には、イントネーションや感情表現など、キャプションより多くの情報を含めることができるため、よりよい情報提供と言えるものです。
1-2-7: &c1-2-7
code: 1-2-7
name: 拡張音声解説 (収録済)
guideline: *g1-2
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/media-equiv-extended-ad.html
summary: |
前景音の合間が、音声解説で映像の意味を伝達するのに不十分な場合、同期したメディアに含まれているすべての収録済の映像コンテンツに対して、拡張音声解説が提供されている。
doc: |
視覚障害者は映像の中で視覚的に提供されている情報を知覚できません。映像を理解するためには、映像の内容を書き起こしたテキストまたは音声解説（副音声）が必要です。
[1.2.3]で求められる「音声解説」を、ページに存在するすべての同期したメディアに対して求めています。[1.2.3]で求められている内容としては、会話と会話の間などで説明を補う形でも良いのですが、本達成基準の「拡張音声解説」では、動画をいったん停止するなどして、状況を理解するのに十分な音声解説を提供することをもとめています。
1-2-8: &c1-2-8
code: 1-2-8
name: メディアに対する代替 (収録済)
guideline: *g1-2
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/media-equiv-text-doc.html
summary: |
すべての収録済の同期したメディア及びすべての収録済の映像しか含まないメディアに対して、時間依存メディアに対する代替コンテンツが提供されている。
doc: |
視覚障害者は映像の中で視覚的に提供されている情報を知覚できません。映像を理解するためには、映像の内容を書き起こしたテキストまたは音声解説（副音声）が必要です。
聴覚障害者は映像の中の音声を取得できません。画面の進行に合わせて音声を文字化した情報提供や手話通訳が必要になります。
ページ内のすべての、音声、映像（音声なし）、映像（音声あり、いわゆる「同期したメディア」）は、これらを正確に表現した「時間依存メディアの代替コンテンツ」を用意してください。「正確」にというのは、いわば脚本のように、詳しい状況説明を含んだ文章である必要があります。
メディアがインタラクティブな要素を持っている場合は、そのインタラクティブ性を備えている必要があります。たとえば、動画ではあっても、ある場面で進行がいったん停止し、閲覧者に選択肢を提示。その、選択肢によって以降の展開が変わるようなコンテンツであれば、その展開をハイパーリンクなどで提示して、はじめて「正確」といえます。
1-2-9: &c1-2-9
code: 1-2-9
name: 音声のみ (ライブ)
guideline: *g1-2
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/media-equiv-live-audio-only.html
summary: |
ライブの音声しか含まないコンテンツに対して、それと同等の情報を提示する、時間依存メディアの代替コンテンツが提供されている。
doc: |
聴覚障害者は音声を取得できません。本達成基準では、[1.2.8]で求められるような「時間依存メディアの代替コンテンツ」をライブ音声に適用しています。ラジオ放送などライブ音声について正確な代替コンテンツを用意することが求められていますが、これは極めて難しい達成基準でしょう。
1-3-1: &c1-3-1
code: 1-3-1
name: 情報及び関係性
guideline: *g1-3
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html
url_as: http://waic.jp/docs/as/info/201406/7.1.3.1.html
summary: |
何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。
doc: |
ある利用者にとって、なんらかの情報の役割が理解できるとき、そのほかの利用者にも、その情報の役割を理解できるようにしてください。晴眼者であれば、大きい文字を見たら、「これは見出しだ」と理解できますが、スクリーンリーダを利用している視覚障害者には、「文字の大きさ」という情報が与えられないため、何が見出しなのかわからなくなってしまいます。
たとえば見出し(<code><h*></code>、<code><th></code>など)でマークアップすることで、機械可読性が確保され、様々な利用者に対応できるようになります。
また、「<code><p></code>の文字を大きくして見出しとする」、「文字を小さくするために<code><h6></code>を使う」などの実装はプログラムによる解釈を阻害するものなので不適合になります。
プログラムによる解釈を担保した実装をするのが難しい文書の場合、「行頭のアスタリスクは見出しのレベルを表します」「括弧内にお名前を入力してください」といった、テキストによる説明を明示することで達成できますが、原則、HTMLの意味のあるマークアップを優先してください。
<!-- HTML 4.01 及び XHTML 1.x を含むマークアップ言語の場合、b要素およびi要素は、強調目的の場合はstrong/em要素に置き換えてください。HTML5では、本チェッカーでは、警告を出しません。 -->
strike要素、basefont要素、center要素、font要素は、代わりにCSSを用いて構造と表現を分離するようにしてください。sやstrikeの場合はdel要素に置き換えても良いでしょう。
見出しはh1〜h6が、順序良く降順になっているべきです。h1が大見出し、h2が中見出し、h3が小見出しだとすると、h1のつぎにh3が現れるのは不自然です。
formを使う時には、labelを使うことで、formのアクセシビリティが向上します。labelは実はHTML4.01では、複数のラベル可能要素を内包しても文法違反ではありませんが、アクセシビリティ・サポーテッドがあまり確かでないので、特に理由がなければ1対1対応にしておいたほうが安全です。
多くのスクリーンリーダが、input要素等のtitle属性値をラベルとして読み上げますが、labelもtitleも書いている場合は、これを一致させておいたほうが安全です（現時点ではほとんどの場合、titleが優先して読み上げられるようです）。その観点からツールチップ表示を期待したtitle属性に関しては、注意してください。また、ツールチップ表示を期待している場合は、hoverでしか表示しないことが多く、focusでは表示されないことが多いようです。この点にも注意を払っておいてください。
formを用いる際、placeholder属性値をlabelとして用いることはできません。placeholder属性は入力されると、見えなくなくなるので、使いづらく、また読み上げ対象にならない環境もあります。
<!-- WAI-ARIA属性のaria-labelとaria-labelledbyの普及も進んでいますが、現時点では、スクリーンリーダのことを考えるとlabel（あるいはtitle）があるほうが安全です。 -->
form類は、checkboxやradioなどは、labelでマークアップして、関連付けをしてください。こうすることで、スクリーンリーダでは、それぞれの項目がわかりやすくなり、マウスなどのポインティング・デバイスを使いづらい利用者にとっては、クリックしやすくなります。
1-3-2: &c1-3-2
code: 1-3-2
name: 意味のある順序
guideline: *g1-3
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/content-structure-separation-sequence.html
summary: |
コンテンツが提示されている順序が意味に影響を及ぼす場合には、正しく読む順序はプログラムによる解釈が可能である。
doc: |
視覚障害者が用いるスクリーンリーダは、画面内の配置を利用者に伝えることができません。スクリーンリーダは、ほぼHTMLの記述順にテキスト等を読み上げます。こういった利用者に配慮するため、順序に意味のあるコンテンツについては、注意が必要です。
CSSのpositionやfloatプロパティによる表示位置の制御の際、それが意味に影響を与えるかどうかをよく吟味してください。
「博物館」を「博 物 館」と記述してしまうようなこと（いわゆる「単語の泣き別れ」）や、改行や空文字を駆使したレイアウトをして、意味の理解を妨げないようにしてください。改行で行の終端をそろえたり、空文字で行等をそろえていると、スクリーンリーダで情報を取得しづらくなるだけでなく、文字サイズ変更時などにも、たいへん読みづらくなります。また、検索エンジン対策上もけっしてプラスには働きません。
他方、スペースを用いて整形するのが自然な場合もあります。エラーチェックに引っかかることがありますが、法人格と法人名を「株式会社 みやこ酒店」というような表記を禁止する必要はないでしょう。
マークアップエンジニアがHTMLの可読性維持のために、altなどの属性値中で、改行による整形をする場合、一部のスクリーンリーダで改行ごとに意図しない読み上げを行う事例もあることを覚えておくと良いでしょう。
表組みの場合は線形情報にして意味が通るようにすることが望ましいです。表組みを線形情報にするのは、技術者でなければ難しいかもしれません。原則は「左上から右下に向かって読んでいく」と考えてください。また、じっさいのスクリーンリーダで確認するのも有効です。
1-3-3: &c1-3-3
code: 1-3-3
name: 感覚的な特徴
guideline: *g1-3
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/content-structure-separation-understanding.html
summary: |
コンテンツを理解し操作するための説明は、形、大きさ、視覚的な位置、方向、又は音のような、構成要素が持つ感覚的な特徴だけに依存していない。
doc: |
視覚障害者は、形や位置関係から情報を取得することができません。
「右の写真は……」「次のページへ行くには、右のボタンを押してください。前のページに戻るには、左のボタンを押してください」というようなものが挙げられるでしょう。ただし「写真の中の右上の人物は……」というような情報提供は、これにあたりません。
1-4-1: &c1-4-1
code: 1-4-1
name: 色の使用
guideline: *g1-4
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html
summary: |
色が、情報を伝える、動作を示す、反応を促す、又は視覚的な要素を判別するための唯一の視覚的手段になっていない。
doc: |
全盲および色覚異常のある視覚障害者は、色を知覚し判別することができないか、難しい場合があります。色に依存した情報提供を避けましょう。
たとえば「赤文字の項目は必須です」「カレンダの赤いマスは休日です」というような、必須項目の提供の仕方はNGです。
全盲視覚障害者向けには、項目付近に「（必須）」と明示したり、カレンダの休日を別の手段で提供する必要があるでしょう。色覚異常のある利用者に対しては、色だけでなくたとえば「ダイアの形をしたアイコンは休日です」というようにしても、「色のみに依存しない情報提供」と言えるでしょう。だたし、ダイアの形にしても、全盲視覚障害者への配慮の必要は残ります。
なお、この達成基準は、かならずしも、カレンダの休日を赤で表してはいけないとは<strong>言っていない</strong>ことに注意すべきです。色がわからない人にとっては、きちんとわかるように提供しつつも、色がわかる人がわかりやすいということを妨げる必要はありません。
1-4-2: &c1-4-2
code: 1-4-2
name: 音声の制御
guideline: *g1-4
level: *lv1
non-interference: true
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/visual-audio-contrast-dis-audio.html
summary: |
ウェブページ上にある音声が自動的に再生され、3秒より長く続く場合、その音声を一時停止又は停止するメカニズム、もしくはシステム全体の音量レベルに影響を与えずに音量レベルを調整できるメカニズムが利用できる。
doc: |
自動的に再生される音声が、停止、あるいは音量調整ができないと、視覚障害者のスクリーンリーダ利用を致命的に阻害することがあるため本項目は「非干渉（必ず達成しないといけません）」です。
音声がなっているため、スクリーンリーダでは、音声をどうやって止めたらいいか、音量をどうやって下げたらいいかわかりづらくなることもあります。
ちなみに、YouTubeは自動再生です。……が、視覚障害者にとっては、自動再生がありがたい（＝リンクを踏むだけで、情報を得る流れを得られる。しかもYouTubeとはそういうものだ、という了解もある）という側面もあります。この自動再生の利便性は、もしかするとYouTube以外でもありえることかもしれないですが、普通のウェブページでは、注意するようにしてください。
1-4-3: &c1-4-3
code: 1-4-3
name: コントラスト (最低限)
guideline: *g1-4
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html
summary: |
テキスト及び文字画像の視覚的提示に、少なくとも 4.5:1 のコントラスト比がある。
doc: |
色覚異常のある利用者、弱視の視覚障害者、高齢者は、文字色と背景色が、近い色でデザインされていると、文字を読みづらくなります。このコントラスト比は、4.5:1を最低限保つ必要がある、とするのが本達成基準です。
意味のある文字について、前景色と背景色が、明確に異なっているのでなければ、注意をした方が良いです。微妙な箇所については、コントラスト比を計測してください。とくに、本文欄、メニュー類は注意を払う必要があります。コントラスト比のチェックツールはインターネットを検索することで無料のツールを見つけられるでしょう。
チェック項目の中では、ウェブページ側がコントラストを変更する仕組みを提供していればよい[G174]としていますが、弱視の利用者はそもそもOSレベルで白黒反転をしていることもあり、理想的なのは、十分なコントラストを確保することでしょう。
色弱者向けに、特定の色の組み合わせに配慮が必要です。<!-- 注意すべきなのは、赤と緑、オレンジと黄緑、緑と茶、青と紫、ピンクと白または灰色、緑と灰色・黒、赤と黒、ピンクと青です。 -->
なお、たいへん大きな文字や、ロゴ、意味のない文字であれば、コントラストの配慮要件から外れます。たいへん大きな文字とは、Understanding WCAG2.0には、「18ポイント又は太字の14ポイント」程度とあり、これは印刷した場合は、およそ6mm程度の大きさの文字なのですが、ディスプレイにおいては、こういった絶対値は扱いづらいので、注意してください。なお、日本語の場合はそれぞれ太字でなければ22ポイント、太字であれば18ポイントが基準とされています[G18]。大きな文字であれば、コントラスト比は3:1でもよいということになっています。
1-4-4: &c1-4-4
code: 1-4-4
name: テキストのサイズ変更
guideline: *g1-4
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html
url_as: http://waic.jp/docs/as/info/201406/7.1.4.4.html
summary: |
キャプション及び文字画像を除き、テキストは、コンテンツ又は機能を損なうことなく、支援技術なしで 200％ までサイズ変更できる。
doc: |
弱視の視覚障害者および高齢者は、小さい文字を読むことが困難です。こういった利用者が文字のサイズを変更することを妨げないようにしてください。
古いブラウザでは、CSSで、pxやcmなどで文字サイズを指定すると、ブラウザの機能で文字の拡大縮小ができないことがあったため、パーセント、emなどの相対的な文字サイズ指定をしたほうがよいとされています[C12][C13][C14]。
キャプション及び文字画像を除き、テキストは、コンテンツ又は機能を損なうことなく、支援技術なしで200％までサイズ変更できるようにしてください。「支援技術なし」とは、要はブラウザでの拡大を念頭におけばよく、ウェブページ側が、かならずしも文字サイズコントローラを提供する必要はありません。
文字を拡大した際に、文字が何かの要素に隠れてしまって、読めなくなる、ということがないようにしてください。幅の狭いinputなどは要注意です。横スクロールの発生にも注意を払うとなお良いでしょう。
1-4-5: &c1-4-5
code: 1-4-5
name: 文字画像
guideline: *g1-4
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/visual-audio-contrast-text-presentation.html
summary: |
使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが情報伝達に用いられている。
doc: |
テキストデータはもっともアクセシブルな情報の形式です。テキストデータであれば、スクリーンリーダでの読み上げ、スムーズな拡大縮小、コピーアンドペースト、機械翻訳などさまざまな可用性を発揮します。文字を画像にするということは、このテキストデータの便利さを現じてしまうことなので、なるべく文字画像は用いないことが推奨されています。
本達成基準では、CSSによる修飾や、フォントの選択で、意図した視覚提示が可能であれば、極力テキストを用いることを求めています。
Understanding WCAG2.0では、ロゴ、書体サンプルなどを「視覚的な効果が必要不可欠」と定義していて、これらは文字画像を使って良いとしています。しかし、たとえば「どんな環境でもアンチエイリアスをかけた表示をしたい」「この見出しはどうしてもこのフォントで表現したい」なども、「視覚的な効果をCSSで表現できない」としてよいようです。
訴求効果のためのバナー画像を置く場合（リンク）、特定の見出しを特に目立たせたい場合（構造）など、重要な場所で使うことが多い手法ですので、文字画像を使う場合は、altを忘れないようにしましょう。
JavaScriptやCSSなどで、画像からaltを抽出し、画像と置き換える仕組みを提供する達成方法[C30]もありますが、そういったUIが、利用できるべき利用者に対して、わかりやすいことは少ないので、おすすめしません。
1-4-6: &c1-4-6
code: 1-4-6
name: コントラスト (高度)
guideline: *g1-4
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/visual-audio-contrast7.html
summary: |
テキスト及び文字画像の視覚的提示には、少なくとも 7:1 のコントラスト比がある。
doc: |
色覚異常のある利用者、弱視の視覚障害者、高齢者は、文字色と背景色が、近い色でデザインされていると、文字を読みづらくなります。この達成基準では、[1.4.3]の基準を厳しく、7:1のコントラスト比を求めます。なお大きい文字については、[1.4.3]では、3:1のコントラスト比を要求していましたが、本達成基準では、大きい文字でも4.5:1のコントラスト比を要求します。
1-4-7: &c1-4-7
code: 1-4-7
name: 小さな背景音、又は背景音なし
guideline: *g1-4
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/visual-audio-contrast-noaudio.html
summary: |
収録済の音声しか含まないコンテンツで、(1) 前景に主として発話を含み、(2) 音声CAPTCHA又は音声ロゴではなく、かつ、(3) 例えば、歌やラップなどのように、主として音楽表現を意図した発声ではないものについては、配慮がある。
doc: |
視覚障害者は、聴覚からの情報取得が重要であるため、聴覚に頼った情報提供には、ちょうどテキストにおける視覚的情報提供のコントラスト配慮（[1.4.3]）と同じように、聞こえやすい情報提供を心がけてください。
背景音をミュート（前景音のみに）できるようにすることなどを求められますが、そもそも小さい背景音にするか、背景音を無しにしておく方がシンプルでしょう。
「小さい背景音」というのは前景音（主たる発話）と背景音の音量の差が20デシベルあればよい、ということになっていますが、ウェブコンテンツ担当者が配慮をすることは難しい領域なので、アクセシビリティ方針を立てる時点で、動画コンテンツを含むことがわかっている場合は、あらかじめ動画担当者と共有しておいてください。
なにかの説明を動画でするのであれば、そもそも背景音を用いない、という方針を立ててしまうのもよいでしょう。
1-4-8: &c1-4-8
code: 1-4-8
name: 視覚的提示
guideline: *g1-4
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html
summary: |
テキストブロックの視覚的提示において、配慮がある。
doc: |
認知の障害、言語の障害、及び学習障害、あるいはロービジョンの視覚障害者にとっては、テキストのレイアウトに問題があると、理解しづらい場合があります。一行が長すぎると、文字を追うのが困難になることがあります。また行間が狭いと理解しづらい場合があります。こういった箇所について、いくつかの配慮があるとよいでしょう。
文字のコントラストを、利用者が自由に選べるようにしてください。これはほとんどの場合、白い背景に対して、黒い文字で記述（つまり無指定）すれば満たせます[C25][G156]。
段落中の行送りは、少なくとも1.5文字分確保してください。そして、段落の間隔は、その行送りの少なくとも1.5倍以上確保してください[C21]。
また、文字サイズを利用者が変更することを妨げないでください（[1.4.4]も参考にしてください）。
1-4-9: &c1-4-9
code: 1-4-9
name: 文字画像 (例外なし)
guideline: *g1-4
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/visual-audio-contrast-text-images.html
summary: |
文字画像は、純粋な装飾に用いられているか、テキストの特定の表現が伝えようとする情報にとって必要不可欠である場合（ロゴタイプなど）に用いられている。
doc: |
[1.4.5]の解説を先に読んでください。[1.4.5]では、CSSで得たい視覚効果が得られないのであれば、画像化された文字を使っても良いとしていますが、本達成基準では、書体サンプル、ロゴタイプなど「どうしても視覚的な効果が本質的」である場合を除いて、画像化された文字の利用を禁じている、と理解してください。つまり、文字についての装飾はCSSでできる範囲にとどめるようにすれば、本達成基準を満たせます。
2-1-1: &c2-1-1
code: 2-1-1
name: キーボード
guideline: *g2-1
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/keyboard-operation-keyboard-operable.html
url_as: http://waic.jp/docs/as/info/201406/7.2.1.1.html
summary: |
コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボードインタフェースを通じて操作可能である。ただし、その根本的な機能が利用者の動作による始点から終点まで続く一連の軌跡に依存して実現されている場合は除く。
doc: |
視覚障害者はマウスポインタを見られないため、マウスを利用できません。また、上肢障害者や肢体不自由の利用者は、身体的理由からマウスなどのポインティングデバイスを利用できない場合があります。こういった利用者はキーボードインタフェースをもちいて、ウェブページを利用します。
キーボードインタフェースには、ソフトウェアキーボードのように物理的でないキーボードも含みます。重度の身体障害の場合、視線入力やスイッチをもちいて、ソフトウェアキーボードを操作している場合があります。
こういった利用者への配慮から、ウェブページはキーボードのみで操作できることが望ましいとされています。
<!-- ただし、文字の手書き入力など、一連の軌跡に依存している場合などは、マウスなどのポインティングデバイスによる操作が前提であるため、本達成基準では例外としています。 -->
エンターキーを検知しないJavaScriptのonclick()による実装や、<code><div></code>や<code><span></code>など、通常フォーカス対象とならない要素を操作対象としている場合にも注意してください。
ドライビングシミュレータなど、「特定のタイミング」に必然性がある場合は、コンテンツの本質であるといえるでしょう。
2-1-2: &c2-1-2
code: 2-1-2
name: キーボードトラップなし
guideline: *g2-1
level: *lv1
non-interference: true
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/keyboard-operation-trapping.html
url_as: http://waic.jp/docs/as/info/201406/7.2.1.1.html
summary: |
キーボードインタフェースを用いてキーボードフォーカスをそのウェブページのあるコンポーネントに移動できる場合、キーボードインタフェースだけを用いてそのコンポーネントからフォーカスを外すことが可能である。さらに、修飾キーを伴わない矢印キー、 Tab キー、又はフォーカスを外すその他の標準的な方法でフォーカスを外せない場合は、フォーカスを外す方法が利用者に通知される。
doc: |
[2.1.1]で示したような利用者は、キーボードに依存したウェブページ利用をしています。こういった利用者にとって、キーボードで操作できないウェブページは大変使いづらいものですが、とりわけこの「キーボードトラップ」には注意が必要です。
「キーボードトラップ」とは、ある要素にフォーカスが移ってしまうと、そこからキーボード操作で抜け出せなくなるような実装を指します。モーダルウィンドウなどを作る場合は、それを閉じる操作がマウスだけでなく、キーボードでも行えなければいけません。また、その操作方法を利用者に提示してください。
「キーボードのみで操作できること」は、ウェブアクセシビリティの基本的な要件です。本項目は「非干渉（必ず達成しないといけません）」です。
2-1-3: &c2-1-3
code: 2-1-3
name: キーボード (例外なし)
guideline: *g2-1
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/keyboard-operation-all-funcs.html
summary: |
コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボードインタフェースを通じて操作可能である。
doc: |
[2.1.1]で示した、キーボードによる操作を確保することの重要性とその対処方法を先に読んでください。その上で、[2.1.1]で示したような、「マウスの手書き入力」「ドライビングシミューレータ」などの例外を禁止するのが、本達成基準です。
2-2-1: &c2-2-1
code: 2-2-1
name: タイミング調整可能
guideline: *g2-2
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/time-limits-required-behaviors.html
summary: |
コンテンツに制限時間を設定する場合は、配慮がある。
doc: |
制限時間のあるコンテンツというのは、「スクロールする文字列」「アニメーション」「カルーセル（スライドショー）」「時間制限のあるコンテンツ」です。
全盲、ロービジョン、巧緻性障害、及び、認知能力の低下している利用者などは、制限時間のあるコンテンツをまったく利用できない場合があります。読むのに時間のかかる利用者にとっては、情報がスクロールしたり、自動的に切り替わってしまうと、情報を取得できません。
コンテンツを操作あるいは読み取るのに必要とする制限時間を解除できるか、制限時間が十分に長い(20時間程度)か、制限時間を10倍以上の長さに設定可能にしてください。ただし、制限時間がコンテンツの必須要件(オークションなど)の場合は除きます。
動画、音声、カルーセルなどは、制限時間を延長や調整という措置は考えづらいのですが、一時停止と再開ができれば、本達成基準を満たすことになります（[G4]）。なお、カルーセルに関しては、[2.2.2]で類似達成項目があり、利用者が停止できなければ、レベルAが取得できないので、注意してください。
利用者の読む時間を制限してしまうため、meta要素のrefreshによるリダイレクト等の秒数指定は、しないようにしてください。
動画や音声は本質的に「制限時間のあるコンテンツ」ですが、1.2「時間依存メディア」で定められている対応をしていれば、制限時間についての問題にも対応できるといえます。
2-2-2: &c2-2-2
code: 2-2-2
name: 一時停止、停止、非表示
guideline: *g2-2
level: *lv1
non-interference: true
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/time-limits-pause.html
url_as: http://waic.jp/docs/as/info/201406/7.2.2.2.html
summary: |
動きのある、点滅している、スクロールする、又は自動更新する情報には、配慮がある。
doc: |
動きのある、点滅している、スクロールする、又は自動更新する情報は、その情報に注意を逸らされてしまわないように、一時停止、停止、非表示することができる必要があります。
読字障害、知的障害、注意力欠如障害のある利用者は、こういったコンテンツのために、他のコンテンツを利用できなくなる恐れがあるため、本項目は「非干渉（必ず達成しないといけません）」です。「他のコンテンツ」については「達成基準 2.2.2 を理解する」の「全面広告」に示唆のある事例が上がっているのでみると良いです。
文字をスクロールさせるmarqueeや、文字を点滅させるblinkは、用いないようにしてください。
動画、音声、カルーセル等は、動きのあるコンテンツです。
動き、点滅のあるコンテンツが5秒以内の場合は、この達成基準を満たすことになりますが、「点滅」は、ときとして「閃光」と同じ弊害をもたらすことがあり、5秒以内であっても、「閃光」的な点滅は許されません。「閃光」については、[2.3.1]を参照してください。
動画や音声は本質的に「制限時間のあるコンテンツ」ですが、1.2「時間依存メディア」で定められている対応をしていれば、制限時間についての問題にも対応できるといえます。
2-2-3: &c2-2-3
code: 2-2-3
name: タイミング非依存
guideline: *g2-2
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/time-limits-no-exceptions.html
summary: |
タイミングは、コンテンツによって提示されるイベント又は動作の必要不可欠な部分ではない。ただし、インタラクティブではない同期したメディア及びリアルタイムのイベントは除く。
doc: |
全盲、ロービジョン、認知能力の低下、又は運動障害のある利用者は、すばやく状況を判断して、操作をするということが難しい場合があります。
[2.1.1]は、情報の取得に対しての達成基準でしたが、本達成基準では、操作を必要とする項目についての達成要件を定めています。
カルーセルが切り替わっていく際に、良いタイミングでクリックしないと、目的のページにたどり着けない、といような実装はNGです。
たとえばとあるページのお知らせ一覧は、3分ごとに最新の状態に自動更新される（制限時間のあるコンテンツ）が、そのページ以外に、自動更新されずにすべてのお知らせ記事にアクセスできる仕組みを設けていれば、制限時間のあるコンテンツは「コンテンツ利用について、必要不可欠」でなくなります。
2-2-4: &c2-2-4
code: 2-2-4
name: 割り込み
guideline: *g2-2
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/time-limits-postponed.html
summary: |
割り込みは、利用者が延期、又は抑制することができる。ただし、緊急を要する割り込みは除く。
doc: |
認知能力の低下、又は注意力欠如のある利用者は、コンテンツへの集中を妨げられると、たいへん困ることがあります（[2.2.2]も参照してください）。本達成項目では、緊急時を除き、コンテンツを閲覧している状況になんらかの割り込みをかけることを禁じています。
割り込みというのは、利用者の意図しないバナー広告表示や画面の再描画などがあたります。こういった割り込みは、利用者が延期、又は抑制できるようにしてください。
緊急時というのは、緊急警報やシステムの脆弱性検知の警告を指し、これらの割り込みは禁じません。
2-2-5: &c2-2-5
code: 2-2-5
name: 再認証
guideline: *g2-2
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/time-limits-server-timeout.html
summary: |
認証済のセッションが切れた場合は、再認証後でもデータを失うことなく利用者が操作を継続できる。
doc: |
障害があったり、高齢であったりすると、なにかと理解や操作に時間が必要です。
システム（CMS等）によっては、セキュリティの確保のため、長時間操作がない場合、ログアウトさせるような実装をしている場合があります。また、同じアカウントでのログインを許さないシステムでは、同時に2名が同じアカウントでログインした場合、先にログインしていたものを強制的にログアウトさせることもあるでしょう。こういった措置の際、再ログイン（再認証）時にもデータを失わず操作が継続できるようにしてください。
2-3-1: &c2-3-1
code: 2-3-1
name: 3回の閃光、又は閾値以下
guideline: *g2-3
level: *lv1
non-interference: true
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/seizure-does-not-violate.html
summary: |
ウェブページには、どの1秒間においても3回を超える閃光を放つものがない、又は閃光が一般閃光閾値及び赤色閃光閾値を下回っている。
doc: |
発作性障害のある利用者は、閃光を放つ視覚的なコンテンツによって発作（てんかん）を引き起こすことがあります。こういった発作の危険のあるコンテンツは、発作により、ウェブページをまったく利用できなくなる恐れがあるため、本達成基準は「非干渉（必ず達成しないといけません）」になっています。
本達成基準では、閃光の度合いについて例外を求めていますが、閃光の詳しい定義については、「達成基準 2.3.1 を理解する」を参照してください。
画面ももちろん、動画のなかでも注意をする必要があるので、動画を再生して確認してください。
視覚障害のある利用者や高齢者の中には、画面の一部を極めて大きく拡大していることがあります。こういう場合、1ピクセルの点滅が閃光として機能してしまう場合がありますので、小さい範囲であっても、注意するようにしてください。
2-3-2: &c2-3-2
code: 2-3-2
name: 3回の閃光
guideline: *g2-3
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/seizure-three-times.html
summary: |
ウェブページには、どの1秒間においても3回を超える閃光を放つものがない。
doc: |
閃光のもたらす問題については[2.3.1]を参照してください。本達成基準では、[2.3.1]の例外を認めない、より厳しい達成基準になっています。
2-4-1: &c2-4-1
code: 2-4-1
name: ブロックスキップ
guideline: *g2-4
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/navigation-mechanisms-skip.html
url_as: http://waic.jp/docs/as/info/201406/7.2.4.1.html
summary: |
複数のウェブページ上で繰り返されているコンテンツのブロックをスキップするメカニズムが利用できる。
doc: |
スクリーンリーダを使用している視覚障害者は、すばやく画面を把握することができないため、順繰りに音声で聞いて、ウェブページを利用しています。文字を極端に拡大している利用者も、ページスクロールが増え、目的の場所にたどり着くのに時間を要します。肢体不自由の障害のある利用者は、キーボードインタフェースでしかコンテンツを操作できないため、自在にページ内を移動するのは困難です。こういった利用者への配慮として、「ブロックスキップ」があります。
ブロックスキップとは、ウェブページ内のなんらかのまとまりを読み飛ばしたり、移動したりすることを指します。
たとえば、すべてのページに存在するグローバルメニューは、スクリーンリーダ利用者にとっては、なんども同じものを読み上げるため、煩わしい情報提供になりますが、こういった部分をスキップできるようにすることで、情報にアクセスしやすくできます。
具体的な実装方法としては、[G1]や[H69]があります。
frame要素やiframe要素はまとめてブロックスキップの対象とすることが可能な場合があります。なんのframe/iframeなのか、title属性できちんと情報提供することでブロックスキップの判断のたすけになります。
ブロックスキップ用のリンクは、なにもグローバルメニューや広告領域だけでなく、たとえばたくさんの情報を延々と読み上げ続けるTwitterやFacebookの埋め込みなども、その対象とすると、便利が良いでしょう。
2-4-2: &c2-4-2
code: 2-4-2
name: ページタイトル
guideline: *g2-4
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html
summary: |
ウェブページには、主題又は目的を説明したタイトルがある。
doc: |
認知の障害、短期記憶障害、及び読字障害のある利用者は、「いま何を目的としているか」を把握できない場合があります。またスクリーンリーダ利用者は、いまどのページにいるのかがわかりにくい場合があります。こういった場合でも、ウェブページのタイトルが的確であれば、理解の助けになります。
ウェブページはサイト内でできるだけ固有のタイトルを持たせてください。サイト内で共通のタイトルにしてしまうと、利用者は、サイト内の現在位置を把握しづらくなります。titleは、サイト内の現在位置の把握に役立つ他、検索エンジン対策上もたいへん効果が高い箇所です。
2-4-3: &c2-4-3
code: 2-4-3
name: フォーカス順序
guideline: *g2-4
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html
url_as: http://waic.jp/docs/as/info/201406/7.2.4.3.html
summary: |
ウェブページが順を追ってナビゲートできて、そのナビゲーション順が意味又は操作に影響を及ぼす場合、フォーカス可能なコンポーネントは、意味及び操作性を損なわない順序でフォーカスを受け取る。
doc: |
スクリーンリーダや画面拡大をしている利用者はタブキーによるフォーカスの移動を行うことが多くあります。タブキーによるフォーカスの移動は、素直なHTMLであれば、HTMLの記述順になりますが、tabindexを与えることで、変更もできてしまいます。tabindexを与える場合は、意味の把握を妨げるような順序設定にならないように注意するようにしてください。
また、モーダルダイアログを作る場合などは、注意を要します。モーダルダイアログはスクリーンリーダを使っていない利用者にとっては、モーダルダイアログを閉じるまで他の動作はできません（というか、そういうものを「モーダルダイアログ」と呼びます）。スクリーンリーダを使っている利用者にとっても、同じように振舞うべきであり、タブキーでフォーカス移動をしていると、モーダルを抜けられてしまう、というようなことがあってはならないのです。
2-4-4: &c2-4-4
code: 2-4-4
name: リンクの目的 (コンテキスト内)
guideline: *g2-4
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html
url_as: http://waic.jp/docs/as/info/201406/7.2.4.4.html
summary: |
それぞれのリンクの目的が、リンクのテキスト単独で、又はリンクのテキストとプログラムによる解釈が可能なリンクのコンテキストから判断できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。
doc: |
リンク文字列は、そのリンク先がなんであるかを明示するべきです。スクリーンリーダの利用者はタブキー押下だけでリンクのみを辿って文章を読んでいくということをしばしば行いますが、こういう場合に、それぞれのリンク文字列が固有でなく「続きを読む」や「詳しくはこちら」となっていると、リンク先がなんなのかを把握しづらくなります。
ただ本達成基準では、文脈に頼ったリンク文字列の提供はよしとされています。たとえば書籍の内容がHTML、PDF、MP3で提供されている時に、最初のHTMLだけは書籍のタイトルをリンク文字列に含めているが、以降は「PDF」「MP3」と読み上げることが良しとされています。
また、<strong>同じ段落内や<code><h*></code>の一群であれば</strong>、いわゆる「こちらリンク」さえも許されます（[G53]）が、「こちらリンク」については、そもそもあまり用いないほうが良いでしょう。
致命的なバリアではありませんし、JISなどの規格の中でも規定はないのですが、リンク先がPDF等のダウンロード用のファイルの場合は、ファイルであること、ファイルサイズも併記しておくと、誰にとっても便利が良いでしょう。
リンク先の消失などで、そもそもリンクが切れている場合、アクセシビリティの文脈で問うべき問題ではないかもしれませんが、使いづらいので改善しましょう。
2-4-5: &c2-4-5
code: 2-4-5
name: 複数の手段
guideline: *g2-4
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/navigation-mechanisms-mult-loc.html
summary: |
ウェブページ一式の中で、あるウェブページを見つける複数の手段が利用できる。ただし、ウェブページが一連のプロセスの中の1ステップ又は結果である場合は除く。
doc: |
どんな利用者でもコンテンツにたどり着きやすくするために、あるウェブページを見つける複数の手段(例:グローバルメニュー、サイトマップ、サイト内検索)が利用可能にしてください。なお、一連のプロセスであるショッピングカートの途中のページなどを除きます。
ただし、目次ページより下位のページが、何度もクリックしないとたどり着けないページになっていたら、やはりサイト内検索の実装がのぞましいでしょう。またそういったコンテンツが存在してしまう前に、そもそもサイトの構造をシンプルにすべきでもあります。
2-4-6: &c2-4-6
code: 2-4-6
name: 見出し及びラベル
guideline: *g2-4
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/navigation-mechanisms-descriptive.html
summary: |
見出し及びラベルは、主題又は目的を説明している。
doc: |
見出し（<code><h*></code>や<code><th></code>）及びラベル（<code><label></code>やリンク文字列など）は、主題又は目的をわかりやすく説明するようにしてください。ここでは「わかりやすさ」が重要です。
見出しはセクションの主題を的確に説明し、ラベルはインタフェースコンポーネントを的確に説明することがもとめられています。なお、[1.3.1]では、見出し及びラベルが誰にでも知覚可能であることが求められ、[3.3.2]では、コンポーネントについての可視のラベル又は説明の存在を求めています。
formのlabelに関しては、たとえば「ふりがな」を要求するような場面で、カタカナかひらがなのいずれかの入力を求める場合は、labelもしくは付近でその説明を行うなどしてください。もし、システム上の制約がないのであれば、カタカナかひらがなかの入力について、両方受け付ける実装を考えてもいいかもしれません。
2-4-7: &c2-4-7
code: 2-4-7
name: フォーカスの可視化
guideline: *g2-4
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html
url_as: http://waic.jp/docs/as/info/201406/7.2.4.7.html
summary: |
キーボード操作が可能なあらゆるユーザインタフェースには、フォーカスインジケータが見える操作モードがある。
doc: |
まず[2.1.1]を先に読み、キーボードでの操作を確保することの重要性を確認してください。キーボードでしか操作できない利用者にとって、フォーカスの可視化は、操作対象を把握するために非常に重要な役割を果たします。
2-4-8: &c2-4-8
code: 2-4-8
name: 現在位置
guideline: *g2-4
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/navigation-mechanisms-location.html
summary: |
ウェブページ一式の中での利用者の位置に関する情報が利用できる。
doc: |
サイト内での自分の位置が確認できるように、いわゆる「パンくず（あるいはトピックパス）」を用意してください。また、サテライトサイトなど、親サイトを持つ場合は、親サイトへのリンクも広義の「現在位置」理解の助けになるでしょう。たとえば大学のサイトが別にある学部のサイトが、大学本体へのリンクを持っているような事例が考えられます。
2-4-9: &c2-4-9
code: 2-4-9
name: リンクの目的 (リンクのみ)
guideline: *g2-4
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html
summary: |
それぞれのリンクの目的を、リンクのテキスト単独で特定できるメカニズムが利用できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。
doc: |
リンク文字列単独で、リンクの目的を理解できるようにしなければなりません。[2.4.4]と異なるのは文脈依存を許さない点です。[2.4.4]の「書籍」の例を再掲すると、HTML版、PDF版、MP3版はそれぞれ書籍名をリンク文字列内に持っている必要があります。「達成基準 2.4.4 を理解する」のドアの例の方が、理解しやすいかもしれません。
表題があってリンクされており、すこし紹介文があって、「続きを読む」というようにして、こちらも表題と同じところにリンクする、という実装はしばしばあります。この場合、「続きを読む」は、単独で理解可能なリンクとは言えません（ちなみに[2.4.4]では許容されます）。「続きを読む」を「{表題}の続きを読む」と記述すれば、「単独での理解が可能」なので、2.4.9は満たせます。しかし、スクリーンリーダーで、タブでリンクへとスキップしながら読んでいると似たような機能を連続して読み上げることになり少々煩わしくもあります。この場合「続きを読む」（もしくは「{表題}の続きを読む」）を、<code>aria-hidden="true"</code>や<code>tabindex="-1"</code>などして、読まないようにすると、タブキー押下の数が減って、音声環境での利用が快適になります。
ちなみに[3.2.4]では、「同じ機能を有するコンポーネントは一貫して識別できる」ことを求めていて、たとえばサイトのお問い合わせフォームへのリンクが「お問い合わせフォーム」だったり「お問い合わせはこちらから」だったりして統一されていないことを禁じています（つまり「お問い合わせフォーム」か「お問い合わせはこちらから」に一貫せよと言っています）。本達成基準としては、リンクの目的を理解するということは妨げていないと考えられますが、ただリンクの文字列が理解可能であっても、表記の揺れが利用者の利便性を損なうことがあるかもしれない、ということは意識する必要があるでしょう。
2-4-10: &c2-4-10
code: 2-4-10
name: セクション見出し
guideline: *g2-4
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/navigation-mechanisms-headings.html
summary: |
セクション見出しを用いて、コンテンツが整理されている。
doc: |
見出しの重要性については、[2.4.1]、[1.3.1]、[2.4.6]などを参照してください。
この達成基準がAAAであるのは、原稿が構造化されていない場合（手紙や引用文）など、コンテンツ製作者が恣意的に見出しを用いて構造化することができないような場合もあるからです（事例については「達成基準 2.4.10 を理解する」を参照してください）。
3-1-1: &c3-1-1
code: 3-1-1
name: ページの言語
guideline: *g3-1
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/meaning-doc-lang-id.html
url_as: http://waic.jp/docs/as/info/201406/7.3.1.1.html
summary: |
それぞれのウェブページのデフォルトの自然言語がどの言語であるか、プログラムによる解釈が可能である。
doc: |
HTMLのlangの指定で<code><html lang="ja"></code>のように、ウェブページのデフォルトの言語を指定しておくことで、ユーザエージェントや支援技術がコンテンツを正しく解釈することができるようになります。
多言語サイト構築の際など、ついこれを忘れて英語ページでもjaとしてしまうことがあるので要注意です。
3-1-2: &c3-1-2
code: 3-1-2
name: 一部分の言語
guideline: *g3-1
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/meaning-other-lang-id.html
url_as: http://waic.jp/docs/as/info/201406/7.3.1.2.html
summary: |
コンテンツの一節、又は語句それぞれの自然言語がどの言語であるか、プログラムによる解釈が可能である。ただし、固有名詞、技術用語、言語が不明な語句、及びすぐ前後にあるテキストの言語の一部になっている単語又は語句は除く。
doc: |
lang属性を明示することで、ユーザエージェントや支援技術がコンテンツを正しく解釈してくれることがあります。基本は日本語で書かれていて、一部、英語の文章を引用している場合などは、引用部分の言語をマークアップすると良いでしょう。
また、多言語サイトのheaderあたりによくある言語切り替えはa要素にそれぞれのlang属性を付けると良いでしょう。
3-1-3: &c3-1-3
code: 3-1-3
name: 一般的ではない用語
guideline: *g3-1
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/meaning-idioms.html
summary: |
慣用句及び専門用語を含めて、一般的ではない、又は限定された用法で使われている単語、又は語句の、明確な定義を特定するメカニズムが利用できる。
doc: |
一般的でない難しい用語（技術語、業界用語、言語特有の慣用句、リート語）は、その定義を参照できるようになっていることが望ましいです。Understandingの例では、「匙を投げる」が「スプーンを投げる」という意味でない事例を挙げていますが、こういった言葉に逐一注釈をしていくというよりも、そもそも難しい言葉を避けるという対応が求められていると考えたほうがシンプルかもしれません。
3-1-4: &c3-1-4
code: 3-1-4
name: 略語
guideline: *g3-1
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/meaning-located.html
summary: |
略語の元の語、又は意味を特定するメカニズムが利用できる。
doc: |
コンテンツ内に略語がある場合は、略語の元の語あるいは意味を知ることができようにしましょう。[3.1.3]とも関係があると言えます。
3-1-5: &c3-1-5
code: 3-1-5
name: 読解レベル
guideline: *g3-1
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/meaning-supplements.html
summary: |
固有名詞や題名を取り除いた状態で、テキストが前期中等教育レベルを超えた読解力を必要とする場合は、補足コンテンツ又は前期中等教育レベルを超えた読解力を必要としない版が利用できる。
doc: |
コンテンツが前期中等教育レベル（UNESCO基準、9年間の教育を受けたもの、なので、中学校3年生程度）の読解力で読めるようにしましょう。それを超える読解レベルを求めるときには、前期中等教育レベルの読解力で理解できる補足的コンテンツまたはバージョンを用意してください。
なお、どうやって前期中等教育レベルかどうかを判定するかですが、Understandingによれば、だいたいどの国にも判定計算式があるからそれを利用したらいいとなっています。しかし、日本語には、そのものズバリのものは今の所ない様子（インターネット上に研究の残滓は散見されます）。面白い試みとしては、<a href="https://jreadability.net">日本語の学習者と教師のためのWebシステム</a>があり、おそらくここで示されている「中級前半」程度であれば、ほどよろしいかとおもわれますが、これは利用規約によれば「教育・研究目的のみ」で許容されているようなので、商用利用は望めないでしょう。
3-1-6: &c3-1-6
code: 3-1-6
name: 発音
guideline: *g3-1
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/meaning-pronunciation.html
summary: |
文脈において、発音が分からないと単語の意味が不明瞭になる場合、その単語の明確な発音を特定するメカニズムが利用できる。
doc: |
日本語の例でいえば端的なものは人名や漢字の読み方がこれに当たるでしょう。rubyを付与したり、かっこで注釈を加えることが望ましいです。漢字の場合はそれで良いのですが、外国語の読み方などについて、手厚い対応としては、発音の音声ファイルを用意する対応も考えられます。
どの程度の漢字に読み仮名を振るかについては、[3.1.5]を準用して、前期中等教育レベル、というのがひとつの判断になると考えられますが、人名などはこの限りではないですし、じっさいのところ、中学校3年生レベルの漢字はそれなりに難しいこともあるので、このあたりは適宜判断が必要でしょう。
Understandingでは、文脈に依存した読み方（典型的な例は「方」を「かた」あるいは「ほう」と読む場合）について、言及があります。個別事例になりますが、「方」に関しては、スクリーンリーダはそれほど賢く判別はしてくれないのですが、しかしそれで意味がわからなくなるというほど致命的でもないため、問題は少ないと言えます。
いっぽう、これを「発音」の文脈に入れるべきではないかもしれませんが、日付をスラッシュで区切った場合は、分数に読まれることがあり、スクリーンリーダでのユーザビリティを高めるためには避けるとよいといわれることがあります。ただ、全盲視覚障害者もスラッシュ区切りが日付を表すことは知っているので、致命的であるとは言えません。
3-2-1: &c3-2-1
code: 3-2-1
name: フォーカス時
guideline: *g3-2
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html
summary: |
いずれのコンポーネントも、フォーカスを受け取ったときにコンテキストの変化を引き起こさない。
doc: |
フォーカスを受け取っただけで、なんらかの状況の変化を起こしてはいけません。フォーカスを受け取ったら、自動的に開くモーダルウィンドウや、フォーカスを受け取ったらページ移動が起こる、というのが不具合の例です。こういった振る舞いは、障害の有無にかかわらず、多くの利用者にとって予測が難しく、扱いづらいものです。
3-2-2: &c3-2-2
code: 3-2-2
name: 入力時
guideline: *g3-2
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html
summary: |
ユーザインタフェースコンポーネントの設定を変更することが、コンテキストの変化を自動的に引き起こさない。ただし、利用者が使用する前にその挙動を知らせてある場合を除く。
doc: |
ページ内の入力欄全てを入力したら自動的に送信するとか、チェックボックスやラジオボタンをチェックしたらページ移動するとか、そういったことをしてはいけません。
時々あるのは、selectのonchangeを拾ってページ移動するようなインタフェースです。マウスで操作している利用者にとっては、selectの3項目下を選択するというようなことができるのですが、キーボードの場合は、下キーを押した途端にonchange判定されてしまって、永遠に2個下に行けない、ということが起こる（ある意味「キーボードトラップ」になっているとも言えるでしょう）場合があります。こういった場合は、「実行ボタン」を付与する必要があるでしょう（ただし最近のUAではselectでスペースキーを押すことで、候補を展開できることがあるので、判断が分かれることがあります）。
この達成基準は[3.2.1]と似ていますが、状況の変化が予測可能で、制御可能であれば、許されることもあるという点で違います（フォーカスの場合は、予測や制御が本質的に難しい）。たとえばカレンダに予定を追加するフォームがある時、予定の種別をラジオボタンで選択すると、入力欄が動的に変化するような仕掛けは、予測可能で制御可能であると言えるでしょう。
また、クレジットカード番号など4桁ずつ入力する際、4文字入力したら次のフィールドに自動的にフォーカスを映すような挙動も、あらかじめ説明されている場合は許容されます。
3-2-3: &c3-2-3
code: 3-2-3
name: 一貫したナビゲーション
guideline: *g3-2
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/consistent-behavior-consistent-locations.html
summary: |
ウェブページ一式の中にある複数のウェブページ上で繰り返されているナビゲーションのメカニズムは、繰り返されるたびに 相対的に同じ順序で出現する。ただし、利用者が変更した場合は除く。
doc: |
広義にはグローバルナビゲーションを一定の位置に記述することですが、グローバルナビゲーション内の項目の順序についても、サイト内で一貫した順序であるべきという不適合事例が「達成基準 3.2.3 を理解する」に例示されているので注意してください。
たとえば決まった位置に「本文へ」のスキップリンクや検索窓を設置しておくことも重要です。こういったウェブページ一式内で共有されている項目の相対的な位置をみだりに変更しないでください。スクリーンリーダ利用者など視覚による情報取得ができない利用者にとっては、たいへん困る事態になります。
グローバルナビゲーションが、ドロップダウンメニューを持つことは禁じられていません。
3-2-4: &c3-2-4
code: 3-2-4
name: 一貫した識別性
guideline: *g3-2
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/consistent-behavior-consistent-functionality.html
summary: |
ウェブページ一式の中で同じ機能を有するコンポーネントは、一貫して識別できる。
doc: |
同じ機能を提供するリンクやボタンなどはウェブページ一式の中で一貫している必要があります。不適合事例で上がっている例が、「検索」ボタンと「探す」ボタンが同様の機能を提供している場合（英語ではfindとsearchで説明されています）ですが、これはラベルが異なっているためにNGとなります。
リンク先が同じでリンク文字列が異なる場合も注意の対象です（[G197]）。問い合わせページのリンク先が「問い合わせ」であったり「問い合わせフォーム」だったりすることは、NGです。
また、ウェブページ一式のトップページへのリンクが「トップ」だったり、「トップページへ」だったり、サイト名だったりすることがあります。コンテンツ内でこういったリンク先の表記揺れは避けるようにしましょう。
ページの上部にあるサイト名のaltを付与したロゴ画像がトップページのリンクになっていることは比較的よくある実装です。また、同時にパンくずのトップページへのリンクが、サイト名でないこともよくある実装です。解釈が揺れるところかもしれませんが、「サイト名ロゴをクリックするとトップページに行く」という機能の一貫性と、「パンくずでのTOPという文字がトップページに行く」という機能の一貫性が担保されていれば、この文字列が一致していなくてもよいと考えられます。「達成基準 3.2.4 を理解する」の「事例 3： 他のページへの一貫したリンクのラベル」を参照してください。
ちなみに[2.4.9]も確認してください。この「問い合わせ」の例では、ラベルが一致していないことで、本項目を満たせませんが、[2.4.9]で求められている「リンクの機能を理解する」という点では、問題がないとも言えます。
たとえば「記事の詳細を読むリンク」が「こちら」という一貫したラベルであるからよいと考えるのは[2.4.9]の観点から危険です。
3-2-5: &c3-2-5
code: 3-2-5
name: 要求による変化
guideline: *g3-2
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html
summary: |
コンテキストの変化は利用者の要求によってだけ生じるか、又は、そのような変化を止めるメカニズムが利用できる。
doc: |
状況になんらかの変化を起こしうる操作は利用者によって全て制御可能になっていることが望ましいです。
もし、なんらかの理由で、状況になんらかの変化を自動的に起こすような振る舞いがあったとしても、利用者に変化を伝え、利用者がその変化を止めることができるようにする必要があります。
リンクをクリックしたら、自動的に新しいタブ（ウィンドウ）を開くような実装をしてしまうと、利用者にとっては、自らの要求による変化でないので、NGになります。こういった実装が必要な場合は、あらかじめ「新しいタブを開くこと」を利用者に通知するようにしてください。
3-3-1: &c3-3-1
code: 3-3-1
name: エラーの特定
guideline: *g3-3
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/minimize-error-identified.html
url_as: http://waic.jp/docs/as/info/201406/7.3.3.1.html
summary: |
入力エラーが自動的に検出された場合は、エラーとなっている箇所が特定され、そのエラーが利用者にテキストで説明される。
doc: |
フォームに必須項目や所定の形式の値の入力を求める項目があり、ただしく入力されない限り送信を受け付けない場合は、利用者にわかりやすくエラーを表示するようにしてください。エラーを表示する際、たとえば入力されていない必須項目の背景色を変える<strong>だけ</strong>では、視覚障害者にとってエラーがわからないので、不十分です（これは色を変えてはいけない、ということは意味しません。色を明示することで晴眼者のユーザビリティは向上します）。また文章でエラーを説明する必要してください。
3-3-2: &c3-3-2
code: 3-3-2
name: ラベル又は説明
guideline: *g3-3
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/minimize-error-cues.html
url_as: http://waic.jp/docs/as/info/201406/7.3.3.2.html
summary: |
コンテンツが利用者の入力を要求する場合は、ラベル又は説明文が提供されている。
doc: |
利用者にフォームによる入力を求める際、どこに何を入力すべきなのか、わかりやすく情報提供してください。プログラムに解釈できる方法で提供することであればなおよいでしょう。具体的には<code><label></code>要素で各フォーム要素と関連付けることで、視覚障害者にとっても利用しやすいフォームを作ることができます。
また、説明や入力の事例などの掲載も好ましいですが、やりすぎるとかえって邪魔になるので、簡潔にするようにしてください。
必須項目がある場合は、なにが必須項目であるのか、わかりやすく情報提供してください。
なお、説明文や入力時の例を書く際は、入力欄より前に記載しておく方が、線形的に情報取得しているスクリーンリーダの利用者にとって、間違いが少ないです。
ここで言われているラベル又は説明は、入力対象の付近で、可視状態であることを求めます。極端に画面を拡大している利用者にとっては、遠くにある説明文は読めない場合があります。
3-3-3: &c3-3-3
code: 3-3-3
name: エラー修正の提案
guideline: *g3-3
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/minimize-error-suggestions.html
url_as: http://waic.jp/docs/as/info/201406/7.3.3.3.html
summary: |
入力エラーが自動的に検出され、修正方法を提案できる場合、その提案が利用者に提示される。ただし、セキュリティ又はコンテンツの目的を損なう場合は除く。
doc: |
入力内容にエラーがある時、どのように訂正したらいいかを説明することが望ましいです。ただ、Understanding WCAG2.0の事例では、「月を入力してください」に対して「12」を入力したユーザに「Januaryと入力してください」という事例を挙げていますが、あまり良い例ではないでしょう。むしろ、半角英数字での入力を求めている箇所を、全角文字で入力している場合にエラーを出すとして、「アルファベット（a-Z）および数字（0-9）で入力してください」とする、というあたりを参考にすると良いでしょう（エラーを出さず、入力を受け付けてしまって、半角英数字に変換してしまう方が、利用者の手間は少なくなるのですが、こういった対応は場合によります）。
少々分かりづらいのが[3.3.1]との違いです。[3.3.1]の主題はエラー箇所を明示することであって、エラーの修正方法を明示することではありません。
また、[3.3.1]でも、本達成基準でも、エラー箇所へのリンクを付与することが望ましいとされています。
3-3-4: &c3-3-4
code: 3-3-4
name: エラー回避 (法的、金融、データ)
guideline: *g3-3
level: *lv2
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/minimize-error-reversible.html
summary: |
利用者にとって法律行為もしくは金融取引が生じる、利用者が制御可能なデータストレージシステム上のデータを変更もしくは削除する、又は利用者が試験の解答を送信するウェブページでは、取消、チェック、確認のいずれかができるようにしてある。
doc: |
「法的なもの」、「金融取引」、「試験」など、利用者の入力によって重大な損失を引き起こしうるようなフォームは、送信を取り消したり、送信前に確認画面等を設ける必要があります。
3-3-5: &c3-3-5
code: 3-3-5
name: ヘルプ
guideline: *g3-3
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/minimize-error-context-help.html
summary: |
状況に応じたヘルプが利用できる。
doc: |
ラベル又は説明が全ての機能を説明するのに不十分な場合、別途ヘルプを設けることが望ましいです。ちなみにフォームの近くに説明文を書くことでも、本達成基準ではヘルプと見なしています。
3-3-6: &c3-3-6
code: 3-3-6
name: エラー回避 (すべて)
guideline: *g3-3
level: *lv3
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/minimize-error-reversible-all.html
summary: |
利用者に情報の送信を要求するウェブページでは、取消、チェック、確認のいずれかができるようにしてある。
doc: |
フォームは、送信時に取消や確認ができるようにしましょう。[3.3.4]では、利用者に重大な損失を引き起こす場合のみに限っていますが、本達成基準では、すべてのフォームに対してこれを求めます。
4-1-1: &c4-1-1
code: 4-1-1
name: 構文解析
guideline: *g4-1
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/ensure-compat-parses.html
summary: |
マークアップ言語を用いて実装されているコンテンツにおいては、要素には完全な開始タグ及び終了タグがあり、要素は仕様に準じて入れ子になっていて、要素には重複した属性がなく、どの ID も一意的である。ただし、仕様で認められているものを除く。
doc: |
ウェブコンテンツを記述するマークアップ（HTML）に誤りがないようにしてください。
このアクセシビリティチェッカーの解析以外にも<a href="https://validator.w3.org/nu/">Nu Html Checker</a>などを活用すると良いです。
4-1-2: &c4-1-2
code: 4-1-2
name: 名前 (name) ・役割 (role) 及び値 (value)
guideline: *g4-1
level: *lv1
url: http://waic.jp/docs/UNDERSTANDING-WCAG20/ensure-compat-rsv.html
url_as: http://waic.jp/docs/as/info/201406/7.4.1.2.html
summary: |
すべてのユーザインタフェース コンポーネント (フォームを構成する要素、リンク、スクリプトが生成するコンポーネントなど) では、名前 (name) 及び役割 (role) は、プログラムによる解釈が可能である。又、状態、プロパティ、利用者が設定可能な値はプログラムによる設定が可能である。そして、支援技術を含むユーザエージェントが、これらの項目に対する変更通知を利用できる。
doc: |
利用者の操作対象になるような要素は、名前、役割、値を持っている場合、プログラムが解釈できる必要があります。
値(value)の取得、変更などを、さまざまなユーザエージェントで可能にしてください。たとえば<code><a></code>によるリンク文字列は、プログラムで解釈可能です。フォームで入力欄を<code><textarea></code>にすれば、その値(value)は取得も変更もできます。<code><label></code>でラベルをマークアップすれば、入力欄についての説明をプログラムにより解釈可能になります。
普通にHTMLで要素を記述している場合、ここが問題になることは少ないです。しかし普通にHTMLを記述していても、<code><span></code>などがフォーカスを受け取って、JavaScriptなどで、コンテンツになんらかの変化をもたらすような実装をしている場合は要注意です。