タブ型 UI について考える

• 公開日 : 2016年1月18日 (2020年8月30日 更新)
• カテゴリー : ユーザビリティ / アクセシビリティ

タブをクリック/タップすると、JavaScript によって、そのタブに紐づいた情報 (タブパネル) が切り替わり表示されるユーザーインターフェース (UI) があります。限られたスペースで複数のコンテンツを併存させることができ、メタファとしてもわかりやすいと言えます。

今回は、このタブ型 UI について、ユーザビリティおよびアクセシビリティの観点から配慮したいことを考えてみたいと思います。

ユーザビリティの観点から配慮したいこと

タブっぽく見えること

言わずもがなですが、タブ型 UI はユーザーにとって「タブっぽく」見えなければなりません。タブなのかボタンなのか微妙な UI を見かけることもありますが、仮にユーザーがそれをタブではなくボタンと認識してしまった場合、クリック/タップしたときの期待 (ページが遷移する) と実際の挙動 (ボタンっぽいタブの下のタブパネル部分が差し替わる) が異なり、ユーザーを混乱させる恐れがあります。

また、タブっぽく見せるためには、タブ自体だけでなく、それに紐づくタブパネルもセットでデザインする必要があります。各タブとタブパネルがひと続きになっているように見えること、タブを選択するとタブパネルが切り替わるように感じられること、が大事です。

たとえば、タブの数が多すぎるなどの理由で、タブの並びが複数の列にわたってしまうと、選択されているタブと対応するタブパネルが離れてしまう恐れがあります。こうなると、タブっぽく見えませんし、ユーザーの認知負荷も高くなって、使いづらいものになります。

タブの並びが不自然でないこと

タブ型 UI においては、タブの並びが不自然でないことも重要です。ユーザーが数あるタブの中からひとつのタブを選ぶ際に、違和感を感じずスムーズに選択できるようにするためです。

以下を意識するとよいでしょう。

• タブの数 (選択肢) は多すぎず、適切であること。
• タブのラベルは簡潔であること。また各タブの表記スタイル (品詞など) に一貫性があること。
• タブの並び順が、ユーザーにとっての重要度または LATCH (場所、アルファベット/五十音、時系列、カテゴリーや階層関係) の観点で、自然であること。

タブの大きさが十分であるあること

タブは、タッチインターフェースでの利用に際して、指で間違いなくタップできるのに十分な大きさを持っている必要があります。スマートフォンやタブレットに限らず、今やタッチインターフェースを備えた PC もあるので、タブのデザインにおいては基本的に指でタップ操作することを基準にしたいものです。タブの大きさが十分であれば当然、マウスやトラックパッドを使っているユーザーにとってもクリックしやすくなります。

また、タブ内のラベルの可読性も重要です。スマートフォンのように小さな画面であっても、ラベルがストレスなく読める程度の文字サイズを確保するようにしましょう。

タブの切り替えに伴うフィードバックが自然であること

タブ型 UI においては、タブの切り替えに伴うフィードバックが自然であることが求められます。以下を意識するとよいでしょう。

• 選択されたタブが明示的で、瞬時に識別できること。
• タブを切り替えたときに、タブパネルも瞬時に (同時に) 切り替わること。
• タブの切り替え前にユーザーがページをスクロールしている場合は、タブ切り替えに際しても、スクロール位置 (つまりタブの表示位置) がそのまま維持されること。

上の箇条書きのうち3つ目は、特に、タブのクリック/タップがページ遷移 (ページのリロード) を伴うようなケースで要注意です。タブ切り替えの前後でタブの表示位置が変わってしまうと「どの部分が変わったか」がわかりにくくなり、ユーザーを混乱させる恐れがあるからです。個人的には、ページ遷移を伴う場合はタブ型 UI を採用しないほうがよいと考えています。

アクセシビリティの観点から配慮したいこと

キーボード操作ができること

タブ型 UI は、ポインティング操作 (マウスによるクリックや指によるタップ) での利用が大半になりますが、障害や怪我などでポインティングができない人でも利用できるように、キーボード操作ができるようにします。

一般的にウェブサイトのキーボード操作は [Tab] キーでのフォーカス移動と [Enter] キーでの実行が基本ですが、タブ型 UI の場合、フォーカスの動きが二次元的である (タブ選択という横方向の動きと、選択されたタブに紐づいたタブパネルへのフォーカス移動という縦方向の動きがある) ことに気を付ける必要があります。WAI-ARIA 1.0 Authoring Practices という文書の Design Patterns セクションの Tab Panel (widget) の項を見ると、タブの選択には左右 (および上下) 矢印キーを用い、[Tab] キーは、アクティブなタブおよびそのタブに紐づいたタブパネル内のフォーカス可能な要素にフォーカスを当てるのに用いるという考えかたのようです。

