訳注：このWAI-ARIA 1.0仕様の後続仕様として、WAI-ARIA 1.1仕様が発行されています。よって、この翻訳文書はメンテナンスしていません。

この文書の代わりに、WAI-ARIA 1.1日本語訳を参照してください。

1. 導入

#

この章は参考情報である。

この仕様の目的は以下を含む：

WAI-ARIAは、ウェブコンテンツおよびアプリケーションのアクセシビリティーと相互運用性を改良するためのフレームワークを提供する技術仕様である。この文書は、カスタムウィジェットやその他のウェブアプリケーションコンポーネントを作成する開発者を主に対象とする。WAI-ARIAが解決しようとするアクセシビリティーの問題を開発者に紹介するWAI-ARIA入門書のような、他の観客、基本的概念およびWAI-ARIAの技術的アプローチのための関連文書へのリンクは、WAI-ARIA Overviewを参照されたい。

このドラフトは、ロールの2つの側面、ユーザーインターフェイスの機能と構造の関係を目下処理する。詳細と使用例のための、インタラクティブコンテンツをアクセシブルにするロールの使用法については、WAI-ARIA入門書[ARIA-PRIMER] を参照のこと。

ロールのタクソノミーは、プラットフォームのアクセシビリティーAPIに見られる共通のロールをサポートするために、ある程度設計されている。動的なウェブコンテンツによって、このタクソノミーで見つかったロールへの参照は、支援技術との相互運用性をサポートするために使用してもよい。

この規格をサポートするためのスキーマは拡張可能であるように設計されているため、カスタムロールは基本ロールを拡張することによって作成できる。これは、ユーザーエージェントが少なくとも基本ロールをサポートすることを可能にし、かつカスタムロールをサポートするユーザーエージェントは、強化されたアクセスを提供できる。この多くは、XMLスキーマで形式化されうることに注意すること[XSD]。しかし、baseConceptsおよびより記述的な定義のような、ロール間の類似性を定義できるということは、XSDで利用できないだろう。

1.1. リッチ・インターネット・アプリケーション・アクセシビリティー

#

ウェブアクセシビリティーの分野は、障害をもつ人にとってどのようにすればウェブコンテンツを利用可能にするかを定義する。ある種の障害をもつ人は、コンテンツを情報交換するために支援技術（AT）を使用する。支援技術は、ユーザーに対してより適したフォーマットにコンテンツの体裁を変換することができ、ユーザーがさまざまな方法で情報交換することを可能にする。たとえば、ユーザーはマウスをドラッグやドロップする代わりに、矢印キーでスライダウィジェットと情報交換する必要または選択するかもしれない。効果的にこれを達成するために、ソフトウェアはコンテンツのセマンティックスを理解する必要がある。セマンティックスは意味の科学である。この場合、人間が理解するだろうユーザーインターフェイスとコンテンツ要素に適用するロール、ステート、およびプロパティを割り当てるために使用される。たとえば、ある段落が段落のようにセマンティックに識別される場合、支援技術は、その段落の正確な境界線を知ると、コンテンツの残りの部分から分けられる構成単位として情報交換できる。調整可能な範囲スライダまたは折りたたみ可能リスト（別名ツリーウィジェット）は、ウィジェットのさまざまな部分が、効果的なふれ合いをサポートするために支援技術に対して適切に識別される必要があるセマンティックスを持つ、より複雑な例である。

新しい技術は、アクセシビリティーに必要なセマンティックスをしばしば見落とし、しかも新しいオーサリング手法は、これらの技術の意図するセマンティックスをたびたび誤用する。言語において定義された意味を持つ要素が、ユーザーによって理解されるべきものとは異なる意味で使われている。

たとえば、ウェブアプリケーション開発者は、HTMLがセマンティックにtree要素を持たないにもかかわらず、CSSおよびJavaScriptを使用してHTMLで折りたたみ可能なツリーウィジェットを作成する。障害のないユーザーにとって、これは折りたたみ可能なツリーウィジェットのように見えてかつ動作するかもしれないが、適切なセマンティックスをもたず、支援技術がロールを認識しないかもしれないため、ツリーウィジェットは、障害をもつ人によって知覚可能または操作可能でないかもしれない。

