参考資料

試験方法について

1 知覚可能

1.1 テキストによる代替

1.1.1 非テキストコンテンツ (A)

利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されている。

1.2 時間依存メディア

1.2.1 音声のみ及び映像のみ (収録済) (A)

収録済の音声しか含まないメディア及び収録済の映像しか含まないメディアについての配慮。

1.2.2 キャプション (収録済) (A)

同期したメディア(e.g. 音声を伴った映像)に含まれているすべての収録済の音声コンテンツに対して、キャプションが提供されている。

  • 同期したメディアが存在しない
    解説
    • 関連する達成基準が「適用なし適合」になります。
    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 時間依存メディア 時間依存メディアには代替コンテンツを提供すること。
    達成基準 キャプション (収録済)
    (1.2.2 A)
    同期したメディア(e.g. 音声を伴った映像)に含まれているすべての収録済の音声コンテンツに対して、キャプションが提供されている。
    解説: 達成基準 1.2.2 を理解する

    同期したメディア(e.g. 音声を伴った映像)に含まれているすべての収録済の音声コンテンツに対して、キャプションが提供されている。

  • 同期したメディアが存在するが、キャプションを提供している
    解説
    • 「キャプション」は、映画字幕のように話者の発話内容だけを表したものをささない。誰が話しているのか、どんな効果音が鳴ったのか、など映像を理解するために必要な情報を、画面の状況にあわせて(同期して)提示したものを指す。つまり映画字幕のようなものがあるだけでは、1.2.2は達成できない。
    • ちなみに「クローズドキャプション」は、表示非表示を切り替えられるキャプションで、「オープンキャプション」は、動画内に画像化された文字として表示されるキャプションを意味する(ニュース番組等のテロップを想像すると良いでしょう)。
    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 時間依存メディア 時間依存メディアには代替コンテンツを提供すること。
    達成基準 キャプション (収録済)
    (1.2.2 A)
    同期したメディア(e.g. 音声を伴った映像)に含まれているすべての収録済の音声コンテンツに対して、キャプションが提供されている。
    解説: 達成基準 1.2.2 を理解する

    同期したメディア(e.g. 音声を伴った映像)に含まれているすべての収録済の音声コンテンツに対して、キャプションが提供されている。

1.2.3 音声解説、又はメディアに対する代替 (収録済) (A)

同期したメディアに含まれている収録済の映像コンテンツに対して、時間依存メディアに対する代替コンテンツ又は音声解説が提供されている。

1.2.4 キャプション (ライブ) (AA)

同期したメディアに含まれているすべてのライブの音声コンテンツに対してキャプションが提供されている。

1.2.5 音声解説 (収録済) (AA)

同期したメディアに含まれているすべての収録済の映像コンテンツに対して、音声解説が提供されている。

1.2.6 手話 (収録済) (AAA)

同期したメディアに含まれているすべての収録済の音声コンテンツに対して、手話通訳が提供されている。

1.2.7 拡張音声解説 (収録済) (AAA)

前景音の合間が、音声解説で映像の意味を伝達するのに不十分な場合、同期したメディアに含まれているすべての収録済の映像コンテンツに対して、拡張音声解説が提供されている。

1.2.8 メディアに対する代替 (収録済) (AAA)

すべての収録済の同期したメディア及びすべての収録済の映像しか含まないメディアに対して、時間依存メディアに対する代替コンテンツが提供されている。

  • 音声、映像、同期したメディアが存在するが、正確な代替コンテンツを用意してある
    解説
    • ページ内のすべての、音声、映像(音声なし)、映像(音声あり、いわゆる「同期したメディア」)は、これらを正確に表現した「時間依存メディアの代替コンテンツ」を用意すること。「正確」にというのは、いわば脚本のように、詳しい状況説明を含んだ文章である必要がある。
    • メディアがインタラクティブな要素を持っている場合は、そのインタラクティブ性を備えている必要がある。たとえば、動画ではあるが、ある場面で進行がいったん停止し、閲覧者に選択肢を提示する。選択肢によって以降の展開が変わるようなコンテンツであれば、その展開をハイパーリンクなどで提示して、はじめて「正確」といえる。
    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 時間依存メディア 時間依存メディアには代替コンテンツを提供すること。
    達成基準 メディアに対する代替 (収録済)
    (1.2.8 AAA)
    すべての収録済の同期したメディア及びすべての収録済の映像しか含まないメディアに対して、時間依存メディアに対する代替コンテンツが提供されている。
    解説: 達成基準 1.2.8 を理解する

    すべての収録済の同期したメディア及びすべての収録済の映像しか含まないメディアに対して、時間依存メディアに対する代替コンテンツが提供されている。

1.2.9 音声のみ (ライブ) (AAA)

ライブの音声しか含まないコンテンツに対して、それと同等の情報を提示する、時間依存メディアの代替コンテンツが提供されている。

1.3 適応可能

1.3.1 情報及び関係性 (A)

