ARIAとデザイナーの責任｜アクセシブルな利用者インターフェース設計の実践ガイド

ARIAは、HTMLへ追加する技術的な属性の集合として説明されることが多いため、デザイナーの担当範囲から離れたものだと誤解されやすい仕組みです。しかし、ARIAが支援技術へ伝えるのは、操作部品の役割、現在の状態、利用者が認識すべき名前、要素同士の関係、画面内で発生した変化などです。これらの情報は、実装担当者がコードを書く段階で突然生まれるものではありません。ボタンが何を実行するのか、パネルがいつ開くのか、選択中の項目をどのように示すのか、エラー後に利用者をどこへ導くのかといった判断は、利用者体験と画面動作を設計する段階ですでに決められている必要があります。

例えば、デザイナーがモーダルダイアログの通常画面と表示後の画面だけを作成し、開いた直後のフォーカス位置、閉じるための操作、背景領域の扱い、処理完了後の移動先を記載しなかった場合、実装担当者は静止画から挙動を推測しなければなりません。その結果、マウスでは問題なく操作できても、キーボードでは背景へフォーカスが移動する、画面読み上げソフトではダイアログが開いたことが分からない、閉じた後にページ先頭へ戻ってしまうといった問題が発生します。見た目が正確に再現されていても、意味と操作が欠けていれば、完成した利用者インターフェースは設計された体験と同じものにはなりません。

WAI-ARIA 1.2は2023年6月6日にW3C勧告として公開され、WAI-ARIA 1.3は2026年6月4日時点で作業草案として公開されています。実務では安定した勧告、ARIA Authoring Practices Guide、WCAG 2.2、ブラウザや支援技術の対応状況を確認しながら判断する必要があります。ARIAは複雑な利用者インターフェースへ意味を補う強力な仕組みですが、不適切な指定によってHTML本来の意味を上書きし、利用者へ誤った情報を伝える危険もあります。したがって、デザイナーに求められるのは属性名の暗記ではなく、意味、見た目、操作、状態、通知が矛盾しない体験を設計し、それを実装可能な仕様として共有することです。

1. ARIAとは

ARIAは、標準HTMLだけでは十分に表現しにくい複雑な操作部品や動的な画面更新について、支援技術が理解できる意味情報を補うための仕組みです。デザイナーがARIAを理解する際には、属性一覧を覚えることよりも、画面に表示されている視覚情報のうち、見えない利用者にも伝えるべき情報は何かを考える必要があります。

1.1 ARIAが支援技術へ伝える情報

ARIAは、要素がボタン、タブ、ダイアログ、警告、メニューなどの何であるかを示す役割、開いている、選択されている、押されている、無効であるといった状態、さらに操作対象や説明文との関係を支援技術へ伝えます。画面を直接見ている利用者は、色、形、配置、アイコン、アニメーションなどから多くの情報を同時に受け取れますが、画面読み上げソフトは、それらの視覚表現をそのまま意味として理解できるわけではありません。したがって、視覚的に表現されている意味を、プログラムによって判断できる情報として提供する必要があります。

デザイナーは、どのARIA属性を使用するかを単独で決定しなくても、支援技術へ何を伝えるべきかを明確にする責任があります。例えば、絞り込みボタンを押すと条件パネルが開く場合、仕様には「ボタンである」「対象パネルを開閉する」「閉じている状態と開いている状態がある」「画面上の矢印と開閉状態を同期させる」といった情報が必要です。この意味設計が存在すれば、実装担当者は標準HTMLと必要最小限のARIAを選べますが、意味設計がなければ、属性だけを形式的に追加した不正確な実装になりやすくなります。WAI-ARIAは役割、状態、属性を通して利用者インターフェースの意味を提供する枠組みとして定義されています。

1.2 ARIAが必要になる利用者インターフェース

標準的なボタン、リンク、見出し、入力欄、選択欄、チェックボックスなどは、適切なHTML要素を使うことで、ブラウザが必要な役割や基本動作を支援技術へ提供します。一方で、タブ、ツリービュー、独自の候補一覧、複雑なメニュー、動的に更新される検索結果、ドラッグ操作を伴う並べ替えなどは、標準HTMLだけでは状態や関係を十分に伝えにくい場合があります。このような場面では、ARIAによって不足する意味を補い、JavaScriptによって期待される操作を実装する必要があります。

ただし、画面が視覚的に複雑だからという理由だけでARIAを追加してはいけません。例えば、開閉する説明領域は標準のdetails要素で実現できる場合があり、選択肢は標準のselect要素で十分な場合があります。独自部品を設計する前に標準HTMLで目的を達成できるかを検討し、標準要素では満たせない明確な理由がある場合にだけ複雑なパターンを選ぶことが重要です。デザイナーが標準部品を避ける判断をすると、開発側は意味、キー操作、フォーカス、状態同期、支援技術対応を一から再構築することになり、製品全体の保守負担も増加します。

1.3 ARIAが自動的に提供しない動作

ARIAは要素へ意味を付加しますが、クリック、開閉、フォーカス移動、キー入力への応答、入力値の検証などの動作を自動的には追加しません。例えば、div要素へrole="button"を設定すると、支援技術からボタンとして認識される可能性がありますが、標準のbutton要素が持つTabキーによる到達、EnterキーやSpaceキーによる実行、無効状態の処理などがすべて付与されるわけではありません。役割だけがボタンになり、実際の操作がボタンとして成立していない状態は、利用者の期待を裏切る実装です。

デザイナーが「ARIAを付ければアクセシブルになる」と考えると、意味と動作を分離した不完全な仕様が生まれます。操作部品を設計するときは、見た目、役割、操作方法、状態変化、結果の通知、操作後のフォーカス位置を一つの体験として扱う必要があります。実装担当者へ渡す仕様にも、「ボタンとして読み上げる」といった意味だけでなく、「Tabキーで到達できる」「EnterキーとSpaceキーで実行する」「処理中は連続実行を防ぐ」「完了後は結果を通知する」といった動作を含めなければなりません。

コード例：役割だけを付けた不十分な実装

<div role="button">保存</div>

コード例：標準ボタンを使用した実装

<button type="button">保存</button>

1.4 アクセシビリティツリーとの関係

ブラウザは、HTML、ARIA、要素の状態、表示状況などを解釈し、支援技術が参照するアクセシビリティツリーを構築します。このツリーでは、画面上の色や座標よりも、見出し、ボタン、入力欄、ナビゲーション、選択状態などの意味が重要になります。画面読み上げソフトの利用者は、この構造を使って見出しから見出しへ移動したり、ボタンの一覧を表示したり、フォーム項目だけを順番に確認したりできます。

デザイナーはアクセシビリティツリーを直接作成するわけではありませんが、その元になる意味構造を決めます。画面上の大きな文字が見出しなのか装飾文なのか、複数の入力欄がどのグループに属するのか、現在選択されている項目は何か、補足説明はどの操作部品を説明しているのかといった関係を明確にする必要があります。デザインデータの階層名やフレーム構造だけでは、ウェブページ上の意味構造は確定しません。実装仕様として見出しレベル、領域の役割、ラベルとの関連、読み上げ順序まで共有することで、視覚構造とアクセシビリティツリーの不一致を減らせます。

1.5 不適切なARIAが引き起こす問題

ARIAを誤って使用すると、情報が不足しているだけでなく、利用者へ事実と異なる情報を伝える可能性があります。例えば、ページ移動を行うリンクへボタンの役割を指定すると、利用者は現在の画面上で処理が実行されると期待するかもしれません。また、閉じているパネルのボタンへaria-expanded="true"が残っていれば、画面読み上げソフトでは開いていると通知される一方、画面上には内容が存在しないという矛盾が生じます。存在しない要素をaria-labelledbyで参照した場合には、操作部品の名前そのものが失われることもあります。

この問題を防ぐには、ARIA属性の数を品質指標にせず、見た目、意味、操作、状態が一致しているかを確認しなければなりません。ARIA Authoring Practices Guideは、ARIAがHTMLの意味を強化できる一方で、本来の意味を上書きして誤った情報を伝える危険もあると説明しています。デザイナーは「何らかのARIAが付いているから対応済み」と判断せず、利用者が部品の目的を理解できるか、期待する方法で操作できるか、状態変化を認識できるかを受け入れ条件として設定する必要があります。

2. ARIAとネイティブHTMLの違い

ARIAを正しく使うためには、標準HTML要素が最初から備えている意味や操作と、ARIAによって後から補う意味の違いを理解する必要があります。見た目を自由に変更できるという理由だけで独自要素を選ぶと、ブラウザが無料で提供していた多くの機能を、制作チームが自分たちで再実装しなければなりません。

2.1 意味情報の違い

ネイティブHTMLでは、button要素はボタン、a要素はリンク、input type="checkbox"はチェックボックスという意味を要素自体が持っています。ブラウザと支援技術は、この標準的な意味を共通の規則として解釈できます。一方、divやspanのような意味を持たない要素へARIAの役割を設定する場合、制作者が意図した意味を後から追加することになります。指定が正しければ不足する意味を補えますが、指定を間違えると、実際の動作と異なる役割が支援技術へ伝わります。

デザイナーが標準要素を前提として設計すれば、実装担当者はブラウザが提供する意味を利用し、必要な状態だけを追加できます。これに対し、見た目の都合で独自要素を前提にすると、役割、状態、名前、説明、操作方法をすべて個別に設計しなければなりません。標準要素を選ぶことは視覚表現を諦めることではなく、安定した意味を基礎として見た目を設計することです。特殊な表現が本当に標準要素では実現できないのかを確認してから、独自部品を選ぶ順序が重要です。

2.2 キーボード操作の違い

標準のbutton要素は通常、Tabキーでフォーカスでき、EnterキーまたはSpaceキーで実行できます。チェックボックスやラジオボタンも、それぞれの部品に期待される標準的なキー操作をブラウザが提供します。独自要素へARIAの役割を付けただけでは、これらの動作は自動的に追加されません。Tabキーで到達させるための設定、EnterキーやSpaceキーへの応答、無効状態で処理を停止する制御などを個別に実装する必要があります。

