🐾

iOSネイティブアプリのフッターメニューの振る舞いとアクセシビリティ

2022/05/12に公開約6,400字2件のコメント

フッターに横に並んだメニュー(そのほとんどがアイコンとテキストで表現されている)の振る舞いとアクセシビリティについて、業務で調査する機会があったのでまとめた。

iOSのVoiceOver[1]を利用して確認。確認したのは次のことについて。

  • メニューボタンが何のARIAロール[2]を持っているか
  • どのランドマークリージョン[3]に所属しているか
  • ボタンクリック後に画面が切り替わった後にフォーカスはどこに移動するのか

調査結果表

アプリ名 ボタンのロール 所属するランドマーク フォーカスの移動先
iOS標準 App Store tab なし 移動しない
iOS標準 カレンダー button なし メイン画面の最初の要素
iOS標準 ブック tab なし 移動しない
iOS標準 ヘルスケア tab なし 移動しない
iOS標準 ミュージック tab なし 移動しない
iOS標準 写真 tab なし 移動しない
iOS標準 電話 tab なし 移動しない
Amazon tab なし 移動しない[4]
Anchor tab なし 移動しない
Discord tab[5] なし 移動しない
Duolingo なし なし メイン画面の最初の要素
freee人事労務 tab なし 移動しない
GitHub tab なし 移動しない
Gmail tab なし メイン画面の最初の要素
Google Maps button[6] なし 移動しない
Googleドライブ tab なし メイン画面のどこか(一貫性なし)
Googleフォト tab なし 移動しない
Instagram tab なし 移動しない
LINE tab なし 移動しない
Messenger tab なし 移動しない
note tab なし 移動しない
Spotify tab なし 移動しない
Twitter tab[7] なし 移動しない
Udemy tab なし 移動しない
Wikipedia tab なし 移動しない
Yahoo! JAPAN tab なし 移動しない
Yahoo!防災情報 tab なし 移動しない
YouTube tab なし ヘッダーメニュー
クックパッド button なし 移動しない
メルカリ tab なし 移動しない
ユビー button navigation 最初の見出しに移動

ロールはtab、ランドマークは所属なし、フォーカスは移動しないというのが圧倒的に多いことがわかる。iOSアプリの開発には疎いので憶測でしかないが、おそらくiOSアプリの標準のコンポーネント[8]を使用しているのだろうと想像する。

なぜ調べようと思ったのか

フッターメニューを実装するにあたって「ボタンを単純に並べる」という単純な実装の他に、「リンクとして実装する」もしくは「タブとして実装する」という選択肢が上がったからだ。

さて、そこで考えないといけないのは、それぞれの性質を考えること。リンクはもちろんのこと、もともとWAI-ARIA Authoring Practices 1.2でタブの理想的な振る舞いは知っていたので、その中でもクリックするとどうなるかという点に注目した。

リンクにしてもタブにしても、クリックすれば画面は切り替わるわけだが、ひとつ大きく異なる点がある。それはフォーカスが移動する点だ。リンクは画面をリフレッシュするので[9]必然的にフォーカスの位置がリセットされ、画面の最初に移動する。一方、タブはクリックしてもフォーカスは移動しない。

これはWAI-ARIAに限らず、Human Interface Guidelinesには強調して次のように書かれている。

Use a tab bar only to enable navigation, not to help people perform actions.

引用: Tab Bars - Bars - iOS - Human Interface Guidelines - Apple Developer より

少し解釈を加えるとすると「タブはセクションのナビゲート(切り替え)のみ行い、その他の補助的なことはしない」と読み取れる。つまり、

  • 切り替えを行うだけならタブ
  • フォーカスの移動までしたいならリンクかボタン[10]

と区別できる。実際、iOS標準のカレンダーはそれに則っていて、フォーカスを移動させるのでこれだけロールはタブじゃなくボタンとなっている。

自由なGoogle

調査結果的には、そのあたりを割と自由にやっているのはGoogleで、Tabs - Material Designにもそれらしいことは記載されていない。肯定的に想像するとユーザビリティテストから導き出された結果である可能性もあるし、否定的に想像するとただ単純に慣例を無視しているだけだったり、もしくは慣例を壊そうとしているのかもしれない。

ロールがタブとなっているものは読み上げの際に、「5の1」「5の2」「5の4」のように項目の合計数と現在の番号を伝えるところはひとつのメリットで、この振る舞いのためにタブを採用している可能性もあるが…まあいろいろと複雑な理由なのだろうと思っておくしかなさそうだ。

メニューを選び直すには

フォーカスが移動するメリットは、画面が切り替わったことが明確になりすぐに次のアクションに移れることだが、メニューの項目を選び直すには再びメニューにフォーカスを移動させなければならない。ここで問題になるのがメニューの位置だ。フッターにあるのでそこまで移動しないといけない。しかしタブであればフォーカスは移動していないので、誤ってクリックしたとしてもすぐに選び直せる。

このデメリットは割と大きなと思っていて、しばらく何度も考えているけれど、フォーカスを移動させないタブを採用したほうがいいのではと思っている。画面の最初にフォーカスを戻すのは、見出しさえきちんと実装していればローター機能を使って簡単に移動できるので、そのようにユーザーに行動の自由を与えているほうが健全かなと考える。そもそもiOSならHIGに従うのがよいよね。

ひとつ面白いと思ったのはユビーで、これは単純にウェブサイトの作法に則った実装しているからか唯一ランドマークに所属している。この場合、ボタンからフォーカスが画面の先頭に移動したとしても、ローター機能からすぐにランドマークに移動できるので、デメリットは解決できることになる。

以上、フッターメニューを設計・実装するときの参考にしてほしい。

脚注
  1. iOS標準に搭載されているスクリーンリーダー ↩︎

  2. 支援技術に伝達する情報のひとつで、要素の役割を表す。「ボタン」や「リンク」など、スクリーンリーダーでは要素のテキストやラベルとともに読み上げて伝えることが多い。WAI-ARIAcore-aamを参考にされたし。 ↩︎

  3. いわゆる「ヘッダー」「メイン」「ナビゲーション」などの画面内の目印となる領域。ウェブのARIAでは重要だが、ネイティブアプリではあまり利用されていない様子。 ↩︎

  4. 初回レンダリングのみ、おそらく検索バーのautofocus属性でフォーカスを奪われる ↩︎

  5. ただし何番目か読み上げない ↩︎

  6. ラベルに「タブ」を含む ↩︎

  7. ただし何番目か読み上げない ↩︎

  8. Tab Bars - Human Interface Guidelines ↩︎

  9. SPAのそれは擬似的な実装なので割愛 ↩︎

  10. ボタンについては何も定義がないのでフォーカスを移動することを実装してもよい ↩︎

Discussion

実際、iOS標準のカレンダーはそれに則っていて、フォーカスを移動させるのでこれだけロールはタブじゃなくボタンとなっている。

カレンダーはToolbars - Bars - iOS - Human Interface Guidelines - Apple Developerですね。TIPにタブバーとツールバーの役割の違いについて書かれています

なるほど、Toolbarsになるんですね。
情報ありがとうございます。

ログインするとコメントできます