何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。

  • 見出しタグ、強調タグなどを用いて、セマンティックなマークアップをしている
    解説
    • 情報の意味を要素の色、大きさ、位置のみで提供していないこと。文章はh*やstrongなどを用いて構造化し、CSSなしでもきちんと情報が伝わるようにすること。
    • b要素およびi要素は、強調目的の場合はstrong/em要素に置き換えてください。
    • u要素、s要素、strike要素、basefont要素、center要素、font要素は、代わりにCSSを用いて構造と表現を分離するようにしてください。sやstrikeの場合はdel要素に置き換えても良いでしょう。
    • 見出しはh1〜h6が、順序良く降順になっているべきです。h1が大見出し、h2が中見出し、h3が小見出しだとすると、h1のつぎにh3が現れるのは不自然です。
    • NGの例は「右の写真は……」「カレンダの赤いマスは……」「赤い文字の項目は必須項目です」というようなものが挙げられるでしょう。ただし「写真の中の右上の人物は……」というような情報提供は、これにあたらない。また、この達成基準は、かならずしも、カレンダの休日を赤で表してはいけないとは言っていないことに注意すべきです。色がわからない人にとっては、きちんとわかるように提供しつつも、色がわかる人がわかりやすいということを妨げる必要はありません。
    • 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)があるほうが安全です。
    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 適応可能 情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。
    達成基準 情報及び関係性
    (1.3.1 A)
    何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。
    関連項目
    解説: 達成基準 1.3.1 を理解する

    何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。

    アクセシビリティ・サポーテッド
  • tableが存在しない
    解説

    ドキュメントが存在しません

    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 適応可能 情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。
    達成基準 情報及び関係性
    (1.3.1 A)
    何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。
    解説: 達成基準 1.3.1 を理解する

    何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。

  • tableの各要素はthead、thなどを用いて適切にマークアップしている
    解説
    • 表組みの場合は線形情報にして意味が通るようにすることが望ましい。またthead、thなどを正しく使えているとなお良い。表組みを線形情報にするのは、技術者でなければ難しいかもしれません。原則は「左上から右下に向かって読んでいく」と考えてください。また、じっさいのスクリーンリーダで確認するのも有効です。
    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 適応可能 情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。
    達成基準 情報及び関係性
    (1.3.1 A)
    何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。
    解説: 達成基準 1.3.1 を理解する

    何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。

    アクセシビリティ・サポーテッド
  • formが存在しない
    解説

    ドキュメントが存在しません

    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 適応可能 情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。
    達成基準 情報及び関係性
    (1.3.1 A)
    何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。
    解説: 達成基準 1.3.1 を理解する

    何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。

  • formの各要素はlabelを用いて適切にマークアップしている
    解説
    • form類は、checkboxやradioなどは、labelでマークアップして、関連付けをおこなうこと。こうすることで、スクリーンリーダでは、それぞれの項目がわかりやすくなり、マウスなどのポインティング・デバイスを使いづらい利用者にとっては、クリックしやすくなります。
    • formに必須項目がある場合は、それが必須項目であることを、視覚のみに依存した情報提供をしないようにしてください。たとえば「赤文字の項目は必須です」というような、必須項目の提供の仕方はNGです。
    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 適応可能 情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。
    達成基準 情報及び関係性
    (1.3.1 A)
    何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。
    解説: 達成基準 1.3.1 を理解する

    何らかの形で提示されている情報、 構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。

    アクセシビリティ・サポーテッド

1.3.2 意味のある順序 (A)

コンテンツが提示されている順序が意味に影響を及ぼす場合には、正しく読む順序はプログラムによる解釈が可能である。

  • 線形情報化して意味が破壊されない
    解説
    • 線形情報化した時に(スクリーンリーダで読んだ時に)意味が壊れないように構築すること。CSSのposition absoluteなどで、任意の位置に要素類を配置している場合は要注意です。CSSをオフにして確認すると良いです。
    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 適応可能 情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。
    達成基準 意味のある順序
    (1.3.2 A)
    コンテンツが提示されている順序が意味に影響を及ぼす場合には、正しく読む順序はプログラムによる解釈が可能である。
    解説: 達成基準 1.3.2 を理解する

    コンテンツが提示されている順序が意味に影響を及ぼす場合には、正しく読む順序はプログラムによる解釈が可能である。

  • スペースや改行を用いて文章を整形していない
    解説
    • 「博物館」を「博 物 館」と記述してしまうようなこと(いわゆる「単語の泣き別れ」)や、改行や空文字を駆使したレイアウトをして、意味の理解を妨げないようにしてください。改行で行の終端をそろえたり、空文字で行等をそろえていると、スクリーンリーダで情報を取得しづらくなるだけでなく、文字サイズ変更時などにも、たいへん読みづらくなります。また、検索エンジン対策上もけっしてプラスには働きません。
    • 他方、スペースを用いて整形するのが自然な場合もあります。エラーチェックに引っかかることがありますが、法人格と法人名を「株式会社 みやこ酒店」というような表記を禁止する必要はないでしょう。
    • マークアップエンジニアがHTMLの可読性維持のために、altなどの属性値中で、改行による整形をする場合、一部のスクリーンリーダで改行ごとに意図しない読み上げを行う事例もあることを覚えておくと良い。
    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 適応可能 情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。
    達成基準 意味のある順序
    (1.3.2 A)
    コンテンツが提示されている順序が意味に影響を及ぼす場合には、正しく読む順序はプログラムによる解釈が可能である。
    解説: 達成基準 1.3.2 を理解する

    コンテンツが提示されている順序が意味に影響を及ぼす場合には、正しく読む順序はプログラムによる解釈が可能である。