WAI-ARIAの取り込みは、ウィジェットのアクセシビリティー、ユーザビリティー、および支援技術との相互運用性を整備するために、開発者がカスタムウィジェットに適切なセマンティックスを提供できる方法の一つである。この仕様は、コンテンツに付けられるロールのオントロジーを提供することによって、アクセシビリティー製品が一般に認識するウィジェットおよび構造のタイプを識別する。これは、与えられたロールをもつ要素が、実装するホスト言語から継承された任意のセマンティックに関係なく、特定のウィジェットまたは構造タイプとして理解できる。ロールは、支援技術が有効な見栄えと対話をユーザーに提供するために使用する、プラットフォームのアクセシビリティーAPIの共通のプロパティである。

このロールタクソノミーは、文書構造を示すインタラクションウィジェットおよび要素を含む。ロールタクソノミーは、継承および各ロールがサポートする属性の詳細を説明する。アクセシビリティーAPIに対するロールの対応付けに関する情報は、WAI-ARIAユーザーエージェント実装ガイド [ARIA-IMPLEMENTATION]によって提供される。

ロールは要素タイプであり、時間またはユーザーアクションとともに変化しない。ロール情報は、指定された要素タイプの通常の処理を提供するために、ユーザーエージェントとの情報交換を経由して、支援技術によって使用される。

ステートおよびプロパティは、対話に影響および説明する要素の重要な属性を宣言するために使用される。属性がクライアントサイドのスクリプトによって動的に変更される場合でも、ステートおよびプロパティはユーザーエージェントおよびオペレーティングシステムに適切に要素を処理することを可能にする。たとえば、スクリーンリーダーや音声ディクテーションソフトウェアなどの代替入出力技術は、ユーザーに様々な情報交換の状態（無効、チェックなど）を認識し、効果的に操作され、通信できるようにする必要がある。

支援技術が文書オブジェクトモデル [DOM]を介してこれらのプロパティに直接アクセスすることは可能である一方、ユーザーエージェントにとって好ましいメカニズムは、オペレーティングシステムのアクセシビリティーAPIに対してステートおよびプロパティを対応づけることである。詳細についてはWAI-ARIAユーザーエージェント実装ガイド [ARIA-IMPLEMENTATION]を参照のこと。

図1は、ユーザーエージェント（ブラウザーなど）、アクセシビリティーAPI、および支援技術との関係を示している。図は、GUIのための多くのアクセシブルなプラットフォームに対するアクセシビリティーAPIに見られる典型的なアクセシビリティー情報（ロール、ステート、選択、イベント通知、関係情報、および説明）を含む、ユーザーエージェントによって支援技術に提供される"規約"を説明する。通常HTMLであるDOMは、データモデルおよび典型的なモデル - ビュー - コントローラ関係でビューとして機能し、そしてJavaScriptは、表示されたデータのスタイルおよびコンテンツを操作することでコントローラーとして機能する。ユーザーエージェントは、スクリーンリーダーなどの任意の支援技術によって使用できる、オペレーティングシステムのアクセシビリティーAPIに関連する情報を伝える。

The contract model with accessibility APIs

図1：アクセシビリティーAPIをもつ規約モデル

インタラクティブなコンテンツをアクセシブルにするためのロールの使用方法について詳細は、WAI-ARIA Primer [ARIA-PRIMER]を参照のこと。

文書に加えて、ロールタクソノミーは、リソース記述フレームワーク [RDF]で表現されるウェブオントロジー言語 [OWL]で提供される。ツールは、指定したコンテンツ文書でロールの実装を検証するためにこれらを使用できる。たとえば、いくつかのロールのインスタンスは、特定の親ロールの子となることが期待される。また、いくつかのロールは、別のロールがサポートしない特定のステートまたはプロパティをサポートするかもしれない。

注：将来の拡張性をサポートするためにRDF/OWLをロールの正式な表現として使用するかもしれない。標準RDF/OWLのメカニズムは、この仕様で定義されたロールから継承する新しいロールを定義するために使用することができる。ただし、相互運用可能な方法でロールの拡張を定義しかつ使用するためのメカニズムは、この仕様で定義されない。将来のWAI-ARIAのバージョンは、ロールを拡張するための方法を定義することが期待される。

