UAAG（User Agent Accessibility Guidelines）は、Webブラウザ、ブラウザ拡張、メディアプレイヤー、リーダーアプリなど、Webコンテンツを表示・操作するユーザーエージェントをアクセシブルにするための指針です。
Webアクセシビリティというと、ページ側のHTMLやデザインを整えるWCAG 2.2とは何かが注目されがちです。しかし、利用者が実際に触れるのは、ブラウザやアプリ、支援技術を含む利用環境全体です。UAAGは、その見る・聞く・操作する道具側をどう整えるかに焦点を当てます。
この記事では、UAAGの基本、WCAGとの違い、UAAG 2.0で押さえたい観点、Webサイト担当者が実務でどう活用すべきかを整理します。
UAAGとは何か
UAAGは、障害のある人を含む多様な利用者が、ユーザーエージェントを通じてWebコンテンツにアクセスしやすくするためのガイドラインです。
ここでいうユーザーエージェントとは、単なるWebブラウザだけではありません。動画や音声を再生するメディアプレイヤー、Webページを読むリーダー、ブラウザ拡張、Webコンテンツを表示して操作できるアプリケーションも含まれます。
たとえば、ページに適切な見出しや代替テキストがあっても、ブラウザや支援技術との連携が弱ければ、利用者には正しく届きません。逆に、ユーザーエージェントがキーボード操作、文字サイズ変更、代替コンテンツの表示、支援技術への情報提供を適切に扱えれば、同じコンテンツでも使いやすさは大きく変わります。
WCAG・ATAGとの違い
UAAGを理解するには、Webアクセシビリティをコンテンツ、作る道具、利用する道具に分けて考えると整理しやすくなります。
| 指針 | 主な対象 | 見るポイント |
|---|---|---|
| WCAG | Webページやアプリのコンテンツ | 見出し、代替テキスト、コントラスト、キーボード操作、エラー表示など。 |
| ATAG | CMS、エディタ、制作ツール | 作成者がアクセシブルなコンテンツを作りやすいか、ツール自体が使いやすいか。 |
| UAAG | ブラウザ、メディアプレイヤー、リーダー、拡張機能など | 利用者が表示・操作を調整できるか、支援技術と連携できるか。 |
Webサイト担当者にとっては、まずWCAGへの対応が基本になります。そのうえでUAAGを知っておくと、ページ側で直すべき問題と、ブラウザや支援技術との組み合わせで確認すべき問題を分けて考えやすくなります。
UAAG 2.0で押さえたい5つの観点
UAAG 2.0は、ユーザーエージェントのアクセシビリティを複数の観点から整理しています。細かな達成基準を読む前に、まず次の5つの方向性を押さえると理解しやすくなります。
- 知覚できること：表示内容やユーザーインターフェースの情報を、視覚、聴覚、支援技術などを通じて利用者が受け取れるようにする。
- 操作できること：マウスだけに依存せず、キーボードやその他の入力方法でも主要な操作を行えるようにする。
- 理解できること：設定、エラー、操作結果、ヘルプが分かりやすく、利用者が次に何をすればよいか判断できるようにする。
- 支援技術が情報へアクセスできること：スクリーンリーダーなどが、ボタン名、状態、構造、入力欄の意味を取得できるようにする。
- 仕様やプラットフォームの慣習に沿うこと：Web標準やOSのアクセシビリティ機能と矛盾しない形で動作する。
UAAGはブラウザを作る企業だけが読むものと見られがちですが、実務では品質確認の視点としても役立ちます。特に、スクリーンリーダーと読み上げ環境の実装ポイントを確認するときは、コンテンツだけでなく、ブラウザと支援技術がどのように情報を受け渡しているかを見る必要があります。
視覚障害のある利用者に関係するポイント
元の記事のテーマである視覚障害のある利用者にとって、UAAGの考え方は特に重要です。ただし、UAAGが対象とするのは視覚障害だけではありません。聴覚、身体、認知、学習、言語、加齢に伴う変化など、幅広い利用状況を想定します。
| 利用者の状況 | UAAGの観点で見ること |
|---|---|
| スクリーンリーダーを使う | 見出し、リンク、ボタン、フォームの名前や状態が支援技術へ伝わるか。 |
| 弱視・ロービジョンで文字を拡大する | 文字サイズ、色、表示倍率、コントラストを調整しても内容や操作が破綻しないか。 |
| マウス操作が難しい | キーボードだけで移動・選択・実行でき、現在位置が見えるか。 |
| 動画や音声を利用する | 再生、停止、音量、字幕、代替情報を利用者が操作できるか。 |
サイト側の実装では、キーボード操作とフォーカス表示を崩さないことが基本です。UAAGの視点を加えると、その実装が実際のブラウザや支援技術の上でどう体験されるかまで確認できます。
実装・評価で確認したいチェックポイント
UAAGを実務に取り入れるときは、仕様書を丸暗記するよりも、利用者が困る場面を先に想像すると検討しやすくなります。まずは次の観点から確認します。
- 主要な操作がキーボードだけで完了できるか。
- フォーカス位置が分かりやすく、移動順序が画面の流れと合っているか。
- 文字サイズや表示倍率を変えても、情報や操作ボタンが失われないか。
- 動画・音声コンテンツの再生、停止、字幕、代替情報を利用者が制御できるか。
- フォームのエラーや確認メッセージが、見た目だけでなく支援技術にも伝わるか。
- 設定やヘルプが見つけやすく、専門用語だけで説明されていないか。
- 複数のブラウザ、OS、支援技術の組み合わせで大きな破綻がないか。
これらは、ブラウザベンダーだけの課題ではありません。Web制作側も、特定の環境だけで見た目を確認して終わるのではなく、利用者の操作環境を含めて検証する必要があります。公開後も改善を続ける考え方は、公開して終わりにしないWebアクセシビリティ運用でも重要です。
UAAGをWebサイト改善にどう生かすか
Webサイト担当者がUAAGを読む目的は、ユーザーエージェントそのものを開発することだけではありません。利用者がどの環境で、どの支援技術を使い、どこでつまずくのかを理解するためにも使えます。
たとえば、サイトのボタンにラベルがない場合、ページ側の問題として修正が必要です。一方で、ブラウザや支援技術によって読み上げ方が異なる場合は、複数環境での確認や代替表現の検討が必要になります。この切り分けができると、修正範囲と優先順位を判断しやすくなります。
また、Webアクセシビリティを初めて実務に組み込む場合は、Webアクセシビリティとは何かを押さえたうえで、WCAG、UAAG、実際の利用者テストを組み合わせると、改善の抜け漏れを減らせます。
UUUウェブアクセシビリティウィジェットとの関係
当社では、Webアクセシビリティの向上を支援するUUUウェブアクセシビリティウィジェットを提供しています。
ウィジェットは、サイト側で読みやすさや操作性を補助するための手段の一つです。ただし、ウィジェットだけでUAAGやWCAGのすべてに対応できるわけではありません。ページの設計、HTMLの意味づけ、キーボード操作、支援技術での確認、運用改善と組み合わせて考えることが重要です。
UUUを含むWebアクセシビリティ改善の考え方については、UUUとWebアクセシビリティの考え方もあわせてご覧ください。
まとめ
UAAGは、Webコンテンツそのものではなく、Webコンテンツを表示・操作するユーザーエージェント側のアクセシビリティを考えるための指針です。
- WCAGはコンテンツ、UAAGはブラウザやメディアプレイヤーなどの利用環境に焦点を当てる。
- 視覚障害のある利用者だけでなく、多様な障害や利用状況を想定する。
- キーボード操作、文字表示の調整、支援技術との連携、エラーや設定の分かりやすさが重要になる。
- Webサイト担当者は、WCAG対応に加えて、実際のブラウザ・OS・支援技術での確認を組み込むと改善の精度が上がる。
アクセシビリティは、ページ単体では完結しません。コンテンツ、制作ツール、ユーザーエージェント、支援技術がつながって、初めて利用者に届く体験になります。UAAGは、その全体像を見失わないための実務上の手がかりになります。