1.3.3 感覚的な特徴 (A)

コンテンツを理解し操作するための説明は、形、大きさ、視覚的な位置、方向、又は音のような、構成要素が持つ感覚的な特徴だけに依存していない。

1.4 判別可能

1.4.1 色の使用 (A)

色が、情報を伝える、動作を示す、反応を促す、又は視覚的な要素を判別するための唯一の視覚的手段になっていない。

1.4.2 音声の制御 (A 非干渉)

ウェブページ上にある音声が自動的に再生され、3秒より長く続く場合、その音声を一時停止又は停止するメカニズム、もしくはシステム全体の音量レベルに影響を与えずに音量レベルを調整できるメカニズムが利用できる。

1.4.3 コントラスト (最低限) (AA)

テキスト及び文字画像の視覚的提示に、少なくとも 4.5:1 のコントラスト比がある。

1.4.4 テキストのサイズ変更 (AA)

キャプション及び文字画像を除き、テキストは、コンテンツ又は機能を損なうことなく、支援技術なしで 200% までサイズ変更できる。

1.4.5 文字画像 (AA)

使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが情報伝達に用いられている。

  • 画像化された文字は使用していない
    解説

    ドキュメントが存在しません

    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 判別可能 コンテンツを、利用者にとって見やすく、聞きやすいものにすること。これには、前景と背景を区別することも含む。
    達成基準 文字画像
    (1.4.5 AA)
    使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが情報伝達に用いられている。
    解説: 達成基準 1.4.5 を理解する

    使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが情報伝達に用いられている。

  • 画像化された文字をaltに変換する仕組みがある
    解説
    • JavaScriptなどで、画像からaltを抽出し、画像と置き換える仕組みがある。
    • 視覚的デザイン重視の目的で、グローバルメニューや見出しの文字を画像にすることがありますが、画像化された文字は、さまざまな恩恵(コピーアンドペーストや、機械翻訳の恩恵、拡大縮小等)を失いますので、あまり使わない方がいいでしょう。
    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 判別可能 コンテンツを、利用者にとって見やすく、聞きやすいものにすること。これには、前景と背景を区別することも含む。
    達成基準 文字画像
    (1.4.5 AA)
    使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが情報伝達に用いられている。
    解説: 達成基準 1.4.5 を理解する

    使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが情報伝達に用いられている。

  • 画像化された文字は書体のサンプル、ロゴタイプ、ブランドなど、伝える情報にとってそのテキストの特定の表現が必要不可欠である
    解説
    • 基本的に、「画像化された文字」は、使いづらい利用者がいるので、推奨されませんが、視覚的な効果をCSSで表現できない場合は、画像化された文字を使って良いとしているのが、1.4.5です(ただし、「画像化された文字」なので、altは必要です)。
    • Understanding WCAG2.0では、ロゴ、書体サンプルなどを「視覚的な効果が必要不可欠」と定義していて、これは明確でわかりやすいのですが、たとえば「どんな環境でもアンチエイリアスをかけた表示をしたい」「この見出しはどうしてもこのフォントで表現したい」なども、「視覚的な効果をCSSで表現できない」としてよいようです。
    • 訴求効果のためのバナー画像を置く場合(リンク)、特定の見出しを特に目立たせたい場合(構造)など、重要な場所で使うことが多い手法ですので、altを忘れないようにしましょう。
    • より厳しい1-4-9aという達成基準があり、そちらでは、この例外措置がありません。言い換えると、諸条件を満たさなければ、ロゴ、書体サンプルなど以外で、画像化された文字を使ってはならない、視覚的な効果は、CSSなどで実装できる範囲にとどめた表現にしなければならない、ということになります。
    • 画像化された文字をJavaScript等で、テキスト情報に置き換えて、テキストとして扱うことができるようにしてある場合や、画像化された文字の前景色、背景色、サイズ等を、どんなユーザーエージェントであっても(つまりサーバサイドで)利用者が自由に変更できるような機能が提供されている場合は、1.4.5も、1.4.9を満たせます。
    原則 知覚可能 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。
    ガイドライン 判別可能 コンテンツを、利用者にとって見やすく、聞きやすいものにすること。これには、前景と背景を区別することも含む。
    達成基準 文字画像
    (1.4.5 AA)
    使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが情報伝達に用いられている。
    解説: 達成基準 1.4.5 を理解する

    使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが情報伝達に用いられている。

1.4.6 コントラスト (高度) (AAA)