デザイナーがマウスクリック時の画面だけを示し、キーボード操作を定義しない場合、開発者ごとに異なる操作が実装される可能性があります。ある画面ではEnterキーだけが使え、別の画面ではSpaceキーだけが使えるといった不統一は、利用者の学習負担を増やします。操作方法は実装上の細部ではなく、利用者インターフェースの仕様です。標準要素を使用する場合も、独自部品を使用する場合も、どのキーで到達し、実行し、閉じ、内部を移動するかをデザイン段階で確認する必要があります。

コード例：標準ボタンを優先した開閉操作

<button  type="button"  aria-expanded="false"  aria-controls="filter-panel" >  絞り込み条件を開く </button> <section id="filter-panel" hidden>  <!-- 絞り込み条件 --> </section>

2.3 状態管理と保守性の違い

ネイティブHTMLは、選択、入力、無効、必須などの多くの状態を標準属性として管理できます。ブラウザはそれらの状態を表示や操作へ反映し、支援技術へ伝えます。独自部品の場合、見た目の状態、内部データ、ARIA属性、フォーカス可能性、操作可否を別々に管理しなければならない場合があります。どれか一つの更新を忘れると、画面では選択されているのに支援技術では未選択と伝わるなど、状態の不一致が発生します。

この差は、単一画面よりもデザインシステムや大規模な製品で大きな影響を持ちます。一つの独自コンポーネントに不具合があると、それを利用するすべての画面へ問題が広がります。デザイナーは、独自表現によって得られる価値と、長期的な実装・検証・修正コストを比較しなければなりません。標準部品を利用できる場面で独自部品を増やさないことは、アクセシビリティだけでなく、品質の一貫性、開発速度、将来の変更容易性にもつながります。

2.4 読み上げと利用者の期待の違い

標準HTMLを適切に使用すると、ブラウザは要素の名前、役割、状態を支援技術へ提供します。利用者は、ボタンと通知されればEnterキーやSpaceキーで実行できること、リンクと通知されれば別の場所へ移動することを期待します。ARIAで役割を付けた独自部品も同じ期待を生みますが、実装がその期待を満たしている保証はありません。つまり、ARIAは意味だけでなく、利用者が予測する操作モデルも発生させます。

デザイナーは、画面読み上げソフトが発する文章を一字一句指定する必要はありません。読み上げ方はブラウザ、支援技術、利用者設定、言語によって変わるためです。ただし、何という名前で、何の役割として、どの状態が伝わるべきかは定義しなければなりません。「保存、ボタン」「詳細設定、折りたたまれています」「通知、3件の結果が見つかりました」のように、利用者が判断に必要な情報を想定し、見た目と動作が同じ意味を示しているかを確認します。

2.5 デザイン成果物に必要な情報の違い

標準HTMLを中心に設計する場合、デザイン成果物では標準動作を前提としながら、視覚状態、文言、配置、不足する説明を指定できます。独自部品を設計する場合は、それに加えて役割、キー操作、フォーカス移動、状態属性、内部項目の移動方法、開閉後の挙動、非表示時の扱いなどを詳細に記載する必要があります。画面の静止画像だけでは、複雑な独自部品を正確に実装するための情報が不足します。

「開発側でARIA対応」とだけ注釈する方法では、何をもって対応完了とするのか判断できません。デザイナーは、標準要素を使うのか、独自部品が必要なのか、独自部品であればどの既存パターンを採用するのかを明確にします。さらに、通常、ホバー、フォーカス、選択、無効、読み込み中、エラーなどの状態と、状態間の遷移条件を示す必要があります。独自性が高いほど成果物に含める情報量が増えるという前提を、スケジュールや担当範囲にも反映させることが重要です。

3. デザイナーがARIAに関与する理由

ARIA属性をHTMLへ記述する作業は主に実装担当者が行いますが、その属性が表す意味はデザイン上の判断から生まれます。デザイナーが意味と操作を定義せず、実装担当者だけに判断を任せると、同じ製品内でも部品の役割や状態が一貫しなくなり、利用者にとって予測しにくい体験になります。

3.1 見た目だけでは部品の役割を確定できない

角丸の長方形で表示された要素が、処理を実行するボタンなのか、別ページへ移動するリンクなのか、選択状態を切り替えるトグルなのかは、見た目だけでは判断できません。同様に、三点アイコンは「その他の操作」「詳細情報」「並べ替え」「設定」など複数の意味に使用されます。完成画面だけを渡された実装担当者は、画面遷移資料や会話から目的を推測しなければならず、誤ったHTML要素や役割を選ぶ可能性があります。

デザイナーは各操作部品について、利用者が実行する行為と結果を言葉で説明できる状態にする必要があります。「押すと何が起こるのか」「現在の画面内で処理するのか」「別の場所へ移動するのか」「押すたびに状態が切り替わるのか」を明確にすれば、適切な標準要素を選びやすくなります。役割を視覚スタイルから決めるのではなく、機能と利用者の期待から決めることが、ARIA以前の重要なデザイン責任です。

3.2 状態変化はデザイン工程で決まる

展開、折りたたみ、選択、未選択、押下、無効、読み込み中、成功、警告、エラーなどの状態は、実装時に初めて必要になる情報ではありません。利用者が操作結果を理解し、次の行動を選ぶために必要な画面状態であり、デザイン工程で定義されるべきものです。ARIAの状態属性は、その設計された状態を支援技術へ伝えるために使われるため、デザイナーが状態を決めなければ、正確な属性値も決まりません。

通常状態と最終状態だけを作成し、途中状態や例外状態を省略すると、開発側が独自に補完することになります。例えば保存ボタンを押した後、処理中にボタンを無効にするのか、読み込み表示を出すのか、再度押せるのか、失敗時に入力内容を保持するのかといった判断は、利用者体験へ直接影響します。各状態の見た目だけでなく、発生条件、継続時間、解除条件、利用者への通知方法まで示すことで、視覚状態とARIA状態を同じ仕組みから更新できるようになります。

3.3 操作フローがフォーカス移動を決める

モーダルを開いた直後にどこへフォーカスを移すか、項目を削除した後にどこへ戻すか、入力エラー後にどの位置から修正を始めるかは、単なるJavaScriptの実装方法ではありません。利用者が作業の文脈を維持し、次の行動を迷わず選べるようにする体験設計です。マウス利用者は画面全体を見て次の場所を選べますが、キーボードや画面読み上げソフトの利用者は現在位置を基準に操作するため、フォーカスの移動先が特に重要になります。

デザイナーは画面遷移図にページ単位の移動だけでなく、画面内のフォーカス遷移も含める必要があります。モーダルを閉じたら起動ボタンへ戻る、削除した項目が消えたら次の項目へ移る、フォーム送信に失敗したらエラー概要または最初のエラー項目へ移るなど、主要な操作後の位置を定義します。こうした仕様がなければ、開発者は技術的に実装しやすい位置を選び、利用者の作業順序と合わない挙動になる可能性があります。

3.4 文言設計がアクセシブルな名前を決める

操作部品の名前は、画面読み上げソフトの利用者が部品を識別するだけでなく、音声入力の利用者が画面上の文字を発話して操作する際にも使われます。アイコンだけのボタンに名前がなければ、画面読み上げソフトでは「ボタン」とだけ通知される可能性があり、何を実行するか判断できません。反対に、画面には「検索」と表示されているのに、プログラム上の名前が「商品を見つける」だけであれば、音声入力による指定が難しくなる場合があります。

デザイナーやコンテンツ担当者は、表示文言と支援技術向けの名前を別々の世界として扱ってはいけません。視覚ラベルが存在する場合は、その文字列をアクセシブルな名前に含め、可能であれば同じ語から始めることが重要です。同じ「編集」「削除」「詳細」が一覧内に繰り返される場合は、対象名を追加して識別可能にします。名前の長さを増やしすぎず、単独で聞いても目的が分かり、画面上の文言とも一致する表現を設計する必要があります。

3.5 既存パターンを製品へ適用する判断が必要になる

ARIA Authoring Practices Guideには、ボタン、タブ、ダイアログ、メニュー、リストボックス、ツリーなどの一般的なパターンと、期待されるキー操作、役割、状態が掲載されています。これらは複雑な部品を設計するときの重要な出発点ですが、掲載例をそのまま外見だけコピーすれば完成するわけではありません。製品の情報量、読み込み速度、利用頻度、端末、対象利用者に応じて、どのパターンが適切かを判断する必要があります。

例えば、タブパターンは一つの領域内で複数の内容を切り替える用途に適していますが、切り替えのたびに大きな通信が発生する場合、矢印キーでフォーカスを移動しただけで自動表示すると操作が遅くなることがあります。また、サイトの一般的なナビゲーションへアプリケーション用のメニューロールを適用すると、利用者が期待するキー操作が変化します。デザイナーは既存パターンを基準にしながら、製品の条件に合わせて選択し、変更する場合は理由、代替操作、検証方法まで共有しなければなりません。

4. アクセシブルな名前の設計責任

操作部品には、支援技術がプログラムによって判断できる名前が必要です。この名前は単なる補足文章ではなく、利用者が部品を探し、目的を理解し、音声で指定し、同じ種類の部品を区別するための主要な情報になります。

4.1 視覚ラベルとプログラム上の名前を一致させる

画面上に表示されているラベルと、支援技術へ伝わる名前が異なると、複数の利用方法で矛盾が生じます。画面を見ながら音声入力を使う利用者は、表示されている「検索」という文字を発話して操作しようとします。しかし、プログラム上の名前が「商品を探す」だけであれば、表示文字と音声操作の対象名が一致しません。また、支援者が画面を見ながら操作方法を説明するときにも、互いに異なる名前を認識している状態になります。

WCAG 2.2の達成基準2.5.3では、文字または文字を含む画像による視覚ラベルがある利用者インターフェース部品について、その表示文字列をプログラム上の名前に含めることが求められています。デザイナーは、見た目を短くするための表示文言と、支援技術向けに詳しくした名前を完全に別の文章へ分けるのではなく、表示文言を基礎として必要な対象情報を追加します。「編集」を表示し、名前を「春季キャンペーンを編集」とするように、表示語を保ちながら識別性を高める方法が有効です。