代替入力デバイスのユーザーは、キーボードアクセシブルコンテンツを必要とする。WAI-ARIA オーサリングプラクティス [ARIA-PRACTICES]で提供される推奨キーボード情報交換と組み合わされる場合、新しいセマンティックスは、代替入力ソリューションが代替入力ソリューションを通してコマンドおよびコントロールを容易にする。

WAI-ARIAは、改良されたキーボードナビゲーションを提供することによって、運動機能および視力障害をもつ人を助けることができる、ランドマークのタクソノミーおよびXHTMLロールランドマークを通じてナビゲーションランドマークを導入する。WAI-ARIAはまた、認知学習障害をもつ人を支援するために使用されるかもしれない。追加のセマンティックスは、必要に応じて著者が代替コンテンツを再構築および代用できる。

支援技術は、ウィジェットのステートおよびプロパティの現在値を取得および設定することにより、代替入力をサポートする機能を必要とする。支援技術はまた、どのオブジェクトがリストボックスやグリッドなど複数の選択を許可するウィジェットを選択されて管理するかを判断する必要がある。

音声ベースのコマンドおよび制御システムは、ユーザーに音声情報を伝達するのに役立つrole属性のような、WAI-ARIAセマンティックスの恩恵を受けることができる。たとえば、要素がmenuのロールおよびそれぞれ異なる風味を表すテキストコンテンツを含むロールmenuitemを持つ3つの要素を含むもので決定されることによって、音声システムは「次の3つの選択肢のいずれかを選択してください。チョコレート、ストロベリー、バニラ。」とユーザーに言うかもしれない。

WAI-ARIAは、ネイティヴ言語のセマンティックスに対する代替としてでなく、補足として使用されることを意図する。ホスト言語がWAI-ARIAの機能に相当するアクセシビリティーを提供して機能を提供する場合、ホスト言語の機能を使用する。WAI-ARIAは、ホスト言語が必要なロール、ステート、およびプロパティインジケーターを欠いている場合にのみ使用すべきである。WAI-ARIAの機能にできるだけ類似したホスト言語の機能を使用し、WAI-ARIAを追加することで意味を洗練する。たとえば、選択可能なマルチグリッドはテーブルとして実装することできるかもしれず、その上WAI-ARIAは、単なる静的なデータテーブルでなく、対話型グリッドであることを明確にするために使用する。これは、WAI-ARIAをサポートしないユーザーエージェントのために可能な限り最良のフォールバックを可能にし、ホスト言語のセマンティックスの完全性を維持する。

1.2. 対象読者

#

この仕様は、ロール、ステート、プロパティ、および値を含む、WAI-ARIAのための基本的なモデルを定義する。この仕様が影響を与える複数の読者は次の通り：

各適合性要件は、要件が適用される読者を示す。

この仕様は上記の読者に適用可能ではあるが、これは特に対象を定めるものではなく、上記の読者のいずれかのための独占的な情報源であることを意図しない。以下の文書が重要なサポート情報を提供する：

1.3. ユーザーエージェントのサポート

#

2つの方法で、WAI-ARIAはその機能のためのユーザーエージェントのサポートに依存する：

アクセシビリティーAPIに公開されるものを改善するために、WAI-ARIAマークアップを使用することは別として、ユーザーエージェントはAPIがネイティヴとして振る舞う。支援技術が非ウェブコンテンツで同じ情報に対してすでに行うように、支援技術はアクセシビリティーAPIの追加情報に反応する。しかし、支援技術がないユーザーエージェントは、アクセシビリティーAPIへの適切な更新を提供するよりほかは何もしない必要がある。

WAI-ARIA仕様は、ユーザーエージェントにWAI-ARIAマークアップに基づくネイティヴプレゼンテーションおよび情報交換の動作を強化することを、要求も禁止もしない。メインストリームのユーザーエージェントは、すべてのユーザーのためのナビゲーションを容易にするための意図とともに（たとえば、ダイアログボックスとして、またはキーボードコマンドを通して）、WAI-ARIAナビゲーションランドマークを公開するかもしれない。ユーザーエージェントは、障害を持たないユーザーを含めて、ユーザーにその有用性を最大にすることを推奨する。

