Webアクセシビリティとは、障害の有無や操作環境にかかわらず、必要な情報と機能を利用できるように設計する取り組みです。
画面を見にくい人、マウスを操作しにくい人、音声を聞き取りにくい人など、利用者の状況は一様ではありません。
API（Application Programming Interface）は、ソフトウェア同士がデータや機能を受け渡すための接点です。
外部サービスの情報を取り込むAPIや、ブラウザの音声機能を使うAPIは、情報の受け取り方や操作方法を増やすために役立ちます。
ただし、APIを導入するだけでWebサイトが使いやすくなるわけではありません。
HTMLの構造、WAI-ARIA、キーボード操作、フォーカス管理、処理結果の伝え方を組み合わせて初めて、利用者が目的の操作を完了しやすくなります。
APIが担う役割を切り分ける
「API」という言葉で異なる仕組みを一括りにすると、何を実装すべきかが曖昧になります。
Webアクセシビリティでは、次の三つを分けて考えると設計しやすくなります。
| 仕組み | 主な役割 | 使いどころ |
|---|---|---|
| 外部サービスやデータのAPI | 別のサービスからデータを受け取る | 地図、交通、動画などの情報を画面へ反映する |
| ブラウザのAPI | ブラウザが備える機能を利用する | 音声認識、音声合成、入力イベントなどを扱う |
| HTMLとWAI-ARIA | 画面の意味や状態を支援技術へ伝える | 名前、役割、状態、更新内容を明確にする |
WAI-ARIAは、外部サービスとデータをやり取りするAPIではありません。
HTMLに属性を加え、インターフェースの意味や状態を支援技術へ伝えるための仕様です。
APIで機能を追加する場合も、画面側の意味づけにはHTMLとWAI-ARIAが必要です。
スクリーンリーダーへ意味と状態を伝える
スクリーンリーダーの仕組みと実装ポイントを理解するには、画面に見えている文字だけでなく、操作部品の名前や状態がどのように伝わるかを考える必要があります。
ボタンの目的、メニューの開閉状態、入力欄のラベルが不明確なら、見た目では操作できても読み上げでは判断できません。
アクセシビリティツリーとは、ブラウザが支援技術へ渡すために、ページ内の要素の名前、役割、状態を整理した情報です。
HTMLを目的に合った形で使うと、この情報が伝わりやすくなります。
HTMLだけでは表現しにくい動的な状態は、WAI-ARIAで補います。
WAI-ARIAの代表的な属性
WAI-ARIAの役割と使い方では、属性を付ける目的を先に決めます。
属性を増やすこと自体を目標にせず、利用者へ不足している情報だけを補います。
aria-label：画面上の文字だけでは操作部品の名前が伝わらない場合に、読み上げ用の名前を補います。aria-hidden：装飾や重複した内容など、読み上げる必要のない要素を支援技術から除外します。
操作に必要な要素へ使うと情報が欠けるため、対象を確認して設定します。aria-live：画面の一部が動的に更新されたとき、その変化を通知します。
通知が多すぎると操作を妨げるため、完了、エラー、重要な状態変化などに絞ります。
キーボード操作とフォーカスを整える
マウス操作が難しい利用者は、Tabキーなどで操作対象を移動し、キーボードから機能を実行します。
APIで新しい機能を追加しても、操作対象へ到達できない、現在位置が見えない、操作後にフォーカスが失われるといった状態では利用できません。
tabindexはAPIではなくHTML属性です。
一方、JavaScriptのイベント処理は、キーボード入力を受け取って動作へつなげるために使えます。
両者の役割を分け、次の点を確認します。
- リンク、ボタン、入力欄など、必要な操作対象へキーボードだけで移動できるか。
- フォーカスの順序が、画面の内容を理解する順序と合っているか。
- 現在フォーカスしている場所を見分けられるか。
- 画面が切り替わった後も、次に操作すべき場所が分かるか。
実装と確認の進め方は、キーボード操作とフォーカス表示を整える実務でも確認できます。
音声認識と音声合成を補助機能として使う
Web Speech APIは、ブラウザ上で音声認識と音声合成を扱うための仕組みです。
音声認識は声による入力に、音声合成はテキストの読み上げに利用できます。
ただし、独自の読み上げ機能を加えても、見出しやラベルの不足、キーボードで操作できない問題は解決しません。
音声機能は、意味の通るHTMLと操作可能な画面を用意したうえで、入力方法や情報の受け取り方を増やす補助機能として設計します。
導入時は、開始と停止の操作を分かりやすくし、音声機能を使わなくても同じ情報や機能へ到達できる状態を保ちます。
対象とする端末やブラウザで利用可否と挙動を確認し、利用できない場合の代替手段も用意します。
外部APIのデータを画面へ反映する
地図や交通のAPIに車椅子対応などの情報が含まれていれば、経路や施設を選ぶための手掛かりとして表示できます。
一方、APIの応答に必要な項目がなければ、画面側だけで情報を補うことはできません。
データがない状態を利用者へ伝え、推測した内容を確定情報として表示しない設計が必要です。
動画サービスのAPIで字幕データを扱う場合も同じです。
APIを呼び出すことと、字幕が存在し、内容が適切であることは別の問題です。
字幕の有無を確認し、取得できない場合の表示や代替情報まで決めておきます。
APIの処理結果を分かる形で返す
APIを利用する画面では、通信の待機、完了、エラーによって表示が変化します。
見た目だけが変わると、スクリーンリーダーの利用者は処理が終わったのか、操作をやり直す必要があるのかを判断できません。
処理中であること、成功した結果、エラーの内容、次に取れる操作をテキストで示します。
必要な更新にはaria-liveを使い、同じ通知を繰り返したり、軽微な変化まで読み上げたりしないようにします。
実装と確認の手順
- 利用者の目的を決める：検索、予約、視聴など、APIを使って完了させたい操作を明確にします。
- APIが返す情報を確認する：必要なデータ、欠ける可能性のある項目、エラー時の応答を整理します。
- HTMLで画面の意味を作る：見出し、リンク、ボタン、入力欄を目的に合った要素で構成します。
- 不足する状態だけをWAI-ARIAで補う：動的な更新や開閉状態など、HTMLだけでは伝わりにくい情報を追加します。
- 入力方法を確認する：マウスだけでなく、キーボードや提供する音声操作から同じ目的を達成できるかを試します。
- 実際の利用環境で確認する：キーボード、スクリーンリーダー、対象ブラウザを使い、正常時とエラー時の両方を確認します。
導入時の判断基準
- 追加するAPIは、利用者が直面する具体的な障壁を減らしているか。
- APIを利用できない場合も、主要な情報や操作へ到達できるか。
- データの欠落、待機、エラーを利用者が理解できるか。
- 画面の名前、役割、状態が支援技術へ伝わるか。
- キーボードだけで一連の操作を完了できるか。
APIは、入力方法や出力方法を増やし、外部データを届けるための手段です。
アクセシビリティを自動的に保証するものではないため、HTMLの意味、WAI-ARIA、フォーカス、処理結果の通知までを一つの利用体験として設計します。
当社では、Webアクセシビリティ対応を支援するUUU ウェブアクセシビリティウィジェットツールを提供しています。
Webサイトのアクセシビリティ改善に関心のある方は、サービスの詳細をご覧ください。