4.2 アイコンボタンへ具体的な名前を付ける

虫眼鏡、歯車、鉛筆、星、三点リーダーなどのアイコンは、画面上で頻繁に使用されますが、形だけで機能が一意に決まるわけではありません。鉛筆は編集を表すことが多いものの、注釈の追加や署名を意味する場合もあります。三点リーダーも、その他の操作、詳細、ページ送りなど複数の用途に使われます。アイコンを見られない利用者に対しては、画像の形ではなく、実行される操作を名前として伝える必要があります。

デザイナーは、アイコン部品の仕様に表示用のアイコンだけでなく、アクセシブルな名前を必須項目として含めます。「設定」「検索条件を開く」「プロフィールを編集」「その他の操作を開く」など、動作と対象が分かる名前を指定します。同じアイコンが複数の文脈で使われる場合は、コンポーネントへ固定の名前を埋め込まず、利用箇所に応じた名前を渡せる設計にします。装飾用のアイコンは支援技術から隠し、ボタン本体の名前が重複して読み上げられないようにすることも重要です。

コード例：アイコンボタンへ名前を付ける

<button type="button" aria-label="検索条件を開く">  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">    <!-- 虫眼鏡アイコン -->  </svg> </button>

4.3 aria-labelによる上書きを避ける

aria-labelは、画面上に表示文字がないアイコンボタンなどへ名前を与える際に便利ですが、既存の表示文字や関連付けられたラベルより優先される場合があります。そのため、表示されている文言とは異なるaria-labelを安易に設定すると、画面を見ている利用者と支援技術の利用者が異なる名前を認識する状態になります。また、画面文言を変更したときにaria-labelだけが古いまま残り、意味の不一致が発生することもあります。

視覚ラベルが存在する場合は、まずその表示文字や標準のlabel要素から名前を取得できる構造を選びます。aria-labelを使用するのは、表示文字が存在せず、他の表示要素を参照する方法も適さない場合に限定する方針が安全です。デザインシステムでは、aria-labelを常に必須入力にするのではなく、どの部品で必要になるのか、表示文言との一致を誰が確認するのか、翻訳時にどのように管理するのかを明確にします。

4.4 aria-labelledbyで表示文言を再利用する

aria-labelledbyを使用すると、画面上に存在する見出しやラベルを、別の要素のアクセシブルな名前として参照できます。例えばモーダルダイアログの見出しをダイアログ全体の名前として利用すれば、利用者が画面上で読む見出しと、ダイアログを開いたときに支援技術が伝える名前を同じ情報源から取得できます。文言が変更された場合も一つの要素を更新すればよいため、表示文言とプログラム上の名前が食い違う危険を減らせます。

ただし、この方法を使えば自動的に安全になるわけではありません。参照先の識別子が重複している、参照対象が条件によって削除される、複数の文言を不自然な順序で連結するといった問題が起こる可能性があります。デザイン仕様では、どの表示要素がどの部品の名前になるのかを関係線や注釈で明確にし、実装後にはアクセシビリティツリーで実際の名前を確認します。見出しをデザイン上の理由で非表示にする場合も、名前の参照元として必要かどうかを確認してから変更する必要があります。

コード例：見出しをダイアログの名前として参照する

<div  role="dialog"  aria-modal="true"  aria-labelledby="delete-dialog-title" >  <h2 id="delete-dialog-title">ファイルを削除しますか</h2>  <p>この操作は取り消せません。</p> </div>

4.5 一覧内で繰り返される操作名を区別する

商品一覧、記事一覧、管理画面などでは、「詳細」「編集」「削除」「共有」といった同じ操作が複数回繰り返されます。画面を直接見ている利用者は、各ボタンの近くにある商品名や記事名から対象を判断できます。しかし、画面読み上げソフトの機能でボタンだけを一覧表示した場合、すべてが「編集、ボタン」と通知されると、どの項目を操作するものか区別できません。

デザイナーは、表示上の簡潔さを維持しながら、プログラム上の名前へ対象情報を含める方法を設計します。例えば表示文字は「編集」のままとし、名前を「採用ページを編集」「料金ページを編集」のようにします。ただし、音声入力との整合性を保つため、表示されている「編集」という文字列は名前に含めます。対象名が非常に長い場合は、一覧の構造や行見出しとの関連を使えるかを実装担当者と検討し、不必要に長い名前を各ボタンへ繰り返さない方法を選びます。

5. ロールとコンポーネントの選択

ロールは、その要素が利用者にとって何であるかを支援技術へ伝えます。デザイナーは、見た目の呼び名や社内用語ではなく、利用者がその部品へどのような操作と結果を期待するかに基づいてコンポーネントを選ぶ必要があります。

5.1 ボタンとリンクを機能で使い分ける

ボタンは現在の画面やアプリケーション内で処理を実行するために使い、リンクは別のページ、文書、画面内の位置などへ移動するために使うのが基本です。保存、削除、送信、モーダルを開く、表示を切り替えるといった操作はボタンに適しています。一方、商品詳細へ移動する、別の手続きページを開く、文書を参照するなどの移動はリンクに適しています。見た目を同じスタイルにすることはできますが、内部の意味まで同じにしてはいけません。

この区別を誤ると、利用者が期待するブラウザ機能やキー操作を利用できなくなります。リンクであれば、新しいタブで開く、リンク先をコピーする、訪問済み状態を確認するといった操作が可能です。ボタンであれば、現在の画面内で何らかの処理が起きると予測されます。デザイナーは「青い部品だからボタン」「文字だけだからリンク」と判断せず、実行後に何が起こるかを基準に要素を選びます。APGでも、ボタンは操作や出来事を実行する部品、リンクは資源への参照として説明されています。

5.2 見出しと主要領域を構造として設計する

見出しは文字を大きく太く表示するための装飾ではなく、ページ内容の階層を示す構造です。画面読み上げソフトの利用者は見出し一覧を表示し、興味のある部分へ直接移動できます。したがって、視覚的な大きさだけでなく、どの内容が同じ階層にあり、どの見出しの下へ属するのかをデザイン段階で決める必要があります。見た目の都合で見出しレベルを飛ばしたり、本文を見出しのように装飾したりすると、視覚構造と文書構造が一致しなくなります。

ページ全体の主要領域についても、ヘッダー、ナビゲーション、主内容、補足領域、フッターなどを明確にします。単にフレームを分けるだけでなく、利用者がどの領域へ直接移動できると便利かを考えます。同じ種類の領域が複数存在する場合は、それぞれを区別できる名前も必要です。WCAGの情報及び関係性に関する解説では、視覚的に伝わる構造や関係をプログラムによっても判断可能にすることが重要とされています。

5.3 タブと単なるボタン群を区別する

横に並んだ複数の選択肢は、見た目だけを見るとタブ、絞り込みボタン、ページ内リンク、切り替えスイッチのいずれにも見えます。タブは、一つの領域内に複数の内容パネルがあり、一度に一つのパネルを表示するためのパターンです。各タブは対応するパネルを持ち、選択中のタブと表示中のパネルの関係が明確でなければなりません。単に検索条件を変更するボタンや、別ページへ移動するリンクへタブの役割を付けるのは適切ではありません。

デザイナーは、選択状態が維持されるか、同一画面内のパネルだけが切り替わるか、矢印キーによる内部移動を提供するか、表示中のパネルが一つに限定されるかを確認します。タブを選んだときにURLやページ全体が変わる場合は、通常のナビゲーションの方が利用者の期待に合う可能性があります。見た目をタブ風にすることと、ARIAのタブパターンを採用することは別の判断です。APGでは、タブは関連するタブパネルのうち一つを表示する階層化された内容として説明されています。

5.4 メニューと通常のナビゲーションを区別する

ウェブサイトのヘッダーにあるリンク一覧は、日常的に「メニュー」と呼ばれますが、ARIAのmenuやmenubarは、デスクトップアプリケーションに近い操作コマンドの集合を表すパターンです。メニューロールを使うと、利用者は矢印キーで項目間を移動し、Enterキーで実行し、Escapeキーで閉じるといった操作を期待します。通常のナビゲーションリンクへ不用意にこの役割を付けると、Tabキーで各リンクへ移動できるという一般的なウェブ操作と異なる挙動を実装しなければなりません。

デザイナーは、リンク先へ移動するための一覧なのか、編集や削除などの命令を実行する操作一覧なのかを区別します。サイトナビゲーションであれば、nav要素と通常のリンク一覧で十分な場合が多く、開閉が必要ならボタンで表示を制御できます。アプリケーション内の操作コマンドとしてメニューパターンを採用する場合は、内部のフォーカス移動、開閉、項目選択後の動作まで設計します。名称が「メニュー」であることだけを理由にARIAのメニューロールを選ばないことが重要です。

5.5 ロールと視覚表現を一致させる

支援技術へ正しいロールを伝えても、画面上の見た目がその役割を示していなければ、視覚的に操作する利用者は部品を発見できません。例えば、ボタンが通常の本文と同じ外見で、ホバーやフォーカス時にも変化しない場合、クリック可能な要素だと気付けない可能性があります。反対に、ボタンのような枠や影を持つ装飾要素が操作できなければ、押せると誤解されます。意味と見た目の不一致は、利用者の予測を妨げます。

デザイナーは、役割を色だけに依存せず、形、配置、文言、下線、境界線、状態変化など複数の手掛かりで示します。リンクは周囲の本文から区別でき、ボタンは操作部品として認識でき、選択中のタブは選択状態とフォーカス状態の両方を区別できる必要があります。ARIAは見えない利用者へ意味を伝える仕組みですが、ARIAだけを正しくして視覚表現を曖昧にしてよいわけではありません。異なる利用方法で同じ役割と状態を理解できるようにすることが、デザイン全体の責任です。

6. 状態とARIA属性を同期させる設計

ARIAの状態属性は、操作部品が現在どのような状態にあるかを支援技術へ伝えます。属性を静的な注釈として付けるだけではなく、画面表示、内部データ、操作可能性と常に同期させなければなりません。

6.1 開閉状態とaria-expanded