テキスト及び文字画像の視覚的提示には、少なくとも 7:1 のコントラスト比がある。

1.4.7 小さな背景音、又は背景音なし (AAA)

収録済の音声しか含まないコンテンツで、(1) 前景に主として発話を含み、(2) 音声CAPTCHA又は音声ロゴではなく、かつ、(3) 例えば、歌やラップなどのように、主として音楽表現を意図した発声ではないものについては、配慮がある。

1.4.8 視覚的提示 (AAA)

テキストブロックの視覚的提示において、配慮がある。

1.4.9 文字画像 (例外なし) (AAA)

文字画像は、純粋な装飾に用いられているか、テキストの特定の表現が伝えようとする情報にとって必要不可欠である場合(ロゴタイプなど)に用いられている。

2 操作可能

2.1 キーボード操作可能

2.1.1 キーボード (A)

コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボードインタフェースを通じて操作可能である。ただし、その根本的な機能が利用者の動作による始点から終点まで続く一連の軌跡に依存して実現されている場合は除く。

2.1.2 キーボードトラップなし (A 非干渉)

キーボードインタフェースを用いてキーボードフォーカスをそのウェブページのあるコンポーネントに移動できる場合、キーボードインタフェースだけを用いてそのコンポーネントからフォーカスを外すことが可能である。さらに、修飾キーを伴わない矢印キー、 Tab キー、又はフォーカスを外すその他の標準的な方法でフォーカスを外せない場合は、フォーカスを外す方法が利用者に通知される。

2.1.3 キーボード (例外なし) (AAA)

コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボードインタフェースを通じて操作可能である。

2.2 十分な時間

2.2.1 タイミング調整可能 (A)

コンテンツに制限時間を設定する場合は、配慮がある。

2.2.2 一時停止、停止、非表示 (A 非干渉)

動きのある、点滅している、スクロールする、又は自動更新する情報には、配慮がある。

2.2.3 タイミング非依存 (AAA)

タイミングは、コンテンツによって提示されるイベント又は動作の必要不可欠な部分ではない。ただし、インタラクティブではない同期したメディア及びリアルタイムのイベントは除く。

2.2.4 割り込み (AAA)

割り込みは、利用者が延期、又は抑制することができる。ただし、緊急を要する割り込みは除く。

2.2.5 再認証 (AAA)

認証済のセッションが切れた場合は、再認証後でもデータを失うことなく利用者が操作を継続できる。

2.3 発作の防止

2.3.1 3回の閃光、又は閾値以下 (A 非干渉)

ウェブページには、どの1秒間においても3回を超える閃光を放つものがない、又は閃光が一般閃光閾値及び赤色閃光閾値を下回っている。

2.3.2 3回の閃光 (AAA)

ウェブページには、どの1秒間においても3回を超える閃光を放つものがない。

2.4 ナビゲーション可能

2.4.1 ブロックスキップ (A)

複数のウェブページ上で繰り返されているコンテンツのブロックをスキップするメカニズムが利用できる。

  • ブロックスキップが提供されている
    解説
    • すべてのページで共通の部分は、これをスキップできる実装をすること。共通の部分の例は、グローバルメニューや広告の領域などが挙げられる。スクリーンリーダ利用者や極端に文字サイズを拡大している利用者にとっては、こういった共通の部分をなんども読み上げたり、スクロールによって通り過ぎたりするのが、困難なのです。
    • なお注意すべきはアクセシビリティ・サポーテッドです。達成基準によれば「見出しによる構造化(H69)」か「ブロックスキップ用のリンクを置く(G1)」(カッコ内はUnderstandingの番号)のいずれかを満たせば良いとなっているが、「7.2.4.1 ブロックスキップに関する達成基準 (等級A)」のアクセシビリティ・サポーテッド情報では、「見出しによる構造化」によるブロックスキップはビジュアルブラウザで使えないことが多いので、アクセシビリティ・サポーテッドでないとなっている。ので、G1対応は、現状では2.4.1を満たすために必須であると考えるべきでしょう。
    • frame要素やiframe要素はまとめてブロックスキップの対象とすることが可能です。なんのframe/iframeなのか、title属性できちんと情報提供することでブロックスキップの判断のたすけになります。
    • ブロックスキップ用のリンクは、なにもグローバルメニューや広告領域だけでなく、たとえばたくさんのリンクを延々と読み上げ続けるFacebookのplugin-boxなんかも、その対象とすると、便利が良いでしょう。
    原則 操作可能 ユーザインタフェース コンポーネント及びナビゲーションは操作可能でなければならない。
    ガイドライン ナビゲーション可能 利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。
    達成基準 ブロックスキップ
    (2.4.1 A)
    複数のウェブページ上で繰り返されているコンテンツのブロックをスキップするメカニズムが利用できる。
    解説: 達成基準 2.4.1 を理解する

    複数のウェブページ上で繰り返されているコンテンツのブロックをスキップするメカニズムが利用できる。

    アクセシビリティ・サポーテッド
    関連項目

2.4.2 ページタイトル (A)

