失われるフォーカス
マウスや指で操作しているとあまり意識しないフォーカス。
こんな場面で注意しようという例をいくつか紹介します。
disabled
ボタンにフォーカスがある状態でdisabledになる場合、スクリーンリーダーはフォーカスを失います。
特に
- 削除ボタンを押すとそのボタンがコンテンツごと消える
- 送信ボタンを押したらdisabledになって二重送信を防止する実装がある
みたいなことがあるとよくフォーカスを失います。
実際にキーボードやスクリーンリーダーで操作して確認しないとなかなか気づけません。
スクリーンリーダーで操作していると読み上げが変になるのですぐ気付けます。
disabledになっているボタンにはなぜ無効化されているのかの説明もつけましょう。
視覚以外で状況を把握するのは結構難しいです。
送信中などのフィードバックをボタンのラベルの変更で補うなどの方法もあります。
実際に目を瞑って操作してみるとよくわかるので自分で体験してみるのがおすすめです。
disabledにせずaria-disabledにする、もしくはフォーカス先を移動する実装をしましょう。
画面がそのまま切り替わる
ページ遷移せずにコンテンツが切り替わる場合もフォーカスを失いがちです。
ariaで通知してもいいですが、通知は同期的です。その場にいなければ気付けないかもしれません。
テキストをおいておき、そこにフォーカスを移すなどすると非同期的です。ariaも必要ありません。
そのままテキストから先に読み進めてスムーズに操作できるように設計できます。
フォーカスの移動
ページ遷移
NextやSvelteKitなどでページ遷移するとbodyにフォーカスが移るようになっています。
この二つに関してはページ移動したことが読み上げられる実装もありますが、iOSではbodyへのフォーカス移動が動きません。
たくさんのサイトでこれが起こっています。
どこに行ってしまうかというと、ページ遷移前にタップした近くの要素にフォーカスが移動します。
つまり、遷移先のページの何の関係もないコンテンツにフォーカスが移動してコンテンツを途中から読むことになる可能性があります。
これはどうしようもないかもしれません。あきらめましょう。
私はh1にフォーカスを移動する実装を入れました。
メインコンテンツの初めにフォーカスが移るのは利点ではありますが、ページによってはナビゲーションがメインコンテンツよりも前にある場合もあります。
そういう場合はそれに気づかない可能性がありますが、まだメインコンテンツにフォーカスが移動した方がましじゃないかなと考えています。
大量のコンテンツとスキップ
大量のリンクやボタンが並ぶコンテンツがある場合、その前後に移動したい時があります。
見出しへのジャンプよりもそのコンテンツの前後にジャンプできた方が体験がいいことがあります。
基本的には見出しを置くのがいいですが、実際に触ってみて体験が良い方を採用しましょう。
スクリーンリーダーユーザーの体験
ダイアログ、ポップオーバーと閉じるボタン
よくあるダイアログはダイアログを開いたあとダイアログのフッター付近にあるCloseボタンにフォーカスが移ったりします。
Yes Noの選択などシンプルないわゆるモーダルダイアログならそれでいいかもしれませんが、
ダイアログ内にコンテンツが多い場合はフッター付近にあるCloseボタンにフォーカスが移動すると面倒です。
そうするよりかはダイアログの見出しにフォーカスした方がいいでしょう。
見出しのすぐ後にCloseボタンを配置し、ダイアログの最後にもCloseボタンをおけばすぐに離脱したい人と最後まで読んでから離脱したい人両方にとって体験がよくなります。
そもそもダイアログを開いてすぐにCloseボタンのラベルが読み上げられるのってどうなんでしょう？
私はわけわからんなと思います。
ポップオーバーに関してはモバイルではEscキーを押せないので注意しましょう。
内容が多い場合は画面がこれで埋まってしまうことも想定されます。
Escキーが押せない場合背面などをタップで閉じられますが、背面が見えなくなってしまっている場合閉じる手段がありません。
閉じるボタンをつけてあげると親切かもしれません。
そもそも画面が見えない場合どこが背景かわかりません。
やはり閉じるボタンはあった方が良いでしょう。
ダイアログとaria-describedby
ダイアログにはaria-describedbyで説明を紐付けられます。
最初つけていたのですが、スクリーンリーダーで聞いてみたらかなりうるさかったのでやめました。
普通に読み進めていけば読める形、見出しの後などに置くだけで良さそうです。
あえて使う場面があるとすれば、画面に表示しないけどコンテキストとして伝えたい文章がある場合くらいかと思います。
これもおそらく目に見えた方がいいので、やっぱりダイアログにはaria-describedbyが必要なさそうです。
tablistとaria-labelledby
タブにはそれがなんのタブのリストなのかを説明した方がいいです。
aria-labelledbyにはdisplay: none;のラベルも指定できますが、iOSのVoiceOverでは普通に読まれません。
可視テキストで置くか、focusされ、focusされた時に見えるようになる形で配置しましょう。
そうした場合macのVoiceOverなどではtablistに差し掛かった時にもう一度読まれることになります。
これはこれでうるさいかもしれません。
まとめ
フォーカスの制御をうまくやりましょう！
それだけで体験は大きく変わります。