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

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

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-ARIAやcore-aamを参考にされたし。

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

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

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

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

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

8. Tab Bars - Human Interface Guidelines

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

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