ウェブページには、主題又は目的を説明したタイトルがある。

  • ウェブページは適正なtitle要素を持つ
    解説
    • ウェブページはサイト内で極力固有のタイトルを持たせてください。サイト内で共通のタイトルにしてしまうと、利用者は、サイト内の現在位置を把握しづらくなります。titleは、サイト内の現在位置の把握に役立つ他、検索エンジン対策上もたいへん効果が高い箇所です。
    原則 操作可能 ユーザインタフェース コンポーネント及びナビゲーションは操作可能でなければならない。
    ガイドライン ナビゲーション可能 利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。
    達成基準 ページタイトル
    (2.4.2 A)
    ウェブページには、主題又は目的を説明したタイトルがある。
    解説: 達成基準 2.4.2 を理解する

    ウェブページには、主題又は目的を説明したタイトルがある。

2.4.3 フォーカス順序 (A)

ウェブページが順を追ってナビゲートできて、そのナビゲーション順が意味又は操作に影響を及ぼす場合、フォーカス可能なコンポーネントは、意味及び操作性を損なわない順序でフォーカスを受け取る。

  • ウェブページのフォーカスを受け取る要素の順番が適切である
    解説
    • スクリーンリーダや画面拡大をしている利用者はタブキーによるフォーカスの移動を行うことが多い。タブキーによるフォーカスの移動は、素直なHTMLであれば、HTMLの記述順になるが、tabindexを与えることで、変更もできる。tabindexを与える場合は、意味の把握を妨げるような順序設定にならないように注意すること。
    • また、モーダルダイアログを作る場合などは、注意を要します。モーダルダイアログはスクリーンリーダを使っていない利用者にとっては、モーダルダイアログを閉じるまで他の動作はできない(というか、そういうものを「モーダルダイアログ」と呼びます)。スクリーンリーダを使っている利用者にとっても、同じように振舞うべきであり、タブキーでフォーカス移動をしていると、モーダルを抜けられてしまう、というようなことがあってはならないのです。
    原則 操作可能 ユーザインタフェース コンポーネント及びナビゲーションは操作可能でなければならない。
    ガイドライン ナビゲーション可能 利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。
    達成基準 フォーカス順序
    (2.4.3 A)
    ウェブページが順を追ってナビゲートできて、そのナビゲーション順が意味又は操作に影響を及ぼす場合、フォーカス可能なコンポーネントは、意味及び操作性を損なわない順序でフォーカスを受け取る。
    解説: 達成基準 2.4.3 を理解する

    ウェブページが順を追ってナビゲートできて、そのナビゲーション順が意味又は操作に影響を及ぼす場合、フォーカス可能なコンポーネントは、意味及び操作性を損なわない順序でフォーカスを受け取る。

    アクセシビリティ・サポーテッド

2.4.4 リンクの目的 (コンテキスト内) (A)

それぞれのリンクの目的が、リンクのテキスト単独で、又はリンクのテキストとプログラムによる解釈が可能なリンクのコンテキストから判断できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。

2.4.5 複数の手段 (AA)

ウェブページ一式の中で、あるウェブページを見つける複数の手段が利用できる。ただし、ウェブページが一連のプロセスの中の1ステップ又は結果である場合は除く。

  • グローバルメニューに加えて、サイトマップ(+目次ページ)、サイト内検索、関連ページへのリンクなど、個々のページへの到達手段を複数用意している
    解説
    • 一連のプロセスであるショッピングカートの途中のページなどを除いて、ウェブページ一式内のそれぞれのページにたどり着く複数の手段を提供することが望ましい。多くのウェブサイトは、グローバルメニューを備えているが、それに加えて、サイト内検索や、関連ページへのリンク、サイトマップ、目次(ページ)のいずれかがあれば、この達成基準を満たせる(ただし「目次ページ」のあり方については、その目次ページが個々のページにたどり着く唯一の手段である場合、注意を要するかもしれない)。
    • 目次ページというのは、いわばカテゴリにぶらさがる個々の項目へのリンク一覧である。サイトマップが完全(すべてのページを網羅している)なものでなくても、サイトマップに目次ページを含んでいれば、「複数の手段」を提供したと言える。
    • ただし、目次ページより下位のページが、何度もクリックしないとたどり着けないページになっていたら、やはりサイト内検索の実装がのぞましいでしょう。またそういったコンテンツが存在してしまう前に、そもそもサイトの構造をシンプルにすべきでもあります。
    原則 操作可能 ユーザインタフェース コンポーネント及びナビゲーションは操作可能でなければならない。
    ガイドライン ナビゲーション可能 利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。
    達成基準 複数の手段
    (2.4.5 AA)
    ウェブページ一式の中で、あるウェブページを見つける複数の手段が利用できる。ただし、ウェブページが一連のプロセスの中の1ステップ又は結果である場合は除く。
    解説: 達成基準 2.4.5 を理解する

    ウェブページ一式の中で、あるウェブページを見つける複数の手段が利用できる。ただし、ウェブページが一連のプロセスの中の1ステップ又は結果である場合は除く。

