WCAG 1.4.13 からホバーUIを考える
目次
概要
WCAG 2.2 の達成基準 1.4.13 ホバー又はフォーカスで表示されるコンテンツ について、ホバーUIを実装するときに何を気にすべきか考えてみる。
アクセシビリティの文脈で「なるべくホバーは使わないほうがよい」と聞くことがあるが、ホバー自体が禁止されているというより、ホバーしないと情報が得られない、またはホバーで出た情報をうまく扱えない状態が問題になる認識。
WCAG 1.4.13 とは
ポインタホバー、またはキーボードフォーカスによって追加コンテンツが表示される場合の達成基準。
対象になるものは次のようなUI。
- サブメニュー、メガメニュー
- ツールチップ
- ホバー時にだけ表示されるカード内の詳細情報
逆に、ボタンの背景色が変わるなど追加コンテンツが表示されない単なる視覚的フィードバックは、この達成基準の主な対象ではない。
3つの要件
WCAG 1.4.13 では大きく3つの要件が示されている。
非表示にできる（Dismissible）
追加コンテンツが他のコンテンツを覆う場合、ポインタやフォーカスを動かさずに非表示にできる必要がある。
実装としては Esc キーで閉じられるようにするのが分かりやすい。特に拡大表示している場合、画面内に見えている範囲が狭くなるため、ホバーで出たコンテンツが邪魔になってもマウスを動かすと再度表示される、という状態が起こる。
ホバーできる（Hoverable）
ホバーで出た追加コンテンツに対して、その追加コンテンツ上へポインタを移動できる必要がある。
例えばツールチップが大きい場合や、マウスカーソルを大きくしている場合、ポインタ自体がコンテンツを隠してしまうことがある。そのときにトリガー要素から追加コンテンツへポインタを移動できないと、内容を確認できない。
CSSだけで実装する場合、トリガーと追加コンテンツの間に隙間があると、移動中に :hover が外れて消えてしまうので注意が必要。
表示が継続される（Persistent）
追加コンテンツは、ホバーやフォーカスが外れる、ユーザーが閉じる、または内容が無効になるまで表示され続ける必要がある。
一定時間で勝手に消えるツールチップなどは避ける。読む速度や拡大表示、ポインタ操作の正確さはユーザーによって異なるため、表示時間を実装側で短く決めてしまうのは危うい。
他社ガイドラインの例
Ameba Accessibility Guidelines でも、画面を拡大して閲覧している場合に追加コンテンツを知覚できなかったり、閲覧中のコンテンツが覆い隠されたりする例が挙げられている。ホバーUIは、見えている範囲やポインタ操作のしやすさによって使いやすさが大きく変わる。
SmartHR Design System の Tooltip では、Tooltip はユーザーが能動的に表示しなければならないことや、拡大表示時に領域外に表示される課題があるため、安易な使用は勧められていない。操作に必要な情報は Tooltip ではなく常に表示すること、モバイルでは Tooltip を使わないことも示されている。
ホバーUIの扱い方
自分の中では「ホバーを使わない」というより「ホバーでしか成立しない情報設計を避ける」と考えるのがしっくりきた。実装可否よりも、情報の重要度や表示される文脈で判断するのがよい。
避けたほうがよいもの。
- フォームの入力要件やエラーメッセージをホバー時にだけ表示する
- ホバーで表示された中に操作ボタンやリンクがある
- 拡大表示時に画面の大部分を覆う
- ポインタを少し動かしただけで消える
使ってもよいもの。
- すでに本文やラベルで分かる情報の補足
- アイコンだけのボタンに対する補助的なラベル
- 省略されたテキストの全文表示
- フォーカス、クリック、タップでも同じ内容にアクセスでき、
Escなど閉じる操作が用意されている
ホバーはPCでは自然な操作だが、キーボードやタッチでは別の操作になる。なので、ホバーを入口にする場合でも、フォーカスやクリックでも同じ状態にできるようにしておくのが基本になる。
所感
:hoverだけで表示するのではなく、:focusや:focus-within、クリック/タップでも同じ内容にアクセスできるようにする- 追加コンテンツを読ませたい場合は、
pointer-events: none;にせず、トリガーから追加コンテンツ上へポインタを移動できる構造にする - 重要な情報は最初から表示するか、明示的に開けるUIにする