著者の意図が支援技術に伝達されるように、WAI-ARIAは欠落しているセマンティックスを提供することを目的とする。一般に、WAI-ARIAを用いる著者は、適切な体裁と情報交換機能を提供するだろう。時間とともに、ホスト言語は、新しいフォームコントロールように、ユーザーエージェントによって標準的なアクセシブルユーザーインターフェイスコントロールとして実装される、WAI-ARIA等価物を追加するかもしれない。これは、著者がユーザーインターフェイスコンポーネントを有効にしたカスタムWAI-ARIAをそれらの代わりに使用できる。この場合、ユーザーエージェントは、ネイティヴホスト言語の機能をサポートする。ホスト言語の機能が著者のニーズを満たすのに不十分である場合、WAI-ARIAのセマンティックスがより明確に作者の意図を反映するように、それらは暗黙のホスト言語のセマンティックスに有害に競合しない際、WAI-ARIAを実装するホスト言語の開発者は、WAI-ARIAのセマンティックスをサポートし続けるように忠告する。

1.4. WAI-ARIAとホスト言語の相互進化

#

WAI-ARIAは、HTMLやSVGなどの言語をサポートするものの中でセマンティックスを補強するためのもの、または明示的にARIAのサポートを含まない他のマークアップベースの言語で、アクセシビリティー拡張技術として使用される。オブジェクトの新しい種類の発明はWeb言語で表示する標準化されたサポートよりも高速であるため、スタイルやスクリプト経由で、ページの言語でまだ直接サポートされない、著者がオブジェクトの新しい種類を作成する際、WAI-ARIAは支援技術にセマンティックスを明確にする。

ホスト言語がオブジェクトのその種類にセマンティック要素を提供する場合、スタイルおよびスクリプトをもつオブジェクトを作成することは適切ではない。 WAI-ARIAは、これらのオブジェクトのアクセシビリティーを向上させることができる一方で、アクセシビリティーは、ユーザーエージェントがネイティヴにオブジェクトを処理できるようにすることによって提供される最良のものである。たとえば、div要素にheadingロールを使用するよりも、HTMLのh1要素を使用するほうがよい。

時間とともに、ホスト言語は、今のところWAI-ARIAを使ってのみ宣言できるオブジェクトのセマンティックスを提供するために進化していくことが予想される。WAI-ARIAの1つの目標はよりセマンティックかつアクセシブルなマークアップの出現を刺激する手助けをすることであるので、これは自然で望ましい。所定の機能に対するネイティヴセマンティックスが使用可能になる場合、著者は、ネイティヴ機能を使用し、その機能のWAI-ARIAの使用を中止することが適切である。しかし、レガシーコンテンツは WAI-ARIAを使用し続けるかもしれないので、WAI-ARIAをサポートするユーザーエージェントの必要性が残っている。

WAI-ARIAの特定の機能は時間とともに重要性を失うかもしれない一方で、ウェブページにセマンティックスを追加するWAI-ARIAの一般的な可能性は、持続するニーズが期待される。ホスト言語は、WAI-ARIAが提供するすべてのセマンティックスを実装しないかもしれず、様々なホスト言語は、異なる機能のサブセットを実装するかもしれない。オブジェクトの新しいタイプは継続的に開発されており、そして多くの場合ウェブオーサリングプラクティスは、より高速なホスト言語標準より前進するため、WAI-ARIAの1つの目標は、このようなオブジェクトをアクセシブルにする方法を提供することにある。このように、WAI-ARIAとホスト言語は両方一緒に進化するが、異なる速度で進化する。

一部のホスト言語は、ユーザーインターフェイス以外の機能のセマンティックスを作成するために存在する。たとえば、SVGはオブジェクトが表すだろうユーザーインターフェイスコンポーネントでなく、グラフィカルオブジェクトの生成物の背後にあるセマンティックスを表現し、XFormsは、フォームコントロールにセマンティックスを提供し、幅広いユーザーインターフェイス機能を提供しない。このようなホスト言語は、設計上、WAI-ARIAの機能に対応するネイティヴセマンティックスを提供しないかもしれない。この場合、WAI-ARIAは、ユーザーインターフェイスコンポーネントにセマンティック情報を追加するために、長期的なアプローチを採用することができる。