アコーディオン、絞り込みパネル、開閉ナビゲーション、メニューボタンなどでは、制御する領域が開いているか閉じているかを利用者へ伝える必要があります。通常は、開閉を実行するボタン側へaria-expandedを設定し、閉じているときはfalse、開いているときはtrueへ更新します。画面上の矢印方向、パネルの表示状態、ボタン文言、ARIA属性が別々に管理されると、一部だけ更新されない不具合が起こりやすくなります。

デザイン仕様には、開いた画面と閉じた画面を並べるだけでなく、初期状態、開閉条件、開閉後のフォーカス位置、アニメーション中の操作、パネル内部にフォーカスがある状態で閉じた場合の扱いを記載します。開閉後もボタンへフォーカスを残すのか、内容へ移すのかは、情報量と操作目的によって変わります。見た目とARIA属性を同じ状態変数から更新できるよう、状態名を開発者と共通化することも重要です。

コード例：開閉状態を一つの処理から更新する

<button  id="faq-button"  type="button"  aria-expanded="false"  aria-controls="faq-panel" >  配送には何日かかりますか </button> <div id="faq-panel" hidden>  通常は注文後3〜5営業日で発送します。 </div> <script>  const button = document.querySelector('#faq-button');  const panel = document.querySelector('#faq-panel');  button.addEventListener('click', () => {    const isOpen = button.getAttribute('aria-expanded') === 'true';    const nextState = !isOpen;    button.setAttribute('aria-expanded', String(nextState));    panel.hidden = !nextState;  }); </script>

6.2 選択状態とaria-selected

タブ、リストボックス、グリッドなどでは、現在選択されている項目をaria-selectedで伝える場合があります。ここで重要なのは、選択状態とフォーカス状態が同じではないという点です。フォーカスは現在キーボード操作の対象になっている位置を示し、選択は確定済みの項目や現在表示中の内容に対応する項目を示します。手動選択型のタブでは、矢印キーで別のタブへフォーカスを移動しても、Enterキーで確定するまで表示パネルが変わらないことがあります。

デザイナーは、選択とフォーカスが同時に存在しても区別できる視覚表現を用意します。例えば選択中のタブには下線と太字を使用し、フォーカス中のタブには外側のフォーカス枠を表示します。色だけで両者を分けると認識しにくい利用者がいるため、形や位置の変化も組み合わせます。仕様には、フォーカス移動だけで選択が変わる自動選択型か、確定操作が必要な手動選択型かを明記し、ARIA状態の更新タイミングと画面表示を一致させます。

6.3 押下状態とaria-pressed

お気に入り登録、ミュート、太字、表示固定など、同じボタンを押すたびにオンとオフが切り替わる操作では、トグルボタンとしてaria-pressedを使用できます。この状態は、ボタンが現在押されているかどうかを伝えるものであり、チェックボックスの選択状態やタブの選択状態と同じ意味ではありません。部品の見た目が似ていても、利用者が何を操作していると理解すべきかによって適切な状態が変わります。

トグルボタンを設計する際には、現在状態と実行後の動作を文言で混在させないことが重要です。例えばボタン名を常に「ミュート」とし、aria-pressedでオン・オフを伝える方法と、ボタン名を「ミュートする」「ミュートを解除する」と動作に応じて変更する方法を同時に使うと、読み上げが冗長または矛盾する場合があります。デザインシステムで命名規則を決め、見た目、ボタン名、押下状態が一貫するようにします。APGのボタンパターンでも、通常のボタンとトグルボタンでは名前の扱いが異なる点が示されています。

6.4 無効状態と実際の操作抑止

無効状態は、単に色を薄くするだけでは十分に伝わりません。低コントラストの表示は、視覚的に認識しにくくなるだけでなく、なぜ操作できないのかも分からない状態を生みます。可能であれば、操作を無効にするよりも、実行後に不足情報を具体的に案内する方法を検討します。無効化が必要な場合は、無効であること、解除条件、現在不足している操作を利用者が理解できるようにします。

標準のフォーム部品へdisabled属性を設定すると、通常は操作が停止し、フォーカス順序からも外れます。一方、aria-disabled="true"は支援技術へ無効状態を伝えますが、クリックやキー入力を自動的に停止するものではありません。デザイナーは、無効状態の視覚表現だけでなく、フォーカス可能なまま理由を確認できるようにするのか、完全に操作順序から外すのかを決めます。実装側では、状態通知と実際の処理抑止を両方確認する必要があります。

6.5 現在位置とaria-current

パンくずリスト、ページ番号、段階的な手続き、日付一覧、主要ナビゲーションなどでは、利用者が現在どこにいるかを明確にする必要があります。色、太字、下線だけで現在位置を示すと、その視覚的な差を認識できない利用者や、画面読み上げソフトの利用者へ情報が伝わりません。aria-currentを使用することで、現在のページ、現在の手順、現在の日付などの位置情報をプログラム上でも提供できます。

デザイナーは、どの要素が現在位置を表すのかだけでなく、現在位置と選択状態の違いを明確にします。ページ番号の「3」は現在表示中のページであり、必ずしも選択可能なトグルではありません。手続きの現在段階も、完了済み、現在、未完了という状態を視覚的に区別しながら、支援技術へ現在地点を伝えます。WCAGのARIA技法には、集合内の現在項目を示すためにaria-currentを使用する方法が掲載されています。

7. キーボード操作とフォーカス設計

複雑な利用者インターフェースでは、キーボード操作とフォーカス管理を見た目と同じ重要度で設計する必要があります。ARIAで役割を伝えると、その役割に対応する一般的なキー操作が期待されるため、独自の操作規則を無計画に採用すると利用者を混乱させます。

7.1 Tabキーの移動順序を設計する

Tabキーによる移動順序は、原則としてHTMLの自然な文書順序と一致させます。画面上の配置だけをCSSで入れ替え、文書構造を変更しない場合、視覚上は左から右へ並んでいるのに、フォーカスは右から左へ移動するなどの不一致が起こる可能性があります。利用者は現在位置を見失いやすくなり、画面拡大を使用している場合は、フォーカスが表示範囲外へ突然移動したように感じることもあります。

デザイナーは、単に各要素へ番号を振ってフォーカス順序を指定するのではなく、内容を読む順序と操作する順序が自然になるよう画面構造を設計します。正の数値を持つtabindexで順番を強制すると、画面変更のたびに管理が複雑になるため、文書構造自体を調整する方が安全です。WCAGのフォーカス順序に関する解説でも、フォーカス可能な要素は意味や操作を保つ論理的な順序で移動できる必要があるとされています。

7.2 フォーカス表示を常に確認可能にする

フォーカス表示は、キーボード利用者が現在どの部品を操作しようとしているかを確認するための主要な手掛かりです。ブラウザ標準の外枠をデザイン上の理由で削除し、代替表示を用意しない実装は避けなければなりません。ホバー状態はマウス位置を示しますが、フォーカス状態とは異なります。タッチ操作にもホバーは存在しないため、各入力方法の状態を混同せずに設計します。

デザイナーは、明るい背景、暗い背景、画像上、選択中の部品、エラー状態など、さまざまな条件でもフォーカスが確認できる表現を用意します。色の変化だけに頼らず、外枠、太さ、余白、下線、形状などを組み合わせると識別しやすくなります。また、固定ヘッダー、通知バー、重なった領域によってフォーカス部品が隠れないようにします。WCAG 2.2ではフォーカスの可視性に加え、フォーカス対象が完全に隠されないことや、より明確な外観に関する基準も示されています。

7.3 複合部品の矢印キー操作を定義する

タブ、ラジオグループ、メニュー、リストボックス、ツリービューなどの複合部品では、Tabキーで部品全体へ入り、矢印キーで内部の項目間を移動する操作が一般的です。すべての内部項目をTabキーの停止位置にすると、項目数が多い場合にページを通過するための操作回数が増えます。逆に、矢印キー操作を実装せず、Tabキーでも一つの項目にしか到達できなければ、他の項目を操作できません。

デザイナーは、どのキーで複合部品へ入り、内部を移動し、項目を実行し、部品から抜けるかを仕様へ記載します。左右に並ぶタブでは左右矢印、縦に並ぶメニューでは上下矢印など、方向と表示構造を一致させます。独自のショートカットを発明するより、APGに示される一般的な操作規則を基準にした方が、支援技術から操作方法を推測しやすくなります。APGは、役割と一般的なキーボード規則を一貫して適用することの重要性を説明しています。

7.4 ロービングtabindexを使用する

複合部品では、現在操作対象となる一つの項目だけをtabindex="0"にし、他の項目をtabindex="-1"にする方法があります。利用者が矢印キーで内部を移動すると、次の項目へフォーカスを移し、その項目を0へ変更します。この方法によって、Tabキーでは複合部品全体が一つの停止位置として扱われ、内部項目が多い場合でもページ移動の負担を抑えられます。

この方式を採用するときは、フォーカス中の項目、選択中の項目、最後に操作した項目の関係を明確にします。例えば手動選択型のタブでは、選択中のタブとフォーカス中のタブが一時的に異なることがあります。デザイナーは両者を視覚的に区別し、ページを再表示したときにどの項目へTabキーが入るのかも決めます。実装担当者へ「矢印キー対応」とだけ伝えるのではなく、フォーカスと選択がいつ更新されるかを状態遷移として共有します。

コード例：タブ一覧内のフォーカス移動

const tabs = [...document.querySelectorAll('[role="tab"]')]; function moveFocus(currentIndex, direction) {  const nextIndex =    (currentIndex + direction + tabs.length) % tabs.length;  tabs.forEach((tab) => {    tab.tabIndex = -1;  });  tabs[nextIndex].tabIndex = 0;  tabs[nextIndex].focus(); } tabs.forEach((tab, index) => {  tab.addEventListener('keydown', (event) => {    if (event.key === 'ArrowRight') {      event.preventDefault();      moveFocus(index, 1);    }    if (event.key === 'ArrowLeft') {      event.preventDefault();      moveFocus(index, -1);    }  }); });

7.5 操作完了後のフォーカス位置を決める