2.4.6 見出し及びラベル (AA)

見出し及びラベルは、主題又は目的を説明している。

  • 見出し要素(h*)やformのlabelがわかりやすい
    解説
    • formのlabelに関しては、たとえば「ふりがな」を要求するような場面で、カタカナかひらがなのいずれかの入力を求める場合は、labelもしくは付近でその説明を行うなどしてください。もし、システム上の制約がないのであれば、カタカナかひらがなかの入力について、両方受け付ける実装を考えてもいいかもしれません。
    • 本文欄の見出しについては、確認がしやすいのですが、本文以外のナビゲーション部分などに、非表示の見出しを置くことがあります。非表示になっている箇所なので、うっかり見落とすかもしれませんが、適切な内容を入れるようにしてください。CSSをオフにして確認すると良いです。
    原則 操作可能 ユーザインタフェース コンポーネント及びナビゲーションは操作可能でなければならない。
    ガイドライン ナビゲーション可能 利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。
    達成基準 見出し及びラベル
    (2.4.6 AA)
    見出し及びラベルは、主題又は目的を説明している。
    解説: 達成基準 2.4.6 を理解する

    見出し及びラベルは、主題又は目的を説明している。

2.4.7 フォーカスの可視化 (AA)

キーボード操作が可能なあらゆるユーザインタフェースには、フォーカスインジケータが見える操作モードがある。

2.4.8 現在位置 (AAA)

ウェブページ一式の中での利用者の位置に関する情報が利用できる。

  • パンくずが存在する
    解説
    • いわゆる「パンくず(あるいはトピックパス)」が存在していることが望ましい。また、サテライトサイトなど、親サイトを持つ場合は、親サイトへのリンクも広義の「現在位置」理解の助けになる。たとえば大学のサイトが別にある学部のサイトが、大学本体へのリンクを持っているような事例である。
    原則 操作可能 ユーザインタフェース コンポーネント及びナビゲーションは操作可能でなければならない。
    ガイドライン ナビゲーション可能 利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。
    達成基準 現在位置
    (2.4.8 AAA)
    ウェブページ一式の中での利用者の位置に関する情報が利用できる。
    解説: 達成基準 2.4.8 を理解する

    ウェブページ一式の中での利用者の位置に関する情報が利用できる。

2.4.9 リンクの目的 (リンクのみ) (AAA)

それぞれのリンクの目的を、リンクのテキスト単独で特定できるメカニズムが利用できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。

  • リンク文字列は、一部の例外を除いて単独で理解可能である
    解説
    • リンク文字列単独で、リンクの目的を理解できるようにしなければなりません。2.4.4と異なるのは文脈依存を許さない点です。2.4.4の「書籍」の例を再掲すると、HTML版、PDF版、MP3版はそれぞれ書籍名をリンク文字列内に持っている必要があります。ただし、「ほとんどの利用者にとってリンクの目的が曖昧」な場合は、この限りではないらしいが、「グァバ」の例は、障害のない利用者にも使いづらいように考えられます。「達成基準 2.4.4 を理解する」のドアの例の方が、理解しやすいかもしれません。
    • 表題があってリンクされており、すこし紹介文があって、「続きを読む」というようにして、こちらも表題と同じところにリンクする、という実装はしばしばあります。この場合、「続きを読む」は、単独で理解可能なリンクとは言えません(ちなみに2.4.4では許容されます)。「続きを読む」を「{表題}の続きを読む」と記述すれば、「単独での理解が可能」なので、2.4.9は満たせます。しかし、スクリーンリーダーで、タブでリンクへとスキップしながら読んでいると似たような機能を連続して読み上げることになり少々煩わしくもあります。この場合「続きを読む」(もしくは「{表題}の続きを読む」)を、aria-hidden="true"tabindex="-1"などして、読まないようにすると、タブキー押下の数が減って、音声環境での利用が快適になります。
    • ちなみに3-2-4aでは、「同じ機能を有するコンポーネントは一貫して識別できる」ことを求めていて、たとえばサイトのお問い合わせフォームへのリンクが「お問い合わせフォーム」だったり「お問い合わせはこちらから」だったりして統一されていないことを禁じています(つまり「お問い合わせフォーム」か「お問い合わせはこちらから」に一貫せよと言っています)。2.4.9の項としては、リンクの目的を理解するということは妨げていないと考えられますが、ただリンクの文字列が理解可能であっても、表記の揺れが利用者を不安にすることがあるかもしれない、ということは意識する必要があるでしょう。
    原則 操作可能 ユーザインタフェース コンポーネント及びナビゲーションは操作可能でなければならない。
    ガイドライン ナビゲーション可能 利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。
    達成基準 リンクの目的 (リンクのみ)
    (2.4.9 AAA)
    それぞれのリンクの目的を、リンクのテキスト単独で特定できるメカニズムが利用できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。
    関連項目
    解説: 達成基準 2.4.9 を理解する

    それぞれのリンクの目的を、リンクのテキスト単独で特定できるメカニズムが利用できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。

    アクセシビリティ・サポーテッド
    関連項目