• Tab - only the active tab is in the tab order. The user reaches the tabbed panel component by pressing the tab key until the active tab title receives focus.
• Left Arrow - with focus on a tab, pressing the left arrow will move focus to the previous tab in the tab list and activate that tab. Pressing the left arrow when the focus is on the first tab in the tab list will move focus and activate the last tab in the list.
• Right Arrow - with focus on a tab, pressing the right arrow will move focus to the next tab in the tab list and activate that tab. Pressing the right arrow when the focus is on the last tab in the tab list will move focus to and activate the first tab in the list.
• Up arrow - behaves the same as left arrow in order to support vertical tabs
• Down arrow - behaves the same as right arrow in order to support vertical tabs

出典 : WAI-ARIA 1.0 Authoring Practices の Tab Panel (widget) の項 (Characteristic テーブルの「Keyboard Interaction」)

jQuery UI の「Tabs」 や heydonworks.com の Practical ARIA Example のサンプル (Simple ARIA tab interface) を見ると、上述の WAI-ARIA 1.0 Authoring Practices の考えに近い挙動をします。その一方で、メジャーな HTML/CSS/JavaScript フレームワーク (Bootstrap のタブ UI や Zurb Foundation のタブ UI) では、タブの選択 (タブ間のフォーカス移動) は矢印キーではなく [Tab] キーを用いる仕様になっています。

タブの選択に矢印キーを使うのか [Tab] キーを使うのか、どちらがスタンダードになるのか流動的ですが、今後の動向を注視しつつ、少なくとも同一サイト内では操作法の一貫性を維持したいところです。

スクリーンリーダーでも利用できること

キーボード操作に加えて、視覚障害者 (スクリーンリーダーのユーザー) でも利用できるようにしましょう。幸い、WAI-ARIA で、タブ型 UI のセマンティクスについて、以下のように設定することができるようになっています。

<ul role="tablist">
<li role="presentation"><a href="#tabpanel1" id="tab1" role="tab" aria-controls="tabpanel1" aria-selected="true">タブ1</a></li>
<li role="presentation"><a href="#tabpanel2" id="tab2" role="tab" aria-controls="tabpanel2">タブ2</a></li>
<li role="presentation"><a href="#tabpanel3" id="tab3" role="tab" aria-controls="tabpanel3">タブ3</a></li>
</ul>

<div id="tabpanel1" role="tabpanel" aria-labelledby="tab1">タブパネル1</div>
<div id="tabpanel2" role="tabpanel" aria-labelledby="tab2" aria-hidden="true">タブパネル2</div>
<div id="tabpanel3" role="tabpanel" aria-labelledby="tab3" aria-hidden="true">タブパネル3</div>

• タブの並びをリストとしてマークアップする。各 <li> の中には、タブパネルの要素 (<div>) の id 値を href 属性値に持つ <a> 要素がある。
• <ul> 要素に role="tablist"、各 <li> 要素に role="presentation"、各 <li> の中の <a> 要素に role="tab" を記述する。
• タブパネルの要素 (<div>) に、role="tabpanel" を記述する。
• タブとタブパネルの紐付けとして、各タブの <a> 要素に aria-controls 属性を記述する。属性値は、各タブに紐づくタブパネルの要素の id を入れる。
• タブパネルのラベル付けとして、各タブパネルの要素に aria-labelledby 属性を記述する。属性値は、各タブパネルに紐づくタブの <a> 要素の id を入れる。
• 選択されているタブの <a> 要素に対しては、aria-selected="true" を適用する。
• 選択されていないタブに紐づいている (隠れた) タブパネルの要素に対しては aria-hidden="true" を適用する。

マルチデバイス時代における制約

以上、タブ型 UI のユーザビリティおよびアクセシビリティ上の配慮ポイントを挙げてみましたが、マルチデバイスでのウェブ利用が当たり前になっている現在、ウェブサイトにおけるタブ型 UI の採用は、以前より限定的になっている気がしています。スマートフォンでのポートレート表示を考慮した場合、十分な大きさのタブを並べる (とりわけ日本語で、可読性の高いラベルを含む) となると、タブの数は2つないし3つが限度なケースが多いな、という感覚です。

タブ型 UI は他の多くの UI コンポーネントと異なりどうしても二次元的 (機能が縦方向と横方向の両方に展開される) なので、それがマルチデバイス対応においては制約となりますが、逆にユーザーにとっては (タブつまり選択肢が少ない分) 使いやすくなるとも言えるわけで、個人的にはこの制約をポジティブに受け入れたいと考えています。