利用者がモーダルを閉じる、一覧項目を削除する、新しい項目を追加する、フォームを送信するなどの操作を行った後、画面内容が変わってもフォーカスが適切な位置へ移動しなければ、現在位置を失う可能性があります。削除された要素へフォーカスが残ることはできないため、ブラウザが自動的に本文先頭などへ移す場合があります。視覚的には小さな更新でも、キーボード利用者には作業場所を失う大きな変化になります。

デザイナーは、各主要操作について「処理後に何が見えるか」と同時に「処理後にどこを操作している状態になるか」を定義します。モーダルを閉じた後は通常、開いたボタンへ戻します。項目を削除した後は、次の項目、前の項目、一覧見出し、完了通知などから、作業を続けやすい位置を選びます。追加後は、新しい項目をすぐ編集する必要があるのか、追加完了だけを通知して元の位置へ残すのかを利用目的から決定します。

8. モーダルダイアログのARIA設計

モーダルダイアログは、背景の操作を一時的に停止し、確認や短い作業へ利用者を集中させる部品です。中央へ箱を表示し背景を暗くするだけでは成立せず、名前、説明、フォーカス、閉じ方、背景領域の無効化を一体として設計する必要があります。

8.1 モーダルを使用する目的を限定する

モーダルは、重要な確認、短い入力、現在の作業に直接関係する補助操作などに適しています。しかし、長い文章、複数段階の入力、多数の選択肢、複雑な比較作業をモーダルへ入れると、拡大表示や小さな画面で内容を把握しにくくなります。モーダルの中からさらに別のモーダルを開く設計は、現在位置と戻り先を理解しにくくするため、特に慎重な判断が必要です。

デザイナーは「画面上で目立たせたい」「ページ遷移を減らしたい」という理由だけでモーダルを選ばず、利用者が背景の文脈を保持する必要があるか、独立したページの方が内容を理解しやすいかを検討します。重要でない宣伝や案内を自動的にモーダル表示すると、利用者の作業を中断します。適切な部品を選ぶ段階で複雑さを減らすことは、後からARIAを追加するよりも大きなアクセシビリティ改善につながります。

8.2 ダイアログの名前と説明を指定する

ダイアログが開いたとき、利用者は何の画面が表示されたのかをすぐ理解できる必要があります。通常は、ダイアログ内の見出しをaria-labelledbyで参照し、ダイアログ全体の名前として使用します。必要に応じて短い説明をaria-describedbyで関連付けますが、長い本文全体を説明として参照すると、開いた直後に大量の文章が一度に読み上げられ、内部の操作へ移るまで時間がかかる場合があります。

デザイナーは、最初に伝えるべき名称、重要な注意、利用者が自分のペースで読む本文を分けます。例えば削除確認では、「ファイルを削除しますか」という見出しと、「この操作は取り消せません」という短い注意を最初に伝え、対象ファイルの詳細や補足は本文として順番に読めるようにします。見出しが視覚的に不要に見えても、ダイアログの目的を示すために必要な場合があるため、単に余白を減らす目的で削除しないようにします。

8.3 初期フォーカスを内容に応じて配置する

モーダルを開いた直後のフォーカス位置は、ダイアログの内容と利用者が最初に行うべき判断によって変わります。短い入力ダイアログであれば最初の入力欄、単純な選択であれば最初の安全な操作、長い説明を含む場合は見出しや本文先頭へ移す方法があります。破壊的な主要ボタンへ自動的にフォーカスを置くと、利用者が内容を確認する前に誤って実行する可能性があります。

デザイナーは、見た目上の主要ボタンだからという理由だけで初期フォーカスを決めず、利用者が最初に理解すべき情報と、誤操作の影響を考慮します。長い内容で見出しへフォーカスを置く場合は、プログラムからフォーカスできるようにしつつ、通常のTab順序へ不要な停止位置を増やさない方法を実装担当者と検討します。初期フォーカスの指定は注釈として画面上へ明示し、ダイアログごとに開発者が推測しない状態を作ります。

8.4 フォーカスをダイアログ内へ保つ

モーダルが開いている間、TabキーとShift＋Tabキーによるフォーカスはダイアログ内を循環し、背景画面へ移動しないようにします。背景が半透明の覆いで隠されていても、キーボードでは背景のリンクやボタンを操作できる状態であれば、視覚状態と操作状態が一致しません。画面読み上げソフトの利用者が背景領域へ移動すると、ダイアログがまだ開いているのか、元の画面へ戻ったのか判断しにくくなります。

閉じる手段も、背景クリックだけに依存してはいけません。明確な閉じるボタン、キャンセル操作、状況に応じたEscapeキー操作を提供し、それぞれの結果を仕様へ記載します。処理中で閉じられない時間がある場合は、その理由と進行状況を伝えます。APGのモーダルダイアログパターンでは、背景を操作不能にし、Tabキーの移動をダイアログ内へ保つ操作が示されています。

コード例：名前と説明を持つモーダル構造

<div  id="profile-dialog"  role="dialog"  aria-modal="true"  aria-labelledby="profile-dialog-title"  aria-describedby="profile-dialog-description"  hidden >  <h2 id="profile-dialog-title">プロフィールを編集</h2>  <p id="profile-dialog-description">    公開する名前と自己紹介を変更できます。  </p>  <label for="display-name">表示名</label>  <input id="display-name" name="display-name">  <button type="button">変更を保存</button>  <button type="button">キャンセル</button> </div>

8.5 閉じた後のフォーカスを適切に戻す

モーダルを閉じた後は、原則としてモーダルを開いた操作部品へフォーカスを戻します。これにより、利用者は元の作業位置を維持し、その周辺の操作を続けられます。閉じた後にページ先頭や本文の予期しない位置へ移動すると、モーダルを開く前の場所を探し直さなければなりません。長い一覧や複雑な画面では、この負担が特に大きくなります。

ただし、ダイアログ内の処理によって起動ボタンや元の項目自体が削除された場合、同じ位置へ戻すことはできません。その場合は、次の一覧項目、更新後の見出し、完了通知、主要な次の操作など、論理的な移動先を設計します。処理成功時とキャンセル時で戻り先が異なる場合もあります。デザイナーは閉じるアニメーションだけでなく、各終了経路とフォーカス移動先をフローとして記載する必要があります。

9. タブ・アコーディオン・メニューの設計

情報の切り替えや折りたたみに使用される部品は、限られた表示領域を効率的に使える一方、役割や操作が曖昧になりやすい部分です。見た目が似ていても、タブ、アコーディオン、メニューボタンでは状態、関係、キー操作が異なります。

9.1 タブとタブパネルの関係を示す

タブは、複数の内容パネルのうち一つを表示するための部品です。タブ一覧には複数のタブが存在し、それぞれが対応するパネルを持ちます。選択中のタブは、現在表示されているパネルを示さなければなりません。デザイナーは、タブ名だけを横に並べるのではなく、どのタブがどのパネルを制御するのか、初期選択はどれか、パネルが切り替わったときにフォーカスをどこへ残すかを定義します。

タブの数が多すぎると、ラベルを読んで目的の内容を探す負担が増え、狭い画面では項目が見切れます。横スクロールを採用する場合は、隠れているタブが存在することと、キーボードで全項目へ移動できることを確認します。タブ名を短くしすぎて意味が曖昧になる場合は、別の情報構造を検討します。タブは内容を隠して表示領域を節約するためだけの装飾ではなく、関連する情報集合の構造として設計する必要があります。

コード例：タブとパネルを関連付ける

<div role="tablist" aria-label="アカウント設定">  <button    id="tab-profile"    type="button"    role="tab"    aria-selected="true"    aria-controls="panel-profile"    tabindex="0"  >    プロフィール  </button>  <button    id="tab-security"    type="button"    role="tab"    aria-selected="false"    aria-controls="panel-security"    tabindex="-1"  >    セキュリティ  </button> </div> <section  id="panel-profile"  role="tabpanel"  aria-labelledby="tab-profile" >  <!-- プロフィール設定 --> </section>

9.2 自動選択と手動選択を使い分ける

自動選択型のタブでは、矢印キーでフォーカスが別のタブへ移動した時点で、そのタブが選択され、対応するパネルが表示されます。手動選択型では、矢印キーは候補間のフォーカス移動だけを行い、EnterキーまたはSpaceキーで選択を確定したときにパネルが切り替わります。どちらを選ぶかによって、フォーカスと選択の関係、必要なキー操作、利用者が受け取るフィードバックが変わります。

パネルがすぐ表示でき、切り替えによる大きな処理が発生しない場合は、自動選択によって素早く内容を確認できます。一方、各パネルを表示するたびに通信が発生する、内容が大きく変化する、音声や動画が開始される場合は、フォーカス移動だけで切り替えると負担になります。デザイナーは、見た目だけでなく応答速度と内容の性質を確認し、選択方式を明記します。APGのタブパターンでも、自動選択と手動選択の双方が例示されています。

9.3 アコーディオンの開閉規則を決める

アコーディオンでは、一度に一つだけ開ける方式と、複数項目を同時に開ける方式があります。一つだけ開ける方式は画面を短く保てますが、別の項目を開くと現在の内容が自動的に閉じるため、複数の情報を比較しにくくなります。よくある質問、仕様比較、手順説明などでは、複数項目を同時に確認したい利用者もいるため、情報の利用目的に基づいて方式を選ぶ必要があります。

デザイナーは、見出し文字と開閉アイコンのどちらを押せるのかを曖昧にせず、見出しを含む十分な範囲を一つのボタンとして設計します。小さな矢印だけを操作対象にすると、ポインター操作が難しくなります。開いている状態はアイコン方向だけでなく、必要に応じて文字や位置でも認識できるようにします。また、内容内にフォーカスがある状態で別の項目を開いた場合、現在の項目を自動的に閉じないなど、フォーカスを失わない規則も検討します。

9.4 メニューボタンの開閉と内部移動を設計する

メニューボタンは、押すと操作項目の一覧を表示するボタンです。ボタン自体にはメニューを開閉する状態があり、開いたメニュー内では矢印キーによる項目移動、Enterキーによる実行、Escapeキーによる終了などが期待されます。メニューが開いた直後に最初の項目へフォーカスを移すのか、選択中の項目へ移すのかは、メニューの目的に応じて決めます。