2.4.10 セクション見出し (AAA)

セクション見出しを用いて、コンテンツが整理されている。

3 理解可能

3.1 読みやすさ

3.1.1 ページの言語 (A)

それぞれのウェブページのデフォルトの自然言語がどの言語であるか、プログラムによる解釈が可能である。

3.1.2 一部分の言語 (AA)

コンテンツの一節、又は語句それぞれの自然言語がどの言語であるか、プログラムによる解釈が可能である。ただし、固有名詞、技術用語、言語が不明な語句、及びすぐ前後にあるテキストの言語の一部になっている単語又は語句は除く。

3.1.3 一般的ではない用語 (AAA)

慣用句及び専門用語を含めて、一般的ではない、又は限定された用法で使われている単語、又は語句の、明確な定義を特定するメカニズムが利用できる。

3.1.4 略語 (AAA)

略語の元の語、又は意味を特定するメカニズムが利用できる。

3.1.5 読解レベル (AAA)

固有名詞や題名を取り除いた状態で、テキストが前期中等教育レベルを超えた読解力を必要とする場合は、補足コンテンツ又は前期中等教育レベルを超えた読解力を必要としない版が利用できる。

3.1.6 発音 (AAA)

文脈において、発音が分からないと単語の意味が不明瞭になる場合、その単語の明確な発音を特定するメカニズムが利用できる。

3.2 予測可能

3.2.1 フォーカス時 (A)

いずれのコンポーネントも、フォーカスを受け取ったときにコンテキストの変化を引き起こさない。

3.2.2 入力時 (A)

ユーザインタフェースコンポーネントの設定を変更することが、コンテキストの変化を自動的に引き起こさない。ただし、利用者が使用する前にその挙動を知らせてある場合を除く。

  • 入力時に予告なしに状況を変化させるような要素は存在しない。
    解説
    • ページ内の入力欄全てを入力したら自動的に送信するとか、チェックボックスやラジオボタンをチェックしたらページ移動するとか、そういったことをしてはならない。
    • 時々あるのは、selectのonchangeを拾ってページ移動するようなインタフェイス。マウスで操作している利用者にとっては、selectの3項目下を選択するというようなことができるが、キーボードの場合は、下キーを押した途端にonchange判定されてしまって、永遠に2個下に行けない、ということが起こる(ある意味「キーボードトラップ」になっているとも言えるでしょう)。こういった場合は、「実行ボタン」を付与する必要があるでしょう。
    • この達成基準は3.2.1と似ているが、状況の変化が予測可能で、制御可能であれば、許されることもあるという点で違う(フォーカスの場合は、予測や制御が本質的に難しい)。たとえばカレンダに予定を追加するフォームがある時、予定の種別をラジオボタンで選択すると、入力欄が動的に変化するような仕掛けは、予測可能で制御可能であると言えるでしょう。
    • また、クレジットカード番号など4桁ずつ入力する際、4文字入力したら次のフィールドに自動的にフォーカスを映すような挙動も、あらかじめ説明されている場合は許容される。
    原則 理解可能 情報及びユーザインタフェースの操作は理解可能でなければならない。
    ガイドライン 予測可能 ウェブページの表示や挙動を予測可能にすること。
    達成基準 入力時
    (3.2.2 A)
    ユーザインタフェースコンポーネントの設定を変更することが、コンテキストの変化を自動的に引き起こさない。ただし、利用者が使用する前にその挙動を知らせてある場合を除く。
    関連項目
    解説: 達成基準 3.2.2 を理解する

    ユーザインタフェースコンポーネントの設定を変更することが、コンテキストの変化を自動的に引き起こさない。ただし、利用者が使用する前にその挙動を知らせてある場合を除く。

3.2.3 一貫したナビゲーション (AA)

ウェブページ一式の中にある複数のウェブページ上で繰り返されているナビゲーションのメカニズムは、繰り返されるたびに 相対的に同じ順序で出現する。ただし、利用者が変更した場合は除く。

3.2.4 一貫した識別性 (AA)

