今回は、より大規模でモダンな開発環境、特にReactやVueなどのフレームワークを用いたSPA（シングルページアプリケーション）開発において、見過ごされがちなアクセシビリティの課題と、それを解決するための応用的な戦略をご紹介します。
1. SPAの最大の課題：ルーティング後のコンテキスト喪失を防ぐ
SPAでは、ページ遷移（ルーティング）が発生しても、ブラウザの「ページ更新」は行われません。これにより、視覚的な変化はあっても、スクリーンリーダーには「ページが変わった」ことが伝わらず、ユーザーが迷子になるという深刻な問題が発生します。
💡 解決策：仮想のページタイトルとフォーカス管理
- 仮想ページタイトルの設定:ルーティング後のコンポーネントがマウントされた際、JavaScriptでページの<title>タグを更新します。これにより、スクリーンリーダーユーザーに「今、どこにいるか」を伝えます。
- メインコンテンツへのフォーカス移動:ページ遷移完了後、メインコンテンツのコンテナ要素（role=”main”を持つ要素や<main>タグ）にプログラム的にフォーカスを移動させます。JavaScript
// ルーティング後 document.title = '新しいページタイトル | サイト名'; document.getElementById('main-content').focus(); // ※ main-contentにはtabindex="-1"を設定し、プログラムからフォーカス可能にしておく
2. コンポーネント指向開発におけるARIAの責任範囲
コンポーネント指向（例：Atomic Design）で開発を進める際、どのコンポーネントがARIA属性の責任を持つべきか、その粒度を明確にすることが、効率的な管理の鍵となります。
🧩 粒度に応じたARIA管理の原則
| コンポーネント粒度 | ARIA属性の責任範囲 | 例 |
| アトム (最小単位) | 状態（State）に関する属性を管理。 | aria-expanded (開閉ボタン)、aria-selected (タブヘッダー) |
| 分子 (UIの塊) | 構造（Role）に関する属性を管理し、アトムのステートを集約。 | role="tablist" (タブの親)、aria-labelledby (ラベル参照) |
| テンプレート/ページ | ランドマークロールやグローバルな関連付けを管理。 | <header role="banner">、ページ全体のエラー通知（ライブリージョン） |
この責任を明確化することで、「このボタンのaria-expandedは誰が更新するのか？」といった曖昧さをなくし、大規模なチーム開発でも一貫したアクセシビリティ品質を保つことができます。
3. 高度な情報伝達：カスタム通知システムとライブリージョン
前回触れたライブリージョンを、カスタムの通知・トーストメッセージシステムに応用するテクニックです。
📣 トースト通知の実装戦略
多くのSPAでは、画面上部に一時的な「トースト通知」が表示されます。これをスクリーンリーダーに確実に伝えるためには、通知コンテナに**role="status"またはrole="alert"**を使用します。
- role=”status” （控えめ）：システムの状態変化（例：「保存が完了しました」「オフラインになりました」）など、ユーザーの操作を中断しなくても良い情報に使います。これはaria-live=”polite”の暗黙のロールを持ちます。
- role=”alert” （断定的）：即座の注意を要するエラーや警告（例：「接続に失敗しました」「不正な入力です」）に使います。これはaria-live=”assertive”の暗黙のロールを持ちます。
📌 実装のポイント:
通知メッセージのコンテナ要素をあらかじめDOM内に用意し、aria-live属性を設定しておきます。そして、通知が発生した際にJavaScriptでコンテナ内にメッセージを挿入することで、スクリーンリーダーに新しい内容を読み上げさせることができます。
4. まとめ：ARIAを設計段階から組み込む
応用編で学んだ内容は、もはや「後から付け足す」アクセシビリティ対策ではなく、ウェブアプリケーションの設計段階で組み込むべきアーキテクチャの一部です。
- SPAルーティング: 仮想のページタイトル更新とメインコンテンツへのフォーカス移動で、コンテキストを維持する。
- コンポーネント責任: 粒度に応じてARIA属性の管理責任を明確にし、一貫性を保つ。
- カスタム通知:
role="status"やrole="alert"を使い分け、ユーザーへの情報伝達を最適化する。
