解説書 達成基準 1.4.13:ホバー又はフォーカスで表示されるコンテンツ (レベル AA)
要約
- 目標
- より多くの利用者が、非永続的なコンテンツを知覚し、非表示にできる。
- 何をすればよいか
- ホバー又はフォーカスによってコンテンツが変化する場合、インタラクションを確実に予測可能にする。
- なぜそれが重要か
- 予測不可能な一時的なコンテンツは、ある人にとっては利用しづらく、他の人にとっては混乱を招く可能性がある。
意図
キーボードフォーカス又はポインタホバーと連動して現れたり消えたりする追加のコンテンツはしばしばアクセシビリティの問題へ発展することがある。そのような問題の理由には以下が含まれる:
- 利用者はインタラクションを引き起こすことを目的としていなかった可能性がある
- 利用者は新しいコンテンツが現れたことに気づかない可能性がある
- 新しいコンテンツは利用者のタスクを実行する能力を妨げる可能性がある
そのようなインタラクションの例には、ホバー及びフォーカスで表示されるカスタムツールチップ、サブメニュー及びその他の非モーダルポップアップが含まれる。この達成基準の意図は、コンテンツ制作者が追加のコンテンツを表示及び非表示にするようなインタラクションを設計する際に、利用者が下記を利用できなければならないということである:
- 追加のコンテンツを知覚できる、及び
- ページ体験を損なうことなく非表示にすることができる。
大抵はより予測可能かつアクセシブルな、ページにコンテンツを追加する方法があり、コンテンツ制作者にはそれらの採用が推奨される。コンテンツ制作者が追加のコンテンツをホバー及びキーボードフォーカスと連携して表示及び非表示にすることを選んだ場合、この達成基準は満たさなければならない三つの条件を指定する:
- 非表示にすることができる
- ホバーすることができる
- 表示が継続される
それぞれは個別の節で議論されている。
非表示にすることができる
この条件の意図は、追加のコンテンツがページの元のコンテンツを確認する又は操作することを妨げないようにすることである。拡大時、ビューポート内で表示されるページの部分は極端に狭くなることがある。マウスの利用者は、拡大したビューポートをパンして画面の他の部分を表示するために、頻繁にポインタを動かす。しかし、この限られたビューポートで表示されるページのほぼ全域が追加のコンテンツをトリガーするかもしれず、利用者がコンテンツを再トリガーせずにパンすることを困難にする。キーボードで追加コンテンツを非表示にする方法は、回避方法を提供する。
代わりに、キーボードを用いてのみナビゲートするロービジョンの利用者は、拡大されたビューポートの小さい領域がホバーテキストで雑然としてほしくない。彼らは現在のフォーカスが当たっている領域を覆い隠すものをキーボードで非表示にする方法が必要である。
この条件を満たし、このような干渉を防ぐために、二つの方法が使用できる:
- 余白及び情報を提供しない背景画像などの純粋な装飾コンテンツを除き、トリガーを含む他のあらゆるコンテンツを隠さないよう追加のコンテンツを配置する。
- Esc キーを押すなど、追加のコンテンツを容易に非表示にするメカニズムを提供する。
ほとんどの比較的小さいサイズのトリガーには、両方の方法が実装されることが望ましい。トリガーが大きい場合、追加コンテンツがトリガーより遠くに現れると、気づくことが難しいかもしれない。そのような場合は、二つ目の方法のみが適切かもしれない。
注目、明示的な確認、又は是正措置が必要な場合があるため、達成基準は、入力エラーメッセージを持続させることを許している。
ホバーすることができる
この条件の意図は、ターゲットにホバーすることで現れるかもしれない追加のコンテンツがそれ自身にもホバーできるように保証することである。ホバーで現れるコンテンツは、利用者がマウスポインタをトリガーの上に固定することを求められた場合、知覚するのが難しい又は不可能な可能性がある。追加されたコンテンツが大きい場合、拡大されたビューは、利用者がそのコンテンツを完全に表示するためにスクロール又はパンする必要があることを意味し、これは、追加コンテンツが消えないように利用者がトリガーからポインタを移動できない限り不可能である。
もう一つの一般的な状況は、大きいポインタがプラットフォームの設定又は支援技術により選択されていた場合である。ここでは、ポインタが追加コンテンツの重要な領域を隠してしまう可能性がある。両方の状況でコンテンツを完全に見る方法は、マウスポインタをトリガーから新しいコンテンツに直接移動させることである。この機能はまた、マウスとのインタラクションのフィードバックにスクリーンリーダーを使用する利用者に重要な利点を提供する。この条件は、ほとんどの場合、追加コンテンツがターゲットに重なる又はそれが隣接して配置されていることを暗示する。
表示が継続される
この条件の意図は、利用者に追加コンテンツが可視になった後、知覚するための十分な時間があるようにすることである。障害のある利用者は拡大率を変更する、ポインタを動かす、又は可視領域に新しいコンテンツを持ってくるなどの様々な理由により、より多くの時間が必要かもしれない。一度現れたら、次の条件を満たすまでコンテンツは可視のままにするべきである:
- 利用者がトリガー及び追加コンテンツからホバー又はフォーカスを取り除く。これは典型的なユーザ体験と一致するものである。
- 利用者が非表示にすることができる条件を満たすために提供されたメカニズムを通して追加コンテンツを非表示にする。又は、
- もはや有効ではない「使用中」メッセージなど、追加コンテンツにより伝えられた情報が無効になる。
追加の注記
- この基準は、追加コンテンツの見た目が完全にユーザエージェントにより制御されている時に、このような問題を解決することに努めていない。顕著な例は、HTML の
title属性を小さなツールチップとして表示するブラウザの一般的な挙動である。 - モーダルダイアログはキーボードフォーカスを受け取らなければならないため、ホバー又はフォーカスで現れるべきではなく、この基準のスコープ外である。 達成基準 3.2.1 フォーカス時を参照すること。
- ポインタホバーを通して動作するコンテンツはキーボードフォーカスでも動作するべきである。達成基準 2.1.1 キーボードを参照すること。
利点
- 拡大してコンテンツを見ているロービジョンの利用者は、望ましい倍率を減らさなくてもより上手くホバー又はフォーカスしたコンテンツを見ることができるようになる。
- プラットフォームの設定又は支援技術を通してマウスカーソルのサイズを大きくしている利用者は、ホバー時に隠されたコンテンツを見る方法を使用できるようになる。
- ロービジョン又は認知障害のある利用者はホバー又はフォーカスで現れる追加コンテンツを知覚し、かつトリガーコンテンツを気を散らすことなく見るための十分な時間を持てるようになる。
- ポインタの正確さが低い利用者は、より簡単に意図せず動作させた追加コンテンツを非表示にできるようになる。
事例
事例 1: 非表示にすることができるツールチップ
事例 2: ホバーすることができるツールチップ
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
テクニック
この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断するテクニック、又は複数のテクニックの組み合わせを表している。しかしながら、必ずしもこれらのテクニックを用いる必要はない。その他のテクニックについての詳細は、WCAG 達成基準のテクニックを理解するの「その他のテクニック」を参照のこと。
十分なテクニック
- SCR39: Making content on focus or hover hoverable, dismissible, and persistent
- ARIA: Using role="tooltip" (Potential future technique)
- CSS: Using hover and focus pseudo classes (Potential future technique)
失敗例
以下に挙げるものは、WCAG ワーキンググループが達成基準の失敗例とみなした、よくある間違いである。
- F95: Failure of Success Criterion 1.4.13 due to content shown on hover not being hoverable
- Failure to make content dismissable without moving pointer hover or keyboard focus (Potential future technique)
- Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Potential future technique)
重要な用語
障害のある利用者の要件を満たすために、主流のユーザエージェントが提供する機能を超えた機能を提供するような、ユーザエージェントとして動作する、又は主流のユーザエージェントと共に動作するハードウェア及び／又はソフトウェア。
注記
支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。
注記
支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
注記
主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害のある個人を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。
与えられた規格、ガイドライン、又は仕様のすべての要件を満たすこと。
利用者が入力した情報で、受け付けられないもの。
注記
以下のものが含まれる:
- そのウェブページでは必須であるが、利用者が入力しなかった情報
- 利用者が入力したが、要求されたデータ形式あるいは値ではない情報
結果を得るためのプロセス又は手法。
注記
メカニズムは、宣言する適合レベルのすべての達成基準を満たしている必要がある。
ある活動を完了させるために必要な利用者の一連の動作。
ユーザエージェントがどのようにレンダリング、再生、又は実行するかを符号化するメカニズム。
注記
このガイドラインで用いられている「ウェブ技術」及び (単独で用いられている) 「技術」という用語は、どちらもウェブコンテンツ技術を指す。
注記
ウェブコンテンツ技術には、マークアップ言語、データ形式、及びプログラム言語などがあり、これらをコンテンツ制作者が単独で、又は組み合わせて用いることによって、静的なウェブページや同期したメディアによる提示、さらには動的なウェブアプリケーションに至るまでの様々なエンドユーザ体験を作ることができる。
ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。
単一の URI から HTTP で得た埋め込まれていないリソースに加え、レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。