画面外をクリックする方法だけで閉じられる設計は、キーボード利用者に終了手段を提供できません。また、メニュー内でTabキーを押した場合に閉じるのか、次の操作部品へ移動するのかも仕様として必要です。項目を実行した後にメニューを閉じるか、複数操作のために開いたままにするかも、操作内容によって異なります。APGのメニューボタンパターンを参照しながら、製品内で一貫した動作を採用します。

9.5 非表示状態とフォーカス可能性を同期する

パネルやメニューを視覚的に隠しても、内部のリンクやボタンがTabキーの移動先として残っていると、利用者は画面上に見えない要素へ移動してしまいます。位置を画面外へ移すだけ、透明度をゼロにするだけといった非表示方法では、アクセシビリティツリーやフォーカス順序に残る場合があります。見た目、支援技術への公開、キーボード操作可能性を同じ状態として管理する必要があります。

デザイナーは、閉じた状態では内部の操作が利用できないことを明確にし、アニメーション中の扱いも実装担当者と相談します。閉じるアニメーションを表示している短い時間に内部要素へフォーカスが残ると、消えていく要素を操作している状態になります。表示完了後にいつ操作可能になるか、連続して開閉された場合に状態が矛盾しないか、外部から内容が更新された場合に閉じたまま通知する必要があるかまで検討すると、安定した部品になります。

10. フォームとエラーメッセージの設計

フォームでは、入力項目の目的、必要な形式、必須条件、エラー内容、修正方法を、視覚的にもプログラム上でも理解できるようにする必要があります。ARIAは不足する関連情報を補えますが、明確なラベルや分かりやすい文章を置き換えるものではありません。

10.1 常に確認できるラベルを配置する

プレースホルダーは入力例や形式の補助には使えますが、入力を始めると消えるため、入力項目のラベルとしては不十分です。複数の入力欄を行き来して内容を確認するとき、表示ラベルがなければ、どの値を入力したのか判断しにくくなります。記憶や注意の維持が難しい利用者にとっても、常に確認できるラベルは重要です。

デザイナーは、ラベル、入力例、補足説明を役割ごとに分けます。「電話番号」は項目名、「09012345678」は入力例、「ハイフンなしで入力してください」は形式説明です。これらを一つのプレースホルダーへまとめると、入力開始後に必要な情報が消えます。ラベルを入力欄内部へ移動させる浮動形式を採用する場合も、拡大表示、長い翻訳文、入力済み状態、エラー状態でラベルが読みやすいかを確認します。

10.2 必須項目を文字でも伝える

必須項目を赤色だけで示すと、色の違いを認識しにくい利用者へ情報が伝わりません。星印を使う場合も、その記号が必須を意味することをフォーム冒頭で説明するか、各項目へ「必須」という文字を表示します。必須項目が大多数の場合は、少数の任意項目へ「任意」と示した方が画面を簡潔にできることもありますが、製品全体で表記規則を統一する必要があります。

HTMLのrequired属性やARIAの必須状態は支援技術へ情報を伝えますが、画面上の説明を不要にするものではありません。デザイナーは、必須であることに加え、入力形式、文字数、選択可能数など、利用者が入力前に知るべき条件を表示します。送信後に初めて条件を示すより、入力前に理解できる方がエラーを減らせます。WCAGのラベルまたは説明に関する解説でも、入力が必要な場合には適切なラベルや説明を提供することが求められています。

10.3 エラーと対象入力欄を関連付ける

エラーは、画面上部に一覧表示するだけでなく、該当する入力欄の近くにも表示します。長いフォームで上部の一覧だけを示すと、利用者は各項目を探し直さなければなりません。反対に、入力欄の近くにだけ表示すると、画面読み上げソフトの利用者が送信失敗の全体像を把握しにくい場合があります。フォームの長さやエラー数に応じて、概要と項目別メッセージを組み合わせます。

エラー文には、何が間違っているかだけでなく、どのように修正するかを具体的に記載します。「正しく入力してください」では期待形式が分かりません。「郵便番号はハイフンなしの7桁で入力してください」のように、問題と修正条件を一つの文章で示します。色、枠線、警告アイコンは補助として利用できますが、文字による説明を省略してはいけません。WCAGのエラー特定に関する解説でも、エラーを文字で説明することが重視されています。

コード例：入力欄、説明、エラーを関連付ける

<label for="postal-code">  郵便番号  <span>必須</span> </label> <p id="postal-code-hint">  ハイフンなしの7桁で入力してください。 </p> <input  id="postal-code"  name="postal-code"  inputmode="numeric"  aria-describedby="postal-code-hint postal-code-error"  aria-invalid="true"  required > <p id="postal-code-error">  郵便番号は7桁の数字で入力してください。 </p>

10.4 エラー発生後のフォーカスを設計する

フォーム送信後にエラーが発生した場合、画面上へ赤いメッセージを表示するだけでは、現在のフォーカス位置から離れている変化を認識できない利用者がいます。長いフォームでは、最初のエラー項目、エラー概要、フォーム見出しなどへフォーカスを移し、送信できなかったことと修正対象をすぐ確認できるようにします。どの位置が適切かは、フォームの長さ、エラー数、内容の重要度によって変わります。

複数のエラーがある場合、上部のエラー概要に各項目へのリンクを設けると、利用者は全体を把握してから修正位置へ移動できます。短いフォームでエラーが一つだけなら、該当入力欄へ直接移す方法が分かりやすい場合があります。デザイナーは、エラー表示の見た目だけでなく、送信ボタンを押した直後に何が読み上げられ、どこへフォーカスが移り、修正後にどの順序で再送信するかまで確認します。

10.5 成功、失敗、処理中を明確に区別する

フォーム送信後の結果は、色やアイコンだけでなく、具体的な文章で示します。「保存しました」「送信できませんでした」「3項目を確認してください」のように、何が起こったかと次に何をすべきかを明確にします。成功したように見える緑色のチェックだけでは、画面を見られない利用者へ結果が伝わらず、視覚的に見ている利用者にも何が保存されたのか分かりにくい場合があります。

処理に時間がかかる場合は、開始、進行、完了、失敗の各状態を設計します。送信ボタンの文言を「送信中」に変えるだけでなく、連続実行を防ぐのか、キャンセルできるのか、一定時間後に再試行を案内するのかを決めます。画面遷移しない成功通知は、ライブリージョンや状態メッセージとして支援技術へ通知する必要がありますが、フォーカスを不要に移動させないことも重要です。

11. ライブリージョンと動的更新の設計

検索結果数、保存完了、カートへの追加、読み込み状況など、フォーカスを移動せずに画面内容だけが更新される場合、画面を直接見ない利用者は変化に気付けない可能性があります。ライブリージョンは、必要な更新を適切なタイミングで通知するために使用されます。

11.1 自動通知すべき更新を選ぶ

画面上で変化するすべての情報を自動的に読み上げればよいわけではありません。装飾アニメーション、時計、頻繁に変化する数値、入力するたびに更新される細かな候補数などをすべて通知すると、画面読み上げソフトが話し続け、現在操作している項目の情報を聞き取れなくなります。通知は、利用者の判断や作業継続に必要な変化へ限定する必要があります。

デザイナーは、操作結果、エラー、保存完了、検索結果数、読み込み完了など、利用者が確認しなければ次の行動を選べない更新を優先します。視覚的に大きく表示される情報が必ずしも自動通知に適しているとは限りません。逆に、画面上では小さな変化でも、操作が成功したかを知るために必要なら通知すべきです。通知の必要性は、視覚上の大きさではなく、利用者の作業へ与える影響から判断します。

11.2 通知の強度を使い分ける

aria-live="polite"は、現在の読み上げを可能な限り妨げず、適切な区切りで更新内容を通知します。保存完了、検索結果数、カートへの追加など、多くの一般的な状態通知では穏やかな通知が適しています。一方、aria-live="assertive"は、現在の読み上げを中断して通知する可能性があるため、作業を直ちに止める必要がある重大なエラーや緊急情報に限定します。

デザイナーは、画面上で赤く大きく表示されるから強い通知にするのではなく、利用者の現在の作業を中断させる必要が本当にあるかを判断します。強い通知が複数回発生すると、利用者が読んでいた内容を繰り返し中断し、かえって問題を理解できなくなります。WCAGの状態メッセージに関する解説では、フォーカスを受け取らない状態変化についても、支援技術が役割や属性を通じて認識できるようにすることが示されています。

コード例：検索結果数を穏やかに通知する

<p  id="search-status"  role="status"  aria-atomic="true" >  24件の商品が見つかりました。 </p>

11.3 同じ文言が連続する場合を考慮する

同じ操作を繰り返したときに、同じメッセージを同じ要素へ設定しても、ブラウザや支援技術の組み合わせによっては新しい変化として通知されない場合があります。例えば、自動保存が行われるたびに「保存しました」と表示するだけでは、二回目以降の通知を認識できない可能性があります。一方で、毎回長い文章を読み上げると作業を妨げます。

デザイナーは、対象名、件数、時刻、処理内容など、利用者が変化を識別するために必要な情報を文言へ含める方法を検討します。「下書きを保存しました」「プロフィール画像を保存しました」のように対象を示せば、複数の保存処理を区別できます。ただし、秒単位の時刻など不必要な情報を追加して読み上げを長くしないよう注意します。技術的な再通知方法は実装担当者が決めますが、何を伝えるべきかはデザイン仕様として定義します。

11.4 読み込み状態と進行状況を伝える

通信処理やファイルアップロードに時間がかかる場合、利用者は操作が受け付けられたのか、処理が停止したのか、完了まで待つ必要があるのかを判断できなければなりません。回転するアイコンだけでは、画面を見られない利用者へ状態が伝わらず、視覚的に見ている利用者にも何を処理しているか分からない場合があります。「検索しています」「画像をアップロードしています」「注文を確定しています」のように、処理内容を具体的に示します。

進行率を表示できる処理では、パーセント、完了件数、残り時間などから、利用者にとって信頼できる情報を選びます。正確な残り時間を計算できない場合に不安定な数値を表示すると、かえって混乱を招きます。処理中に他の操作を続けられるのか、画面を閉じても処理が継続するのか、キャンセルできるのかも説明します。状態表示は待ち時間を装飾するためではなく、利用者が次の行動を判断するための情報として設計します。