ウェブページ一式の中で同じ機能を有するコンポーネントは、一貫して識別できる。

  • ウェブページ一式の中で、同じ機能を提供するラベルは一貫している。
    解説
    • 同じ機能を提供するリンクやボタンなどはウェブページ一式の中で一貫している必要があります。この達成基準は結構見落としやすいです。ほとんど自明と思えるようなラベルであっても、厳密に一貫していない場合は、この達成基準を満たせないからです。不適合事例で上がっている例が、「検索」ボタンと「探す」ボタンが同様の機能を提供している場合(英語ではfindとsearchで説明されています)ですが、これはラベルが異なっているためにNGとなります。
    • リンク先が同じでリンク文字列が異なる場合も注意の対象です(G197)。問い合わせページのリンク先が「問い合わせ」であったり「問い合わせフォーム」だったりすることは、NGのようです。
    • また、ウェブページ一式のトップページへのリンクが「トップ」だったり、「トップページへ」だったり、サイト名だったりすることがあります。コンテンツ内でこういったリンク先の表記揺れは避けるようにしましょう。
    • ページの上部にあるサイト名のaltを付与したロゴ画像がトップページのリンクになっていることは比較的よくある実装です。また、同時にパンくずのトップページへのリンクが、サイト名でないこともよくある実装です。解釈が揺れるところかもしれませんが、「サイト名ロゴをクリックするとトップページに行く」という機能の一貫性と、「パンくずでのTOPという文字がトップページに行く」という機能の一貫性が担保されていれば、この文字列が一致していなくてもよいと考えられます。「達成基準 3.2.4 を理解する」の「事例 3: 他のページへの一貫したリンクのラベル」を参照してください。
    • ちなみに2.4.9も確認してください。この「問い合わせ」の例では、ラベルが一致していないことで、本項目を満たせませんが、2.4.9で求められている「リンクの機能を理解する」という点では、問題がないとも言えます。
    • たとえば「記事の詳細を読むリンク」が「こちら」という一貫したラベルであるからよいと考えるのは2.4.9の観点から危険です。
    原則 理解可能 情報及びユーザインタフェースの操作は理解可能でなければならない。
    ガイドライン 予測可能 ウェブページの表示や挙動を予測可能にすること。
    達成基準 一貫した識別性
    (3.2.4 AA)
    ウェブページ一式の中で同じ機能を有するコンポーネントは、一貫して識別できる。
    関連項目
    解説: 達成基準 3.2.4 を理解する

    ウェブページ一式の中で同じ機能を有するコンポーネントは、一貫して識別できる。

    関連項目

3.2.5 要求による変化 (AA)

コンテキストの変化は利用者の要求によってだけ生じるか、又は、そのような変化を止めるメカニズムが利用できる。

3.3 入力支援

3.3.1 エラーの特定 (A)

入力エラーが自動的に検出された場合は、エラーとなっている箇所が特定され、そのエラーが利用者にテキストで説明される。

3.3.2 ラベル又は説明 (A)

コンテンツが利用者の入力を要求する場合は、ラベル又は説明文が提供されている。

  • フォームが存在するが、ラベルまたは説明文等が存在する
    解説
    • 利用者にフォームによる入力を求める際、どこに何を入力すべきなのか、わかりやすく情報提供すること。プログラムに解釈できる方法で提供することであればなおよい。具体的にはlabel要素で各フォーム要素と関連付けることで、視覚障害者にとっても利用しやすいフォームを作ることができる。
    • また、説明や入力の事例などの掲載も好ましいが、やりすぎるとかえって邪魔になるので、簡潔にすること。
    • 必須項目がある場合は、なにが必須項目であるのか、わかりやすく情報提供すること。
    • なお、説明文や入力時の例を書く際は、入力欄より前に記載しておく方が、線形的に情報取得しているスクリーンリーダの利用者にとって、間違いが少ない。
    原則 理解可能 情報及びユーザインタフェースの操作は理解可能でなければならない。
    ガイドライン 入力支援 利用者の間違いを防ぎ、修正を支援すること。
    達成基準 ラベル又は説明
    (3.3.2 A)
    コンテンツが利用者の入力を要求する場合は、ラベル又は説明文が提供されている。
    解説: 達成基準 3.3.2 を理解する

    コンテンツが利用者の入力を要求する場合は、ラベル又は説明文が提供されている。

    アクセシビリティ・サポーテッド

3.3.3 エラー修正の提案 (AA)

入力エラーが自動的に検出され、修正方法を提案できる場合、その提案が利用者に提示される。ただし、セキュリティ又はコンテンツの目的を損なう場合は除く。

3.3.4 エラー回避 (法的、金融、データ) (AA)

利用者にとって法律行為もしくは金融取引が生じる、利用者が制御可能なデータストレージシステム上のデータを変更もしくは削除する、又は利用者が試験の解答を送信するウェブページでは、取消、チェック、確認のいずれかができるようにしてある。

3.3.5 ヘルプ (AAA)

状況に応じたヘルプが利用できる。

3.3.6 エラー回避 (すべて) (AAA)

利用者に情報の送信を要求するウェブページでは、取消、チェック、確認のいずれかができるようにしてある。

4 堅牢性

4.1 互換性

4.1.1 構文解析 (A)

マークアップ言語を用いて実装されているコンテンツにおいては、要素には完全な開始タグ及び終了タグがあり、要素は仕様に準じて入れ子になっていて、要素には重複した属性がなく、どの ID も一意的である。ただし、仕様で認められているものを除く。

4.1.2 名前 (name) ・役割 (role) 及び値 (value) (A)

すべてのユーザインタフェース コンポーネント (フォームを構成する要素、リンク、スクリプトが生成するコンポーネントなど) では、名前 (name) 及び役割 (role) は、プログラムによる解釈が可能である。又、状態、プロパティ、利用者が設定可能な値はプログラムによる設定が可能である。そして、支援技術を含むユーザエージェントが、これらの項目に対する変更通知を利用できる。