タブのアクセシビリティ実装テクニック
公開日：
更新日：
タブはなぜ難しい？
ウェブでよく使われるUIのひとつが「タブ」。
見た目はシンプルですが、実際にアクセシビリティ対応を行うと「ロールや属性の付与」「選択状態の管理」「キーボード操作」など考えることが多く、実装難度は意外と高めです。
タブをUIとして選択しないという手段もありますが、必要なケースもあります。
よくある惜しい実装例
キーボード操作できない
現在地が伝わらない
すべてtabindex="0"
こうした実装を避けるため、ここでは APG（ARIA Authoring Practices Guide） をベースにしつつ、利用シーンに合わせて調整できる実装方法を紹介します。
https://www.w3.org/WAI/ARIA/apg/patterns/
1) ロールと要素を正しく関連付ける
タブUIの基本は 「どことどこが結びついているか」を明示することです。
tablist・tab・tabpanel のロールを付与し、aria-controls・aria-labelledby で相互参照を作ります。参照IDは一意であることが必須です。
2) ロービングタブインデックスを理解
Tabキーで移動したときに、選択中のタブだけがフォーカス可能にするのが「ロービングタブインデックス」です。aria-selected とセットで更新するのがポイントです。
これにより、矢印キーやTabキーでの移動が直感的かつスムーズになります。
3) キーボード操作（矢印＋Home/End）
タブは キーボード操作のしやすさが大事です。
横型なら ←/→、縦型なら ↑/↓ を割り当て、Home/End で先頭・末尾に移動できるようにします。
循環移動（最後の次は最初へ）も実装すると操作性が上がります。
また、aria-orientationで 向きを明示することも大切です。
これにより、縦型タブでもスクリーンリーダー・キーボード操作の両方に正しく伝わります。
タブとスクリーンリーダー対応について
主要な支援技術での挙動は以下の通りです。
特に PC-Talker ユーザーにとっては「タブUIそのものが見えない」課題が残ります。
NVDA（Windows）：○ タブを認識する
VoiceOver（iOS / Mac）：○ タブを認識する
TalkBack（Android）：○ タブを認識する
PC-Talker（Windows）：△ タブを認識しない
PC-Talker向け改善案
他のスクリーンリーダーでは少し冗長になりますが、補助的にスクリーンリーダー用テキストなど用意することで改善できる場合があります。「現在は〇〇のタブを表示中です」といった短い一言を補足的に伝えるイメージです。
プロジェクトの性質や利用者層に応じて、採用してみてください。
まとめ
タブのアクセシビリティ実装は難しく見えますが、ポイントを押さえればシンプルです。
ロールや要素で関係を作る
選択中だけtabindex=0とaria-selected="true"
矢印キー操作を入れる
向きをaria-orientationで伝える
この4つを押さえるだけで、支援技術ユーザーにとってぐっと快適になります。
告知
2025年10月3日（金）21:00 - 26:00 オンライン開催の「#朝までマークアップ 3（JS編）」に出演いたします。
当日は、アクセシビリティを考慮したUIの話をします。
この記事にご興味を持っていただけましたら、ぜひご参加ください！
関連記事
この記事のハッシュタグ #Accessibility から関連する記事を表示しています。
動きのあるウェブアクセシビリティ対応はどうやって対応するの？
モーダルやタブ、アコーディオンなど「動き」のあるUIは、デザイン性や利便性を高める一方で、支援技術ユーザーにとっては操作や理解が難しくなることがあります。そのため、動きを伴うコンポーネントを実装する際は「アクセシビリティ対応」が欠かせません。参考ガイドラインW3C が公開している ARIA Authoring Practices Guide (APG) では、実際のUIパターンごとに「ロールや属性の付け方」「キーボード操作の仕様」などが整理されています。タブ、モーダル、ツリー、メニューなど、多くのケースで 実装コード例 が紹介されており、開発者が迷わず対応できるようになっています。ARIA Authoring Practices Guide (APG)このガイドを参考にすることで、動きのあるUIをアクセシブルに作るための基本を把握することができます。実際にどう活かすか実務では、APGが全て正解として見るだけでなく、実装しているUIが 想定された操作と一致しているかロービングタブインデックスやaria属性の相互参照が抜けていないかスクリーンリーダーで操作が伝わるかスクリーンリーダー読み上げに無理はないかキーボード操作で操作できるかといった観点でチェックするのも大事なポイントです。自社の取り組み：ハンドブックとブログ私たち、ましじめでも、社内外の方に役立つよう「ウェブアクセシビリティハンドブック」と「アクセシビリティ連載ブログ」を公開しています。日本語で考え方もまとめていますので、ぜひ参考にしてみてください。ウェブアクセシビリティハンドブックブログ：アクセシビリティ連載おわりに「動きのあるUI」をアクセシブルにすることは、単に基準に適合させるためだけではなく、誰にとっても「自然に使いやすい」体験につながります。APGを基盤としつつ、私たちのハンドブックやブログも実装の一助になれば幸いです。
スタッフブログ
ウェブアクセシビリティとは
ウェブアクセシビリティとは、視覚障害、聴覚障害、肢体不自由、認知障害など、様々な障害を持つ人を含む、すべての人がウェブサイトやウェブアプリケーションを支障なく利用できるようにするための取り組みです。アクセシビリティとは | ウェブアクセシビリティ基盤委員会（WAIC）ウェブアクセシビリティは、決して特別なものではありません。なぜなら、それはすべての人にとって使いやすいウェブサイトを作るための基本的な考え方だからです。一時的な困りごと日差しで画面が読みにくい、片手がふさがって操作しづらい など日常の小さな不便マウスなし（キーボードだけ）で操作したい場面 など状態・位置の見失いフォームでどこがエラーか分からない など高齢者で文字が見えづらい、日本語を母語としない人が翻訳機能を使いたい、といった場合も同様です。このようなさまざまな不都合があります。まとめアクセシブルなUIは、一部の人だけではなく、すべてのユーザーにとって使いやすいUIです。つまり、ウェブアクセシビリティは、より多くの人に価値を提供し、より良いウェブ体験を実現するための鍵なのです。
スタッフブログ
