Webアクセシビリティにおける堅牢性（Robust）とは、ブラウザや支援技術がコンテンツの構造と操作方法を安定して解釈できるように作ることです。
スクリーンリーダー、音声入力、点字ディスプレイなどを利用する場合でも、見出しやボタンの役割が伝わり、必要な操作を続けられる状態を目指します。
ここでいう「堅牢性」は、「壊れないサイト」や「どのブラウザでも見た目が完全に同じサイト」を意味しません。
見た目や実行環境が変わっても、情報の意味と操作に必要な手掛かりが失われにくい実装を指します。
堅牢性が支える情報と操作
支援技術は、画面の見た目だけを手掛かりにしているわけではありません。
HTMLで示された構造や、UI部品に設定された名前、役割、状態などを利用して、利用者に情報と操作方法を伝えます。
- 構造：見出し、段落、リストなどの関係がコードから読み取れること。
- 操作部品：リンクやボタンの名前と役割が判別でき、キーボードなどでも操作できること。
- 状態：開閉、選択、入力結果など、操作による変化が見た目以外の方法でも伝わること。
画面上ではボタンに見えても、コード上では役割のない要素になっていれば、支援技術は操作部品として判断できない場合があります。
堅牢性を高める作業では、見た目とコードが伝える意味を一致させます。
堅牢な実装の優先順位
標準HTMLで意味を示す
セマンティックHTMLとは、見た目ではなく、情報の意味に合うHTML要素を選ぶ書き方です。
見出しには見出し要素、箇条書きにはリスト要素、操作にはボタンやリンクを使うと、ブラウザと支援技術が構造を共有しやすくなります。
<section>
<h2>製品情報</h2>
<p>取り扱っている製品を紹介します。</p>
<ul>
<li>商品A</li>
<li>商品B</li>
</ul>
</section>要素の入れ子や属性の記述を正しく保つことは、予期しない表示や動作を減らすうえで有用です。
ただし、構文エラーがないことだけでは、見出しの順序やボタンの名前が適切かまでは判断できません。
ARIAは標準HTMLで足りない情報を補う
ARIA（Accessible Rich Internet Applications）は、UI部品の名前、役割、状態などを支援技術へ伝えるための属性群です。
まず標準HTMLで表現できないかを確認し、それだけでは意味が伝わらない箇所にARIAを使います。
たとえば、文字のない検索ボタンは、アイコンを見れば目的が分かっても、支援技術が利用する名前（アクセシブルネーム）を持たない場合があります。
その場合は、次のように目的を補います。
<button type="button" aria-label="検索を実行">
<span aria-hidden="true">🔍</span>
</button>一方、ボタン内に「検索」と表示できるなら、その文字を名前として利用できます。
ARIAを加えること自体を目的にせず、表示内容と支援技術へ伝わる情報が食い違わないようにします。
「名前、役割、値」の実装方法では、ボタンや開閉UIの例を詳しく確認できます。
HTML、CSS、JavaScriptの役割を整理する
HTMLで構造、CSSで見た目、JavaScriptで動作を担当させると、どの層に問題があるかを追いやすくなります。
ただし、ファイルや技術を分けるだけでアクセシビリティが確保されるわけではありません。
JavaScriptを使うUIでは、操作できる要素を適切に選び、キーボード操作を妨げず、操作後の状態がコードからも分かるようにします。
すべての機能をJavaScript無効時にも再現するという一律の条件ではなく、必要な情報や操作が環境の違いによって失われないかを確認することが実務上の焦点です。
対象となる環境で組み合わせを試す
同じコードでも、ブラウザ、端末、支援技術の組み合わせによって伝わり方や操作感が異なることがあります。
対象読者が利用すると考えられる環境を決め、表示確認だけでなく、キーボード操作や読み上げも試します。
確認する環境を際限なく増やすのではなく、主要な組み合わせを選び、更新後も同じ手順で再確認できるようにします。
この運用が、変更による問題の見落としを減らします。
ツールと手動確認の使い分け
自動チェックは、同じルールを繰り返し確認する作業に向いています。
一方、操作の流れが理解しやすいか、読み上げ順が自然かといった判断には手動確認が必要です。
Webアクセシビリティのチェックツールも参照し、目的に応じて組み合わせます。
| 確認方法 | 見つけやすい問題 | 補うべき確認 |
|---|---|---|
| W3C Markup Validation Service | HTMLの構文や属性に関する問題 | 情報の意味、操作方法、読み上げ内容は別に確認する |
| Lighthouse | ルールに基づいて検出できる一般的な問題 | 指摘されない項目をキーボードや支援技術で確認する |
| axe Accessibility Checker | HTMLやARIAに関する機械判定可能な問題 | 画面の文脈と操作の流れを人が確認する |
| キーボードとスクリーンリーダー | フォーカス移動、部品の名前、役割、操作後の変化 | 複数の主要環境で結果を比べる |
自動ツールで指摘がゼロになっても、確認は完了ではありません。
自動チェックで修正候補を絞り、実際の操作で情報と機能が伝わるかを確かめます。
公開前に確認したいチェックリスト
- 見出し、段落、リストが見た目ではなくHTML要素で表現されているか。
- リンクとボタンを目的に応じて使い分け、名前から操作結果を予測できるか。
- 画像だけ、色だけ、アイコンだけに意味を任せていないか。
- ARIAの役割やラベルが、画面に表示される内容と一致しているか。
- JavaScriptで変化するUIの状態を、支援技術も判別できるか。
- キーボードだけで必要な場所へ移動し、操作を完了できるか。
- 自動チェックに加え、対象とするブラウザや支援技術で確認したか。
堅牢性を保つための考え方
堅牢なWebサイトは、特定の属性やツールを一つ導入すれば完成するものではありません。
標準HTMLで意味を示し、必要な情報だけをARIAで補い、実際の操作環境で確認するという順序で整えます。
この順序を設計、実装、更新の各段階で繰り返せば、技術や利用環境が変わっても、コンテンツの意味と操作方法を保ちやすくなります。
Webアクセシビリティ対応を継続しやすくするために
当社では、Webアクセシビリティを導入しやすくするUUU ウェブアクセシビリティウィジェットツールを提供しています。
アクセシビリティ向上に関心のある方は、サービスの詳細をご覧ください。