11.5 通知過多を実際の操作で検証する

ライブリージョンが技術的に正しく設定されていても、通知の頻度、長さ、順序が適切とは限りません。検索欄へ一文字入力するたびに候補数、読み込み状態、最初の候補、補足説明が連続して通知されると、利用者は自分が入力した内容を確認できなくなります。複数のライブリージョンが同時に更新される画面では、通知順序が視覚上の順序と異なる場合もあります。

デザイナー自身が画面読み上げソフトを使い、実際の作業を通して通知を確認する必要があります。さらに、日常的に支援技術を使う利用者によるテストでは、必要な情報が足りないだけでなく、情報が多すぎる問題も確認します。WCAGの状態メッセージに関する解説は、ライブリージョンや警告を過剰に利用すると騒がしい体験になり得ることを示しています。通知が存在するかだけでなく、作業を妨げず理解を助けているかを評価します。

12. デザインシステムへのARIA組み込み

アクセシビリティの判断を画面ごとの担当者へ任せると、同じ部品でも名前、役割、状態、キー操作が異なる実装になります。デザインシステムへ意味と動作を組み込むことで、再利用時の判断を減らし、製品全体の一貫性を高められます。

12.1 コンポーネントへ意味の仕様を持たせる

デザインシステムのコンポーネント仕様には、色、余白、角丸、文字サイズだけでなく、想定するHTML要素、役割、必須となる名前、状態属性、キー操作を記載します。例えば、見た目が同じボタンでも、通常の実行ボタン、開閉ボタン、トグルボタン、メニューボタンでは必要な状態と操作が異なります。一つの「ボタン」部品へすべてを詰め込まず、用途と意味に応じて変種を定義します。

利用者がコンポーネントを選ぶときも、「青いボタン」「小さいボタン」といった見た目の分類ではなく、「主要操作」「補助操作」「危険な操作」「開閉操作」のように目的から選べる構成にします。実装コンポーネントの資料にも、使用場面、禁止場面、必要なラベル、処理中の挙動を記載します。デザインとコードの双方で同じ名称と状態を使えば、引き継ぎ時の翻訳作業を減らせます。

12.2 すべての状態を再利用可能にする

コンポーネントには、通常、ホバー、フォーカス、押下、選択、無効、読み込み中、成功、警告、エラーなど、実際に発生する状態を用意します。通常状態とホバー状態しか存在しないデザイン部品では、実装担当者が不足状態を独自に作成することになり、製品内で色や余白、アイコンの使い方がばらつきます。状態が不足していること自体が、仕様不足の兆候です。

各状態には、視覚表現だけでなく、発生条件、ARIA属性、操作可否、通知内容を対応させます。開閉ボタンであれば、アイコン方向、aria-expanded、パネル表示を同じ状態として定義します。トグルボタンであれば、押下状態、色、アイコン、ラベルの規則を一致させます。コンポーネント資料から状態の意味を確認できれば、画面担当者が属性を一から調査する必要がなくなります。

12.3 アクセシビリティ注釈を標準化する

デザインデータへアクセシビリティ注釈を追加する場合、担当者ごとに異なる書き方をすると、実装担当者が必要情報を探しにくくなります。名前、役割、状態、説明、制御対象、キー操作、フォーカス移動、動的通知などを共通の項目として用意します。各画面で自由記述するだけではなく、一定の順序と記号で表示すると、レビュー時の確認漏れを減らせます。

注釈には属性名だけでなく、利用者へ何を伝えるための指定かを書きます。例えば「aria-expanded="true"」だけでは、どのタイミングで値が変わるか分かりません。「絞り込み条件が表示されている状態を伝え、パネルの表示と同時に更新する」と目的と条件を記載します。技術構成が変更された場合も、利用者へ伝えるべき目的が残っていれば、実装担当者は別の適切な方法を選べます。

12.4 禁止パターンと代替方法を示す

デザインシステムには推奨例だけでなく、避けるべきパターンと、その代わりに使用する方法を掲載します。例えば、クリック可能なdivをボタン代わりにする、プレースホルダーだけで入力欄の目的を示す、フォーカス枠を削除する、色だけでエラーを示す、表示文字と異なる名前を設定するなどです。禁止例がなければ、担当者は見た目が近い部品を自由に組み合わせ、同じ問題を繰り返す可能性があります。

単に「禁止」と書くのではなく、どの利用者にどのような問題が生じるか、代わりに何を使うべきかを説明します。「divボタンは禁止」だけでなく、「標準のbuttonを使用すれば、役割、Tabキーでの到達、Enter・Spaceキーの操作を利用できる」と示します。理由が理解できれば、資料に載っていない新しい画面でも同じ考え方を応用できます。

12.5 デザイン部品と実装部品を対応させる

デザインライブラリに存在する部品と、コード上のコンポーネントが同じ名前、同じ状態、同じ用途を持つように対応させます。デザイン上では「開閉リスト」、コード上では「アコーディオン」、仕様書では「詳細表示」と異なる名称を使うと、同じ部品かどうか判断しにくくなります。担当者が別部品として再実装し、挙動の異なる類似コンポーネントが増える原因になります。

アクセシビリティ修正を行った場合は、デザインデータだけでなく実装部品と利用画面へ反映する流れを作ります。例えばフォーカス表示を改善しても、古い画面が独自スタイルで上書きしていれば、問題は残ります。変更履歴、影響範囲、移行方法、利用停止予定を管理し、どの製品が新しい仕様へ対応済みか追跡できるようにします。

コード例：状態を外部から正確に受け取る開閉部品

function updateDisclosure(button, panel, isOpen) {  button.setAttribute('aria-expanded', String(isOpen));  panel.hidden = !isOpen; } function setDisabled(button, isDisabled) {  button.disabled = isDisabled; }

13. 仕様書・引き継ぎ・受け入れ条件

ARIAを正しく実装するには、完成画面だけでなく、部品の意味、状態、操作方法、通知、フォーカス移動を引き継ぐ必要があります。実装担当者と品質保証担当者が同じ完成像を持てるよう、確認可能な仕様として記載します。

13.1 名前・役割・状態を明記する

各操作部品について、利用者に伝わる名前、部品の役割、初期状態、変化後の状態を記載します。アイコンボタンであればアクセシブルな名前、開閉ボタンであれば開閉状態と制御対象、トグルボタンであれば押下状態を示します。属性名を記載する場合も、値がいつ変わるのかを併記しなければ、静的に設定されたままになる危険があります。

WCAG 2.2の達成基準4.1.2では、利用者インターフェース部品について、名前と役割をプログラムによって判断でき、利用者が設定できる状態や値を支援技術へ提供できることが求められています。仕様書で名前、役割、状態を確認できるようにすると、実装前のレビューと実装後の検証を同じ基準で行えます。「ARIA対応」とだけ書くのではなく、利用者が何を認識できるべきかを具体化します。

13.2 キーボード操作を入力と結果で記載する

「キーボード対応」とだけ書かれていても、どのキーで何が起こるか確認できません。Tabキー、Shift＋Tabキー、Enterキー、Spaceキー、Escapeキー、矢印キーなど、各入力に対する結果を文章で示します。特に複合部品では、Tabキーが内部項目を一つずつ移動するのか、部品全体を一つの停止位置として扱うのかを明確にします。

仕様は、「右矢印キーで次のタブへフォーカスを移す」「Enterキーでフォーカス中のタブを選択する」「Escapeキーでメニューを閉じ、メニューボタンへ戻す」のように記載します。画面上の動画や試作品だけに依存すると、細かな条件を検索しにくく、変更履歴も追いにくくなります。文章による操作仕様と、必要に応じた動作試作品を組み合わせることで、実装とテストの両方に利用できる資料になります。

13.3 フォーカス遷移を画面フローへ追加する

一般的な画面遷移図は、ページやモーダルの表示変化を示しますが、キーボード利用者の現在位置までは示さないことがあります。モーダルを開く、削除する、項目を追加する、エラーを表示する、通知を閉じるといった操作では、表示変化とフォーカス変化を同じ図へ記載する必要があります。フォーカス位置が決まらなければ、操作後の体験は完成していません。

フォーカス遷移には、通常の成功経路だけでなく、キャンセル、失敗、対象要素の削除などの例外経路も含めます。例えば、削除確認をキャンセルした場合は削除ボタンへ戻し、削除を実行した場合は次の一覧項目へ移すというように、結果に応じた移動先を定義します。画面読み上げソフトへ通知するだけでフォーカスを移動しない場合も、その判断を記載します。

13.4 利用者の行動を基準に受け入れ条件を作る

受け入れ条件を「ARIA属性が設定されている」「キーボードに対応している」と書くだけでは、属性値が更新されない、キー操作が一部だけ使える、フォーカスが見えないといった問題を見逃します。受け入れ条件は、利用者が特定の入力方法で目的の作業を完了できるかという形で記載します。

例えば、「キーボードだけでモーダルを開き、内容を確認し、閉じられる」「開いている間は背景へフォーカスが移動しない」「閉じた後は起動ボタンへ戻る」のように、操作、状態、結果を一連の流れとして確認します。属性の存在は実装手段であり、利用者の成功が最終的な品質基準です。

13.5 担当者と確認時期を決める

アクセシビリティの責任を一人の専門担当者へ集中させると、その人が関与できない案件で確認が抜けます。デザイナーは意味、文言、状態、操作フローを確認し、実装担当者はHTML、ARIA、状態同期、キー処理を確認し、品質保証担当者は実環境で作業を完了できるかを確認します。役割を分けても、互いの領域を完全に切り離さず、複雑な部品は共同でレビューします。

確認時期も、開発完了後だけでは不十分です。ワイヤーフレーム段階で部品選択を確認し、詳細設計で名前と状態を確認し、コンポーネント実装でキー操作とアクセシビリティツリーを確認し、結合テストで画面全体のフォーカスと通知を確認します。早い段階で問題を発見すれば、複雑な独自部品を標準部品へ変更するなど、構造的な改善も行いやすくなります。

14. テスト・レビュー・継続改善