1.5. オーサリングプラクティス

#

1.5.1. オーサリングツール

#

WAI-ARIAのロール、ステート、プロパティの定義における要件の多くは、コードを検証するために使用される他の品質管理プロセスと同様、開発プロセスの間に自動的にチェックできる。カスタムウィジェットを作成している著者を支援するために、オーサリングツールは、WAI-ARIAでサポートされるものだけでなく、関連および相互参照されるロール。ステート、およびプロパティでサポートされる、ウィジェットのロール、ステート、およびプロパティと比較してもよい。オーサリングツールは、ウィジェットのデザインパターンのエラーを著者に通知してもよく、また単独のコンテキストから決定できない情報を開発者に表示してもよい。たとえば、スクリプトライブラリーは、ツリービューにおけるツリー項目のラベルを決定できるが、ツリー全体にラベルを付けることを著者に促す必要があるかもしれない。著者に論理アクセシビリティー構造の視覚化を促すために、オーサリング環境は、WAI-ARIAマークアップに基づいてウェブリソースのアウトラインビューを提供するかもしれない。

HTMLにおいて、tabindexは、ブラウザがWAI-ARIAの実装に対してキーボードのフォーカスナビゲーションをサポートする重要な手段である。オーサリングツールおよびデバッグツールはtabindex値が適切に設定されていることを確認するためにチェックしてもよい。たとえば、エラー条件は、ツリーで1つ以上のツリー項目が0以上tabindex値である場合、tabindexがどのツリー項目にも設定されない場合、またはロールツリーを伴う要素が0以上のtabindex値を持つ際にaria-activedescendentが定義されない場合を含むかもしれない。

1.5.2. プラクティスおよびツールのテスト

#

インタラクティブコンテンツのアクセシビリティーは、静的なチェックだけで確認できない。インタラクティブコンテンツの開発者は、ウィジェットやアプリケーションにデバイスに依存しないアクセスのためにテストすべきであり、ユーザーと情報交換中にすべてのコンテンツと変更へのアクセシビリティーAPIへのアクセスを確認すべきである。

1.6. 支援技術

#

アクセシビリティーセマンティックスへのプログラムアクセスが支援技術に不可欠である。ほとんどの支援技術は、認識されたアクセシビリティーAPIを通じて、他のアプリケーションと同様に、ユーザーエージェントと情報交換する。ユーザーインターフェイスで知覚可能なオブジェクトは、アクセシビリティーAPIインターフェイスで定義されたアクセシブルオブジェクトとして支援技術に公開される。これを適切に行うために、アクセシビリティー情報―ロール、ステート、プロパティならびに文脈情報―は、アクセシビリティーAPIを通じて支援技術に正確に伝える必要がある。状態変化が発生した場合、ユーザーエージェントはアクセシビリティーAPIに適切なイベント通知を提供する。HTMLのような多くのホスト言語で、コンテキスト情報は、文脈ツリー階層を提供するので、DOM自体から決定できる。

一部の支援技術はこれらアクセシビリティーAPIと情報交換する一方で、他は、DOMから直接コンテンツにアクセスできる。これらの技術は、異なるユーザー集合を助けるために、コンテンツを再構築、簡素化、スタイル付け、またはリフローできる。この適応タイプに対する一般的なユースケースは、高齢化、認知障害のある人、またはそのツールの使用を妨害する環境にいる人かもしれない。たとえば、地域のナビゲーションランドマークの可用性は、そのセマンティックスに基づいて、一度にコンテンツの一部のみを表示するモバイルデバイスへの適応を可能にする。これは、ユーザーが一度に処理するために必要な情報量を減らすことができる。他の状況において、キーボードまたはタッチスクリーンデバイスを使ってナビゲートしやすいものをもつカスタムユーザーインターフェイスコントロールを置き換えるために適切かもしれない。

セマンティックプログラムに対するこれらの要求は、ユーザーエージェントにだけでなく、コンテンツに適用されることを除いて、並列にユーザーエージェントアクセシビリティーガイドライン：ユーザーエージェントユーザーインターフェイスプログラム操作および変更のプログラム通知（[UAAG]）にアクセスする。