アクセシビリティは、デザインデータ、コード、属性一覧のどれか一つだけを確認しても保証できません。自動検査、キーボード操作、アクセシビリティツリー、画面読み上げソフト、実際の利用者による確認を組み合わせる必要があります。

14.1 自動検査で確認できる範囲を理解する

自動検査は、名前のないボタン、無効なARIA属性、重複した識別子、ラベルのない入力欄、一定のコントラスト不足など、多くの問題を効率的に検出できます。継続的な開発工程へ組み込めば、修正済みの問題が再発したときに早く発見できます。しかし、自動検査で問題がゼロであっても、利用者が作業を完了できるとは限りません。

自動検査は、ボタン名が文脈に合っているか、フォーカス移動が自然か、エラー文が修正方法を説明しているか、ライブリージョンが騒がしすぎないかを完全には判断できません。デザイナーは、自動検査の合格を完成条件の一部として扱い、人による操作確認を省略しないようにします。検出できる問題と検出できない問題をチームで共有し、検査結果を過大評価しないことが重要です。

14.2 キーボードだけで主要作業を確認する

マウスやタッチを使わず、Tabキー、Shift＋Tabキー、Enterキー、Spaceキー、Escapeキー、矢印キーだけで、製品の主要な作業を完了できるか確認します。単にすべての部品へ到達できるかだけでなく、移動順序が自然か、フォーカスが見えるか、非表示領域へ移動しないか、操作後に位置を失わないかを確認します。

デザイナー自身がキーボード操作を行うと、静止画では見えなかった問題を発見できます。例えば、カード全体に多数のフォーカス位置があり移動回数が過剰、固定ヘッダーでフォーカスが隠れる、モーダルを閉じた後にページ先頭へ戻る、メニュー内の項目へ到達できないといった問題です。確認は個々の部品だけでなく、検索から購入、入力から送信などの実際の利用者フローで行います。

14.3 アクセシビリティツリーで名前・役割・状態を確認する

ブラウザの開発者向け機能を使うと、操作部品がどのような名前、役割、状態としてアクセシビリティツリーへ公開されているかを確認できます。画面上では正しく見えていても、ボタンの名前が空、見出しが存在しない、閉じたパネルが開いていると通知される、説明文との関連が切れているといった問題を発見できます。

デザイナーがすべての技術情報を理解する必要はありませんが、主要部品の名前、役割、状態を確認できれば、実装担当者とのレビューが具体的になります。特にデザインシステムの基礎コンポーネントは、多数の画面へ影響するため、状態ごとの公開情報を定期的に確認します。デザイン上の変更がアクセシブルな名前や関係へ影響していないかも、変更時に再検証します。

14.4 画面読み上げソフトで実際の流れを操作する

画面読み上げソフトによる確認では、名前、役割、状態、読み上げ順序、ライブリージョン、見出し移動、フォーム操作を実際に聞きます。アクセシビリティツリー上で情報が存在しても、読み上げ順序が分かりにくい、同じ言葉が重複する、通知が操作説明を遮るといった体験上の問題が残る可能性があります。

一つの画面読み上げソフトとブラウザだけで、すべての利用環境を保証することはできません。対象利用者と利用状況を踏まえ、主要な環境の組み合わせを決めます。読み上げ文章をすべての環境で一字一句同じにすることを目標にするのではなく、部品の目的を理解できるか、状態変化を認識できるか、作業を完了できるかを評価します。

14.5 利用者テストの結果を共通仕様へ戻す

仕様上は正しく見える部品でも、実際の利用者が効率的に操作できるとは限りません。タブ数が多すぎる、ボタン名が似ている、通知が頻繁すぎる、エラー修正の順番が分かりにくい、モーダルの内容が長すぎるといった問題は、実際の作業を観察することで明確になります。適合基準を満たすことと、使いやすい体験を提供することは関係していますが、完全に同じではありません。

利用者テストで見つかった問題は、対象画面だけを修正して終わらせず、デザインシステム、文言規則、コンポーネント選択基準、受け入れ条件へ反映します。例えば一覧の「編集」ボタンを区別できない問題が見つかった場合、同じ形式を使うすべての画面を調査し、一覧操作の命名規則を更新します。個別対応を共通知識へ変えることで、同じ問題の再発を減らせます。

15. 組織におけるデザイナーの責任

ARIAとアクセシビリティを一人の専門家や開発工程だけに任せると、その担当者が関与できない案件で品質が低下します。デザイナーを含む各職種が自分の判断範囲を理解し、共通の品質基準で協力できる体制を作る必要があります。

15.1 デザイナーの責任範囲を明文化する

デザイナーの責任は、すべてのARIA属性を暗記してコードを書くことではありません。部品の目的、表示文言、役割、状態、操作方法、フォーカス移動、結果通知を設計し、実装担当者が判断できる形で共有することです。標準HTMLで実現できるかを早期に相談し、独自部品が必要な場合は、既存パターンと異なる点を明確にします。

責任範囲が明文化されていないと、「ARIAは開発者が後から付けるもの」「アクセシビリティは品質保証担当者が最後に確認するもの」という分断が生まれます。デザイン完了条件へ、アクセシブルな名前、フォーカス状態、キー操作、エラー状態、動的通知の確認を含めます。デザイナーが実装方法を単独で決める必要はありませんが、利用者体験に必要な情報を未定のまま渡してはいけません。

15.2 実装担当者との共同レビューを行う

複雑な操作部品は、デザインレビューとコードレビューを完全に分離せず、デザイナーと実装担当者が共同で確認します。デザイナーは利用者の目的、情報の優先順位、状態遷移を説明し、実装担当者は標準HTMLの利用可能性、ARIAの必要性、ブラウザや支援技術の対応状況を説明します。双方の知識を早い段階で組み合わせることで、見た目と実装可能性の両方を改善できます。

共同レビューを詳細設計の後まで待つと、複雑な独自部品を作り直すコストが大きくなります。ワイヤーフレーム段階で相談すれば、独自候補一覧を標準の選択欄へ変更する、長いモーダルを別ページへ変更する、ドラッグ操作へボタンによる代替方法を追加するなど、構造的な改善が可能です。ARIA属性の修正だけでは解決できない問題を早期に減らすことが重要です。

15.3 品質保証担当者と期待結果を共有する

品質保証担当者には、画面の見た目だけでなく、キーボード操作、フォーカス移動、名前、役割、状態、通知の期待結果を共有します。仕様が「タブを表示する」だけであれば、クリックで切り替わることしか確認されない可能性があります。「Tabキーでタブ一覧へ入り、左右矢印で移動し、選択状態とパネルが同期する」と記載すれば、必要な操作を具体的に検証できます。

不具合報告も、「ARIAが間違っている」という属性単位の表現だけでなく、利用者が何を認識できず、どの作業を完了できないかを記載します。「メニューを閉じた後にフォーカスが失われ、キーボード利用者が元の作業位置へ戻れない」のように影響を示せば、修正の優先度と適切な解決方法を判断しやすくなります。

15.4 学習を日常の制作工程へ組み込む

ARIAとアクセシビリティの範囲は広く、一度の研修ですべてを覚えることは困難です。属性一覧を暗記する講義だけでなく、実際のコンポーネントレビュー、失敗事例の共有、画面読み上げソフトによる確認、利用者テストの観察を日常業務へ組み込みます。自分が設計した画面を異なる入力方法で操作する経験は、次の設計判断へ直接つながります。

最初からすべての複雑なパターンを学ぶのではなく、ボタン、リンク、フォーム、モーダル、タブ、通知など、製品内で頻繁に使用する部品から共通理解を作ります。問題が見つかったときは担当者個人の失敗として扱わず、仕様、資料、部品、レビュー工程のどこを改善すれば再発を防げるかを検討します。知識を個人に閉じず、デザインシステムやチェックリストへ蓄積することが重要です。

15.5 アクセシビリティを完成条件へ含める

アクセシビリティを努力目標や公開後の改善項目として扱うと、納期が厳しい案件で後回しになりやすくなります。デザイン完了、実装完了、公開判断の各段階へ、役割、名前、状態、キーボード操作、フォーカス、エラー、通知に関する確認を含めます。問題が残る場合は、影響、代替手段、修正期限、責任者を記録し、既知の問題を無期限に放置しない仕組みを作ります。

すべての画面を一度に完全改善できない場合でも、新しい画面で同じ問題を増やさないことはできます。影響の大きい利用者フロー、利用頻度の高いコンポーネント、作業を完全に妨げる問題から優先して改善します。アクセシビリティを特別な追加作業ではなく、正確な役割、予測可能な操作、理解可能な状態を設計する通常の品質活動として扱うことで、組織全体に責任を定着させられます。

おわりに

ARIAは、実装担当者が開発工程の最後に追加する装飾的な属性ではありません。操作部品が何であるか、現在どの状態にあるか、何を制御しているか、利用者の操作によって何が変化したかを、支援技術へ伝えるための意味情報です。その意味はコードから自動的に生まれるのではなく、部品の目的、文言、状態、操作フローを設計する段階で決まります。したがって、ARIAの品質は実装担当者だけでなく、デザイナーがどこまで具体的に利用者体験を定義したかに大きく左右されます。

デザイナーに求められるのは、すべての属性名を暗記し、単独で技術的な実装方法を決定することではありません。標準HTMLを優先し、ボタンとリンクを機能で区別し、視覚ラベルとアクセシブルな名前を一致させ、選択、開閉、無効、処理中、エラーなどの状態を定義することが重要です。さらに、キーボード操作、フォーカス移動、動的な通知を画面仕様へ含め、実装担当者や品質保証担当者と共同で、見た目、意味、動作が一致しているかを確認します。

ARIA対応の成果は、属性を何個追加したかではなく、利用者が現在位置と操作対象を理解し、予測可能な方法で作業を完了できるかによって評価されるべきです。デザインシステム、仕様書、受け入れ条件、テスト工程へこの考え方を組み込めば、特定の担当者の知識だけに依存せず、製品全体で継続的に品質を高められます。アクセシビリティを後付けの対応ではなく、意味と操作を正確に設計するための通常のデザイン責任として扱うことが、長期的に利用しやすい製品を作るための基盤になります。