この文書は「Accessible Rich Internet Applications (WAI-ARIA) 1.1（W3C Recommendation 2017-12-14）」の日本語訳です。日本語訳は参考情報であって、公式な文書ではありません。また、翻訳に誤りがありえます。
訳者への連絡先、他の仕様の翻訳等については、Wikiを参照ください。
Accessible Rich Internet Applications (WAI-ARIA) 1.1 日本語訳 W3C Recommendation 14 December 2017出版以来の報告されたエラーや問題に対するエラッタを確認されたい。
翻訳も参照のこと【訳注：これは日本語非公式訳です】。
Copyright © 2013-2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
概要支援技術が障害をもつ人に対し適切な情報を伝えられるようにするために、ウェブコンテンツのアクセシビリティは、ウィジェット、構造、動作に関するセマンティック情報を要求する。この仕様は、アクセシブルなインターフェイスの要素を定義するロール、ステート、プロパティのオントロジーを提供するものであり、ウェブコンテンツやウェブアプリケーションのアクセシビリティと相互運用性を向上する目的で使用することができる。これらのセマンティクスは、文書レベルのマークアップにおいて著者がユーザーインターフェイスの動作と構造情報を支援技術に適切に伝えることができるよう設計されている。このバージョンは、[HTML5]と[SVG2]に対して一貫したアクセシビリティモデルを形成するために、支援技術との相互運用性を向上させるためにWAI-ARIA 1.0 [wai-aria-1.0]以降の新機能が追加される。この仕様は、[html5]と[SVG2]の両者を補完することが期待される。
この文書は、WAI-ARIA Overviewで説明されているWAI-ARIAスイートの一部と位置付けられている。
この文書の位置付けこの節は、公開時点におけるこの文書のステータスについて説明する。他の文書がこの文書に取って代わるかもしれない。W3Cが現在公開しているリストとテクニカルレポートの最新版は、W3C technical reports index at https://www.w3.org/TR/で見つけることができる。
この文書は、Accessible Rich Internet Applications Working GroupによるWAI-ARIA 1.1の W3C Recommendationである。Working Groupは、仕様が実装可能であることを実証するために WAI-ARIA 1.1実装レポートを作成した。WAI-ARIA 1.1への変更点の履歴は付録で利用可能である。
この文書にコメントするには、W3C ARIA GitHubリポジトリーに提出する。これを実行できない場合、public-aria@w3.org（コメントアーカイブ）にメールを送信する。WAI-ARIA 1.1勧告に寄せられたコメントは、この仕様のバージョンに変更をもたらすことはできないが、エラッタまたはWAI-ARIAの将来のバージョンで対処することができる。ワーキンググループは、コメントに正式な回答をすることはないが、ワーキンググループによって行われる将来の仕事は、この文書で寄せられたコメントに対処することができる。技術の進行中の更新は、公開エディターズドラフトで見ることができる。
この文書は、RecommendationとしてAccessible Rich Internet Applications Working Groupによって発行された。
Working Groupの実装レポートを参照されたい。
この文書は、W3Cのメンバー、ソフトウェア開発者、および他のW3Cグループや利害関係者によって検討され、W3C勧告としてディレクターによって承認されている。これは安定した文書であり、規範的仕様として使用されてもよく、他の文書から引用してもよい。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範な開発を促進することである。これはウェブの機能と相互運用性を強化する。
この文書は2004年2月6日のW3C特許ポリシーの下で活動するグループによって作成された。W3Cは、グループの成果物に関するあらゆる開示特許の公開リストを管理する。ここには、特許開示にあたっての指示も含まれている。特許について十分に知識のある人物が、仕様にEssential Claim(s)が認められると判断した場合は、W3C特許ポリシーの第6章に従い情報を開示する必要がある。
この文書は2017年3月1日のW3Cプロセス文書によって管理される。
(非表示)訳注：このWAI-ARIA 1.1の後続仕様として、WAI-ARIA 1.2が勧告されています。よって、この翻訳文書はメンテナンスしていません。
代わりに、WAI-ARIA 1.2日本語訳を参照してください。
目次この章は非規範的である。
この仕様の目的は以下を含む：
WAI-ARIAは、ウェブコンテンツおよびアプリケーションのアクセシビリティと相互運用性を改良するためのフレームワークを提供する技術仕様である。この文書は、カスタムウィジェットやその他のウェブアプリケーションコンポーネントを作成する開発者を主に対象とする。WAI-ARIAが解決しようとするアクセシビリティの問題を開発者に紹介するWAI-ARIA Authoring Practices [wai-aria-practices-1.1]のような、他の観客、基本的概念およびWAI-ARIAの技術的アプローチのための関連文書へのリンクは、WAI-ARIA Overviewを参照されたい。
このドラフトは、ロールの2つの側面、ユーザーインターフェイスの機能と構造の関係を目下処理する。詳細と使用例のための、インタラクティブコンテンツをアクセシブルにするロールの使用法については、[wai-aria-practices-1.1]を参照のこと。
ロールのタクソノミーは、プラットフォームのアクセシビリティAPIに見られる共通のロールをサポートするために、ある程度設計されている。動的なウェブコンテンツによって、このタクソノミーで見つかったロールへの参照は、支援技術との相互運用性をサポートするために使用してもよい。
この規格をサポートするためのスキーマは拡張可能であるように設計されているため、カスタムロールは基本ロールを拡張することによって作成できる。これは、ユーザーエージェントが少なくとも基本ロールをサポートすることを可能にし、かつカスタムロールをサポートするユーザーエージェントは、強化されたアクセスを提供できる。この多くは、[xmlschema-2]で形式化されうることに注意すること。しかし、baseConceptsおよびより記述的な定義のような、ロール間の類似性を定義できるということは、XSDで利用できないだろう。
WAI-ARIA 1.1は、WAI-ARIAおよび他のウェブコンテンツ言語をアクセシビリティAPIにセマンティクスを公開する方法を定義するWAI-ARIA 1.1スイートのメンバーである。
1.1 リッチ・インターネット・アプリケーション・アクセシビリティ§ウェブアクセシビリティの分野は、障害をもつ人にとってどのようにすればウェブコンテンツを利用可能にするかを定義する。ある種の障害をもつ人は、コンテンツを情報交換するために支援技術（AT）を使用する。支援技術は、ユーザーに対してより適したフォーマットにコンテンツの体裁を変換することができ、ユーザーがさまざまな方法で情報交換することを可能にする。たとえば、ユーザーはマウスをドラッグやドロップする代わりに、矢印キーでスライダーウィジェットと情報交換する必要または選択するかもしれない。効果的にこれを達成するために、ソフトウェアはコンテンツのセマンティクスを理解する必要がある。セマンティクスは意味の科学である。この場合、人間が理解するだろうユーザーインターフェイスとコンテンツ要素に適用するロール、ステート、およびプロパティを割り当てるために使用される。たとえば、ある段落が段落のようにセマンティックに識別される場合、支援技術は、その段落の正確な境界線を知ると、コンテンツの残りの部分から分けられる構成単位として情報交換できる。調整可能な範囲スライダーまたは折りたたみ可能リスト（別名ツリーウィジェット）は、ウィジェットのさまざまな部分が、効果的なふれ合いをサポートするために支援技術に対して適切に識別される必要があるセマンティクスを持つ、より複雑な例である。
新しい技術は、アクセシビリティに必要なセマンティクスをしばしば見落とし、しかも新しいオーサリング手法は、これらの技術の意図するセマンティクスをたびたび誤用する。言語において定義された意味を持つ要素が、ユーザーによって理解されるべきものとは異なる意味で使われている。
たとえば、ウェブアプリケーション開発者は、HTMLがセマンティックにtree要素を持たないにもかかわらず、CSSおよびJavaScriptを使用してHTMLで折りたたみ可能なツリーウィジェットを作成する。障害のないユーザーにとって、これは折りたたみ可能なツリーウィジェットのように見えてかつ動作するかもしれないが、適切なセマンティクスをもたず、支援技術がロールを認識しないかもしれないため、ツリーウィジェットは、障害をもつ人によって知覚可能または操作可能でないかもしれない。同様に、ウェブアプリケーション開発者は、SVGがセマンティックなbutton要素を持たないにもかかわらず、JavaScriptを使用するSVGでインタラクティブなボタンウィジェットを作成する。障害のないユーザーにとって、これはボタンウィジェットのように見えてかつ動作するかもしれないが、適切なセマンティクスをもたず、支援技術がロールを認識しないかもしれないため、ボタンウィジェットは、障害をもつ人によって知覚可能または操作可能でないかもしれない。
WAI-ARIAの組み込みは、ウィジェットをアクセシブルで、使いやすく、支援技術と相互運用できるようにするために、著者がカスタムウィジェットに適切なセマンティクスを提供する方法の一つである。この仕様は、コンテンツに付けられるロールのオントロジーを提供することによって、アクセシビリティ製品が一般に認識するウィジェットおよび構造のタイプを識別する。これは、与えられたロールをもつ要素が、実装するホスト言語から継承された任意のセマンティクスに関係なく、特定のウィジェットまたは構造タイプとして理解できる。ロールは、支援技術が有効な見栄えと対話をユーザーに提供するために使用する、プラットフォームのアクセシビリティAPIの共通のプロパティである。
このロールタクソノミーは、文書構造を示すインタラクションウィジェットおよび要素を含む。ロールタクソノミーは、継承および各ロールがサポートする属性の詳細を説明する。アクセシビリティAPIへのロールのマッピングに関する情報は、Core Accessibility API Mappings 1.1 [core-aam-1.1]によって提供される。
ロールは要素タイプであり、時間またはユーザーアクションとともに変化しない。ロール情報は、指定された要素タイプの通常の処理を提供するために、ユーザーエージェントとの情報交換を経由して、支援技術によって使用される。
ステートおよびプロパティは、対話に影響および説明する要素の重要な属性を宣言するために使用される。属性がクライアントサイドのスクリプトによって動的に変更される場合でも、ステートおよびプロパティはユーザーエージェントおよびオペレーティングシステムに適切に要素を処理することを可能にする。たとえば、スクリーンリーダーや音声ディクテーションソフトウェアなどの代替入出力技術は、ユーザーに様々な情報交換の状態（無効、チェックなど）を認識し、効果的に操作しかつ通信できるようにする必要がある。
支援技術が文書オブジェクトモデル [dom]を介してこれらのプロパティに直接アクセスすることは可能である一方、ユーザーエージェントにとって好ましいメカニズムは、オペレーティングシステムのアクセシビリティAPIに対してステートおよびプロパティを対応づけることである。詳細についてはCore Accessibility API Mappings 1.1 [core-aam-1.1]およびAccessible Name and Description: Computation and API Mappings 1.1 [accname-aam-1.1]を参照のこと。
図1は、ユーザーエージェント（ブラウザーなど）、アクセシビリティAPI、および支援技術との関係を示している。図は、GUIのための多くのアクセシブルなプラットフォームに対するアクセシビリティAPIに見られる典型的なアクセシビリティ情報（ロール、ステート、選択、イベント通知、関係情報、および説明）を含む、ユーザーエージェントによって支援技術に提供される"規約"を説明する。通常HTMLであるDOMは、データモデルおよび典型的なモデル - ビュー - コントローラ関係でビューとして機能し、そしてJavaScriptは、表示されたデータのスタイルおよびコンテンツを操作することでコントローラーとして機能する。ユーザーエージェントは、スクリーンリーダーなどの任意の支援技術によって使用できる、オペレーティングシステムのアクセシビリティAPIに関連する情報を伝える。
図1：アクセシビリティAPIをもつ規約モデル
インタラクティブなコンテンツをアクセシブルにするためのロールの使用方法について詳細は、WAI-ARIA Authoring Practices [wai-aria-practices-1.1]を参照のこと。
文書に加えて、ロールタクソノミーは、Resource Description Framework (RDF) [rdf-concepts]で表現されるWeb Ontology Language (OWL) [owl-features]で提供される。ツールは、指定したコンテンツ文書でロールの実装を検証するためにこれらを使用できる。たとえば、いくつかのロールのインスタンスは、特定の親ロールの子となることが期待される。また、いくつかのロールは、別のロールがサポートしない特定のステートまたはプロパティをサポートするかもしれない。
注
将来の拡張性をサポートするためにRDF/OWLをロールの正式な表現として使用するかもしれない。標準RDF/OWLのメカニズムは、この仕様で定義されたロールから継承する新しいロールを定義するために使用することができる。ただし、相互運用可能な方法でロールの拡張を定義しかつ使用するためのメカニズムは、この仕様で定義されず、RDF/OWL処理はこの仕様の相互運用可能な実装に不可欠ではない。将来のWAI-ARIAのバージョンは、ロールを拡張するための方法を定義することが期待される。
代替入力デバイスのユーザーは、キーボードアクセシブルコンテンツを必要とする。WAI-ARIA Authoring Practices [wai-aria-practices-1.1]で提供される推奨キーボード情報交換と組み合わされる場合、新しいセマンティクスは、代替入力ソリューションが代替入力ソリューションを通してコマンドおよびコントロールを容易にする。
WAI-ARIAは、改良されたキーボードナビゲーションを提供することによって、運動機能および視力障害をもつ人を助けることができる、ランドマークのタクソノミーおよびXHTMLロールランドマークを通じてナビゲーションランドマークを導入する。WAI-ARIAはまた、認知学習障害をもつ人を支援するために使用されるかもしれない。追加のセマンティクスは、必要に応じて著者が代替コンテンツを再構築および代用できる。
支援技術は、ウィジェットのステートおよびプロパティの現在値を取得および設定することにより、代替入力をサポートする機能を必要とする。支援技術はまた、どのオブジェクトがリストボックスやグリッドなど複数の選択を許可するウィジェットを選択されて管理するかを判断する必要がある。
音声ベースのコマンドおよび制御システムは、ユーザーに音声情報を伝達するのに役立つrole属性のような、WAI-ARIAセマンティクスの恩恵を受けることができる。たとえば、異なるフレーバーを表すテキストコンテンツをそれぞれ含むロールmenuitemの子要素をもつmenuのロールを伴う要素と遭遇するとき、音声システムは「次の3つの選択肢のいずれかを選択してください。チョコレート、ストロベリー、バニラ。」とユーザーに言うかもしれない。
WAI-ARIAは、ネイティヴ言語のセマンティクスに対する代替としてでなく、補足として使用されることを意図する。ホスト言語がWAI-ARIAの機能に相当するアクセシビリティを提供して機能を提供する場合、ホスト言語の機能を使用する。WAI-ARIAは、ホスト言語が必要なロール、ステート、およびプロパティインジケーターを欠いている場合にのみ使用すべきである。WAI-ARIAの機能にできるだけ類似したホスト言語の機能を使用し、WAI-ARIAを追加することで意味を洗練する。たとえば、選択可能なマルチグリッドはテーブルとして実装することできるかもしれず、その上WAI-ARIAは、単なる静的なデータテーブルでなく、対話型グリッドであることを明確にするために使用する。これは、WAI-ARIAをサポートしないユーザーエージェントのために可能な限り最良のフォールバックを可能にし、ホスト言語のセマンティクスの完全性を維持する。
1.2 対象読者§この仕様は、ロール、ステート、プロパティ、および値を含む、WAI-ARIAのための基本的なモデルを定義する。この仕様が影響を与える複数の読者は次の通り：
各適合性要件は、要件が適用される読者を示す。
この仕様は上記の読者に適用可能ではあるが、これは特に対象を定めるものではなく、上記の読者のいずれかのための独占的な情報源であることを意図しない。以下の文書が重要なサポート情報を提供する：
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は、[html5]や[SVG2]などの言語をサポートするものの中でセマンティクスを補強するためのもの、または明示的にARIAのサポートを含まない他のマークアップベースの言語で、アクセシビリティ拡張技術として使用される。オブジェクトの新しい種類の発明はウェブ言語で表示する標準化されたサポートよりも高速であるため、スタイルやスクリプト経由で、ページの言語でまだ直接サポートされない、著者がオブジェクトの新しい種類を作成する際、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およびSVGにおいて、tabindexは、ブラウザーがWAI-ARIAの実装に対してキーボードのフォーカスナビゲーションをサポートする重要な手段である。オーサリングツールおよびデバッグツールはtabindex値が適切に設定されていることを確認するためにチェックしてもよい。たとえば、エラー条件は、ツリーで1つ以上のツリー項目が0以上のtabindex値である場合、tabindexがどのツリー項目にも設定されない場合、またはロールツリーを伴う要素が0以上のtabindex値を持つ際にaria-activedescendantが定義されない場合を含むかもしれない。
インタラクティブコンテンツのアクセシビリティは、静的なチェックだけで確認できない。インタラクティブコンテンツの開発者は、ウィジェットやアプリケーションにデバイスに依存しないアクセスのためにテストすべきであり、ユーザーと情報交換中にすべてのコンテンツと変更へのアクセシビリティAPIへのアクセスを確認すべきである。
1.6 支援技術§アクセシビリティセマンティクスへのプログラムアクセスが支援技術に不可欠である。ほとんどの支援技術は、認識されたアクセシビリティAPIを通じて、他のアプリケーションと同様に、ユーザーエージェントと情報交換する。ユーザーインターフェイスで知覚可能なオブジェクトは、アクセシビリティAPIインターフェイスで定義されたアクセシブルオブジェクトとして支援技術に公開される。これを適切に行うために、アクセシビリティ情報―ロール、ステート、プロパティならびに文脈情報―は、アクセシビリティAPIを通じて支援技術に正確に伝える必要がある。状態変化が発生した場合、ユーザーエージェントはアクセシビリティAPIに適切なイベント通知を提供する。HTMLのような多くのホスト言語で、コンテキスト情報は、文脈ツリー階層を提供するので、DOM自体から決定できる。
一部の支援技術はこれらアクセシビリティAPIと情報交換する一方で、他は、DOMから直接コンテンツにアクセスできる。これらの技術は、異なるユーザー集合を助けるために、コンテンツを再構築、簡素化、スタイル付け、またはリフローできる。この適応タイプに対する一般的なユースケースは、高齢化、認知障害のある人、またはそのツールの使用を妨害する環境にいる人かもしれない。たとえば、地域のナビゲーションランドマークの可用性は、そのセマンティクスに基づいて、一度にコンテンツの一部のみを表示するモバイルデバイスへの適応を可能にする。これは、ユーザーが一度に処理するために必要な情報量を減らすことができる。他の状況において、キーボードまたはタッチスクリーンデバイスを使ってナビゲートしやすいものをもつカスタムユーザーインターフェイスコントロールを置き換えるために適切かもしれない。
2. WAI-ARIAを使用する§この章は非規範的である。
支援技術が、文書の一部の後ろにあるセマンティクスを決定できない場合、またはユーザーが効果的に使用可能な方法で文書のすべての部分に移動できない場合、複雑なウェブアプリケーションはアクセシブルでなくなる（WAI-ARIA Authoring Practices [wai-aria-practices-1.1]を参照）。WAI-ARIAは、セマンティクスをロール（ユーザーインターフェイス要素を定義する種類）と、ロールでサポートされるステートおよびプロパティに分割する。
著者は、要素がすでにステートおよびプロパティに適切な暗黙のWAI-ARIAセマンティクスを持たない限り、ライフサイクルの間に、WAI-ARIAロールおよび適切なステートおよびプロパティ（aria-*属性）に文書内の要素を関連付ける必要がある。ロール属性は、ホスト言語要素の暗黙的なロールよりも優先されると同時に、このような場合において同等のホスト言語のステートおよびプロパティは、競合を避けるために優先される。
2.1 WAI-ARIAロール§WAI-ARIAロールは、Role Attributeで定義されるrole属性と類似の、role属性を使用する要素上で設定される[role-attribute]。
例1
<li role="menuitem">Open file…</li>
この仕様で定義されるロールは、文書ランドマークおよびWAI-ARIAロールタクソノミーを含む。
このタクソノミーおよびその期待される動作におけるロールは、RDF/OWLを用いてモデル化される[owl-features]。ロールタクソノミーの機能は、各ロールに対して以下の情報を提供する：
directoryはlistの一種である）listitemはlistの内部に含まれる）checkboxはaria-checkedによってチェックされるものをサポートする）付随するロールは、支援技術に各要素を扱うための方法に関する情報を与える。
2.2 WAI-ARIAステートおよびプロパティ§WAI-ARIAは、さまざまなOSプラットフォーム上のプラットフォームのアクセシビリティAPIをサポートするために使用されるステートおよびプロパティ一式を提供する。支援技術は、公開されたユーザーエージェントのDOMを通して、またはプラットフォームのアクセシビリティAPIへのマッピングを通して、この情報にアクセスしてもよい。ロールと組み合わせる場合、ユーザーエージェントは、いつでもユーザーに伝えるためのユーザーインターフェイス情報を支援技術に提供することができる。ステートまたはプロパティの変化は、支援技術に通知をもたらす。これは、変更が発生したことをユーザーに通知するかもしれない。
以下の例において、リスト項目（html:li）がチェック可能なメニュー項目を作成するために使用されており、JavaScriptのイベントがaria-checkedの値を切り替えるためにマウスおよびキーボードのイベントを取り込む。ロールは、この単純なウィジェットの動作をユーザーエージェントに知らせるために使用される。ユーザーアクションとともに変化する属性（aria-checkedなど）は、ステートおよびプロパティの節で定義される。
例2
<li role="menuitemcheckbox" aria-checked="true">Sort by Last Modified</li>
管理されたステートと呼ばれる一部のアクセシビリティステートは、ユーザーエージェントによって制御される。管理されたステートの例は、キーボードフォーカスおよび選択を含む。管理されたステートは多くの場合、スタイルの変更を定義するために対応するCSS擬似クラス（:focusや::selectionなど）を持つ。対照的に、この仕様におけるステートは一般に著者によって制御され、管理されないステートと呼ばれる。aria-posinsetおよびaria-setsizeのような一部のステートは、ユーザーエージェントによって管理されるが、DOMが完全でなくかつユーザーエージェントの計算に誤りをもたらす場合、著者はステートを上書きすることができる。ユーザーエージェントは、管理されたステートと管理されないステートの両方をプラットフォームアクセシビリティAPIにマッピングする。
ほとんどのモダンなユーザーエージェントは、CSS属性セレクター（[css3-selectors]）をサポートし、同等の機能を実現するのに必要なスクリプトの量を減らす、WAI-ARIA属性情報に基づくUIの変更を著者に作成できるようにする。次の例において、CSSセレクターは、aria-checked属性値に基づき、テキストが太字でありかつチェックマークの画像が表示されるかどうかを決定するために使用される。
例3
[aria-checked="true"] { font-weight: bold; }
[aria-checked="true"]::before { background-image: url(checked.gif); }
CSSがチェックマークの視覚的表現を切り替えるために使用されない場合、著者はmenuitemcheckboxがチェックされてるかどうかを示す画像を管理するために追加のマークアップおよびスクリプトを含めるかもしれない。
例4
<li role="menuitemcheckbox" aria-checked="true"> <img src="checked.gif" role="presentation" alt=""> Sort by Last Modified </li>2.3 フォーカスの管理 §
アプリケーションがユーザー入力を提供する場所をユーザーに要求するため、applicationは、使用時にフォーカスをともなう要素を常に持つべきである。著者は、ユーザー操作でない限り、フォーカスをもつ要素を破壊または画面外にスクロールしないことを勧める。すべてのインタラクティブオブジェクトはフォーカス可能になるべきである。複合インタラクティブコントロールあらゆる部分は、キーボードショートカットのような、フォーカス可能であるか、またはコントロールの機能を達成するための文書化された別の方法を持つ必要がある。任意のインタラクティブ要素にフォーカスを移動するためにキーボードのユーザーに対して、著者は、タブ移動または他の標準的なナビゲーション技術のいずれかを通して、明白な、検出可能な方法を維持することを勧める。User Agent Accessibility Guidelines、ガイドライン9（[UAAG10]、ガイドライン9）を参照のこと。
標準的なHTMLおよび基本的なWAI-ARIAウィジェットを使用する場合、アプリケーション開発者は、単純にタブ順序を操作したり、文書における要素にキーボードショートカットを作成するためにスクリプトを使用したりすることができる。より複雑なウィジェットの使用は、著者がそのウィジェット内でフォーカスを管理する必要がある。SVG Tinyは、デフォルトで文書の順序に従い、かつシステム依存入力機能（ほとんどのデスクトップコンピュータ上でTABキー）を使用して実装されるべき類似のナビゲーション"リング"メカニズムを提供する。SVGの著者は、フォーカス可能な属性を操作することでナビゲーション順序において要素を置いてもよく、著者が要素のナビゲーション属性を変更することで動的にナビゲーション順序を指定してもよい。
WAI-ARIAは、"コンポジット"ウィジェットとしても知られる、多数の"管理コンテナー"ウィジェットを含む。適切な場合、コンテナーはアクティブであった最後の子孫を追跡する責任がある（デフォルトは通常コンテナーにおける最初の項目である）。フォーカスがコンテナーを残してかつ、後で再びフォーカスされる場合、コンテナーが使用可能で一貫性のある戦略を維持することが不可欠である。例外が存在してもよい一方で、以前にフォーカスされたコンテナーが再びフォーカスされる場合、コンテナーが最後にフォーカスされた際にアクティブな子孫と同じ子孫をアクティブにすることが推奨される。例外は、コンテナーウィジェットのコンテンツが変更されている場合、およびフォーカスがメニューバーに残る際に、ユーザーが常に最初の項目に戻ることを期待する場合にメニューバーのようなウィジェットを含む。たとえば、ユーザーがツリーグループから外へタブを使った際にツリーグループの2つ目の項目がアクティブであった場合、ツリーグループに再びフォーカスを持つ際にその2つ目の項目がアクティブな子孫となる。ユーザーはまた、コンテナー内のいずれかの子孫をクリックすることによってそのコンテナーをアクティブにしてもよい。
コンテナーまたはコンテナーのアクティブな子孫がフォーカスを持つ場合、ユーザーは、現在のアクティブな子孫を変更するために矢印キーのような追加キーを押すことでコンテナーをナビゲーションしてもよい。メインナビゲーションキー（一般にTabキー）をさらに押すと、コンテナーから抜け出して次のウィジェットへ移動する。
たとえば、grid（全部が一度に文書で存在しなくてもよい）は、何千ものgridcell要素をもつスプレッドシートとして使用されてもよい。これは、フォーカスが、管理コンテナー要素上のaria-activedescendant属性を使用するコンテナーによって管理される、またはその子要素のtabindexを管理しかつ適切な子にフォーカスを設定するコンテナーによって管理される必要がある。
コンテンツ著者は、次のコンテナーのロールでフォーカスを管理することが必須となる：
フォーカスの管理の詳細については、WAI-ARIA Authoring Practices [wai-aria-practices-1.1]のDeveloping a Keyboard Interfaceのセクションを参照のこと。
3. 適合性§非規範的とマークとしてマークされる章と同様に、この仕様のすべてのオーサリングガイドライン、図、例、およびノートは非規範的である。この仕様における他のすべては規範的である。
キーワードMAY、MUST、MUST NOT、SHOULD、SHOULD NOTは、[RFC2119]で示されるとおりに解釈される。
この仕様は、ある章が規範的または参考情報であるかどうかを表示する。規範的または参考情報としての章の分類は、章全体に適用される。文「この章は規範的である」または「この章は参考情報である」は、その章のすべての節に適用される。
規範的な章は、著者、ユーザーエージェント、および支援技術がこの仕様に準拠するように実装するために従わなければならない要件を規定する。
参考情報の章は、この仕様を理解するのに有益な情報を提供する。そのような章は、推奨されるプラクティスの例を含むかもしれないが、この仕様に適合するためにそのような推奨に従うことを必要としない。
3.1 ホスト言語非干渉§ユーザーエージェントによるWAI-ARIAの処理は、ホスト言語の組み込み機能の正常な動作を妨害してはならない。
CSSセレクターがWAI-ARIA属性を含む場合（たとえば、input[aria-invalid="true"]）、ユーザーエージェントは、属性がいつでもDOMで追加、変更、除去されるセレクターに一致する（または、もはや一致しない）任意の要素の視覚的な表示を更新しなければならない。ユーザーエージェントは、ホスト言語機能のマッピングをアクセシビリティAPIに変更してもよいが、ユーザーエージェントは、ホスト言語機能にWAI-ARIAマークアップを再マッピングするために、DOMを変更してはならない。
W3C DOM仕様に適合しないドキュメントオブジェクトモデルを実装する適合ユーザーエージェントは、処理はどのように要素がアクセシビリティAPIに公開されるかに影響するにもかかわらず、著者によって指定されるようなDOMにおけるWAI-ARIAステートおよびプロパティだけでなく、ロール属性と属性のWAI-ARIAロール値に対するコンテンツ属性も含まなければならない。そうすることで、各ロール属性および、その値を含むすべてのWAI-ARIAステートおよびプロパティは、変更されない形式で文書において存在することを保証し、結果として支援技術などの他のツールがそれらにアクセスすることができる。適合W3C DOMはこの基準を満たす。
3.3 ウェブアプリケーションに伝えられる支援技術の通知§音声認識システムおよび運動障害をもつユーザーのための代替入力デバイスのような支援技術は、デバイスに依存しない方法でウェブアプリケーションを制御する能力を必要とする。WAI-ARIAステートおよびプロパティは、リッチインターネットアプリケーションコンポーネントの現在の状態を反映する。ウェブアプリケーションは、これら代替入力ソリューションをユーザーが効果的に直接制御することができない標準入力デバイスに依存せずにアプリケーションを制御することを可能にするため、必要な変更をウェブアプリケーションに通知する支援技術のための能力が不可欠である。
ユーザーエージェントは、変更がシステムアクセシビリティAPIにおけるステートまたはプロパティに発生する際に、ウェブアプリケーションに通知する方法を提供しなければならない。同様に、ユーザーエージェントまたは支援技術からの変更要求を通知する場合、ウェブアプリケーションの著者は、それに応じて、ウェブアプリケーションを更新すべきである。
注
多くのステートおよびプロパティは、デフォルトのアクションイベントに応答することによって、既存のアクセシビリティAPIを通じて支援技術で変更することができる。たとえば、tabpanelにおけるtabのaria-selectedステートは、要素のデフォルトのアクションをトリガーすることによって変更することができる。
任意のアプリケーションまたはスクリプトの文書検証の適合性や妥当性は、この仕様で規範的な著者の要件のすべてに対して試験を含むべきである。与えられた要件のための試験の場合、適合性チェッカーは、著者が"MUST"要件が満たされない場合はエラーを発行しなければならず、かつ著者"SHOULD"要件が満たされない場合に警告を発行しなければならない。
3.5 非推奨の要件 §技術の進化により、以前に定義された機能よりもよりよい動作をする、ユースケースを満たすための新しい方法が時には利用可能になる。しかし、先行した機能の既存の実装のため、その機能は、以前の適合コンテンツをレンダリングすることなく、適合モデルから削除することはできない。この場合、古い機能は"deprecated"（非推奨）としてマークされる。これは、その機能が適合モデルで許可され、ユーザーエージェントによってサポートされることが期待されるが、著者が新しいコンテンツにその機能を使用しないことが勧められることを示す。仕様の将来のバージョンにおいて、機能がもはや広く使用されない場合、その機能は削除され、もはやユーザーエージェントによってサポートされることが期待できないだろう。
4. 重要な用語§この章は非規範的である。
一部の用語は適当な位置に定義されるが、以下の定義は、この文書全体で使用される。
オペレーティングシステムおよびその他のプラットフォームは、支援技術にオブジェクトおよびイベントに関する情報を公開する一連のインターフェイスを提供する。支援技術は、情報を取得し、それらのウィジェットと対話するためにこれらのインターフェイスを使用する。アクセシビリティAPIの例は、Microsoft Active Accessibility [MSAA]、Microsoft User Interface Automation [UI-AUTOMATION]、MSAA with UIA Express [UIA-EXPRESS]、Mac OS X Accessibility Protocol [AXAPI]、Linux/Unix Accessibility Toolkit [ATK]およびAssistive Technology Service Provider Interface [AT-SPI]、IAccessible2 [IAccessible2]である。
アクセシブルな説明は、インターフェイス要素に関連する、アクセシブルな名前を補完する追加情報を提供する。アクセシブルな説明は、視覚的に知覚されるかもしれないし、されないかもしれない。
アクセシブルな名前は、ユーザーインターフェイス要素の名前である。各プラットフォームのアクセシビリティAPIは、アクセシブルな名前プロパティを提供する。アクセシブルな名前の値は、可視（たとえば、ボタンの可視テキスト）またはユーザーインターフェイス要素の不可視（たとえば、アイコンを説明する代替テキスト）プロパティから得られるかもしれない。関連するアクセシブルな説明を参照のこと。
アクセシブルな名前プロパティに対する簡単な用法は、"OK"ボタンによって説明することができる。テキスト"OK"は、アクセシブルな名前である。ボタンがフォーカスを受け取る場合、支援技術は、アクセシブル名前をもつプラットフォームのロールの説明を連結できる。たとえば、スクリーンリーダーは、"押しボタンOK"または"OKボタン"を話すことができる。連結の順序および役割の説明の詳細（たとえば"ボタン"、"押しボタン"、"クリック可能ボタン"）は、プラットフォームアクセシビリティAPIまたは支援技術によって決定される。
ハードウェアおよび/またはソフトウェアは：
この定義は他の文書で使用したものと異なるかもしれない。
この文書のコンテキストにおいて重要である支援技術の例としては次のものを含む：
この仕様において、属性は、マークアップ言語における属性として使用される。属性は、要素によって表されるオブジェクトのステートおよびプロパティに関する情報を提供するために要素に追加される構造的特徴である。
類似の特性を共有する一連のインスタンスオブジェクト。
非推奨のロール、ステートまたはプロパティは、新しい構築物または変更状況によって時代遅れされており、かつWAI-ARIA仕様の将来のバージョンで削除されるかもしれないものである。ユーザーエージェントは、下位互換性のために非推奨として識別される項目のサポートを継続することを勧める。詳細については、適合性セクションの非推奨要件を参照のこと。
この仕様において、要素は、マークアップ言語における要素として使用される。要素は、オブジェクトに対するデータプロファイルを含むマークアップ言語における構成要素である。
コンピュータシステムにおける他のオブジェクトにオブジェクトのステートで個別の変化を通信するために使用されるプログラムのメッセージ。ウェブページへのユーザー入力は、相互作用を記述する抽象イベントを介して一般的に媒介され、ドキュメントオブジェクトのステートの変化の通知を提供することができる。一部のプログラミング言語において、イベントは、通知としてより一般的には知られる。
ユーザーナビゲート可能な部分をもつグラフィック表現を含む文書。グラフ、地図、図表、設計図、およびダッシュボードは、グラフィカルな文書の例である。グラフィカルな文書は、記号、画像、テキスト、および基本図形（円、点、線、軌道、矩形などの図形）の任意の組み合わせを使用して構成される。
要素がすべてのユーザーに可視、知覚可能またはインタラクティブでないことを示す。要素またはいずれかのその祖先要素がレンダリングされないか明示的に隠される場合、要素は非表示と考えられる。
情報目的で提供されかつ適合のために必須でないコンテンツ。適合するために必要なコンテンツは、規範的と呼ばれる。
キーボードまたは、息操作チューブのようなキーボード入力を模倣する支援技術を使用するユーザーにアクセシブルなもの。この文書における参照は、WCAG 2.0ガイドライン 2.1：キーボード操作可能: すべての機能をキーボードから利用できるようにするに関連する[WCAG20]。
ユーザーがすばやくアクセスしたいかもしれないページ上の領域の種類。そのような領域におけるコンテンツは、主要なコンテンツのナビゲート、検索および熟読のような、ページ上の他の領域のそれと異なり、かつ特定のユーザーの目的と関連する。
ライブ領域は、ユーザーフォーカスが別の場所にあるかもしれない場合、一般に、外部イベントの結果として更新されるウェブページの知覚領域である。この領域は、必ずしもユーザーの相互作用の結果として更新されるとは限らない。この慣習は、Ajax利用の増加で一般的になっている。ライブ領域の例は、チャットログ、株価表示機、またはゲームの統計を反映するために定期的に更新するスポーツのスコアリングセクションを含む。これらの非同期の領域はユーザーのフォーカス領域の外側で更新することが期待されるので、スクリーンリーダーなどの支援技術は、どちらかその存在に気づかないか、ユーザーに対して領域を処理することができないかのいずれかである。WAI-ARIAは、著者がこれらライブ領域を識別することおよび処理することを可能にするプロパティのコレクションを提供している：aria-live、aria-relevant、aria-atomicおよびaria-busy。
フォーカスや選択のような、ユーザーエージェントによって制御されるアクセシビリティAPIステート。これは、一般に著者によって制御される"非管理ステート"と対比される。それにもかかわらず、著者は、aria-posinsetおよびaria-setsizeのような一部の管理されたステートを上書きすることができる。多くの管理されたステートは、:focusなどの対応するCSS擬似クラス、および::selectionなどの対応するCSS疑似要素を持つ。
数式のためのネメス点字コードは、数学および科学表記を符号化するための点字コードである。WikipediaのNemeth Brailleを参照のこと。
適合のために必要とされるもの。対照的に、参考情報または"非規範"として識別されるコンテンツは、適合のために必要とされない。
ユーザーインターフェイスのコンテキストで、1つ以上の要素によってマークアップ言語で表現され、ユーザーエージェントによってレンダリングされる、知覚的ユーザーエクスペリエンスの項目。
プログラミングのコンテキストで、1つ以上のクラスおよび同様のオブジェクトの一般的な特性を定義するインターフェイスのインスタンス。アクセシビリティAPIにおけるオブジェクトは、1つ以上のDOMオブジェクトを表すことができる。アクセシビリティAPIは、DOMインターフェイスと区別されるインターフェイスを定義している。クラスの特徴の説明およびどのようにクラスが互いに関連するか。
ユーザーが制御することができる方法でユーザーが使用可能なもの。この文書における参照は、WCAG 2.0原則2：コンテンツは操作可能でなければならないに関連する[WCAG20]。キーボードアクセシブルを参照のこと。
'所有される要素'は、要素の任意のDOM子孫、aria-owns経由で子として指定される任意の要素、または所有する子の任意のDOM子孫である。
ユーザーが感じることができる方法でユーザーに提示可能なもの。この文書における参照はWCAG 2.0原則1：コンテンツは知覚可能でなければならないに関連する。[WCAG20]
指定されたオブジェクトの性質に不可欠である、またはオブジェクトに関連付けられたデータ値を表す属性。プロパティの変化は、オブジェクトの意味または見栄えに著しい影響を与えるかもしれない。特定のプロパティ（たとえば、aria-multiline）は、ステートを変更する可能性がより低いが、変更差分の周期は原則でないことに注意する。aria-activedescendant、aria-valuenow、およびaria-valuetextのような少数のプロパティは、頻繁に変更することが期待される。ステート対プロパティの明確化を参照のこと。
2つの別なものの間の関係。関係は、オブジェクトがもう1つのオブジェクトを分類したり制御したりすることを示すような、様々な種類であってもよい。
種類の主な指標。 このセマンティックな関連付けはツールが存在してもよく、その種類の他のオブジェクトに関するユーザーの期待と一致する方法でオブジェクトとの相互作用をサポートしてもよい。
コンピューターが要素および属性などのオブジェクトの表現を処理し、かつさまざまな人間がオブジェクトの一貫した理解を相互に達成するような方法でオブジェクトを確実に表現できるような方法で定義される、人間によって理解されるようなものの意味。
ステートは、ユーザーのふるまいまたは自動化プロセスに応じて変更することができるオブジェクトの特性を表現する動的なプロパティである。ステートは、オブジェクトの本質的な性質に影響を与えないが、オブジェクトまたはユーザーインタラクションの可能性に関連したデータを表す。プロパティに対するステートの明確化を参照のこと。
階層においてクラスがスーパークラスのプロパティを継承する、どのようにさまざまなクラスの特性が互いに関係するかの階層的な定義。タクソノミーは、オントロジーの形式的な定義の一部を構成することができる。
ユーザーが適切な意味を構築することができる方法で提示可能なもの。この文書の参照は、WCAG 2.0原則3：情報およびユーザーインターフェイスの動作は理解可能でなければならないに関連する。[WCAG21]
ウェブコンテンツとのエンドユーザーのやりとりを引き出し、レンダリングしかつ容易にする任意のソフトウェア。この定義は他の文書で使用したものと異なるかもしれない。
ユーザーが対話することができる個別のユーザーインターフェイスオブジェクト。ウィジェットは、1つの値または操作（たとえば、ボックスやメニュー項目をチェックする）を持つ単純なオブジェクトから、多数の管理されたサブオブジェクト（たとえば、ツリーやグリッド）を含む複雑なオブジェクトへと多岐にわたる。
この節は、WAI-ARIAロールタクソノミーを定義し、すべてのロールの特性およびプロパティを説明する。ここで提示されるすべての情報の正式なRDF/OWL表現は、スキーマ付録で利用可能である。
ロール、ロールの特性、ロールがサポートするステートおよびプロパティ、およびどのようにロールがマークアップで使用されてもよいかの仕様は、規範的なものとみなすものとする。タクソノミーをモデル化するために使用されるRDF/OWL表現は、参考情報とみなされるものとする。RDF/OWLタクソノミーは、将来的にWAI-ARIAを拡張するための媒体として、またはこの仕様によってロールに適用できるステートおよびプロパティを検証するためのツールのメーカーによって使用されるかもしれない。
ロールは、要素タイプでありかつ、著者は、時間の経過またはユーザーアクションとともにロール値を変えてはならない。ロールを変更することを望む著者は、関連する要素とその子を削除し、かつ適切なロールをもつ新しい要素に置き換えることによってそうしなければならない。一般的に、プラットフォームアクセシビリティAPIは、ロール値変化の支援技術に通知するための手段を提供せず、その結果、支援技術は、新しいロール属性値をもつ支援技術のキャッシュを更新しないかもしれない。
DOMにおけるコンテンツを反映させるために、ユーザーエージェントは、実装されるアクセシビリティAPIで適切な値にロール属性を対応づけるべきであり、ロール属性を変更する場合にユーザーエージェントは、対応づけを更新すべきである。
5.1 概念間の関係§ロールタクソノミーは、WAI-ARIAロール間同士およびHTMLやXFormsなどの、他の仕様からの概念との関係を示すために以下の関係を使用する。
5.1.1 スーパークラスロール§継承は、RDFスキーマ1.1 subClassOf ([rdf-schema]) プロパティを使用するRDFで表現される。
現在のサブクラス化されたロールがタクソノミーに拡張するロール。この拡張は、すべてのプロパティおよびスーパークラスのロールの制約にサブクラスのロールを伝搬させる。よく知られている安定した仕様以外、継承はこの仕様の中で定義された項目に制限され、その結果外部項目を変更できないようにして継承されたクラスに影響を与えることができる。
5.1.2 サブクラスロール§このロールがスーパークラスであるためにロールの有益なリスト。これは、仕様の読みやすくするために提供されるが、新しい情報を追加しない。
5.1.4 ベース概念§ロールのプロトタイプと見なされるオブジェクトに関する有益なデータ。ベース概念はタイプに似ているが、制限およびプロパティの継承はない。ベース概念は、外部の概念の継承に代わるものとして設計されている。ベース概念は、ロール定義とほぼ同一であることを除いて、関連する概念に似たものである。
たとえば、この文書で定義されるcheckboxは、HTMLで定義されるチェックボックスに似た機能および予想される挙動を持つ。したがって、checkboxはbaseConceptとしてHTML checkboxを持つ。しかし、元のHTMLチェックボックスbaseConcept定義が変更された場合、各タイプの実際の継承はないため、この文書におけるcheckboxの定義は影響を受けない。
ロールは、ロールの特性によって定義および説明される。特性は、ロールがどのようなものかのような、ロールの構造上の機能、ロールの背後にある概念、およびロールが含むことができるまたは必要があるインスタンスを定義する。ウィジェットの場合、これはまた、ウィジェットがどのようにHTMLフォームおよびXFormsへの対応づけに基づいたユーザーエージェントと対話するかを含む。ロールによってサポートされるWAI-ARIAからのステートおよびプロパティも示される。
ロールタクソノミーは、次のような特性を定義する。この特性は、ロールを記述するOWLクラスのプロパティとしてRDFに実装されている。
5.2.1 抽象ロール§抽象ロールは、他のすべてのWAI-ARIAロールが構築される基盤である。このロールはAPIバインディングで実装されていないため、コンテンツ著者は、抽象ロールを使用してはならない。ユーザーエージェントは、アクセシビリティAPIの標準ロール機構に抽象ロールを対応づけてはならない。抽象ロールは、以下を助けるために提供される：
ロールおよびサブクラスロールのために具体的に必要とされるステートおよびプロパティ。コンテンツ著者は、必要とされるステートおよびプロパティに対して値を提供しなければならない。コンテンツ著者は、undefinedがそのステートまたはプロパティの明示的にサポートされた値でない限り、必要とされるステートおよびプロパティに対して値undefinedを使用してはならない。
オブジェクトが複数の先祖から継承され、ある祖先がプロパティがサポートされることを示す一方で、別の祖先がそのプロパティが必須であることを示す場合、プロパティは継承オブジェクトで必須である。
5.2.3 サポートされるステートおよびプロパティ§ロールおよび子ロールに具体的に適用できるステートおよびプロパティ。ユーザーエージェントは、アクセシビリティAPIにロールに対してすべてのサポートされるステートおよびプロパティを対応づけなければならない。コンテンツ著者は、サポートされるステートおよびプロパティに対して値を提供してもよいが、デフォルト値で十分な場合の一部のケースでは必要ない。
5.2.4 継承されるステートおよびプロパティ§スーパークラスロールからロールに継承されるプロパティの有益なリスト。ステートおよびプロパティは、DOMツリーにおける祖先要素からではなく、ロールタクソノミーにおけるスーパークラスロールから継承される。プロパティの継承は自動的に行われるため、このプロパティは、ロールで明示的に定義されない。この情報は、この仕様を読みやすくするために提供されている。継承されるステートおよびプロパティと組み合わせるサポートされるステートおよびプロパティのセットは、ロールによってサポートされるステートおよびプロパティの完全なセットを形成する。
5.2.5 必要とされる所有される要素§このロールをもつ要素によって所有される任意の要素。たとえば、ロールlistをもつ要素は、ロールgroupまたはlistitemの少なくとも1つの要素を所有する。
複数のロールがロールに対して必要とされる所有される要素として指定される場合、1つの必要とされる所有される要素の少なくとも1つのインスタンスが期待される。この仕様は、列挙される所有ロールのそれぞれのインスタンスを要求しない。たとえば、menuはmenuitem、menuitemcheckbox、またはmenuitemradioの少なくとも1つのインスタンスを持つ必要がある。menuロールは、それぞれの1つのインスタンスを要求しない。
たとえば、データセットの編集中またはロード中に、必要とされる所有される要素が見つからないことがあるかもしれない。スクリプトの実行またはロードが原因でウィジェットが必要とされる所有される要素が見つからない場合、著者は、trueに同等なaria-busyをもつ要素を含むものをマークしなければならない。たとえば、ページが完全に初期化されて完了するまで、著者はbusyなどの文書要素をマークするかもしれない。
注
「必要とされる所有される要素」を持つロールは、逆の関係を意味しない。ロールの処理が子孫として存在する与えられたロールの要素なしで不完全かもしれない一方で、このリストでロールをもつ要素は常に与えられたロールの要素内で発見される必要はない。与えられたロールの要素が含まれる場所のコンテキストに関する要件については、必要とされるコンテキストロールを参照のこと。
注
「必要とされる所有される要素」のサブクラスロールをもつ要素はこの要件を満たさない。たとえば、listロールは、listitemまたはgroupロールのいずれかを使用して要素の所有権を要求する。groupロールはrowのスーパークラスであるが、rowのロールをもつ所有要素の追加は、listがlistitemまたはgroupを所有しなければならないという要件を満たすことはない。
必要とされるコンテキストロールは、このロールが許可される所有コンテナーを定義する。ロールが必要とされるコンテキストを持つ場合、著者はロールをもつ要素が 必要とされるコンテキストロールをもつ要素を内部に（または所有されて）含まれることを保証しなければならない。たとえば、ロールlistをもつ要素を内部に含まれる（または所有される）場合、ロールlistitemをもつ要素のみが意味を持つ。
注
「必要とされるコンテキストロール」を持つロールは、逆の関係を意味しない。与えられるロールをもつ要素が意味のあるものにするために記載されるロールの要素内に出現する必要がある一方で、記載されるロールの要素は意味のあるものにするために与えられるロールの子孫要素を常に必要としない。与えられる子孫の存在に適切に処理されるよう要求する要素に関する要件については、必要とされる所有される要素を参照のこと。
5.2.7 アクセシブルな名前の計算§aria-label属性、aria-labelledby属性、または、代替テキストを指定するための最低の優先順位を持つHTML title属性を伴う、HTMLにおけるaltまたはtitle属性のようなホスト言語ラベル付け機構のような明示的なマークアップ機能で著者によって提供される値に由来する名前。名前計算は、Accessible Name and Description specificationで定義される[accname-aam-1.1]。
5.2.7.2 説明計算§説明計算は、Accessible Name and Description仕様で定義される[accname-aam-1.1]。
5.2.7.3 代替テキスト計算§代替テキスト計算は、Accessible Name and Description specificationで定義される[accname-aam-1.1]。
5.2.7.4 著者由来の名前をサポートするロール§すべてのロールは、2つの例外をもつ著者由来の名前をサポートする。著者由来の名前をサポートしないロールは、presentationおよびnoneである。
Boolean (true | false)
DOM子孫はプレゼンテーショナルである。ユーザーエージェントは、プラットフォームアクセシビリティAPIを通してこの要素の子孫を公開すべきでない。ユーザーエージェントが子孫ノードを非表示にしない場合、一部の情報は2回読み取られる。
5.2.9 暗黙のロールに対する値§多くのステートおよびプロパティはデフォルト値を持つ。時折、与えられたロールで使用される際のデフォルト値は、通常のデフォルトと異なるべきである。非標準のデフォルト値を持つステートまたはプロパティを要求するロールは、「暗黙のロールに対する値」でこれを示す。これは、「ステートまたはプロパティ名が新しいデフォルト値である」形で表現される。著者が明示的な値を提供しない場合、これを定義するロールは、ステートまたはプロパティの新しいデフォルト値を持つ。
現在のユーザーシナリオをサポートするために、この仕様は、ユーザーインターフェイスのウィジェット（スライダー、ツリーコントロールなど）およびページ構造（セクション、ナビゲーションなど）を定義するロールを分類する。一部の支援技術は、ロールapplicationまたはdocumentとマークされる領域に対する相互作用の特別なモードを提供することに注意する。
ロールは次のように分類される：
5.3.1 抽象ロール§次のロールは、一般的なロール概念を定義する目的でWAI-ARIAロールタクソノミーをサポートするために使用される。
抽象ロールはオントロジーのために使用される。著者は、コンテンツにおいて抽象ロールを使用してはならない。
5.3.2 ウィジェットロール§次のロールは、スタンドアロン・ユーザーインターフェイスウィジェットまたはより大きな複合ウィジェットの一部として機能する。
buttoncheckboxgridcelllinkmenuitemmenuitemcheckboxmenuitemradiooptionprogressbarradioscrollbarsearchboxseparator（フォーカス可能な場合）sliderspinbuttonswitchtabtabpaneltextboxtreeitem次のロールは、複合ユーザーインターフェイスウィジェットとして機能する。このロールは、ウィジェットを含む、その他を管理するコンテナーとして一般に機能する。
5.3.3 文書構造§次のロールは、ページにおけるコンテンツを体系づける構造を記述する。文書構造は通常、インタラクティブではない。
applicationarticlecellcolumnheaderdefinitiondirectorydocumentfeedfiguregroupheadingimglistlistitemmathnonenotepresentationrowrowgrouprowheaderseparator（フォーカス可能でない場合）tabletermtoolbartooltip次のロールは、ナビゲーションランドマークとして意図されるページの領域である。これらロールのすべては、landmark基本型から継承し、かつすべてがRole Attributeからインポートされる[role-attribute]。ロールは、WAI-ARIAロールタクソノミーの一部を明確にするためにここに含まれる。
次のロールはライブ領域であり、ライブ領域属性によって変更されてもよい。
5.3.6 ウィンドウロール§次のロールは、ブラウザーまたはアプリケーション内でウィンドウとして機能する。
5.4 ロールの定義§以下は、リッチインターネットアプリケーションの著者によって使用されるWAI-ARIAロールのアルファベット順リストである。
抽象ロールはオントロジーのために使用される。著者は、コンテンツにおいて抽象ロールを使用してはならない。
alert
alertdialogおよびstatusを参照のこと。
alertdialog
alertおよびdialogを参照のこと。
application
widgetロールによってサポートされる標準的な相互作用パターンに従わない、キーボードまたはジェスチャーイベントなどの、ユーザー入力を要求する1つ以上のフォーカス可能な要素を含む structure。
article
banner
button
linkを参照のこと。
cell
gridcellを参照のこと。
checkbox
true、false、またはmixedの3つの可能性がある値を持つチェック可能な入力。
columnheader
combobox
textboxの値を設定する、ユーザーを助けるために動的にポップアップ表示することができる、たとえばlistboxやgridなどの、単一行textboxと他の要素を含む複合widget。
command （抽象ロール）
complementary
composite （抽象ロール）
contentinfo
definition
termを参照のこと。
dialog
body要素。
directory
document
feed
articleにリストのいずれかの端に追加させるまたは端から削除させるかもしれない場所でarticleのスクロール可能なlist。
figure
section。figureの一部は、ユーザー移動可能であってもよい。
form
landmark領域。関連するsearchを参照のこと。
grid
widget。
gridcell
gridまたはtreegrid内のcell。
group
heading
img
input （抽象ロール）
landmark （抽象ロール）
section。そのようなページの概要は、ユーザーエージェントまたは支援技術によって動的に生成することがある。
link
buttonを参照のこと。
list
listitem要素を含むsection。関連するlistboxを参照のこと。
listbox
comboboxおよびlistを参照のこと。
listitem
log
marqueeを参照のこと。
main
marquee
logを参照のこと。
math
menu
menubar
menuのプレゼンテーション。
menuitem
menuまたはmenubarに含まれる選択肢のセットにおけるオプション。
menuitemcheckbox
true、false、またはmixedであるチェック可能な状態をもつmenuitem。
menuitemradio
menuitem。
navigation
none
presentationを参照のこと。
note
option
selectリストで選択可能な項目。
presentation
noneを参照のこと。
progressbar
radio
radiogroup
radioボタンのグループ。
range （抽象ロール）
region
section。そのようなページの概要は、ユーザーエージェントまたは支援技術によって動的に生成することがある。
roletype （抽象ロール）
row
rowgroup
rowheader
scrollbar
search
landmark領域。関連するformおよびsearchboxを参照のこと。
searchbox
textboxおよびsearchを参照のこと。
section （抽象ロール）
sectionhead （抽象ロール）
select （抽象ロール）
separator
slider
spinbutton
rangeのフォーム。
status
alertを正当化するほど重要ではなく、多くの場合ステータスバーとして提示される必要のないライブ領域の種類。
structure （抽象ロール）
switch
checkboxを参照のこと。
tab
table
section。関連するgridを参照のこと。
tablist
tabpanel要素への参照であるtab要素のリスト。
tabpanel
tabがtablistに含まれる、tabに関連付けられたリソースに対するコンテナー。
term
definitionを参照のこと。
textbox
timer
toolbar
tooltip
tree
listの種類。
treegrid
treeの場合と同様に開いたり閉じたりすることができるgrid。
treeitem
treeのオプション項目。これは、より低いレベルのツリー項目要素のグループを含む場合に、開いたり閉じたりするかもしれないツリー内の要素である。
widget （抽象ロール）
window （抽象ロール）
alert （ロール）§
重要かつ通常は時間依存の情報をもつライブ領域の種類。関連するalertdialogおよびstatusを参照のこと。
アラートは、ユーザーに警告するためのメッセージを伝えるために使用される。音声警告の場合、これは、聴覚障害のあるユーザー対するアクセシブルな代替となる。alertロールは、アラートメッセージを含むノードに登場する。アラートは、分割不能なライブ領域として処理される、statusのロールの特別な形式である。
アラートは、断定的なライブ領域であり、支援技術によってそのように処理される。著者もユーザーエージェントも、アラートを処理するためにアラートへのフォーカスを設定または管理することを要求されない。アラートはフォーカスを受け取ることを要求されないため、コンテンツ著者は、アラートを閉じることをユーザーに要求すべきでない。オペレーティングシステムが許可する場合、WAI-ARIAアラートが作成される際、ユーザーエージェントは、アクセシビリティAPIを通してシステムのアラートイベントを起動すべきである。アラートがアラートを閉じるためにフォーカスを要求する場合、コンテンツ作成者は、代わりにalertdialogを使用すべきである。
ロールalertをもつ要素は、assertiveの暗黙のaria-live値を持ち、trueの暗黙のaria-atomic値を持つ。
alertdialog （ロール）§
初期のフォーカスがダイアログ内の要素に行く場所で、警告メッセージを含むダイアログの種類。関連するalertおよびdialogを参照のこと。
アラートダイアログは、ユーザーに警告するメッセージを伝えるために使用される。alertdialogロールは、アラートメッセージとダイアログの残りの部分との両方を含むノードで発生する。コンテンツ著者は、alertdialogが示される間、キーボードとマウスの相互作用がダイアログ内でのみ動作することを保証することによってアラートダイアログをモーダルに確認させるべきである。aria-modalを参照のこと。
alertと異なりalertdialogは、ユーザーからの応答を受信することができる。たとえば、ユーザーが生成されているアラートが理解するのを確認することなどである。アラートダイアログが表示される場合、著者は、フォーム編集フィールドまたはOKボタンのような、アラートダイアログ内のアクティブな要素にフォーカスを設定すべきである。ユーザーエージェントは、アラートが作成された場合、意図されるアクセシビリティAPIによって指定されるアラートイベントを提供され、アクセシビリティAPIを通してシステムのアラートイベントを発火すべきである。
著者は、ダイアログで警告メッセージ要素を指すようにalertdialog上のaria-describedbyを使用すべきである。そうでない場合、支援技術は、警告メッセージのコンテンツを決定するために内部の回復機構に頼る。
application （ロール）§
widgetロールによってサポートされる標準的な相互作用パターンに従わない、キーボードまたはジェスチャーイベントなどの、ユーザー入力を要求する1つ以上のフォーカス可能な要素を含む structure。
一部のユーザーエージェントおよび支援技術は、上矢印および下矢印キーイベントなどの標準入力イベントが 読み取りカーソルを制御するために傍受され使用される、ブラウズモードを持つ。このブラウズモードの動作は、widgetロールを持たない要素がインタラクティブな機能を提供するためのキーボードやジェスチャーイベントの受信や使用しないように防ぐ。
WAI-ARIA widgetロールのいずれかによってサポートされない相互作用モデルをもつ要素を作成する必要がある場合、著者はその要素にロールapplicationを与えてもよい。そして、ユーザーがロールapplication要素にナビゲートする場合、標準入力イベントを傍受する支援技術は、ウェブアプリケーションを通じてほとんどまたはすべての標準入力イベントを通過するモードに切り替えるべきである。
たとえば、プレゼンテーションスライドエディターは、スライド上のテキストボックスや画像要素の位置を変更するために矢印キーを使用する。著者がスライドコンテナーにロールapplication、「スライド エディター」のaria-roledescriptionを与え、そして指示を与えるためにaria-describedbyを使用するので、このような相互作用モデルに対応するWAI-ARIA widgetロールは存在しない。
application要素に含まれるフォーカス可能な要素のみが一部の支援技術のユーザーにアクセシブルであるので、著者は、アクセシブルであるアプリケーションの内側にすべての非装飾な静的テキストまたは画像コンテンツを保証するために次の方法のいずれかを使用しなければならない：
aria-labelledbyまたはaria-describedbyを使用してフォーカス可能な要素とコンテンツを関連付ける。documentまたはarticleを持つフォーカス可能な要素でコンテンツを配置する。aria-activedescendantの値を更新し、フォーカスの管理で説明したように子孫のフォーカスを管理する。article （ロール）§
文書、ページ、またはサイトの独立した部分を形成する文章から成るページのセクション。
記事は、ナビゲーションランドマークではないが、支援技術が次の議論でユーザーを支援するために記事のネスティングに注意を払うことができる場合に議論を形成するためにネストされるかもしれない。記事は、フォーラムの投稿、雑誌や新聞記事、ウェブログ項目、ユーザーが送信したコメント、またはコンテンツの他の独立した項目であるかもしれない。たとえばシンジケーションにおいて、そのコンテンツが孤立することができるという点で、独立である。しかし、要素は依然として要素の祖先に関連する。たとえば、親body要素に適用する連絡先情報は、依然としてなおも記事をカバーする。記事をネストする場合、子記事は、親記事のコンテンツに関連するコンテンツを表す。たとえば、ユーザーが送信したコメントを受け入れるサイト上のウェブログ項目は、ウェブログ項目の記事内にネストされる記事としてコメントを表すかもしれない。著者、見出し、日付、または記事に関連する他の情報は、ネストされた記事に適用されない。
ユーザーがarticleのロールを割り当てられた要素へナビゲートする場合、ウェブアプリケーションを通してキーボードイベントを渡すのとは対照的に、通常は標準のキーボードイベントを横取りする支援技術は、文書閲覧モードに切り替えるべきである。支援技術は、ユーザーが任意のネストされたarticle要素の階層をナビゲートすることを可能にする機能を提供してもよい。
articleがfeedのコンテキスト内にある場合、著者はaria-posinsetおよびaria-setsizeに値を指定してもよい。
button （ロール）§
クリックまたは押された際にユーザー誘発のアクションを可能にする入力。関連するlinkを参照のこと。
ボタンは、個別のアクションに大部分は使用される。ボタンの外観を標準化することは、ボタンとしてウィジェットの利用者の認識を高め、ツールバーでよりコンパクトな表示が可能になる。
ボタンはオプション属性aria-pressedをサポートする。空でないaria-pressed属性をもつボタンは、トグルボタンである。aria-pressedがtrueである場合にボタンは「押された」ステートにあり、aria-pressedがfalseである場合にボタンは押されていない。属性が存在しない場合、ボタンは単純なコマンドボタンである。
cell （ロール）§ checkbox （ロール）§
true、false、またはmixedの3つの可能性がある値を持つチェック可能な入力。
checkboxのaria-checked属性は、入力がチェックされる（true）、チェックされない（false）かどうかを示し、またはチェックされるおよびチェックされないの混合物（mixed）を持つ要素のグループを表す。多くのチェックボックスはmixed値を使用せず、よって事実上真偽チェックボックスである。
columnheader （ロール）§
列のヘッダー情報を含むセル。
columnheaderは、テーブルまたはグリッドの列見出しとして使用することができる。これはまた、データ内の類似関係を示す円グラフで使用することもできる。
ColumnHeaderは、対応する列における見出しとすべてのセルとの間の関係を確立する。これは、列の範囲をもつHTML th要素と構造的に等価である。
著者は、ロールrowをもつ要素に含まれる、または所有されるロールcolumnheaderをもつ要素を保証しなければならない。
columnheader上のaria-selectedの適用は、ユーザーエージェントに対応する列におけるすべてのセルにaria-selectedステートを自動的に伝搬させてはならない。著者は、特定の用途に応じてこの方法で選択の伝搬を選択してもよい。
columnheaderロールはインタラクティブなグリッドと非インタラクティブなテーブルの両方で使用することができる一方で、aria-readonlyおよびaria-requiredの用途はインタラクティブな要素にのみ適用可能である。したがって、著者はtableから伝わるcolumnheaderにおいてaria-requiredまたはaria-readonlyを使用すべきでなく、かつcolumnheaderがgridから伝わらない限り、ユーザーエージェントは支援技術にいずれかのプロパティを公開すべきでない。
注
セルは列に編成されるので、列に対する単一のコンテナー要素は存在しない。列は、それぞれのrowコンテナー内の特定の位置におけるgridcell要素のセットである。
combobox （ロール）§
textboxの値を設定する、ユーザーを助けるために動的にポップアップ表示することができる、たとえばlistboxやgridなどの、単一行textboxと他の要素を含む複合widget。
著者は、ロールcomboboxをもつ要素、またはロールのtextboxもしくはsearchboxをもつテキスト入力要素およびfalseに設定されるaria-multilineをもつテキスト入力要素を含むまたは所有することを保証しなければならない。comboboxがaria-autocompleteで記載されるようにテキスト入力のための自動補完の動作を提供する場合、著者は提供される動作に対応する値にtextbox要素のaria-autocompleteを設定しなければならない。
一般に、comboboxのデフォルト状態は折りたたみである。折りたたみ状態において、comboboxのtextbox要素のみが可視である。comboboxは、textboxとそのポップアップとして機能する補助要素の両方が可視である場合に展開されると言われる。著者は、要素が展開された場合にロールcomboboxをもつ要素でtrueにaria-expandedを、および要素が折りたたまれた場合にfalseに設定しなければならない。ロールcomboboxをもつ要素は、trueの暗黙のaria-expanded値を持つ。
comboboxが展開される場合、著者はlistbox、tree、grid、またはdialogのロールを持つ要素を含むまたは所有することを保証しなければならない。この要素は、comboboxのポップアップである。comboboxが展開される場合、著者は、comboboxのポップアップ要素を参照する値にtextbox要素のaria-controlsを設定しなければならない。
ロールcomboboxをもつ要素は、listboxの暗黙のaria-haspopup値を持つ。comboboxのポップアップ要素がlistbox以外のロールを持つ場合、著者はそのポップアップの種類に対応するaria-haspopupの値を指定しなければならない。
フォーカスの管理で説明したように、キーボードアクセシブルであるために、著者は、このロールのすべてのインスタンスに対する子孫のフォーカスを管理すべきである。comboboxがフォーカスを受け取る際、著者はフォーカスがtextbox要素に置かれていることを保証すべきである。
著者は、textbox要素とポップアップに含まれる要素との間でフォーカスを移動するためのキーボードメカニズムを提供すべきである。たとえば、1つの一般的な規則は、Down Arrowがポップアップ要素の最初のフォーカス可能な子孫へのテキスト入力からフォーカスを移動することである。ポップアップ要素がaria-activedescendantをサポートする場合、フォーカスを移動する代わりに、そのようなキーボードメカニズムは、textbox要素のaria-activedescendantの値を制御することができる。ポップアップ要素の子孫がアクティブである場合、フォーカスがtextbox要素上に残っている間、著者は、ポップアップ内のアクティブな要素を参照する値にtextboxのaria-activedescendantを設定してもよい。
例5
<div aria-label="Tag" role="combobox" aria-expanded="true" aria-owns="owned_listbox" aria-haspopup="listbox">
<input type="text" aria-autocomplete="list" aria-controls="owned_listbox" aria-activedescendant="selected_option">
</div>
<ul role="listbox" id="owned_listbox">
<li role="option">Zebra</li>
<li role="option" id="selected_option">Zoom</li>
</ul>
ARIA 1.0仕様は、テキスト入力要素がcomboboxロールを持ち、かつlistbox要素を所有するcomboboxのパターンを説明する。ユーザーエージェント、支援技術、および適合性チェッカーはARIA 1.0パターンをサポートし続けるべきでありその結果ARIA 1.0パターンの既存の実装は引き続きうまく機能する。
コンボボックスの実装の機能および挙動は大きく異なる。その結果として、多くの重要なオーサリング考慮事項が存在する。コンボボックスの設計パターンの実装に関する詳細については、WAI-ARIA Authoring Practices Guide [wai-aria-practices-1.1]を参照のこと。
command （抽象ロール）§
アクションを実行するが入力データを受信しないウィジェットのフォーム。
注
commandは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてこのロールを使用すべきでない。
complementary （ロール）§
DOM階層において同等のレベルで主要コンテンツに相補的であるよう設計されたが、主要コンテンツから分離される際に意味のあるままにする、文書のサポートセクション。
このロールを適切に持つコンテンツの様々な種類が存在する。たとえば、ポータルの場合に、これは含まれるが、視聴時間、現在の天気、関連記事、または注目の株に限定されるものではない。包含されるコンテンツを示す補完的なロールは、主要コンテンツに関連する。相補的なコンテンツが主要コンテンツから完全に分離可能である場合、より一般的なロールを使用することが適切だろう。
ユーザーエージェントは、ナビゲーションランドマークとしてcomplementaryのロールをもつ要素を扱うべきである。
composite （抽象ロール）§
ナビゲーション可能な子孫または所有する子を含むことができるウィジェット。
著者は、複合ウィジェットがウェブページのより大きなナビゲーションシステム内の単一のナビゲーションストップとして存在することを確認すべきである。複合ウィジェットがフォーカスを一度持つと、著者は、子孫または複合要素の所有される子である要素にナビゲートするためにユーザーに対する独立したナビゲーション機構を提供すべきである。
注
compositeは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてこのロールを使用すべきでない。
contentinfo （ロール）§
親文書に関する情報を含む大規模な知覚可能な領域。
ページのこの領域に含まれる情報の例は、著作権やプライバシーステートメントへのリンクである。
ユーザーエージェントは、ナビゲーションランドマークとしてcontentinfoのロールをもつ要素を扱うべきである。
任意のdocumentまたはapplicationの中で、著者は、contentinfoロールをもつ複数の要素をマークすべきでない。
注
documentおよびapplication要素はDOMでネストすることができるので、DOMのネスト（たとえば、document内のdocument）によってか、またはaria-owns属性の使用によってのいずれかで、それぞれが異なる文書ノードに関連付けられていると仮定して、DOMの子孫として複数のcontentinfo要素を持ってもよい。
definition （ロール）§ dialog （ロール）§
ウェブアプリケーションの主要ウィンドウの子孫ウィンドウであるダイアログ。HTMLページに対して、主要アプリケーションウィンドウはウェブコンテンツ全体である。たとえばbody要素。
ダイアログはほとんどの場合、情報への入力または応答をユーザーに促すために使用される。ワークフローを中断するように設計されたダイアログは、通常モーダルである。関連するalertdialogを参照のこと。
著者は、aria-labelまたはaria-labelledby属性に対処することができる、ダイアログラベルを提供すべきである。
著者は、すべてのダイアログ（モーダルと非モーダルの両方）が少なくとも1つのフォーカス可能な子孫要素を持つことを保証すべきである。ダイアログが表示される場合に、著者は、モーダルダイアログ内の要素にフォーカスすべきであり、かつ著者は、モーダルダイアログのフォーカスを管理すべきである。
注
このロールの説明において、用語"ウェブアプリケーション"は、特定の支援技術の動作を指定する、applicationロールを参照しない。
directory （ロール）§
静的な目次のような、グループのメンバーへの参照のリスト。
著者は、リンクされているかどうか、静的な目次に対してこのロールを使用すべきである。これは、ネストされたリストを含む、リストで構築された目次を含む。しかし、動的な目次は、代わりにtreeロールを使用するかもしれない。
document （ロール）§
支援技術のユーザーが読み取りモードで閲覧することを望むかもしれないコンテンツを含む要素。
ユーザーエージェントのフォーカスがdocumentのロールを割り当てられた要素に移動する場合、静的なコンテンツを閲覧するための読み取りモードを持つ支援技術は、読み取りに切り替えて、読み取りカーソルを制御するために、上または下矢印キーボードイベントなどの、標準入力イベントを傍受してもよい。
読み取りモードを持つ支援技術はwidgetまたはapplicationロールのいずれかを持つものを除くすべての要素に適したデフォルトモードになるので、documentロールが支援技術の動作を変更する便利な唯一の状況は、ロールdocumentをもつ要素がwidgetまたはapplicationのフォーカス可能な子要素となる場合である。たとえば、いくつかの静的なリッチテキストが含まれるapplication要素を考えると、著者はロールdocumentをテキストを含む要素に適用することができ、0のtabindexを与えることができる。スクリーンリーダーのユーザーがTabキーを押してdocument要素にフォーカスを置く場合、ユーザーはスクリーンリーダーの読み取りカーソルをもつテキストを読むことができる。
feed （ロール）§
スクロールがarticleにリストのいずれかの端に追加させるまたは端から削除させるかもしれない場所でarticleのスクロール可能なlist。
feedは、ユーザーが読むようにより多くのコンテンツを読み込むことによって無限にスクロールし続けるかもしれないリッチコンテンツのストリームを介して読み込みとスクロールの両方をするためのカーソル読み込みブラウズモードを使用することを、スクリーンリーダーなどの文書閲覧モードを持つ支援技術のユーザーにできるようにする。feedにおいて、支援技術は、ユーザーがページを閲覧するように新しいコンテンツを追加し視覚的にコンテンツを配置するアプリケーションを有効する、ユーザーエージェントのフォーカスを移動することによってユーザーの読み取りカーソルの動きの信号とともにウェブアプリケーションを提供する。feedはまた、支援技術が読み取りの混乱またはパフォーマンスの低下をすることなく、より確実に読み取り表示を更新できるように追加および削除が発生する場合に、著者に支援技術を告知させる。
たとえば、各articleがテキスト、リンク、画像と同様に共有やコメントのためのウィジェットをもつニュース記事を含む場所で、ニュース記事のストリームを提示するためにfeedを使用することができる。スクリーンリーダーのユーザーは、各ニュース記事を読み取って対話し、記事から記事へスクリーンリーダーの読み取りカーソルを移動するので、必要に応じて各記事は、表示にスクロールし、そして新しい記事は読み込まれる。
feedは、子がロールarticleを持つコンテナー要素である。articleがfeedの片方または両方の端に追加または削除される場合、著者は 変更が作成される前にfeed要素上でaria-busyをtrueに設定し、変更が完了した後にこれをfalseに設定すべきである。著者は、feedの真ん中でarticleを挿入または削除を避けるべきである。この要件は、支援技術がfeed内で読み取りカーソルを移動するためにユーザーコマンドと同時に発生するfeedコンテンツにおける変化に正常に対応するのを助ける。
著者は、ユーザーエージェントのフォーカスがarticleまたはその子孫要素のいずれかで設定される場合に、フォーカス可能なfeedで各articleを作成し、アプリケーションがビューにarticleをスクロールすることを保証すべきである。たとえば、HTMLで、各article要素は、-1または0のいずれかのtabindex値を持つべきである。
支援技術の読み取りカーソルがarticleから別のものに移動する場合、支援技術は、読み取りカーソルを含むarticleにユーザーエージェントのフォーカスを設定すべきである。読み取りカーソルがarticle内部のフォーカス可能な要素に到着する場合、支援技術は、articleを含んでいるフォーカスを設定する代わりにその要素にフォーカスを設定してもよい。
支援技術の読み取りカーソルをもつ別のarticleにスクロールする機能は、ページ内の別のarticleの存在に依存するため、著者は、ユーザーエージェントのフォーカスが読み込まれたarticleのセットのどちらかの端でarticleに達する前に、追加のarticleを読み込もうと試みるべきである。また、著者は、buttonのような、ユーザーに読み込まれているより多くのarticlesを要求させる要素を含む読み込まれた一連のarticlesのどちらかまたは両方の端にarticleを含めてもよい。
簡単なラベルを提供することに加えて、ユーザーがarticleによってナビゲートする場合に、著者は、ラベルの後で話す要素へスクリーンリーダーに示唆するためにfeedにおいてaria-describedbyをarticle要素に適用されてもよい。スクリーンリーダーは、著者が記述の外から残っている、埋め込まれたインタラクションウィジェットなどの、反復またはほとんど無い重要な要素を無視することをユーザーに有効にする、articleでナビゲートする際、ラベルとアクセシブルな説明の両方を話すことによってfeedコンテンツをすばやくスキャンする方法を著者に提供してもよい。
著者は、articleのナビゲーション機能を提供する支援技術を利用しないユーザーがfeedをナビゲートするためにキーボードを使用できるように、feedにおけるarticle間でフォーカスを移動するためのキーボードコマンドを提供すべきである。
feedで利用可能な記事の数が静的である場合、著者はそのfeedにおけるarticle要素にaria-setsizeを指定してもよい。しかし、合計数が非常に大きい、不定、または頻繁に変更する場合、著者は、セットの不明なサイズを通信するためにaria-setsizeを-1に設定してもよい。
フィードの設計パターンの実装に関する詳細については、WAI-ARIA Authoring Practices [wai-aria-practices-1.1]を参照のこと。
figure （ロール）§
グラフィカルな文書、画像、コード断片、またはテキスト例を通常含むコンテンツの知覚可能なsection。figureの一部は、ユーザー移動可能であってもよい。
著者は、主要テキストからfigureへの参照を提供すすべきであるが、figureは参照する要素と同じ場所で表示される必要はない。著者は、aria-describedbyを使用するキャプションとしての機能を果たすテキストを参照してもよい。著者は、aria-labelを使用してラベルを提供してもよく、aria-labelledbyを使用してラベルとして機能を果たすテキストを参照してもよい。
支援技術は、ユーザーがすばやく図にナビゲートできるようにすべきである。メインストリームのユーザーエージェントは、ユーザーがすぐに図にナビゲートできるようにしてもよい。
form （ロール）§
全体として、フォームを作成するために組み合わせるアイテムおよびオブジェクトのコレクションを含むlandmark領域。関連するsearchを参照のこと。
フォームは、ホスト言語のフォームコントロール、スクリプト化コントロール、およびハイパーリンクのミックスであるかもしれない。著者は、可能な限り、フォームコントロールを作成するためにネイティヴホスト言語のセマンティクスを使用することに注意する。検索機能のために、著者は、汎用なformロールでなく、searchロールを使用すべきである。著者は、aria-labelledbyで参照されるフォームに対して可視ラベルを提供すべきである。著者がonsubmitイベントをトリガーしない（たとえば、フォーム要素の値を変更するユーザーによってトリガーされるフォーム送信）ユーザーアクションに基づくフォーム送信をするスクリプトを使用する場合、著者は、行動の事前通知をユーザーに提供すべきである。
ユーザーエージェントは、ナビゲーションランドマークとしてformのロールをもつ要素を扱うべきである。
grid （ロール）§
方向矢印キーのような、グリッドで一部またはすべてのセルが2次元のナビゲーションのメソッドを使用することでフォーカス可能となる、1つ以上のセルをもつ1つ以上の行のコレクションを含む複合widget。
gridロールは、特定の視覚、たとえば、表、プレゼンテーションを意味するものではない。これは、要素間の関係を記述する。これは、チェックボックスまたはナビゲーションリンクのコレクションをグループ化するような単純な目的、またはフル機能のスプレッドシートアプリケーションの作成のような複雑な目的のために使用されてもよい。
gridのセル要素は、ロールgridcellを持つ。著者は、gridcellロールの代わりにrowheaderかcolumnheaderロールのいずれかを使用することで行または列ヘッダーとしてセルを指定してもよい。著者は、ロールgridcell、columnheaderまたはrowheaderを持つ要素が、順番にロールrowgroupまたはgridをもつ要素に所有される、ロールrowをもつ要素によって所有されることを保証しなければならない。
フォーカスの管理で説明されるように、キーボードアクセシブルであるために、著者は、gridの子孫のフォーカスを管理すべきである。ユーザーがキーボードでgridコンテンツをナビゲートしている場合、著者は、次のようにフォーカスを設定すべきである：
gridcellセルが、checkbox、button、またはlinkのような、フォーカスを受け取る際に矢印キーが押されることを消費しない単一のインタラクティブなwidgetを含む場合、著者は、そのセルに含まれるインタラクティブな要素にフォーカスを設定してもよい。これは、含まれるウィジェットが直接操作可能にすることを可能にする。gridcell、rowheader、またはcolumnheader要素であることを保証すべきである。著者は、フォーカス可能なセルが次のいずれかが含まれる場合に、そのフォーカス可能なセルの内側に含まれるコンテンツにユーザーがナビゲートして対話することを可能にする相互作用または編集モードに変更するためのメカニズムを提供すべきである。
comboboxまたはradiogroupたとえば、スプレッドシート内のセルがcomboboxまたは編集可能なテキストを含む場合、Enterキーは、そのセルが方向矢印キーが含まれているcomboboxまたはtextboxを操作するために使用することができるようなフォーカスを持つ場合、セル間相互作用または編集モードをアクティブにするために使用されるかもしれない。実装に応じて、もう一度Enter、Tabは、Escape、または別のキーを押すことで、アプリケーションとグリッドナビゲーションモードとを切り替えてもよい。
著者は、ユーザーが編集することができた式の結果を表示するには、gridcellを使用してもよい。たとえば、スプレッドシートアプリケーションにおいて、textboxが編集可能な状態で式を含むgridcellに出現する場合に、ユーザーが編集のためにgridcellをアクティブにするまで、gridcellは式から算出した値を示してもよい。
aria-readonlyがロールgridをもつ要素に設定される場合、ユーザーエージェントは、gridに所有されるすべてのgridcell要素に値を伝播し、アクセシビリティAPIに値を公開しなければならない。著者は、個々のgridcell要素のためにaria-readonlyの伝播値を上書きしてもよい。
フォーカス可能なgridcell要素のコンテンツが編集可能でない場合、セルコンテンツの編集機能を提供するgridにおいて、著者は、gridcell要素上のaria-readonlyにtrueを設定してもよい。しかし、aria-readonlyの値は、gridまたは個々のセルに指定されたかどうかを、セルに含まれるコンテンツが編集可能であるかどうかのみを示す。これは、grid自身をナビゲートまたは操作するための機能の利用可能性を示すものではない。
aria-readonlyの未指定値はgridまたはgridcellに編集可能なコンテンツが含まれていることを意味しない。たとえば、gridが、日付ピッカーで日付を表すlink要素のコレクションのような、編集可能でない要素のコレクションを提示する場合、著者がaria-readonlyに値を指定することは必須ではない。
著者は、フォーカス可能なgridcellがaria-selected属性をもつアクションの対象として選択可能であることを示してもよい。gridが複数のgridcellを選択すること可能である場合、著者は、ロールgridをもつ要素でaria-multiselectableをtrueに設定すべきである。
WAI-ARIAはホスト言語の要素を増強することができるため、gridは、HTMLのtable要素などのネイティブテーブルの要素および属性を再利用することができる。たとえば、著者がHTMLのtable要素にgridロールを適用する場合、ユーザーエージェントが自動的に適切な変換を行うため、著者は子孫のHTML trおよびtd要素にロールをrowおよびgridcellを適用する必要はない。著者がネイティヴホスト言語テーブル要素を再利用しかつ複数の行または列にまたがるgridcell要素を必要とする場合、著者は、WAI-ARIA aria-rowspanまたはaria-colspanプロパティの代わりに適切なホスト言語属性を適用すべきである。
グリッドの設計パターンの実装に関する詳細については、WAI-ARIA Authoring Practices Guide [wai-aria-practices-1.1]を参照のこと。
gridcell （ロール）§
gridcellは、フォーカス可能、編集可能、または選択可能であってもよい。gridcellは、機能的関係のアプリケーションを扱うためにaria-controlsのような関係を持ってもよい。
著者がgridcellに行ヘッダー、列ヘッダー、またはその両方を持たせ、かつ関連する見出しがDOM構造から決定することができない場合、著者は、gridcellのaria-describedbyを適用しロールrowheaderまたはcolumnheaderをもつ要素を参照することによってにどのヘッダーセルがgridcellに関連しているかを明示的に示すべきである。
treegridにおいて、著者はaria-expanded属性を使用することで拡張可能としてgridcellを定義してもよい。aria-expanded属性が提供される場合、個々のセルにのみ適用される。拡張することもできるコンテナーrowに対する代理ではない。gridcell上にこの属性を提供するための主なユースケースは、ピボットテーブルの動作である。
著者は、ロールgridcellをもつ要素が、ロールrowをもつ要素で含まれるまたは所有されることを保証しなければならない。
group （ロール）§
支援技術によってページサマリーまたは目次に含まれることを意図されないユーザーインターフェイスオブジェクトのセット。
ページサマリーまたは目次に含まれるユーザーインターフェイスオブジェクトのグループ化したregionと対比する。
著者は、階層内の兄弟のコレクション、またはディレクトリで同じコンテナーを持つアイテムのコレクションを形成するツリーウィジェットにおける子のような、ウィジェットにおける項目の論理的な集合を形成するためにgroupを使用すべきである。しかし、groupがリストのコンテキストで使用される場合、著者は、その子をlistitem要素に制限しなければならない。したがって、著者および支援技術によるgroupの適切な取り扱いは、グループが提供されるコンテキストによって決定される。
著者は、group要素をネストしてもよい。セクションがウェブページの目次に含まれることを保証するのに十分大きい場合、著者は、セクションにregionのロールまたは標準ランドマークロールを割り当てるべきである。
heading （ロール）§ img （ロール）§
画像を形成する要素のコレクションのコンテナー。
imgは、一緒に見た場合に1枚の画像の印象を与える複数の画像ファイルだけでなく、キャプションおよび説明テキストを含めることができる。imgは、描画オブジェクトのコレクションによって形成されているかどうかに関わりなく、文書内の1つのグラフィックを表す。imgのロールをもつ要素が知覚可能であるために、著者は、アクセスシブルな名前の計算により決定される代替テキストまたはラベルを提供しなければならない。
input （抽象ロール）§
ユーザー入力を許可するウィジェットの一般的な種類。
landmark （抽象ロール）§
ユーザーがセクションに容易にナビゲートでき、かつページの要約に記載させることを望むだろう胃、特定の、著者が指定した目的に関連し、かつ十分に重要なコンテンツを含む知覚可能なsection。そのようなページの概要は、ユーザーエージェントまたは支援技術によって動的に生成することがある。
著者は、ランドマークロールのサブクラスであるロールを割り当てることで、および必要な場合、簡単な説明ラベルを提供することで、コンテンツの目的を指示する。
ランドマークロールのサブクラスであるロールをもつ要素は、ランドマーク領域またはナビゲーションランドマーク領域として知られる。支援技術は、ユーザーがすばやくランドマーク領域に移動できるようにすべきである。メインストリームのユーザーエージェントは、ユーザーがすぐにランドマーク領域に移動できるようにしてもよい。
注
landmarkは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてこのロールを使用すべきでない。
link （ロール）§
活性化された場合、ユーザーエージェントにそのリソースにナビゲートさせる、内部または外部のリソースへのインタラクティブなリファレンス。関連するbuttonを参照のこと。
これが（href値をもつHTMLアンカーのような）ホスト言語におけるネイティヴリンクである場合、リンクをアクティブにすると、そのリソースにユーザーエージェントをナビゲートさせる。これがシミュレートされたリンクである場合、ウェブアプリケーションの著者は、ナビゲーションを管理する責任を負う。
注
リンクを押すとアクションをトリガーするが、ブラウザのフォーカスまたはページの場所を変更しない場合、著者は、linkロールの代わりにbuttonロールの使用を検討することを勧める。
list （ロール）§ listbox （ロール）§ listitem （ロール）§
リストまたはディレクトリにおける1つの項目。
著者は、ロールlistitemをもつ要素が、ロールlistまたはgroupをもつ要素に含まれるまたは要素によって所有されることを保証しなければならない。
log （ロール）§
新しい情報が意味のある順序で追加されかつ古い情報が消えることのあるライブ領域の種類。関連するmarqueeを参照のこと。
例は、チャットログ、メッセージの履歴、ゲームログ、またはエラーログを含む。他のライブ領域とは対照的に、このロールでログにおける新しい項目の到着と読み上げ順序との間に関係がある。ログは、意味のある配列を含み、新しい情報は任意の点でなく、ログの末尾にのみ追加される。
ロールlogをもつ要素は、暗黙のaria-live値politeを持つ。
main （ロール）§
文書の主要コンテンツ。
これは、直接に関連する、または文書の主要なトピックを詳しく述べるコンテンツをマークする。mainロールは、ダイアログを通したユーザーエージェントによって、または支援技術によって提供される主要コンテンツ（または他のランドマーク）に行くためのナビゲーションオプションで、"メインコンテンツにスキップする"リンクに対する控えめな代替手段である。
ユーザーエージェントは、ナビゲーションランドマークとしてmainのロールをもつ要素を扱うべきである。
任意のdocumentまたはapplication内で、著者はmainロールをもつ複数の要素をマークすべきではない。
注
documentおよびapplication要素はDOMでネストすることができるので、DOMのネスト（たとえば、document内のdocument）によってか、またはaria-owns属性の使用によってのいずれかで、それぞれが異なる文書ノードに関連付けられていると仮定して、DOMの子孫として複数のbanner要素を持ってもよい。
marquee （ロール）§
必須でない情報が頻繁に変更されるライブ領域の種類。関連するlogを参照のこと。
marqueeの一般的な使用法は、株価表示や広告バナーである。marqueeとlogとの間の主な違いは、ログは通常、意味の順序または重要なコンテンツの変更の配列を持つことである。
ロールmarqueeをもつ要素は、暗黙のaria-live値offを持つ。
math （ロール）§
数式を表すコンテンツ。
ロールmathをもつコンテンツは、支援技術によってアクセシブルな形式に容易に変換することができる、MathML [MathML3]のようなまたは、TeXやLaTeXのようなテキスト表現の別の種類をもつ、支援技術によって容易にアクセシブルな形式に変換することができることを意図する。
数式の画像を使用することは理想的ではないが、画像が数式を表すために使用される大量のレガシーコンテンツが存在する。著者は、数学の画像が話されるかもしれないものとして数式を説明するテキストによってラベル付けされることを保証すべきである。
注
MathMLのネイティヴ実装をサポートするブラウザは、数学のプレーンテキスト近似を用いて達成することができるものよりもより堅牢な、アクセシブルな数学の体験を提供することが可能である。一部のレンダリングエンジンは、ネメス点字形式で式および再生可能な点字ディスプレイ出力の空間タッチ探査を許可するスクリーンリーダーとの緊密な統合を持つ。このレベルの統合は、たとえ著者がプレーンテキスト近似を提供しても、数式の画像をサポートしない。
これの執筆時点では、一部の主流のブラウザは、ネイティヴにMathMLをサポートせず、またJavaScriptのpolyfillライブラリーを使用して改造しなければならない。数学コンテンツをオーサリングする場合、可能な限りネイティヴMathMLを使用し、徹底的にテストする。polyfillライブラリーを使用するか、必要に応じて代替テキスト近似で代替画像を提供する。
埋め込みTeX注釈をもつMathML例§例6
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<mi>x</mi>
<mo>=</mo>
<mfrac>
<mrow>
<mo form="prefix">−</mo>
<mi>b</mi>
<mo>±</mo>
<msqrt>
<msup>
<mi>b</mi>
<mn>2</mn>
</msup>
<mo>−</mo>
<mn>4</mn>
<mo>⁢</mo>
<mi>a</mi>
<mo>⁢</mo>
<mi>c</mi>
</msqrt>
</mrow>
<mrow>
<mn>2</mn>
<mo>⁢</mo>
<mi>a</mi>
</mrow>
</mfrac>
</mrow>
<annotation encoding="TeX">
x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}
</annotation>
</math> プレーンHTMLまたはMathMLの二次式のPolyfill DOM結果§
レンダリングエンジンがMathMLのようなネイティヴ数学形式をサポートしない場合、著者は、データURIとプレーンテキスト代替を使用して次のHTML画像のような、ブラウザーで表示することができる形式にコンテンツをダウングレードするためにJavaScriptを使用してもよい。
例7
<img role="math" src="..." alt="x=⟮−b±√⟮b²−4ac⟯⟯÷2a">
navigation （ロール）§
文書または関連する文書をナビゲートするためのナビゲーション要素（通常はリンク）のコレクション。
ユーザーエージェントは、ナビゲーションランドマークとしてnavigationのロールをもつ要素を扱うべきである。
none （ロール）§
暗黙のネイティヴロールセマンティクスがアクセシビリティAPIに対応づけされない要素。類義語presentationを参照のこと。
注
ARIA 1.1noneロールに関する注§
ARIA 1.1において、ワーキンググループは、単語"presentation"または"presentational"の意図された意味の周囲の著者の混乱のために、presentationのロールに同義語としてnoneを導入した。多くの人はrole="presentation"をaria-hidden="true"と同義であると誤って考え、我々はrole="none"がより明確に実際の意味を伝えると考える。
実装がrole="none"に対して十分なサポートを含むまで、ウェブ制作者は、presentationロールだけでrole="presentation"またはnoneロールのフォールバックとして重複してrole="none presentation"を使用することを勧める。
note （ロール）§
コンテンツがリソースの主要コンテンツに挿入的または付随的であるセクション。
option （ロール）§ presentation （ロール）§
暗黙のネイティヴロールセマンティクスがアクセシビリティAPIに対応づけされない要素。類義語noneを参照のこと。
注
ARIA 1.1noneロールに関する注§
ARIA 1.1において、ワーキンググループは、単語"presentation"または"presentational"の意図された意味の周囲の著者の混乱のために、presentationのロールに同義語としてnoneを導入した。多くの人はrole="presentation"をaria-hidden="true"と同義であると誤って考え、我々はrole="none"がより明確に実際の意味を伝えると考える。
実装がrole="none"に対して十分なサポートを含むまで、ウェブ制作者は、presentationロールだけでrole="presentation"またはnoneロールのフォールバックとして重複してrole="none presentation"を使用することを勧める。
要素がページの外観を変更するために使用されるが、要素型によって暗黙的な、機能的な、インタラクティブな、または構造の関連性を一切持たない、またはWAI-ARIAをサポートしない古いブラウザーでアクセシビリティフォールバックを提供するために使用する場合が使用目的である。
ユースケースの例：
aria-labelledbyと（必要な場合）aria-describedbyでマークアップされるimgロールをもつコンテナーにおける画像。フォーカス可能でない、presentationのロールをもつ任意の要素に対して、ユーザーエージェントは、アクセシビリティAPIへ要素の暗黙のネイティヴセマンティクス（ロールとそのステートおよびプロパティ）を公開してはならない。しかし、ユーザーエージェントは、presentationの明示的または継承されたロールを持たないコンテンツまたは子孫要素を公開しなければならない。このように、presentationロールは与えられる要素に何のロールも持たないものとして扱われせる、またはアクセシビリティツリーから削除させるが、要素内に含まれているコンテンツにアクセシビリティツリーから削除させることはない。
たとえば、アクセシビリティAPIによれば、次のマークアップ要素は、同じロールセマンティクス（ロールなし）と同じコンテンツを持つように見えるだろう。
例8
<h1 role="presentation"> Sample Content </h1> <span> Sample Content </span> <span role="presentation"> Sample Content </span> Sample Content
presentationロールは、要素に対するデフォルトのアクセシビリティAPIロールが存在することを意味する、暗黙のネイティヴセマンティクスを持つ要素で使用される。一部の要素は、追加の子孫要素が与えられた場合にのみ完結する。たとえば、HTMLにおいて、（gridロールとマッチする）table要素は、順番にthまたはtdの子（gridcell、columnheader、rowheaderロール）を要求する、trの子孫（rowロール）を要求する。同様に、リストはリスト項目の子を必要とする。要素のセマンティクスを完全なものにする子孫要素は、必要とされる所有される要素としてWAI-ARIAに記載される。
presentationの明示的または継承されるロールが、所有される要素を必要としているWAI-ARIAロールの暗黙のセマンティックをもつ要素に適用され、さらにpresentationの明示的なロールを持つ要素である場合、ユーザーエージェントは、定義された明示的なロールを持たないすべての所有される要素にpresentationの継承されたロールを適用しなければならない。また、presentationの明示的または継承されたロールは、ホスト言語仕様によって定義されるような任意の必要とされる子を持つホスト言語要素に適用され、さらにpresentationの明示的なロールを持つ要素である場合、ユーザーエージェントは、定義された明示的なロールを持たない任意の必要とされる子にpresentationの継承されたロールを適用しなければならない。
HTMLにおいて、img要素は、画像ファイルのタイプにかかわらず単一の実態として扱う。したがって、HTML imgのrole="presentation"またはrole="none"を使用することは、aria-hidden="true"を使用することと同じである。画像コンテンツをアクセシブルにするために、著者は、objectまたはiframe要素を使用してオブジェクトを埋め込む、またはインラインSVGコードを使用して、画像コンテンツのアクセシビリティガイドラインに従うことができる。
presentationの明示的または継承されるロールをもちかつフォーカス可能でない任意の要素に対して、ユーザーエージェントは、その要素に対するロール固有のWAI-ARIAステートおよびプロパティを無視しなければならない。たとえばHTMLにおいて、presentationのロールをもつulまたはol要素は、ulまたはolが対応するlistロールがlistitemの必要とされる所有される要素を持つので、li要素の暗黙のネイティヴセマンティクスを取り除かさせる。同様に、HTMLのtable要素がWAI-ARIAロールに直接対応する暗黙のネイティヴセマンティックロールを持たないが、HTML仕様は要素がtable要素の必要とされる構造的な子孫であることを示すため、そのthead/tbody/tfoot/tr/th/td子孫の暗黙のネイティヴセマンティクスもまた削除される。
注
WAI-ARIA必要とされる所有される要素に対応する要素の暗黙のネイティヴセマンティクスのみが削除される。この要素がまた適用されるpresentationの明示的なロールを持たない限り、ネストした表やリストを含む、任意の他のコンテンツは、そのまま残る。
たとえば、アクセシビリティAPIによれば、次のマークアップ要素は、同じロールセマンティクス（ロールなし）と同じコンテンツを持つように見えるだろう。
例9
<ul role="presentation"> <li> Sample Content </li> <li> More Sample Content </li> </ul> <foo> <foo> Sample Content </foo> <foo> More Sample Content </foo> </foo>
注
この状況が適用可能である必要とされる子をもつ他のWAI-ARIAロールが存在する（たとえば、radiogroupsおよびlistboxes）が、テーブルおよびリストは、プレゼンテーションの継承を適用する可能性がある最も一般的な実世界のケースである。
presentationの明示的または継承されるロールをもつ任意の要素に対して、ユーザーエージェントは、プレゼンテーション要素に対するすべてのホスト言語固有の分類要素に継承されるpresentationのロールを適用しなければならない。たとえば、captionは単なるプレゼンテーションテーブルのラベルであるため、presentationのロールをもつtable要素は、caption要素の暗黙のネイティヴセマンティクスを取り除かせる。
presentationロールを画像に適用する場合、著者は（HTMLのalt=""を使用するなど）意味のある代替テキストを提供すべきでない。
次のコードサンプルにおいて、imgを含むものは、キャプションの段落によって適切に分類される。ロールおよび代替テキストが包含する要素によって提供されるため、この例においてimg要素はpresentationとしてマークすることができる。
例10
<div role="img" aria-labelledby="caption"> <img src="example.png" role="presentation" alt=""> <p id="caption">A visible text caption labeling the image.</p> </div>
次のコードサンプルにおいて、アンカー（HTMLのa要素）はtreeitemとして動作しているので、リスト項目（HTMLのli要素）は、リスト項目に対するユーザーエージェントの暗黙のネイティヴセマンティクスを上書きするために明示的なWAI-ARIA presentationロールが割り当てられる。
例11
<ul role="tree"> <li role="presentation"> <a role="treeitem" aria-expanded="true">An expanded tree node</a> </li> … </ul>プレゼンテーションロールの競合の解決§
プレゼンテーションロールの競合を解決するためのさまざまな方法がある。
適用されてもよい、ロールなしの暗黙的なプレゼンテーションロールを持つホスト言語要素は、アクセシビリティツリーで公開されてはならない。この例外により、ユーザーエージェントは、アクセシビリティAPIへグローバルなWAI-ARIAステートおよびプロパティを常に公開しなければならない。この場合、ユーザーエージェントは、presentationロールを無視し、要素の暗黙的なネイティヴセマンティクスに応じて要素を公開する。しかし、明示的な役割が適用される継承されたプレゼンテーションロールにある場合を除いて、ユーザーエージェントは、任意の非グローバル、ロール固有WAI-ARIAのステートおよびプロパティを無視しなければならない。
たとえば、aria-haspopupはグローバル属性であり、常に適用される。aria-levelはグローバル属性ではなく、したがって、要素がプレゼンテーションステートではなかった場合にのみ適用される。
例12
<h1 role="presentation" aria-haspopup="true"> Sample Content </h1> <h1 role="presentation" aria-level="2"> Sample Content </h1>
子孫または所有される要素の明示的なロールは、presentationの継承されたロールを上書きし、所有する要素に明示的なロールをもつ他の要素として動作させる。公開する暗黙のロールの動作がアクセシビリティツリーに不正な形式をもたらす場合、期待される結果は未定義であり、ユーザーエージェントは、アクセシビリティツリーを修復するために内部の回復メカニズムに助けを求めてもよい。
presentationのロールをもつ要素がフォーカス可能である場合、またはそうでなければインタラクティブである場合、要素が理解可能と操作可能の両方であることを保証にするために、ユーザーエージェントは、ロールの正常な効果を無視しなければならず、かつ暗黙のネイティヴセマンティクスで要素を公開しなければならない。
ユーザーエージェントは、たとえ要素が明示的または継承されるpresentationのロールを持つとしても、グローバルなWAI-ARIAステートおよびプロパティをアクセシビリティAPIに常に公開しなければならない。この場合、ユーザーエージェントは、presentationロールを無視し、要素の暗黙的なネイティヴセマンティクスに応じて要素を公開する。しかし、明示的な役割が適用される継承されたプレゼンテーションロールにある場合を除いて、ユーザーエージェントは、任意の非グローバル、ロール固有WAI-ARIAのステートおよびプロパティを無視しなければならない。
progressbar （ロール）§
長い時間がかかるタスクの進捗状況を表示する要素。
プログレスバーは、ユーザーの要求が受信され、かつアプリケーションが要求された動作を完了に向けて進行していることを示す。著者がaria-valuenow属性を省略すべきである場合に、不確定でない限り、著者は、aria-valuenow、aria-valuemin、aria-valuemaxに値を提供すべきである。視覚的な進捗インジケーターが更新される際に、著者はこれらの値を更新すべきである。progressbarがページの特定領域の読み込み進捗を説明している場合、著者は、ステータスを指すためにaria-describedbyを使用すべきであり、ページの読み込みが完了するまで領域上のaria-busy属性をtrueに設定すべきである。常に読み取り専用であるため、ユーザーがprogressbarの値を変更することは不可能である。
注
aria-valuetextが指定されない限り、支援技術は、一般にaria-valueminとaria-valuemaxとの値の間の範囲のパーセントとしてaria-valuenowの値をレンダリングする。この計算に適した方法で、aria-valuemin、aria-valuemax、およびaria-valuenowに対する値を設定するのが最適である。
radio （ロール）§
一方のみが一度にチェックすることができる、同じロールをもつ要素のグループにおけるチェック可能な入力。
著者は、ロールradioをもつ要素が、どれが同じ値に影響を与えるかを示すために明示的にグループ化されることを保証すべきである。これは、ロールradiogroupをもつ要素でradio要素を囲むことによって達成される。ラジオボタンをradiogroupのDOMの子にすることが可能でない場合、著者はその子との関係を示すためにradiogroup要素のaria-owns属性を使用すべきである。
radiogroup （ロール）§
radioボタンのグループ。
radiogroupは、どの時点においてもチェックされる単一のエントリーのみを持つことができるselectリストの種類である。著者は、同時にチェックすることができるグループで1つのみのラジオボタンを強制すべきである。グループで1つの項目をチェックする場合、以前にチェックされた項目はチェックを外す（そのaria-checked属性をfalseにする）。
range （抽象ロール）§
ユーザーによって設定可能な値の範囲を表す入力。
注
rangeは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてこのロールを使用すべきでない。
region （ロール）§
ユーザーがセクションに容易にナビゲートでき、かつページの要約に記載させることを望むだろう胃、特定の、著者が指定した目的に関連し、かつ十分に重要なコンテンツを含む知覚可能なsection。そのようなページの概要は、ユーザーエージェントまたは支援技術によって動的に生成することがある。
著者は、main、complementary、navigationのような、他のlandmarkロールのいずれかで正確に記述されない目的をもつコンテンツを含むセクションへのregionロールの使用を制限すべきである。
著者は、ロールregionをもつ各要素に、その領域におけるコンテンツの目的を説明する簡潔なラベルを与えなければならない。可視ラベルが存在する場合、著者は、aria-labelledbyをもつ可視ラベルを参照すべきである。著者は、可能な限り、見出しの内側のラベルを含めるべきである。見出しは、標準ホスト言語の見出し要素のインスタンス、またはロールheadingをもつ要素のインスタンスであってもよい。
支援技術は、ユーザーがロールregionをもつ要素にすばやくナビゲートできるようにすべきである。メインストリームのユーザーエージェントは、ユーザーがロールregionをもつ要素にすばやくナビゲートできるようにしてもよい。
roletype （抽象ロール）§
このロールのプロパティは、（"インスタンス"としてRDF用語で知られる）このロールに割り当てられるオブジェクトの構造的および機能的目的を説明する。ロールは、インスタンスを理解および操作するために使用することができる概念である。
注
roletypeは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてこのロールを使用すべきでない。
row （ロール）§ rowgroup （ロール）§
テーブルコンテナーにおける1つ以上の行要素を含む構造。
rowgroupロールは、所有されるrow要素間の関係を確立する。これは、HTML table要素におけるthead、tfoot、およびtbody要素と構造的に等価である。
著者は、ロールrowgroupをもつ要素がロールtableまたはgridをもつ要素に含まれるまたは所有されることを保証しなければならない。
注
rowgroupロールは、部分的に、HTMLでロール対称性をサポートするために存在し、適用される明示的なpresentationロールをもつHTML table要素でプレゼンテーション継承の伝播を可能にする。
注
このロールは、行グループ（たとえばthead対tbody）の種類を区別しないが、問題がWAI-ARIA2.0に対して提起されている。
scrollbar （ロール）§ search （ロール）§
全体として、検索機能を作成するために組み合わせるアイテムおよびオブジェクトのコレクションが含まれるlandmark領域。関連するformおよびsearchboxを参照のこと。
探索領域は、ホスト言語のフォームコントロール、スクリプト化コントロール、およびハイパーリンクの組み合わせかもしれない。
ユーザーエージェントは、ナビゲーションランドマークとしてsearchのロールをもつ要素を扱うべきである。
searchbox （ロール）§
検索条件の指定を対象としたテキストボックスの型。関連するtextboxおよびsearchを参照のこと。
section （抽象ロール）§
文書またはアプリケーションでレンダリング可能な構造収納単位。
注
sectionは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてこのロールを使用すべきでない。
sectionhead （抽象ロール）§
構造の関連セクションのトピックを分類するまたは要約するもの。
注
sectionheadは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてこのロールを使用すべきでない。
select （抽象ロール）§
ユーザーが選択肢のセットから選択を行うことを可能にするフォームウィジェット。
注
selectは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてこのロールを使用すべきでない。
separator （ロール）§
コンテンツのセクションまたはメニュー項目のグループを分離して区別する仕切り。
2種類のセパレータ－がある：可視境界のみ提供しかつフォーカス可能な静的なstructure、移動可能でもあるインタラクティブなwidget。separatorがフォーカス可能でない場合、静的な構造要素として支援技術に公開される。たとえば、静的なseparatorは、メニューにおけるメニュー項目の2つのグループを視覚的に分割する、またはページの2つのセクションの間の水平方向の罫線を提供するのを助けるために使用することができる。
著者は、両者がコンテンツの2つのセクション間の可視境界を提供し、separatorの位置を変更することによってセクションの相対的なサイズを変更することを可能にするwidgetを作成するためにseparatorをフォーカス可能にしてもよい。固定セパレーターseparatorが2つの離散的な位置のみをサポートする一方で、可変separatorウィジェットは範囲内で連続的に移動させることができる。一般に、固定separatorウィジェットは、展開と折りたたみ状態の間のいずれかのセクションを切り替えるために使用される。
separatorがフォーカス可能である場合、著者は、separatorの現在の位置を反映するnumberにaria-valuenowの値を設定し、その数値が変化する際にその値を更新しなければならない。著者はまた、0でない場合にaria-valueminの値を、および100でない場合にaria-valuemaxの値を提供すべきである。欠損または数でない場合、属性の暗黙の値は次のようになる：
aria-valuenowの暗黙の値は0である。aria-valuemaxの暗黙の値は100である。aria-valuenowの暗黙の値は0である。複数のフォーカス可能なseparatorが存在するアプリケーションにおいて、著者は、それぞれにアクセシブルな名前を提供すべきである。
ロールseparatorをもつ要素は、暗黙のaria-orientation値horizontalを持つ。
slider （ロール）§
ユーザーが与えられた範囲内から値を選択するユーザー入力。
スライダーは、スライダーの大きさとつまみの位置を介して現在値と可能な値の範囲を表す。矢印キーなどの方向キーを使用することによって現在の値に加算または減算することが一般に可能である。
著者は、aria-valuemin、aria-valuemaxおよびaria-valuenow属性を設定しなければならない。欠損する場合、これら属性の暗黙の値はHTML範囲入力型と同じ規則に従う：
aria-valueminが欠損するまたは数でない場合、デフォルトは0となる。aria-valuemaxが欠損するまたは数でない場合、デフォルトは100となる。aria-valuenowが欠損するまたは数でない場合、デフォルトは aria-valueminとaria-valuemaxとの間の半分になる。aria-valuenowが存在するがaria-valueminより小さい場合、デフォルトはaria-valueminの値となる。aria-valuenowが存在するがaria-valuemaxより大きい場合、デフォルトはaria-valuemaxの値となる。ロールsliderをもつ要素は、暗黙のaria-orientation値horizontalを持つ。
spinbutton （ロール）§
ユーザーに個別の選択肢の中から選択することを期待するrangeのフォーム。
一般にspinbuttonは、キーボードの上下ボタンの利用を通して与えられた範囲からユーザーが選択できる。見かけ上は、最大値または最小値に達するまで現在値が増加または減少する。著者は、キーボードの↑と↓の使用を通して、プログラム的に実現されるべきである。
spinbuttonはselectの多くのプレゼンテーションに外観が似ているが、個別のオプションとは対照的に（特に大きな範囲の場合に）既知の範囲で作業する際にspinbuttonを使用することを勧める。たとえば、1から1,000,000までの範囲を表すspinbuttonは、同じ値を表すselectウィジェットよりもはるかに優れた性能を提供するだろう。
著者は、子または所有する要素をもつspinbuttonを作成してもよいが、textboxおよび/または2つのbuttonにそれら要素を制限しなければならない。
フォーカスの管理で説明したように、キーボードアクセシブルであるために、著者は、このロールのすべてのインスタンスに対する子孫のフォーカスを管理すべきである。spinbuttonがフォーカスを受け取る際、著者は、フォーカスが存在する場合、textbox要素に、そうでなければspinbutton自体に配置されることを保証すべきである。著者は、キーボードデバイスを使用する人に不要であるため、たとえばHTMLにおけるタブのリングのような、プライマリナビゲーションリング内のbutton要素を含めるべきでない。
著者は、aria-valuenow属性を設定しなければならない。著者は、最小値が存在する場合にaria-valuemin、属性を、最大値が存在する場合にaria-valuemax属性を設定すべきである。欠損または数でない場合、属性の暗黙の値は次のようになる：
aria-valueminの暗黙の値は、最小値が存在しない。aria-valuemaxの暗黙の値は、最大値が存在しない。aria-valuenowの暗黙の値は0である。status （ロール）§
コンテンツはユーザーに対する助言情報であるが、alertを正当化するほど重要ではなく、多くの場合ステータスバーとして提示される必要のないライブ領域の種類。
著者は、ロールstatusをもつ要素がステータスにおける変更の結果としてフォーカスを受け取らないことを保証すべきである。
ステータスは、ライブ領域の一形態である。ページの別の部分がステータスに出現する内容を制御する場合、著者は、aria-controls属性との関係を明示すべきである。
支援技術は、ステータスをレンダリングするために点字表示の一部のセルを予約してもよい。
ロールstatusをもつ要素は、暗黙のaria-live値polite、および暗黙のaria-atomic値trueを持つ。
structure （抽象ロール）§
文書構造要素。
文書構造のためのロールは、静的な文書コンテンツに対するアクティブコンテンツを決定する支援技術を支援することによって、動的なWebコンテンツのアクセシビリティをサポートする。自身によるstructuralロールはアクセシビリティAPIへのマップを一切しないが、ウィジェットロールを作成したり、支援技術のためのコンテンツ適応を支援するために使用される。
注
structureは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてこのロールを使用すべきでない。
switch （ロール）§
checked/unchecked値とは対照的に、on/off値を表すチェックボックスの型。関連するcheckboxを参照のこと。
switchのaria-checked属性は、入力がオン（true）またはオフ（false）であるかどうかを示す。mixed値は不正であり、かつユーザーエージェントは、このロールに対してfalseと等価としてmixed値を扱わなければならない。
注
switchは、checkboxやトグルbuttonとほぼ同じ機能を提供するが、その画面上の外観をもつ一貫した方法で支援技術でウィジェットを提示できるようにする。
tab （ロール）§
ユーザーにレンダリングされるタブコンテンツを選択するためのメカニズムを提供するグループ化ラベル。
tabpanelにおけるtabpanelまたは項目がフォーカスを持つ場合、関連するtabが、フォーカスの管理で定義されるようなtablistにおける現在アクティブなタブである。関連するtab要素のセットを含むtablist要素は、通常先行する、一連のtabpanel要素の近くに一般に配置される。タブセットデザインパターンの実装の詳細については、WAI-ARIA Authoring Practices [wai-aria-practices-1.1]を参照のこと。
著者は、ロールtabをもつ要素がロールtablist要素で含まれるまたは要素によって所有されることを保証しなければならない。
著者は、現在アクティブなタブに関連付けられるtabpanelがユーザーに知覚可能であることを保証すべきである。
1つが選択可能なtablistに対して、ユーザーがそのタブパネルに関連付けられるタブを選択するまで、著者はユーザーからの他のtabpanel要素を非表示にすべきである。複数の選択可能なtablistに対して、著者は、各可視tabpanelがそのaria-expanded属性をtrueに設定され、かつ残りの非表示tabpanel要素がそのaria-expanded属性をfalseに設定されることを確認すべきである。
いずれの場合も、著者は、選択したタブがそのaria-selected属性をtrueに設定され、非アクティブタブ要素がそのaria-selected属性をfalseに設定され、現在選択されるタブが、選択の視覚的な表示を提供することを保証すべきである。現在のタブにaria-selected属性が存在しない場合、ユーザーエージェントは、現在フォーカスされるタブが選択されているプラットフォームのアクセシビリティAPIを通じて支援技術に示すべきである。
table （ロール）§
行列で整列されたデータを含むsection。関連するgridを参照のこと。
tableロールは、相互作用しないテーブルコンテナーを対象とする。テーブルコンテナーが選択状態を維持する、自身の二次元ナビゲーションを提供する、またはユーザーが再配置または他の方法でそのコンテンツを操作する、またはそこから表示する場合、著者は代わりにgridまたはtreegridを使用すべきである。
可能な限り著者は、HTML table要素のように、テーブルに対してホスト言語のセマンティクスを使用することを選ぶべきである。
tablist （ロール）§ tabpanel （ロール）§ term （ロール）§
対応する定義をもつ単語またはフレーズ。関連するdefinitionを参照のこと。
termロールは、definitionが著者によって提供されているまたはユーザーによって提供されると予想される、単語または語句を明示的に識別するために使用される。
著者は、そうすることは、それらの要素との相互作用することから支援技術のユーザーを妨げるかもしれないので、リンクなどの対話型要素でtermロールを使用すべきでない。
textbox （ロール）§
入力値として自由形式のテキストを許可する入力の型。
aria-multiline属性がtrueである場合、ウィジェットは、HTML textareaの中のように、入力内の改行を受け付ける。そうでなければ、これは単純なテキストボックスである。使用目的は、テキスト入力要素を持たない言語に対して、または異なるセマンティクスをもつ要素がテキストフィールドとして再利用されるケースである。
注
ほとんどのユーザーエージェントの実装において、ENTERキーまたはRETURNキーのデフォルトの動作は、HTMLで、単一行と複数行のテキストフィールドとの間で異なる。ユーザーが単一行の<input type="text">要素にフォーカスを持つ場合、キーストロークは通常、フォームを送信する。ユーザーが複数行の<textarea>要素にフォーカスを持つ場合、キーストロークは改行を挿入する。WAI-ARIA textboxロールは、aria-multiline属性をもつボックスのこれらの種類を区別する。よって著者は、フィールドを設計する際にこの区別を意識することを勧める。
timer （ロール）§
開始時点からの経過時間を示す、または終了時点までの残り時間を示す数値カウンタを含むライブ領域の種類。
タイマーオブジェクトのテキストコンテンツは、現在の時間測定を示し、その量が変化するように更新される。タイマー値は必ずしも機械的に解釈できるものではないが、著者は、タイマーが一時停止するまたは終点に到達する場合を除いて、一定間隔でテキストコンテンツを更新すべきである。
ロールtimerをもつ要素は、暗黙のaria-live値offを持つ。
toolbar （ロール）§ tooltip （ロール）§ tree （ロール）§ treegrid （ロール）§
行がtreeの場合と同様に開いたり閉じたりすることができるgrid。
aria-readonlyがロールtreegridをもつ要素に設定される場合、ユーザーエージェントは、treegridに所有されるすべてのgridcell要素に値を伝播し、アクセシビリティAPIに値を公開しなければならない。著者は、個々のgridcell要素のためにaria-readonlyの伝播値を上書きしてもよい。
aria-readonly属性がフォーカス可能なgridcellに適用される場合、gridcellに含まれるコンテンツが編集可能であるかどうかを示す。aria-readonly属性は、treegrid自身をナビゲートするまたは操作するための関数の利用可能性を示すものではない。
フォーカス可能なgridcell要素のコンテンツが編集可能でない場合、コンテンツの編集機能を提供するtreegridにおいて、著者は、gridcell要素上のaria-readonlyにtrueを設定してもよい。しかし、treegridが、link要素のコレクションのような、aria-readonlyをサポートしない要素のコレクションを提示する場合、著者がaria-readonlyに値を指定することは必須ではない。
フォーカスの管理で説明したように、キーボードアクセシブルであるために、著者は、このロールのすべてのインスタンスに対する子孫のフォーカスを管理すべきである。
treeitem （ロール）§
treeのオプション項目。これは、より低いレベルのツリー項目要素のグループを含む場合に、開いたり閉じたりするかもしれないツリー内の要素である。
展開および折りたたまれるtreeitem要素のコレクションは、groupロールをもつ要素で囲まれる。
著者は、ロールtreeitemをもつ要素が、ロールgroupまたはtreeをもつ要素に含まれるまたは要素によって所有されることを保証しなければならない。
widget （抽象ロール）§ window （抽象ロール）§
ブラウザーまたはアプリケーションのウィンドウ。
このロールをもつ要素は、オペレーティングシステムにおけるネイティヴウィンドウとして、または単にウィンドウのように見えるスタイル付けされた文書のセクションとして実装されているかどうかにかかわらず、グラフィカルユーザーインターフェイス（GUI）コンテキストにおける窓状の挙動を持つ。
注
このロールの説明において、用語"アプリケーション"は、特定の支援技術の動作を指定する、applicationロールを参照しない。
注
windowは、オントロジーのために使用される抽象ロールである。著者は、コンテンツにおいてこのロールを使用すべきでない。
用語"ステート"および"プロパティ"は、類似の機能を参照する。両者はオブジェクトに関する特定の情報を提供し、ロールのもつ性質の定義の一部を形成する。この文書において、ステートおよびプロパティはaria-prefixedマークアップ属性として両方扱われる。しかし、両者は、その意味の微妙な違いを明確にするために概念的に異なるよう維持される。一つの大きな違いは、（aria-labelledbyなどの）プロパティの値は多くの場合、ユーザーとの対話に起因して頻繁に変更するかもしれない（aria-checkedなどの）ステートの値よりも、アプリケーションのライフサイクルを通じて変化する可能性がより低いということである。変更差分の周期は習慣ではないことに注意する。aria-valuetextのようないくつかのプロパティは、頻繁に変更することが期待される。ステートとプロパティの区別はほとんどのウェブコンテンツ著者に取るに足りないことであるので、この仕様は、可能ならいつでも、"ステート"と"プロパティ"の両方を単に"属性"として参照する。詳細については、ステートおよびプロパティの定義を参照のこと。
ステートおよびプロパティは、次節で説明する特性を持つ。
6.2.2 ロールで使用される§このステートまたはプロパティを使用するロールに関する助言情報。この情報は、ステートまたはプロパティの適切な使用方法を理解するために提供される。記載される以外のロールに使用される場合に所定のステートまたはプロパティの使用は定義されない。
6.2.3 ロールに継承する§祖先ロールからステートまたはプロパティを継承するロールに関する助言情報。
6.2.4 値§ステートまたはプロパティの値型。値は次の種類のいずれかだろう：
falseである。
falseである。
falseに設定したaria-expandedをもつ要素は、現在展開されていない。undefinedに設定したaria-expandedをもつ要素は、展開可能でない。特に指定しない限り、この値に対するデフォルト値はundefinedである。
undefinedの明示的な値は、値を提供しないことに相当する。
これは、ステートおよびプロパティに対する一般的なタイプであるが、具体的な表現を定義しない。この値がホスト言語で表現され処理される方法の詳細については、ステートおよびプロパティ属性処理を参照のこと。
6.3 ステートおよびプロパティの値§多くのステートおよびプロパティは、値として特定のトークンのセットを受け入れる。許可された値とその意味の説明は、特性表の後に示される。定義される場合、デフォルト値は、括弧内の用語'デフォルト'に続いて、太字で示される。値がデフォルトとして表示される場合、ユーザーエージェントは、ステートまたはプロパティが空または未指定である場合に、この値で規定される動作に従わなければならない。一部のロールはまた、デフォルト値を持たない特定のステートやプロパティが提供されない場合に使用する動作を定義する。
6.4 グローバルなステートおよびプロパティ§一部のステートおよびプロパティは、ロールが適用されるかどうかに関係なく、すべてのホスト言語要素に適用可能である。次のグローバルなステートおよびプロパティは、すべてのロールによって、およびすべての基本マークアップ要素によってサポートされる。
aria-atomicaria-busy （ステート）aria-controlsaria-current （ステート）aria-describedbyaria-detailsaria-disabled （ステート）aria-dropeffectaria-errormessagearia-flowtoaria-grabbed （ステート）aria-haspopuparia-hidden （ステート）aria-invalid （ステート）aria-keyshortcutsaria-labelaria-labelledbyaria-livearia-ownsaria-relevantaria-roledescriptionグローバルなステートおよびプロパティは、基本ロールであるロールroletypeに適用され、よってすべてのロールに継承する。読みやすさのために、仕様においてステートおよびプロパティをサポートされるまたは継承されるかのいずれかとして明示的に識別されない。その代わりに、継承はこのセクションへのリンクで示される。
ステートおよびプロパティは、次のように分類される：
6.5.1 ウィジェット属性§この節は、ユーザー入力およびプロセスのユーザーアクションを受け取るGUIシステム上またはリッチインターネットアプリケーションに見られる共通のユーザーインターフェイス要素に固有の属性が含まれる。以下の属性は、ウィジェットロールをサポートするために使用される。
aria-autocompletearia-checkedaria-disabledaria-errormessagearia-expandedaria-haspopuparia-hiddenaria-invalidaria-labelaria-levelaria-modalaria-multilinearia-multiselectablearia-orientationaria-placeholderaria-pressedaria-readonlyaria-requiredaria-selectedaria-sortaria-valuemaxaria-valueminaria-valuenowaria-valuetextウィジェット属性は、支援技術によるアクセスに対して、プラットフォームアクセシビリティAPIのステートにユーザーエージェントによってマッピングされるかもしれず、またはDOMから直接アクセスされるかもしれない。ユーザーエージェントは、DOM属性変更イベントまたはプラットフォームのアクセシビリティAPIイベントのいずれかを通じて、ステートを変更する際に支援技術に通知するための方法を提供しなければならない。
6.5.2 ライブ領域属性§この節は、リッチインターネットアプリケーションにおけるライブ領域に固有の属性が含まれる。この属性は、任意の要素に適用することができる。この属性の目的は、コンテンツの変更がフォーカスを持つ要素なしに発生することがあり、そしてそのコンテンツの更新を処理する方法の情報を支援技術に提供することを示すためである。一部のロールは、そのロールに固有のaria-live属性にデフォルト値を指定する。ライブ領域の例としては、株価情報の更新を列挙するティッカーセクションがある。
aria-atomicaria-busyaria-livearia-relevantこの節は、ドラッグ可能な要素とそのドロップターゲットのような、ドラッグアンドドロップインターフェイス要素に関する情報を示す属性を列挙する。ドロップターゲット情報は、著者によって視覚的にレンダリングされ、代替モダリティを通じて支援技術に提供される。
6.5.4 関係属性§この節は、文書構造から容易に決定することができない要素間の関係または関連を示す属性を列挙する。
aria-activedescendantaria-colcountaria-colindexaria-colspanaria-controlsaria-describedbyaria-detailsaria-errormessagearia-flowtoaria-labelledbyaria-ownsaria-posinsetaria-rowcountaria-rowindexaria-rowspanaria-setsize以下は、リッチインターネットアプリケーションの著者によって使用されるWAI-ARIAステートおよびプロパティのアルファベット順のリストである。各WAI-ARIAのステートおよびプロパティの詳細な定義は、次の簡潔なリストに従う。
compositeウィジェット、textbox、group、またはapplication上にある場合、現在アクティブな要素を識別する。
aria-relevant属性によって定義される変更通知に基づく変更される領域のすべて、または一部のみを提示するかどうかを示す。
aria-pressedおよびaria-selectedを参照のこと。
table、grid、またはtreegrid内の列の合計数を定義する。関連するaria-colindexを参照のこと。
table、grid、またはtreegrid内の列の合計数に対して、要素の列インデックスまたは位置を定義する。関連するaria-colcountおよびaria-colspanを参照のこと。
table、grid、またはtreegrid内のセルまたはグリッドセルがまたがる列の数を定義する。関連するaria-colindexおよびaria-rowspanを参照のこと。
aria-ownsを参照のこと。
aria-labelledbyを参照のこと。
aria-controlsを参照のこと。
aria-hiddenおよびaria-readonlyを参照のこと。
aria-invalidおよびaria-describedbyを参照のこと。
aria-disabledを参照のこと。
aria-errormessageを参照のこと。
aria-labelledbyを参照のこと。
aria-describedbyを参照のこと。
aria-controlsを参照のこと。
aria-setsizeを参照のこと。
aria-checkedおよびaria-selectedを参照のこと。
aria-disabledを参照のこと。
aria-atomicを参照のこと。
grid、treegridまたはtreegrid内の行の合計数を定義する。関連するaria-rowindexを参照のこと。
table、grid、またはtreegrid内の行の合計数に対して、要素の行インデックスまたは位置を定義する。関連するaria-rowcountおよびaria-rowspanを参照のこと。
table、grid、またはtreegrid内のセルまたはグリッドセルがまたがる行の数を定義する。関連するaria-rowindexおよびaria-colspanを参照のこと。
aria-checkedおよびaria-pressedを参照のこと。
aria-posinsetを参照のこと。
aria-valuetextを参照のこと。
aria-valuenowの人間可読な代替テキストを定義する。
aria-activedescendant （プロパティ）§
DOMフォーカスがcompositeウィジェット、textbox、group、またはapplication上にある場合、現在アクティブな要素を識別する。
aria-activedescendantプロパティは、メニュー、グリッド、ツールバーなどの、複数のフォーカス可能な子孫を含んでもよいインタラクティブな要素のためにフォーカスを管理する代替方法を提供する。子孫要素同士でDOMフォーカスを移動する代わりに、著者は、aria-activedescendantをサポートする要素のDOMフォーカスを設定し、アクティブである要素を参照するためにaria-activedescendantを使用してもよい。
DOMフォーカスをもつ要素のaria-activedescendantの値を設定する場合に、著者は、次の2セットの条件のいずれかが満たされていることを保証しなければならない：
aria-activedescendantの値は、DOMフォーカスをもつ要素の子孫であるまたはaria-owns属性によって示されるように論理的な子孫であるかのいずれかの要素を参照する。aria-activedescendantをサポートする要素を参照するaria-controlsをもつtextboxで、textboxに指定されるaria-activedescendantの値が、textboxによって制御される要素の子孫を参照するまたは、aria-owns属性によって示されるようにその制御要素の論理的な子孫のいずれかである。たとえば、comboboxで、textbox要素上のaria-activedescendantの値がtextboxによって制御されるポップアップlistboxの子孫を参照する間、フォーカスはtextboxに残ることがある。著者はまた、フォーカスされる際に現在アクティブな子孫が可視であり視野内にある（またはスクロールすると視野に入る）ことを保証すべきである。
aria-atomic （プロパティ）§
支援技術がaria-relevant属性によって定義される変更通知に基づく変更される領域のすべて、または一部のみを提示するかどうかを示す。
アクセシビリティAPIとドキュメントオブジェクトモデル[dom]の両者は、支援技術が文書の変更された領域を決定するのを可能にするイベントを提供する。
ライブ領域のコンテンツが変更される場合、ユーザーエージェントは、変更された要素を調査し、aria-atomicセットをもつ最初の要素を見つけるために先祖を横断し、以下の場合に対する適切な動作を適用すべきである。
aria-atomicを設定しない場合、aria-atomicがfalseであるのがデフォルトであり、支援技術はユーザーに変更されたノードのみを表示する。aria-atomicが明示的にfalseに設定される場合、支援技術は、先祖チェーンの検索を停止し、ユーザーに変更されたノードのみを表示する。aria-atomicが明示的にtrueに設定される場合、支援技術は、もし存在する場合に著者定義のライブ領域ラベルを含めて、要素の完全なコンテンツを表示する。aria-atomicがtrueである場合、支援技術は、複数の変更を結合し、一度に全体の変更領域を表示することを選択してもよい。
aria-autocomplete （プロパティ）§
テキストの入力がある入力に対してユーザーの意図した値の1つ以上の予測の表示を引き起こす可能性があるかどうかを示し、予測が作成される場合にその予測を提示する方法を指定する。
aria-autocompleteプロパティは、動的にユーザーのテキスト入力の完了を手助けする場合に、textbox、searchbox、またはcomboboxが利用するインタラクションモデルのタイプを表す。これは、2つのモデルを区別する：テキスト入力内の値完了予測を提示するインラインモデル（aria-autocomplete="inline"）と、テキスト入力に隣接してポップアップする個別に可能な値のコレクションを提示するリストモデル（aria-autocomplete="list"）。入力は、同じ時間（aria-autocomplete="both"）で両方のモデルを提供することが可能である。
aria-autocompleteプロパティは、input要素の予測挙動を記述するのに限定される。著者は、入力要素がどの提案もユーザーによって提供される特定の入力に依存しない1つ以上の入力提案を提供する場合に、aria-autocompleteへの値の指定を省略するまたは、noneにaria-autocompleteを設定するかのいずれかにすべきである。たとえば、aria-autocompleteの値がnoneであるコンボボックスは、ユーザーの入力に基づくリストの任意のフィルタリングなしで5つの最近使用した検索用語をリストすることによって示唆される値を表示する検索フィールドである。aria-autocompleteをサポートするロールをもつ要素は、noneのaria-autocompleteのデフォルト値を持つ。
インライン提案が入力でユーザー型として作成される場合、フィールドの値を完了するために提案されたテキストは、入力カーソルの後にフィールドに動的に出現し、かつユーザーがフィールドをそのままにしてフォーカスをもたらすアクションを実行する場合、提案される値は入力の値として受け入れられる。要素がinlineまたはbothに設定されるaria-autocompleteを持つ場合、著者は、テキストの自動で提案される一部が選択されたテキストとして提示されることを保証すべきである。これは、ユーザーの入力と自動提案とを区別することを支援技術に可能させ、提案が所望の値でない場合には、提案を簡単に削除する、または入力し続けることでその提案を置換することを可能する。
要素がlistまたはbothに設定されるaria-autocompleteを持つ場合、著者は次の両方の条件が満たされることを保証しなければならない：
aria-controlsで指定される値を持つ。comboboxをもつ要素を含むかのいずれかは、提案される値のコレクションを含む要素のロールと一致するaria-haspopupの値を持つ。リストモデルの一部の実装は、提案を選択するために、Down Arrow付きの提案にフォーカスを移動したり、提案をクリックするなどの、アクションを実行することをユーザーに要求する。そのような実装で、著者は、コレクションコンテナーがサポートする場合にaria-activedescendantを使用する、または提案にDOMフォーカスを移動させるかのいずれかによってフォーカスを管理してもよい。しかし、にフィールドがフォーカスを失う場合、たとえば、ユーザーが別のフィールドでTabキーを押すまたはクリックする場合、リストモデルの他の実装は、受け入れられる選択された値として、1つの提案を自動的に強調表示する。要素がlistまたはbothに設定するaria-autocompleteを持つ場合、かつユーザーが入力を提供するよう提案が自動的に選択される場合、著者は次のすべての条件が満たされることを保証しなければならない：
aria-activedescendantをサポートするロールをもつ要素で提示される。aria-activedescendantの値は、aria-activedescendantの定義に記載されるように選択した提案を含む要素を参照するよう動的に調整される。aria-autocompleteプロパティは、完了提案の存在を示すために意図されず、著者は提案の存在を伝えるためにその値を動的に変更すべきでない。要素がlistまたはbothに設定されるaria-autocompleteを持つ場合、著者は提案のコレクションを提示する要素が表示されているかどうかを伝えるためにaria-expandedステートを使用すべきである。
aria-busy （ステート）§
変更をユーザーに公開する前に変更が完了するまで、要素が変更されていて、かつ支援技術が待機することを望んでもよいことを示す。
aria-busyのデフォルト値は、すべての要素に対してfalseである。aria-busyが要素に対してtrueである場合、支援技術は、その要素によって所有されるコンテンツへの変更を無視してもよく、単一の、aria-busyがfalseになる際の微少な更新としてビジー期間中に行われたすべての変更を処理してもよい。
部分的または完全のいずれかに既にレンダリングされるコンテナー要素内に複数の追加、変更、または削除をする必要がある場合、著者は、最初の変更の前にコンテナー要素でaria-busyをtrueに設定してもよく、最後の変更が完了する際にfalseに設定してもよい。たとえば、ライブ領域への複数の変更がスピーチの1つの単位として話されているべきである場合、著者は、変更がされている間にaria-busyをtrueに設定してもよく、変更が完了して話される準備ができた際にfalseに設定してもよい。
ロールfeedをもつ要素がbusyとマークされる場合、支援技術は、ユーザーがビジー期間中に読んでいるarticleの内部で発生するユーザー起動による変更を除いて、feedの内部で発生するレンダリングの変更を延期してもよい。
レンダリングされたwidgetへの変更が、widgetがスクリプトの実行時に欠損する必要とされる所有される要素である状態を作成する場合、著者は、更新プロセス中にwidget上でaria-busyをtrueに設定しなければならない。たとえば、レンダリングされたツリーグリッドが複数の不連続なブランチへの一連の同時更新を要求した場合、単一の更新とともに完全なツリー要素を交換する代わりに、各ブランチが変更されつつ、ツリーをbusyとマークする。
aria-checked （ステート）§ 値： 値 説明 false チェックされている要素はサポートするが、現在チェックされない。 mixed トライステートcheckboxまたはmenuitemcheckboxに対する混合モード値を示す。 true 要素はチェックされる。 undefined （デフォルト） 要素はチェックされるものをサポートしない。 aria-colcount （プロパティ）§
table、grid、またはtreegrid内の列の合計数を定義する。関連するaria-colindexを参照のこと。
列のすべてがDOMに存在する場合、ユーザーエージェントは列の合計数を自動的に計算することができるため、この属性を設定する必要はない。しかし、列の一部のみが与えられた瞬間にDOMに存在する場合、この属性は完全なテーブルで列の数の明示的な指示を提供するために必要とされる。
著者は、完全なテーブルで列の数に等しい整数にaria-colcountの値を設定しなければならない。列の合計数が不明である場合、著者は、値がユーザーエージェントによって計算されるべきでないことを示すためにaria-colcountの値を-1に設定しなければならない。
次の例は、列2、3、4、および9がユーザーに表示される、16列をもつグリッドを示す。
例13
<div role="grid" aria-colcount="16">
<div role="rowgroup">
<div role="row">
<span role="columnheader" aria-colindex="2">First Name</span>
<span role="columnheader" aria-colindex="3">Last Name</span>
<span role="columnheader" aria-colindex="4">Company</span>
<span role="columnheader" aria-colindex="9">Phone</span>
</div>
</div>
<div role="rowgroup">
<div role="row">
<span role="gridcell" aria-colindex="2">Fred</span>
<span role="gridcell" aria-colindex="3">Jackson</span>
<span role="gridcell" aria-colindex="4">Acme, Inc.</span>
<span role="gridcell" aria-colindex="9">555-1234</span>
</div>
<div role="row">
<span role="gridcell" aria-colindex="2">Sara</span>
<span role="gridcell" aria-colindex="3">James</span>
<span role="gridcell" aria-colindex="4">Acme, Inc.</span>
<span role="gridcell" aria-colindex="9">555-1235</span>
</div>
…
</div>
</div>aria-colindex （プロパティ）§
table、grid、またはtreegrid内の列の合計数に対して、要素の列インデックスまたは位置を定義する。関連するaria-colcountおよびaria-colspanを参照のこと。
列のすべてがDOMに存在する場合、ユーザーエージェントは各セルまたはgridcellの列インデックスを自動的に計算することができるため、この属性を設定する必要はない。しかし、列の一部のみが与えられた瞬間にDOMに存在する場合、この属性は完全なテーブルに対して各セルまたはグリッドセルの列の明示的な指示を提供するために必要とされる。
著者は、aria-colindexに対する値を1以上の整数に、同じ列内の任意の以前の要素のaria-colindex値よりも大きく、かつ完全なテーブルの列の数以下に設定しなければならない。複数の列にまたがるセルまたはグリッドセルに対して、著者はスパンの先頭にaria-colindexの値を設定しなければならない。
DOMに存在する列のセットが連続する場合、かつそのセットで1つ以上の行または列にまたがるセルが存在しない場合、著者は、セットの最初の列のインデックスに値を設定し、各行にaria-colindexを置いてもよい。そうでなければ、著者は、子のすべてまたは各行の所有される要素でaria-colindexを配置すべきである。
次の例は、列2から5がユーザーに表示される、16列をもつグリッドを示す。列のセットは連続するので、aria-colindexは、各行に配置することができる。
例14
<div role="grid" aria-colcount="16">
<div role="rowgroup">
<div role="row" aria-colindex="2">
<span role="columnheader">First Name</span>
<span role="columnheader">Last Name</span>
<span role="columnheader">Company</span>
<span role="columnheader">Address</span>
</div>
</div>
<div role="rowgroup">
<div role="row" aria-colindex="2">
<span role="gridcell">Fred</span>
<span role="gridcell">Jackson</span>
<span role="gridcell">Acme, Inc.</span>
<span role="gridcell">123 Broad St.</span>
</div>
<div role="row" aria-colindex="2">
<span role="gridcell">Sara</span>
<span role="gridcell">James</span>
<span role="gridcell">Acme, Inc.</span>
<span role="gridcell">123 Broad St.</span>
</div>
…
</div>
</div>
次の例は、列2から5がユーザーに表示される、16列をもつグリッドを示す。列のセットは連続するが、セルの一部は、複数行にまたがる。その結果、aria-colindexは、各行の所有される要素のすべてに配置する必要がある。
例15
<div role="grid" aria-colcount="16">
<div role="rowgroup">
<div role="row">
<span role="columnheader" aria-colindex="2">First Name</span>
<span role="columnheader" aria-colindex="3">Last Name</span>
<span role="columnheader" aria-colindex="4">Company</span>
<span role="columnheader" aria-colindex="5">Address</span>
</div>
</div>
<div role="rowgroup">
<div role="row">
<span role="gridcell" aria-colindex="2">Fred</span>
<span role="gridcell" aria-colindex="3">Jackson</span>
<span role="gridcell" aria-colindex="4" aria-rowspan="2">Acme, Inc.</span>
<span role="gridcell" aria-colindex="5" aria-rowspan="2">123 Broad St.</span>
</div>
<div role="row">
<span role="gridcell" aria-colindex="2">Sara</span>
<span role="gridcell" aria-colindex="3">James</span>
</div>
…
</div>
</div>
次の例は、列2、3、4、および9がユーザーに表示される、16列をもつグリッドを示す。列のセットは非連続であるため、aria-colindexは、各行の所有される要素のすべてに配置する必要がある。
例16
<div role="grid" aria-colcount="16">
<div role="rowgroup">
<div role="row">
<span role="columnheader" aria-colindex="2">First Name</span>
<span role="columnheader" aria-colindex="3">Last Name</span>
<span role="columnheader" aria-colindex="4">Company</span>
<span role="columnheader" aria-colindex="9">Phone</span>
</div>
</div>
<div role="rowgroup">
<div role="row">
<span role="gridcell" aria-colindex="2">Fred</span>
<span role="gridcell" aria-colindex="3">Jackson</span>
<span role="gridcell" aria-colindex="4">Acme, Inc.</span>
<span role="gridcell" aria-colindex="9">555-1234</span>
</div>
<div role="row">
<span role="gridcell" aria-colindex="2">Sara</span>
<span role="gridcell" aria-colindex="3">James</span>
<span role="gridcell" aria-colindex="4">Acme, Inc.</span>
<span role="gridcell" aria-colindex="9">555-1235</span>
</div>
…
</div>
</div>aria-colspan （プロパティ）§
table、grid、またはtreegrid内のセルまたはグリッドセルがまたがる列の数を定義する。関連するaria-colindexおよびaria-rowspanを参照のこと。
この属性は、ネイティヴテーブルに含まれないセルおよびグリッドセルを対象にする。ネイティヴテーブルにおけるセルまたはグリッドの列スパンを定義する場合、著者は、aria-colspanの代わりにホスト言語の属性を使用すべきである。ホスト言語が同等の属性を提供するための要素でaria-colspanが使用される場合、ユーザーエージェントはaria-colspanの値を無視し、かつ代わりに支援技術にホスト言語の属性の値を公開しなければならない。
著者は、セルまたはグリッドセルに同じ行で次のセルまたはグリッドセルに重ならせる1以上の整数かつ値未満にaria-colspanの値を設定しなければならない。
aria-controls （プロパティ）§
コンテンツまたは存在が現在の要素によって制御される要素を識別する。関連するaria-ownsを参照のこと。
たとえば：
aria-current （ステート）§
コンテナーまたは関連要素のセット内の現在の項目を表す要素を示す。
aria-current属性は列挙型である。許可される値のリストに含まれない値は、あたかも値trueが提供されていたかのように支援技術によって扱われるべきである。属性が存在しないまたは属性値が空文字列またはundefinedである場合、falseのデフォルト値が適用され、かつaria-currentステートはユーザーエージェントや支援技術によって公開されてはならない。
関連要素のセット内の要素が、要素がセット内の現在の項目であることを示すように視覚的にスタイル付けされる場合にaria-current属性は使用される。たとえば：
pageトークンは、リンクが現在表示されるページを表現するために視覚的にスタイル付けされる場合に、改ページのリンクのセット内のリンクを示すために使用される。stepトークンは、リンクが現在のステップを表すように視覚的にスタイル付けされ、ステップベースのプロセスに対するステップインジケーター内のリンクを示すために使用される。locationトークンは、フローチャートの現在の成分として視覚的に注目される画像を示すために使用される。dateトークンは、カレンダー内の現在の日付を示すために使用される。timeは、タイムテーブル内の現在の時刻を示すために使用される。著者は、aria-currentをもつ現在として要素のセット内の1つの要素をマークすべきである。
著者は、aria-selectedが同じ意味を持つウィジェットでaria-selectedの代替としてaria-current属性を使用すべきでない。たとえば、tablistにおいて、aria-selectedは、現在表示されるtabpanelを示すためにtabで使用される。
注
aria-selectedをサポートするウィジェットに対するいくつかの使用事例において、currentおよびselectedは異なる意味を持つことができ、かつ要素の同じセット内で両方使用することができる。たとえば、ユーザーがtreeitemをアクティブにする場合にaria-selected="true"が表示されるページを示す一方で、aria-current="page"は、現在表示されるページを示すためにナビゲーションtreeで使用することができる。さらに、同じツリーは、「削除」や「移動」などのオプションを含むコンテキストメニューを介して、1つ以上の選択されたページ（ツリー項目）上の動作をサポートすることができる。
aria-describedby （プロパティ）§
オブジェクトを記述する要素を識別する。関連するaria-labelledbyを参照のこと。
aria-labelledby属性は、代替テキストを計算するために、その両方の参照要素でaria-describedbyに似ているが、説明がより詳細な情報を提供することを目的とする場所で、ラベルは、簡潔にすべきである。
要素またはaria-describedbyに参照される要素は、全体の記述から成る。必要に応じて、複数の要素にID参照を含む、またはIDによって参照される要素をもつ要素（たとえば、段落）のセットを囲む。
特性： 特性 値 ロールで使用される： 基本マークアップのすべての要素 値： ID参照リストaria-details （プロパティ）§
objectに説明を拡張させる、詳細を提供する要素を識別する。関連するaria-controlsを参照のこと。
aria-details属性は、aria-describedbyによって通常提供されるよりも詳細な情報を提供する単一の要素を参照する。このプロパティは、拡張記述の可用性のユーザーに認識させるだけでなく、ナビゲートすることを支援技術に可能にさせる。著者は、aria-detailsによって参照される要素がすべてのユーザーに可視であることを保証すべきである。
aria-describedbyによって参照される要素とは異なり、Accessible Name and Description仕様[accname-aam]で定義されるように、aria-detailsによって参照される要素は、アクセシブルな名前計算かアクセシブルな説明計算のいずれかで使用されない。したがって、aria-detailsによって参照される要素のコンテンツは、支援技術のユーザーに提示されるときに文字列にフラット化されない。情報の損失を引き起こすまたは拡張説明が理解することをより困難にする文字列に情報を変換する場合に、aria-detailsが特に有用である。
一部のユーザーエージェントにおいて、記述的な情報のための複数の参照関係は、アクセシビリティAPIによってサポートされていない。このような場合に、aria-describedbyとaria-detailsの両方が要素上に提供される場合、aria-detailsが優先される。
aria-detailsの一般的な用途は、拡張記述が説明コンテンツを提供するために構造的マークアップまたは他の技術の埋め込みを要求する著作で伝達される必要があるデジタル出版である。次の例は、このシナリオを示す。
例17
<img src="pythagorean.jpg" alt="Pythagorean Theorem" aria-details="det">
<details id="det">
<summary>Example</summary>
<p>
The Pythagorean Theorem is a relationship in Euclidean Geometry between the three sides of
a right triangle, where the square of the hypotenuse is the sum of the squares of the two
opposing sides.
</p>
<p>
The following drawing illustrates an application of the Pythagorean Theorem when used to
construct a skateboard ramp.
</p>
<object data="skatebd-ramp.svg" type="image/svg+xml"/>
<p>
In this example you will notice a skateboard with a base and vertical board whose width
is the width of the ramp. To compute how long the ramp must be, simply calculate the
base length, square it, sum it with the square of the height of the ramp, and take the
square root of the sum.
</p>
</details>
もう一つの方法として、次の例に示すように、aria-detailsは拡張記述を持つウェブページへのリンクを参照することができる。
例18
<img src="pythagorean.jpg" alt="Pythagorean Theorem" aria-details="det"> <p> See an <a href="http://foo.com/pt.html" id="det">Application of the Pythagorean Theorem</a>. </p>特性： 特性 値 ロールで使用される： 基本マークアップのすべての要素 値： ID参照
aria-disabled （ステート）§
要素が知覚可能であるが無効であるため、編集可能か、そうでなければ操作可能でないことを示す。関連するaria-hiddenおよびaria-readonlyを参照のこと。
例えば、ラジオグループ内の無関係なオプションは、無効化することができる。無効化された要素は、タブ順序からフォーカスを取得しないかもしれない。一部の無効要素の場合、アプリケーションは子孫へのナビゲーションをサポートしないことを選択するかもしれない。aria-disabled属性の設定に加えて、著者は、項目が無効にされていることを示すために（グレー表示など）外観を変更すべきである。
無効にされているステートは、現在の要素およびaria-disabled属性が適用される要素のすべてのフォーカス可能な子孫要素に適用される。
aria-dropeffect （プロパティ）§
[Deprecated in ARIA 1.1]ドラッグされたオブジェクトがドロップターゲットに投下される際に機能が実行できるかを示す。
注
aria-dropeffectプロパティは、WAI-ARIAの将来のバージョンで新しい機能に置き換えることが期待される。したがって、著者は、非推奨としてaria-dropeffectを扱うことを勧める。
このプロパティは、選択肢のポップアップメニューがアプリケーションによって提供されるかどうかを含め、支援技術がユーザーに利用できる可能なドラッグオプションを伝えることを可能にする。一般にドロップ効果機能は、ドロップ効果機能がドラッグされているオブジェクト次第であるので、ドラッグ操作に対してつかまれているオブジェクトにのみ提供することができる。
1つ以上のドロップ効果は、与えられた要素に対してサポートされてもよい。したがって、この属性の値は、効果の可能性を示すスペース区切りのトークンのセット、またはサポートされる操作が存在しない場合はnoneである。aria-dropeffect属性を設定することに加えて、著者は、潜在的なドロップターゲットの視覚表示を示すべきである。
aria-errormessage （プロパティ）§
objectにエラーメッセージを提供する要素を識別する。関連するaria-invalidおよびaria-describedbyを参照のこと。
aria-errormessage属性は、カスタムエラーメッセージテキストを含む別の要素を参照する。著者は、aria-errormessageと連携してaria-invalidを使用しなければならない。最初は、オブジェクトが有効な状態にあり、かつaria-invalidをfalseに設定するまたはaria-invalid属性を持たないかのいずれか、かつaria-errormessageによって参照される要素は適用されない。ユーザーがオブジェクトに無効な値を入力する場合、aria-invalidは、aria-errormessageが今適切であることを示すためにtrueに設定される。aria-errormessageが適切である場合、著者はコンテンツが非表示でなく、かつ支援技術のユーザーがコンテンツにアクセスするためにコンテンツにナビゲートすることが予想されるとして、ユーザーにコンテンツを公開するコンテナーに含まれることを保証しなければならない。
著者は、aria-liveプロパティのいずれかを適用する、または、たとえばalertなどのライブ領域ロールのいずれかを使用する、エラーメッセージの要素にライブ領域を使用してもよい。ユーザーが無効な情報を提供した後にのみ、エラーメッセージがユーザーに表示される場合、ライブ領域シナリオが存在する。メッセージは間違っているものを説明し、要求とされるもののようにユーザーにアドバイスする。たとえば、エラーメッセージは、「無効な時刻：時刻は、午前9時と午後5:00の間でなければならない。」かもしれない。次の例は、初期の有効な状態、および後続の不正な状態に対するマークアップを示す。テキスト入力object上のaria-invalidへの変更、およびエラーメッセージのテキストを含む要素上のaria-liveへの変更に注目する：
例19
<label for="startTime"> Please enter a start time for the meeting: </label> <input id="startTime" type="text" aria-errormessage="msgID" value="" aria-invalid="false"> <span id="msgID" aria-live="off" style="visibility:hidden"> Invalid time: the time must be between 9:00 AM and 5:00 PM" </span> <label for="startTime"> Please enter a start time for the meeting: </label> <input id="startTime" type="text" aria-errormessage="msgID" aria-invalid="true" value="11:30 PM" > <span id="msgID" aria-live="assertive" style="visibility:visible"> Invalid time: the time must be between 9:00 AM and 5:00 PM" </span>特性： 特性 値 ロールで使用される： 基本マークアップのすべての要素 値： ID参照
aria-expanded （ステート）§
要素、または要素が制御する別のグループ化要素が、現在展開されるまたは折りたたまれるかどうかを示す。
これは、たとえば、ツリーの一部を展開または折りたたみされるかどうかを示す。他の例において、これは、コンテンツ密度を管理するための柔軟な展開可能かつ折り畳み可能な領域をマークするためにページのセクションに適用することができる。折りたたみセクションによってユーザーインターフェイスを簡素化することは、認知や発達障害をもつ人も含め、すべての人に対するユーザービリティを向上させることができる。
aria-expanded属性をもつ要素が要素'によって所有'されない別のグループ化コンテナーの展開を制御する場合、著者はaria-controls属性を使用することによってコンテナーを参照すべきである。
aria-flowto （プロパティ）§
ユーザーの裁量で、支援技術が文書ソースの順に読み上げの一般的なデフォルトを上書きを可能にする、コンテンツの代替読み上げ順で次の要素を識別する。
aria-flowtoが単一のIDREFを持つ場合、ユーザーの要求に応じて、支援技術は、通常の文書読み込み順序を見合わせ、対象となるオブジェクトまで進むことを可能にする。 しかし、aria-flowtoが複数のIDREFSを提供される場合、支援技術はパスの選択肢として参照される要素を提示すべきである。
1つ以上のIDREFSの場合、ユーザーエージェントまたは支援技術は、ユーザーにターゲットとなる要素のいずれかにナビゲーションのオプションを与えるべきである。パス名はaria-flowto属性のターゲット要素の名前によって決定することができる。アクセシビリティAPIは、名前付けされたパスの関係を提供することができる。
aria-grabbed （ステート）§
[Deprecated in ARIA 1.1]ドラッグアンドドロップ操作で、要素の"grabbed"ステートを示す。
注
aria-grabbedプロパティは、WAI-ARIAの将来のバージョンで新しい機能に置き換えることが期待される。したがって、著者は、非推奨としてaria-grabbedを扱うことを勧める。
aria-grabbedをtrueに設定することは、要素がドラッグのために選択されていることを示す。aria-grabbedをfalseに設定することは、要素がドラッグアンドドロップ操作のためにつかむことができるが、現在つかんではないことを示す。aria-grabbedが未指定またはundefined（デフォルト）設定される場合、要素はつかむことができない。
aria-grabbedがtrueに設定される場合、著者は、すべての潜在的なドロップターゲットのaria-dropeffect属性を更新すべきである。要素がつかまされない（値がfalse、undefinedに設定される、または属性が削除される）場合、著者は関連したドロップターゲットのaria-dropeffect属性をnoneに戻すべきである。
aria-hidden （ステート）§ 値： 値 説明 false あたかも要素がレンダリングされたかのように要素がアクセシビリティAPIに公開される。 true 要素はアクセシビリティAPIから隠される。 undefined （デフォルト） 要素のhiddenステートは、要素がレンダリングされるかどうかに基づいてユーザーエージェントによって決定される。 aria-invalid （ステート）§
アプリケーションによって期待されるフォーマットに適合しない入力された値を示す。関連するaria-errormessageを参照のこと。
値が不正または範囲外であると計算される場合、アプリケーション著者は、この属性をtrueに設定すべきである。ユーザーエージェントは、ユーザーにエラーを通知すべきである。アプリケーション著者に既知である場合、アプリケーション著者は、修正のための提案を提供すべきである。
aria-requiredがtrueであるフィールドを含むデータをユーザーが提出しようと試みる場合、著者は、エラーが存在することを知らせるためにaria-invalid属性を使用してもよい。しかし、ユーザーがフォームを送信しようと試みない場合、著者は、ユーザーがまだデータを入力していないために必要なウィジェット上のaria-invalid属性を設定すべきではない。
将来の拡張のために、aria-invalid属性は列挙型とする。あたかも値trueが提供されていたかのように、許可された値のリストに認識されないすべての値は、ユーザーエージェントによって処理されなければならない。属性が存在しない、またはその値がfalseである、または属性値が空の文字列である場合、falseのデフォルト値が適用される。
aria-keyshortcuts （プロパティ）§
著者が要素にフォーカスをアクティブにするまたは与えることを実装しているキーボードショートカットを示す。
aria-kbdshortcuts属性の値は、コマンドまたはテキストボックスウィジェットをアクティブにするために押すことができるスペース区切りのキーボードショートカットのリストである。ショートカットで定義されたキーは、生成された実際の文字ではなく、物理的な押下されたキーを表す。各キーボードショートカットは、0個以上の修飾キーと指定したショートカットをアクティブにするために同時に押さなければならない正確に一つの非修飾キーを表す正符号（"+"）で区切られた1つ以上のトークンで構成される。
著者は、UI Events KeyboardEvent key Valuess仕様[uievents-key]に従って正確にキーを指定しなければならない。たとえば、"Alt"、"Control"、"Shift"、"Meta"または"AltGraph"など。Metaは、Appleコンピュータ上でCommandキーに、AltはOptionキーに対応することに注意する。
非修飾キーの有効な名前は、"A"、"B"、"1"、"2"、"$"、正符号の"+"、スペースバーの"Space"、のような任意の印刷可能な文字であるか、またはUI Events KeyboardEvent key Values仕様[[uievents-key]で指定されるその他の非修飾キーの名前である―たとえば、"Enter"、"Tab"、"ArrowRight"、"PageDown"、"Escape"または"F1"。スペースバーに対する"Space"の使用は、スペースまたはスペースバーキーが' 'としてエンコードされかつ空白文字として扱われるので、UI Events KeyboardEvent key Values仕様[uievents-key]の例外である。
著者は、修飾キーがキーボードショートカットの一部である場合に、その修飾キーが最初に来ることを保証しなければならない。著者は、必要とされる非修飾キーがショートカットの一部である場合に、その非修飾キーが最後に来ることを保証しなければならない。修飾キーの順序は特に重要でないため、"Alt+Shift+T"と"Shift+Alt+T"は同等であるが、"T+Shift+Alt"はいずれの修飾キーも最初に来ないため有効ではなく、かつ"Alt"は少なくとも1つの非修飾キーを含まないため有効ではない。
アルファベットのキーを指定する場合、大文字と小文字の両方の異体字は、同等であるとみなされる："a"と"A"は同じである。
キーボードショートカットを実装する場合、著者は、予期しない結果を避けるためにサポートすることを意図するキーボードを検討すべきである。キーボードのデザインは、使用されるデバイスおよびサポートされる言語に基づいて大きく変化する。たとえば、多くの修飾キーは、共通の句読記号を作成するために他のキーと組み合わせて使用され、言語を切り替えるためにバイリンガルキーボードのキーボードの側面を切り替え、他の多数の機能を実行する。
多くのサポートされるキーボードの場合、数字および共通の句読文字はしばしば修飾子を必要とするため、著者はASCII文字以外のキーを回避することによって衝突を防ぐことができる。ここで、入力されたキーボードショートカットは、生成されたキーに一致しない。たとえば、フランス語のキーボードレイアウトにおいて、"Control+2"として定義されるキーボードショートカットはフランス語のキーボードで"2"の文字を入力する方法であるかあいまいになるので、Controlキーを押すまで数字は利用不能となる。
使用される文字が修飾キーによって決定される場合、著者は、得られた文字ではなく、キーによって生成されたものとして、文字を生成するために使用される実際のキーを指定しなければならない。この規則は、キーがショートカットを生成するために使用されなければならないものを正確に伝えることを支援技術を可能にする。たとえば、ほとんどの米国英語キーボードで、百分率記号"%"は、Shift+5を押しDて表示することができる。このショートカットを指定する正確な方法は、"Shift+5"である。"%"または"Shift+%"を指定することは不正確である。しかし、"%"および"Shift+%"が国際的なキーボードで正確である場合に、一部の国際的なキーボードの百分率記号は無変更キーであるかもしれない。
指定する必要があるキーはホスト言語で不当である、または文字列を終了させる場合、著者はキーを指定するためにホスト言語の文字列エスケープシーケンスを使用しなければならない。たとえば、ダブルクォーテーションは、HTMLで"Shift+'"とエンコードすることができる。
有効なキーボードショートカットの例は次のとおり：
ユーザーエージェントは、aria-keyshortcuts属性に反応してキーボードの動作を変更してはならない。著者は、aria-keyshortcutsを処理するために用意されたキーボードイベントを処理しなければならない。aria-keyshortcuts属性は、支援技術がユーザーにこの情報を伝えることができるように、このショートカットの存在を公開する。
著者は、すべてのユーザーが、ツールチップの使用を通してなど、ショートカットを発見することができるようにキーボードショートカットを公開する方法を提供すべきである。著者は無効要素に適用されるaria-keyshortcutsが使用できないことを保証しなければならない。
著者は、オペレーティングシステム、ユーザーエージェント、または支援技術の機能を阻害するショートカットキーの実装を避けるべきである。これは、どのキーを割り当てるかと、キーがユーザーに利用可能であるコンテキストおよび条件の両方を慎重に検討することが著者に要求される。ガイダンスについては、WAI-ARIA Authoring Practices Guide [wai-aria-practices-1.1]のキーボードショートカットの節を参照のこと。
特性： 特性 値 ロールで使用される： 基本マークアップのすべての要素 値： 文字列aria-label （プロパティ）§
現在の要素にラベルを付ける文字列の値を定義する。関連するaria-labelledbyを参照のこと。
aria-labelの目的はaria-labelledbyと同じである。これは、ユーザーにオブジェクトの認識可能な名前を提供する。ラベルをマッピングする最も一般的なアクセシビリティAPIは、アクセシブルな名前プロパティである。
ラベルテキストが画面上で可視である場合、著者はaria-labelledbyを使用すべきであり、aria-labelを使用すべきでない。要素の名前が要素のコンテンツからプログラム的に決定することができない事例があってもよく、可視ラベルの提供が所望のユーザー体験でない場合がある。これはブラウザーのツールチップを提示するかもしれないにもかかわらず、ほとんどのホスト言語は、要素に名前を付けるために使用できる属性を提供する（たとえば、HTMLにおけるtitle属性）。可視ラベルまたは可視ツールチップが望ましくないケースで、著者は、aria-labelを使用して要素のアクセシブルな名前を設定してもよい。テキストによる代替演算により必要に応じて、アクセシブルな名前プロパティを計算する際に、ユーザーエージェントはaria-labelよりaria-labelledbyを優先する。
aria-labelledby （プロパティ）§
現在の要素にラベルを付ける要素を識別する。関連するaria-describedbyを参照のこと。
aria-labelledbyの目的はaria-labelと同じである。これは、ユーザーにオブジェクトの認識可能な名前を提供する。ラベルをマッピングする最も一般的なアクセシビリティAPIは、アクセシブルな名前プロパティである。
インターフェイスが画面上で可視ラベルを持つことが不可能であるような場合、著者はaria-labelを使用すべきであり、aria-labelledbyを使用すべきではない。テキストによる代替演算により必要に応じて、アクセシブルな名前プロパティを計算する際に、ユーザーエージェントはaria-labelよりaria-labelledbyを優先する。
aria-labelledby属性は、代替テキストを計算するために、その両方の参照要素でaria-describedbyに似ているが、説明がより詳細な情報を提供することを目的とする場所で、ラベルは、簡潔にすべきである。
注
アメリカ英語でこのプロパティの期待される綴りは"labeledby"である。しかし、このプロパティがマップされるアクセシビリティAPI機能には、"labelledby"の綴りを確立している。このプロパティは、慣習に一致し、開発者に対する難しさを最小化するためにそのように綴られる。
特性： 特性 値 ロールで使用される： 基本マークアップのすべての要素 値： ID参照リストaria-level （プロパティ）§
構造内の要素の階層レベルを定義する。
これは、ツリー項目、文書内の見出し、ネストされたグリッド、ネストされたtablists、およびコンテナー内に出現するまたは所有権の階層に参加することができる他の構造アイテムに、ツリーの内側で適用することができる。aria-levelの値は1以上の整数である。
レベルは深さとともに増加する。DOMの祖先が正確にレベルを表さない場合、著者は、明示的にaria-level属性を定義すべきである。
この属性は、たとえば、ロールgroupをもつ要素よりもむしろロールtreeitemをもつ要素で、セットの方向内のリーフノードとして動作する要素に適用される。これは、セット内の複数の要素がこの属性に対して同じ値を持ってもよいことを意味する。属性はコンテナーに単一の値を提供するためにより少ない反復的になるが、リーフノードにこれを制限することは、属性を使用するための支援技術に対する単一の方法があることを保証する。
DOMの祖先が正確にレベルを表す場合、ユーザーエージェントは、文書構造から項目のレベルを計算することができる。文書構造またはaria-ownsから算出することができない場合に、この属性はレベルの明示的指示を提供するために使用できる。レベルの自動計算に対するユーザーエージェントのサポートは異なるかもしれない。著者は、この属性が必要かどうかを判断するためにユーザーエージェントおよび支援技術を試験すべきである。著者がレベルを計算するためにユーザーエージェントに対して意図する場合、著者は、この属性を省略すべきである。
注
treegridについて、aria-levelは、ロールgridcellをもつ要素でなく、ロールrowをもつ要素でサポートされる。一見すると、これはtreeitem要素上のaria-levelのアプリケーションと矛盾するように見えるかもしれないが、gridcellが各rowの水平方向内でリーフノードであるのに対して、gridの垂直方向内のリーフノードとしてそのrowの動作で一貫している。レベルは行内のセルのセットでサポートされないので、aria-level属性はロールrowをもつ要素に適用される。
aria-live （プロパティ）§
要素が更新されることを示し、ユーザーエージェントの更新の種類、支援技術の種類を説明し、ユーザーがライブ領域から期待することができる。
この属性の値は、重要度で表現される。領域がpoliteとして指定される場合、支援技術はユーザーに更新に通知するが、一般に現在のタスクを中断せず、更新が低い優先度を取る。領域がassertiveとして指定される場合、支援技術はすぐにユーザーに通知し、かつ潜在的に前の更新の音声キューをクリアすることができる。
ポライトネスレベルは、本質的に更新のための順序付けメカニズムであり、ユーザーエージェントまたは支援技術に強い提案として供給する。値は、ユーザーエージェント、支援技術、またはユーザーによって上書きされるかもしれない。たとえば、支援技術は変更がキー入力やマウスのクリックに反応して発生したと判断できる場合、たとえaria-live属性の値が異なって明言する場合であっても、支援技術はすぐにその変更を提示することができる。
別のユーザーが異なるニーズを持つので、一般に定義されたベースラインからの一定のポライトネスレベルをもつライブ領域へユーザーの支援技術の応答を微調整するのはユーザー次第である。ユーザーがキューと中断に制御をふるうことができるように、支援技術は、増減する粒度のレベルを実装することを選択できる。
プロパティが更新を送信する必要があるオブジェクトに設定されない場合、ポライトネスレベルは、aria-live属性を設定する最も近い祖先の値である。
aria-live属性は、ライブ領域に変更の提示の順序に対する主要な決定である。aria-live属性が祖先チェーンに設定されない場合（たとえば、log変更はデフォルトでpoliteである）、実装はまた、ロールでポライトネスのデフォルトのレベルを考慮する。assertiveである項目は、politeな項目の直後に表示される。ユーザーエージェントまたは支援技術は、断定的な変化が発生する際にキューに入れられた変更をクリアするために選択してもよい。（たとえば、断定的な領域における変更は、すべての現在キューの変更を削除するかもしれない）
ライブ領域がpoliteとしてマークされる場合、支援技術は、現在の文の話の終わりまたはユーザーが入力を一時停止する際のように、次の優雅な機会に更新を発表すべきである。ライブ領域がassertiveとしてマークされる場合、支援技術はすぐにユーザーに通知すべきである。中断はユーザーを混乱させるか、ユーザーの現在のタスクの未完了を引き起こすかもしれないため、中断が不可欠でない限り、著者は断定的な値を使用すべきでない。
aria-modal （プロパティ）§
表示される際に要素がモーダルであるかどうかを示す。
aria-modal属性は、"modal"要素の存在がページ上の他のコンテンツの利用を排除することを示すために使用される。たとえば、モーダルダイアログが表示される際に、モーダルダイアログがフォーカスを失うまたはもはや表示されないまで、ユーザーの相互作用は、ダイアログのコンテンツに限定されることが期待される。
モーダル要素が表示される際に、フォーカスが明示的に別の場所に設定されない限り、支援技術は要素にナビゲートすべきである。支援技術は、モーダル要素のコンテンツへのナビゲーションを制限してもよい。フォーカスがモーダル要素の外側の要素に移動する場合、支援技術は、モーダル要素へのへのナビゲーションを制限すべきでない。
モーダル要素が表示される際に、著者は、インターフェイスがモーダル要素の子孫のみを用いて制御することができることを保証しなければならない。言い換えると、モーダルダイアログが閉じるボタンを持つ場合、ボタンはダイアログの子孫となるべきである。モーダル要素が表示される際に、ホスト言語にそのようにする能力が存在する場合、著者は、（HTMLにおける"不活性サブツリー"など）不活性として他のすべてのコンテンツをマークすべきである。
値： 値 説明 false （デフォルト） 要素はモーダルでない。 true 要素はモーダルである。aria-multiline （プロパティ）§
テキストボックスが複数行の入力または単一行のみを受け入れるかどうかを示す。
注
ほとんどのユーザーエージェントの実装において、ENTERキーまたはRETURNキーのデフォルトの動作は、HTMLで、単一行と複数行のテキストフィールドとの間で異なる。ユーザーが単一行の<input type="text">要素にフォーカスを持つ場合、キーストロークは通常、フォームを送信する。ユーザーが複数行の<textarea>要素にフォーカスを持つ場合、キーストロークは改行を挿入する。WAI-ARIA textboxロールは、aria-multiline属性をもつボックスのこれらの種類を区別する。よって著者は、フィールドを設計する際にこの区別を意識することを勧める。
aria-multiselectable （プロパティ）§
ユーザーが現在の選択可能な子孫から複数の項目を選択できることを示す。
著者は、選択した子孫がtrueに設定されるaria-selected属性を持ち、選択可能な子孫がfalseに設定されるaria-selected属性を持つことを保証すべきである。著者は選択可能でない子孫上のaria-selected属性を使用すべきでない。
注
リストおよびツリーは、ユーザーに一度に複数の項目の選択を可能にするかもしれないロールの例である。
値： 値 説明 false （デフォルト） 1つのみの項目を選択することができる。 true ウィジェット内の複数のアイテムを一度に選択することができる。aria-orientation （プロパティ）§
要素の向きが水平、垂直または未知/不明瞭であるかどうかを示す。
値： 値 説明 horizontal 要素は、水平に方向を合わせる。 undefined （デフォルト） 要素の方向は未知/不明瞭である。 vertical 要素は、垂直に方向を合わせる。aria-owns （プロパティ）§
DOM階層が関係を表すために使用することができないDOM要素間の、可視的、機能的、またはコンテキストの親子関係を定義するために要素を識別する。関連するaria-controlsを参照のこと。
aria-owns属性の値は、IDによって文書における1つ以上の要素を参照するIDREFSのスペース区切りリストである。aria-ownsを追加する理由は、DOMから推測する他の方法では不可能である支援技術に親子コンテキストの関係を公開することである。
要素がaria-ownsとDOMの子の両方を持ち、親子関係に対して子要素の順序が最初のDOMの子である場合、要素はaria-ownsで参照される。著者がDOMの子が最初でないことを意図する場合、望ましい順序でaria-ownsにおいてDOMの子を一覧表示する。著者は、DOM階層の代替としてaria-ownsを使用すべきでない。関係がDOMで表現される場合、aria-ownsを使用してはならない。著者は、要素のIDがいつでも複数の他の要素のaria-owns属性で指定されないことを保証しなければならない。言い換えれば、要素は、1つの明示的な所有者のみを持つことができる。
aria-placeholder （プロパティ）§
コントロールが値を持たない場合にユーザーにデータ入力を支援することを意図される短いヒント（単語または短い語句）を定義する。ヒントは、サンプル値または予想される形式の簡単な説明であるかもしれない。
その目的が異なるために著者は、ラベルの代わりにaria-placeholderを使用すべきでない。ラベルは、情報の種類が予想されるかを示す。プレースホルダーテキストは、期待値についてのヒントである。関連するaria-labelledbyおよびaria-labelを参照のこと。
著者は、コントロールの値が空文字列である任意の時刻でヒントテキストを表示することにより、ユーザーにこのヒントを提示すべきである。これは、コントロールが最初にフォーカスを受け取る場合、およびユーザーが以前に入力した値を削除する場合が含まれる。
注
関連するHTML placeholder属性の場合と同様に、表示されるラベルの代わりとしてプレースホルダーテキストの使用は、高齢ユーザーおよび、認知、運動、洗練された運動技能または視覚障害をもつユーザーを含むさまざまなユーザーに対するコントロールのアクセシビリティおよびユーザービリティを減らすことができる。コントロールのラベルで与えられるヒントは常に示される一方で、プレースホルダー属性で指定される短いヒントは、ユーザーが値を入力する前にのみ表示される。さらに、プレースホルダテキストは、予め埋められた値に間違われるかもしれず、一般に実装されるプレースホルダテキストのデフォルト色は不十分なコントラストを提供し、かつ個別の可視ラベルの不足がコントロール上のフォーカスを設定するために利用可能なヒット領域のサイズを減らす。
次の例は、ユーザーが値を入力しているsearchboxを示す：
例22
<span id="label">Birthday:</span> <div contenteditable role="searchbox" aria-labelledby="label" aria-placeholder="MM-DD-YYYY">03-14-1879</div>
次の例は、ユーザーがまだ値を入力していないまたは以前に入力した値を削除していたのと同じsearchboxを示す：
例23
<span id="label">Birthday:</span> <div contenteditable role="searchbox" aria-labelledby="label" aria-placeholder="MM-DD-YYYY">MM-DD-YYYY</div>
aria-posinset （プロパティ）§
リスト項目またはツリー項目の現在のセットにおける要素の数または位置を定義する。セットにおけるすべての要素がDOMに存在する場合は必要ない。関連するaria-setsizeを参照のこと。
セットにおけるすべての項目が文書構造に存在する場合、ユーザーエージェントが自動的に各項目のセットサイズおよび位置を計算することができるため、この属性を設定する必要はない。しかし、セットの一部だけが与えられた瞬間に文書構造に存在する場合、このプロパティは、要素の位置の明確な表示を提供するために必要とされる。
次の例は、16のセットで5から8の項目を示す。
例24
<h2 id="label_fruit"> Available Fruit </h2> <ul role="listbox" aria-labelledby="label_fruit"> <li role="option" aria-setsize="16" aria-posinset="5"> apples </li> <li role="option" aria-setsize="16" aria-posinset="6"> bananas </li> <li role="option" aria-setsize="16" aria-posinset="7"> cantaloupes </li> <li role="option" aria-setsize="16" aria-posinset="8"> dates </li> </ul>
著者は、そのサイズが既知の場合に1以上かつセットのサイズ以下の整数をaria-posinsetに値を設定しなければならない。著者はaria-setsizeを使用すべきである。
menuitem、menuitemcheckbox、またはmenuitemradioのaria-posinsetを公開する場合、著者は、任意のセパレーターを除いて、menu内の項目の合計数に対するaria-posinsetの値を設定すべきである。
aria-pressed （ステート）§ 値： 値 説明 false 要素は押されていることをサポートするが、現在押されていない。 mixed トライステートトグルボタンに対する混合モード値を示す。 true 要素が押される。 undefined （デフォルト） 要素が押されている状態をサポートしない。 aria-readonly （プロパティ）§
要素は編集可能でないが、他の方法で動作可能であることを示す。関連するaria-disabledを参照のこと。
これは、ユーザーは読むことができるが、ウィジェットの値を設定できないことを意味する。読み取り専用の要素は、ユーザーに関連し、アプリケーションの著者は、要素または要素のフォーカス可能な子孫にナビゲーションを制限すべきでない。要素の値をコピーするなどの他のアクションはまたサポートされる。これは、アプリケーションが子孫へのユーザーナビゲーションを許可しないかもしれない、無効要素とは対照的である。
例は以下を含む：
aria-relevant （プロパティ）§
ライブ領域内のアクセシビリティツリーが変更される際にユーザーエージェントがどの通知をトリガーするかを示す。関連するaria-atomicを参照のこと。
属性は、次の値のスペースで区切りリストとして表現される：additions、removals、textまたは包括的な値all。
単にプレゼンテーション的なものとは対照的に、これは、重要なセマンティック的な変化を説明するために使用される。たとえば、ログの上部から除去されたノードは、単に他のエントリーに対して場所を作成する目的のために除去され、そのノードの除去は意味を持たない。しかし、バディリストの場合、バディ名の除去は、もはやオンラインでないことを示す、そしてこれは意味のあるイベントである。その場合aria-relevantはallに設定される。aria-relevant属性が提供されない場合、デフォルト値、additions text、テキストの修正表示およびノードの追加は関連するが、ノード削除は無関係である。
注
removalsまたはallのaria-relevant値は、控えめに使用される。チャットルームを退出するバディのような、コンテンツの除去が重要な変更を表す場合、支援技術は、コンテンツの除去を告知のみを必要とする。
注
指定された値の1つが'removals'または'all'である場合、テキストの除去は適切に考慮されるべきである。たとえば、デフォルトのaria-relevant値をもつライブ領域において'foo'から'bar'へのテキストの変更のために、テキスト追加（ 'bar'）は話されるが、テキスト除去（'foo'）話されない。
aria-relevantは、ライブ領域のオプションの属性である。これは支援技術に提案するが、支援技術はすべての関連する種類の変更を提示する必要はない。
aria-relevantが定義されない場合、要素の値は定義される値をもつ最も近い祖先から継承される。値はトークンリストであるが、継承された値は追加式ではない。子孫要素に供給される値は、祖先要素から継承された値をすべて完全に上書きする。
テキストの変更がrelevantとして表記される場合、ユーザーエージェントは、あたかもアクセシブルな名前がコンテンツから（nameFrom: contents）決定されたかのように、ライブ領域の代替テキストの計算に影響を与える任意の子孫ノード変更を監視しなければならない。たとえば、含まれる画像のHTML alt属性が変更された場合、テキストの変更はトリガーされる。しかし、たとえそのノードがライブ領域に含まれる要素によって参照された（aria-labelledby経由）としても、ライブ領域外のノードへのテキストの変更があった場合、変更はトリガーされない。
aria-required （プロパティ）§
フォームが送信される前に要素でユーザー入力が必須であることを示す。
ユーザーがアドレスフィールドに記入する必要がある場合、著者は、フィールドのaria-required属性をtrueに設定する必要がある。
注
要素が必要とされるという事実は多くの場合、視覚的に提示される（たとえばウィジェットの後に記号やシンボルなど）。aria-required属性の使用は、著者に要素が必要とされることを支援技術に明示的に伝えることを可能にする。
厳密に等価なネイティヴ属性が利用可能である場合を除き、ホスト言語は、著者にユーザーによって入力または選択を必要とするホスト言語フォーム要素上のaria-required属性の使用を可能にすべきである。
aria-roledescription （プロパティ）§
スクリーンリーダーなどの一部の支援技術は、ユーザーエクスペリエンスの一部として要素のロールを提示する。そのような支援技術は一般に、ロールの名前をローカライズし、しかもカスタマイズしてもよい。この支援技術のユーザーは、ウィジェットである場合、要素の目的を理解するために、どのように相互作用するかを、"region,"、"button"、または"slider"のように、ロール名のプレゼンテーションに依存する。
aria-roledescriptionプロパティは、どのように支援技術がロールの名前をローカライズして表現するかを上書きするための能力を著者に与える。このように、不適切にaria-roledescriptionを使用することは、要素を理解するまたは要素と対話するためのユーザーの能力を阻害するかもしれない。著者は、groupまたはregionのような非対話型のコンテナーロールの目的を明確にするため、またはwidgetのより具体的な説明を提供するために、aria-roledescriptionの使用を制限すべきである。
aria-roledescriptionを使用する場合、著者は次のことを保証すべきである：
aria-roledescriptionが適用される要素は、妥当なWAI-ARIAロールを持つ、または暗黙のWAI-ARIAロールセマンティックを持つ。aria-roledescriptionの値は、空でないまたは空白文字のみを含まない。次のいずれかの条件が存在する場合、ユーザーエージェントはaria-roledescriptionプロパティを公開してはならない：
aria-roledescriptionが適用される要素は、妥当なWAI-ARIAロールを持たない、または暗黙WAI-ARIAロールセマンティックを持たない。支援技術は、要素のロールを提示する際にaria-roledescriptionの値を使用すべきであるが、aria-roledescriptionの値を持つ要素のロールに基づいて他の機能を変更すべきでない。たとえば、次のregionまたはbuttonにナビゲートするための機能を提供する支援技術は、この機能がaria-roledescriptionを持つ領域およびボタンにナビゲートできるようにすべきである。
次の2つの例は、非対話型コンテナーがウェブベースのプレゼンテーションアプリケーションにおける"スライド"であることを示すためにaria-roledescriptionの使用を示す。
例25
<div role="region" aria-roledescription="slide" id="slide42" aria-labelledby="slide42heading"> <h1 id="slide42heading">Quarterly Report</h1> </div>
例26
<section aria-roledescription="slide" id="slide42" aria-labelledby="slide42heading"> <h1 id="slide42heading">Quarterly Report</h1> </section>
前の例において、スクリーンリーダーのユーザーは、より曖昧な"Quarterly Report, region"または"Quarterly Report, group."よりもむしろ、"Quarterly Report, slide"と聞こえるだろう。
次の例は、ウェブベースの電子メールクライアントにおけるbuttonが"attachment"に関連付けられることを示すためのaria-roledescriptionの使用を示す。
例27
<div role="button" tabindex="0" aria-roledescription="attachment button">family_reunion.jpg</div>
例28
<button aria-roledescription="attachment button">family_reunion.jpg</button>
前の2つの例で、"button"はローカライズされた説明の一部であるため、スクリーンリーダーのユーザーは依然としてそのコントロールを操作する方法を理解すべきである。
特性： 特性 値 ロールで使用される： 基本マークアップのすべての要素 値： 文字列aria-rowcount （プロパティ）§
テーブル、grid、treegridまたはtreegrid内の行の合計数を定義する。関連するaria-rowindexを参照のこと。
行のすべてがDOMに存在する場合、ユーザーエージェントは行の合計数を自動的に計算することができるため、この属性を設定する必要はない。しかし、行の一部のみが与えられた瞬間にDOMに存在する場合、この属性は完全なテーブルで行の数の明示的な指示を提供するために必要とされる。
著者は、完全なテーブルで行の数に等しい整数にaria-rowcountの値を設定しなければならない。行の合計数が不明である場合、著者は、値がユーザーエージェントによって計算されるべきでないことを示すためにaria-rowcountの値を-1に設定しなければならない。
次の例は、最初の行と行100から102がユーザーに表示される、2000行をもつグリッドを示す。
例29
<div role="grid" aria-rowcount="2000">
<div role="rowgroup">
<div role="row" aria-rowindex="1">
<span role="columnheader">First Name</span>
<span role="columnheader">Last Name</span>
<span role="columnheader">Company</span>
<span role="columnheader">Phone</span>
</div>
</div>
<div role="rowgroup">
<div role="row" aria-rowindex="100">
<span role="gridcell">Fred</span>
<span role="gridcell">Jackson</span>
<span role="gridcell">Acme, Inc.</span>
<span role="gridcell">555-1234</span>
</div>
<div role="row" aria-rowindex="101">
<span role="gridcell">Sara</span>
<span role="gridcell">James</span>
<span role="gridcell">Acme, Inc.</span>
<span role="gridcell">555-1235</span>
</div>
<div role="row" aria-rowindex="102">
<span role="gridcell">Taylor</span>
<span role="gridcell">Johnson</span>
<span role="gridcell">Acme, Inc.</span>
<span role="gridcell">555-1236</span>
</div>
</div>
</div>aria-rowindex （プロパティ）§
table、grid、またはtreegrid内の行の合計数に対して、要素の行インデックスまたは位置を定義する。関連するaria-rowcountおよびaria-rowspanを参照のこと。
行のすべてがDOMに存在する場合、ユーザーエージェントは各行のインデックスを自動的に計算することができるため、この属性を設定する必要はない。しかし、行の一部のみが与えられた瞬間にDOMに存在する場合、この属性は完全なテーブルに対して各行の位置の明示的な指示を提供するために必要とされる。
著者は、aria-rowindexに対する値を1以上の整数に、任意の以前の行のaria-rowindex値よりも大きく、かつ完全なテーブルの行の数以下に設定しなければならない。複数の行にまたがるセルまたはグリッドセルに対して、著者はスパンの先頭にaria-rowindexの値を設定しなければならない。
著者は、各行にaria-rowindexを配置すべきである。著者はまた、各行の子のすべてまたは所有される要素上のaria-rowindexを配置してもよい。
次の例は、最初の行と行100から102がユーザーに表示される、2000行をもつグリッドを示す。
例30
<div role="grid" aria-rowcount="2000">
<div role="rowgroup">
<div role="row" aria-rowindex="1">
<span role="columnheader">First Name</span>
<span role="columnheader">Last Name</span>
<span role="columnheader">Company</span>
<span role="columnheader">Phone</span>
</div>
</div>
<div role="rowgroup">
<div role="row" aria-rowindex="100">
<span role="gridcell">Fred</span>
<span role="gridcell">Jackson</span>
<span role="gridcell">Acme, Inc.</span>
<span role="gridcell">555-1234</span>
</div>
<div role="row" aria-rowindex="101">
<span role="gridcell">Sara</span>
<span role="gridcell">James</span>
<span role="gridcell">Acme, Inc.</span>
<span role="gridcell">555-1235</span>
</div>
<div role="row" aria-rowindex="102">
<span role="gridcell">Taylor</span>
<span role="gridcell">Johnson</span>
<span role="gridcell">Acme, Inc.</span>
<span role="gridcell">555-1236</span>
</div>
</div>
</div>
次の例は、各列のすべての所有される要素の上に配置されるaria-rowindexをもつ前の例からグリッドを示す。
例31
<div role="grid" aria-rowcount="2000">
<div role="rowgroup">
<div role="row" aria-rowindex="1">
<span role="columnheader" aria-rowindex="1">First Name</span>
<span role="columnheader" aria-rowindex="1">Last Name</span>
<span role="columnheader" aria-rowindex="1">Company</span>
<span role="columnheader" aria-rowindex="1">Phone</span>
</div>
</div>
<div role="rowgroup">
<div role="row" aria-rowindex="100">
<span role="gridcell" aria-rowindex="100">Fred</span>
<span role="gridcell" aria-rowindex="100">Jackson</span>
<span role="gridcell" aria-rowindex="100">Acme, Inc.</span>
<span role="gridcell" aria-rowindex="100">555-1234</span>
</div>
<div role="row" aria-rowindex="101">
<span role="gridcell" aria-rowindex="101">Sara</span>
<span role="gridcell" aria-rowindex="101">James</span>
<span role="gridcell" aria-rowindex="101">Acme, Inc.</span>
<span role="gridcell" aria-rowindex="101">555-1235</span>
</div>
<div role="row" aria-rowindex="102">
<span role="gridcell" aria-rowindex="102">Taylor</span>
<span role="gridcell" aria-rowindex="102">Johnson</span>
<span role="gridcell" aria-rowindex="102">Acme, Inc.</span>
<span role="gridcell" aria-rowindex="102">555-1236</span>
</div>
</div>
</div>aria-rowspan （プロパティ）§
table、grid、またはtreegrid内のセルまたはグリッドセルがまたがる行の数を定義する。関連するaria-rowindexおよびaria-colspanを参照のこと。
この属性は、ネイティヴテーブルに含まれないセルおよびグリッドセルを対象にする。ネイティヴテーブルにおけるセルまたはグリッドの行スパンを定義する場合、著者は、aria-rowspanの代わりにホスト言語の属性を使用すべきである。ホスト言語が同等の属性を提供するための要素でaria-rowspanが使用される場合、ユーザーエージェントはaria-rowspanの値を無視し、かつ代わりに支援技術にホスト言語の属性の値を公開しなければならない。
著者は、セルまたはグリッドセルに同じ行で次のセルまたはグリッドセルに重ならせる1以上の整数かつ値未満にaria-rowspanの値を設定しなければならない。値を0に設定することは、セルまたはグリッドセルが行グループ内のすべての残りの行にまたがることを示す。
aria-selected （ステート）§
さまざまなウィジェットの現在の"selected"ステートを示す。関連するaria-checkedおよびaria-pressedを参照のこと。
この属性は、単一選択および複数選択のウィジェットで使用される：
aria-multiselectable属性がtrueであるコンテナーの任意の選択可能な子孫がaria-selected属性のtrueまたはfalseのいずれかの値を指定することを保証すべきである。任意のaria-selectedの明示的な割り当ては、フォーカスに基づく暗黙の選択よりも優先される。ウィジェットにおいてどのDOM要素も明示的にselectedとしてマークされない場合、支援技術は、管理フォーカスウィジェットのキーボードフォーカスに従う暗黙の選択を伝えてもよい。ウィジェットにおいて任意のDOM要素が明示的にselectedとしてマークされる場合、ユーザーエージェントは、ウィジェットに対して暗黙の選択を伝えてはならない。
aria-setsize （プロパティ）§
リスト項目またはツリー項目の現在のセット内の項目の数を定義する。セットにおけるすべての要素がDOMに存在する場合は必要ない。関連するaria-posinsetを参照のこと。
このプロパティは、セットのメンバーを収集するコンテナー要素ではなく、セットのメンバーにマークされる。要素を言及することでユーザーを方向づけることは、"Yのうち項目X"であり、支援技術は、aria-posinset属性に等しいXおよびaria-setsize属性に等しいYを使用する。
セットにおけるすべての項目が文書構造に存在する場合、ユーザーエージェントが自動的に各項目のセットサイズおよび位置を計算することができるため、この属性を設定する必要はない。しかし、セットの一部だけが与えられた瞬間に文書構造に存在する場合（文書サイズを削減するために）、このプロパティは、セットの大きさの明確な表示を提供するために必要とされる。
著者は、セットにおける項目の数に等しい整数にaria-setsizeの値を設定しなければならない。項目の合計数が不明である場合、著者はaria-colcountの値を-1に設定すべきである。
menuitem、menuitemcheckbox、またはmenuitemradioでaria-setsizeを公開する場合、著者はすべてのセパレーターを除く、menu内の項目の合計数に基づいてaria-setsizeの値を設定すべきである。
次の例は、16のセットで5から8の項目を示す。
例32
<h2 id="label_fruit"> Available Fruit </h2> <ul role="listbox" aria-labelledby="label_fruit"> <li role="option" aria-setsize="16" aria-posinset="5"> apples </li> <li role="option" aria-setsize="16" aria-posinset="6"> bananas </li> <li role="option" aria-setsize="16" aria-posinset="7"> cantaloupes </li> <li role="option" aria-setsize="16" aria-posinset="8"> dates </li> </ul>
次の例は、合計サイズが不明であるセットで5から8の項目を示す。
例33
<h2 id="label_fruit"> Available Fruit </h2> <ul role="listbox" aria-labelledby="label_fruit"> <li role="option" aria-setsize="-1" aria-posinset="5"> apples </li> <li role="option" aria-setsize="-1" aria-posinset="6"> bananas </li> <li role="option" aria-setsize="-1" aria-posinset="7"> cantaloupes </li> <li role="option" aria-setsize="-1" aria-posinset="8"> dates </li> </ul>
aria-sort （プロパティ）§
テーブルまたはグリッド内の項目が昇順または降順にソートされるかどうかを示す。
著者は、テーブル見出しまたはグリッド見出しにこのプロパティを適用すべきである。プロパティが提供されない場合、定義されるソート順は一切存在しない。各テーブルまたはグリッドのために、著者は、一度に1見出しのみaria-sortを適用すべきである。
aria-valuemax （プロパティ）§
範囲ウィジェットに対する最大許容値を定義する。
著者は、aria-valuemaxの値がaria-valueminの値以上であることを保証しなければならない。aria-valuenowが既知の最大値および最小値を持つ場合、著者はaria-valuemaxおよびaria-valueminに対してプロパティを提供すべきである。
注
このプロパティによって定義される、最大値に到達するまで増加させることができる、指定される値で開始する範囲ウィジェット。最小および最大の値を宣言することは、支援技術にユーザーの範囲サイズを伝えることを可能にする。
aria-valuemin （プロパティ）§
範囲ウィジェットに対する最小許容値を定義する。
著者は、aria-valueminの値がaria-valuemaxの値以下であることを保証しなければならない。aria-valuenowが既知の最大値および最小値を持つ場合、著者はaria-valuemaxおよびaria-valueminに対してプロパティを提供すべきである。
注
このプロパティによって定義される、最小値に到達するまで減少させることができる、指定される値で開始する範囲ウィジェット。最小および最大の値を宣言することは、支援技術にユーザーの範囲サイズを伝えることを可能にする。
aria-valuenow （プロパティ）§
範囲ウィジェットに対する現在値を定義する。関連するaria-valuetextを参照のこと。
このプロパティは、たとえば、スライダーやプログレスバーなどの範囲ウィジェットで使用される。
現在値が既知でない（たとえば、不確定な進捗バー）場合、著者はaria-valuenow属性を設定すべきでない。aria-valuenow属性が存在しない場合、いかなる情報も現在値について示されない。aria-valuenowが既知の最大値および最小値を持つ場合、著者はaria-valuemaxおよびaria-valueminに対してプロパティを提供すべきである。
aria-valuenowの値は10進数である。範囲が数値のセットである場合、aria-valuenowは、この値のいずれかである。たとえば、範囲が[0, 1]である場合、有効なaria-valuenowは0.5である。-2.5または1.1のような、範囲外の値は無効である。
progressbar要素およびscrollbar要素の場合、支援技術は、両方が定義される場合はaria-valueminからaria-valuemaxまでの範囲上の位置として算出される、パーセントとしてユーザーに値をレンダリングするべきであり、そうでなければ、パーセントインジケーターをもつ実際値をレンダリングすべきである。ロールsliderおよびspinbuttonをもつ要素の場合、支援技術は、ユーザーに実際値をレンダリングすべきである。
レンダリングされる値が数値として正確に表すことができない場合、著者は、範囲の現在値のユーザーフレンドリーな表現を提供するためにaria-valuenowと併せてaria-valuetext属性を使用すべきである。たとえば、スライダーはsmall、medium、largeの値をレンダリングしているかもしれない。この場合、aria-valuetextの値は、small、medium、またはlargeの文字列のいずれかになる。
注
aria-valuetextが指定される場合、支援技術は、aria-valuenowの値を代わりにレンダリングする。
aria-valuetext （プロパティ）§
範囲ウィジェットに対するaria-valuenowの人間可読な代替テキストを定義する。
このプロパティは、たとえば、スライダーやプログレスバーなどの範囲ウィジェットで使用される。
aria-valuetext属性が設定される場合、その値が不明である場合を除き、著者はaria-valuenow属性も設定すべきである（たとえば、不確定なprogressbar上）。
レンダリングされる値が意味のある数値として表すことができない場合、著者はaria-valuetext属性のみを設定すべきである。たとえば、スライダーはsmall、medium、largeの値をレンダリングしているかもしれない。この場合、aria-valuenowの値は、値空間における各値の位置を示す、1から3までの範囲をとるだろうが、aria-valuetextは、small、medium、またはlargeの文字列のいずれかになる。aria-valuetextが指定される場合、支援技術は、aria-valuenowの値の代わりの値をレンダリングすべきである。
aria-valuetextが指定される場合、支援技術は、aria-valuenowの値の代わりの値をレンダリングすべきである。
この仕様で定義されるロール、ステート、およびプロパティは、完全なウェブ言語またはフォーマットを形成しない。これらは、ホスト言語のコンテキストで使用されることが意図される。この節は、ホスト言語が、WAI-ARIAを実装するための方法、ここで指定されるマークアップがホスト言語のマークアップとスムーズかつ効果的に統合されることを保証するための方法を論じる。
マークアップ言語は表面的に似て見えるが、マークアップ言語は、言語定義のインフラを共有しない。言語構築のアプローチの違いに対応するために、要件は一般的かつモジュール化固有の両方となる。仕様が書かれる方法の違いを可能にする一方で、意図は、WAI-ARIAの情報が著者に見え、WAI-ARIAがスクリプトによってDOMで操作される方法の一貫性を維持することである。
WAI-ARIAロール、ステート、およびプロパティは、要素の属性として実装される。ロールは、ホスト言語が提供するrole属性の値に出現するトークンの中でロールの名前を置くことによって適用される。ステートおよびプロパティはそれぞれ、この仕様における各特定のステートまたはプロパティに対して定義されるように値をもつ、独自の属性を取得する。属性名は、ステートまたはプロパティのaria接頭辞の名前である。
実装するホスト言語は、次の特性をもつ属性を提供する：
roleでなければならない。実装するホスト言語は、次の特性を持つ属性を許可しなければならない。
aria-busy、aria-selected、aria-activedescendant、aria-valuetextのような、サポートされるステートおよびプロパティの節で識別される任意のステートまたはプロパティの名前である。XML名前空間[xml-names]をサポートするホスト言語は、WAI-ARIA属性が名前空間とともに使用することを要求してもよい。この場合、WAI-ARIAステートおよびプロパティ属性に対する名前空間は、http://www.w3.org/ns/wai-aria/でなければならない。ホスト言語が名前空間をサポートし、かつユーザーエージェントがWAI-ARIA名前空間を認識する期待がある場合、名前空間に対するサポートを明示的に記述しないホスト言語でWAI-ARIAを使用するために、著者は、この名前空間を同様に使用すべきである。名前空間接頭辞はこの仕様で定義されないが、一般に"aria"が期待される。
注
WAI-ARIAステートおよびプロパティ属性は、属性すべてが文字列"aria-"で開始するような命名規則を持つ。これは名前空間接頭辞でないが、ステートまたはプロパティ名の一部である。したがって、名前空間接頭辞をもつWAI-ARIAステートおよびプロパティを使用する場合、完全な属性名は"aria:aria-foo"のようになる。
ホスト言語が名前空間をサポートしないため、または設計者がWAI-ARIAをコア機能セットに組み込むようにしたいいずれかため、一部のホスト言語は、WAI-ARIAステートおよびプロパティ属性をもつ名前空間を使用しない。このホスト言語において、この属性の名前空間名は値がない。この属性の名前は、コロンによる接頭辞オフセットがない。名前空間の点で、これは接頭辞のない属性名である。たとえばDOMインターフェイスgetAttributeNSへの結合ECMAScriptは、この状態を表すものとして空文字列("")扱い、getAttribute("aria-busy")とgetAttributeNS("", "aria-busy")の両方が、DOMにおける同じaria-busy属性にアクセスする。
注
この節の要件によると、一部のユーザーエージェントは、名前空間をもつWAI-ARIAステートおよびプロパティを認識し、一部は名前空間をもたないものを認識し、そして一部は両方を認識するかもしれない。著者は、著者が使用しているホスト言語でサポートされる形式を意識することを勧める。ホスト言語およびサポートするユーザーエージェントが明示的に名前空間を要求することを示す場合を除き、著者は名前空間なしで属性を使用することを勧める。名前空間をサポートするユーザーエージェントでさえも、一般にアクセシビリティAPIに名前空間されたWAI-ARIAステートおよびプロパティを公開しない。具体的には、XHTMLを含む、HTMLの現在の実装は、この名前空間をサポートしない。
7.3 フォーカスナビゲーション§実装するホスト言語は、すべてのインタラクティブな要素、つまり、すべてのレンダリング可能またはイベント受理要素をフォーカス可能にするためにサポートを著者に提供しなければならない。実装するホスト言語は、ウェブ著者にこれらのフォーカス可能かどうかを定義することを可能にする機能を提供しなければならず、インタラクティブな要素は、デフォルトでタブナビゲーション順序で出現する。HTML 5のtabindex属性は、1つの実装例である。
ホスト言語がオブジェクトに対してネイティヴセマンティクスを欠く場合、WAI-ARIAは、オブジェクトに関するセマンティック情報を提供するように設計されている。とはいえ、WAI-ARIAは多数のホスト言語のために追加のセマンティクスを提供するよう設計されている。さらに、長い期間をかけてホスト言語は進化し、WAI-ARIAの機能に対応して新しいネイティヴな機能を提供することができる。そのため、WAI-ARIAセマンティクスがホスト言語のセマンティクスと冗長であるような多数の状況がある。
このホスト言語の機能は、「暗黙のWAI-ARIAセマンティクス」を持つとみなすことができる。暗黙のWAI-ARIAセマンティクスを持つ機能のユーザーエージェント処理は、WAI-ARIAの機能の処理と同様だろう。その処理はホスト言語の機能とWAI-ARIAの機能との間の構文上の違いにより同一ではないかもしれないが、一般に、ユーザーエージェントはアクセシビリティAPIに同一の情報を公開するだろう。暗黙のWAI-ARIAセマンティクスを持つ機能は、必要な独自の要素、必要なステートやプロパティなど、WAI-ARIAの構造的要件を満たし、提供される明示的なWAI-ARIAセマンティクスを必要しない。暗黙のWAI-ARIAロールをもつ要素で、著者はまた、WAI-ARIAロールの明確な指示の必要なしにそのロールでサポートされるWAI-ARIAステートおよびプロパティを使用することができる。
たとえば、チェックボックスやラジオボタンなど、機能性をもつ要素が既に存在する場合、ホスト言語のネイティヴセマンティクスを使用する。WAI-ARIAマークアップは、（たとえば、aria-requiredに必要であることを示す）ネイティヴセマンティクスを増強するためにのみ使用されることを意図する、または要素の標準機能をから別の用途にセマンティクスを変更するために使用されることを意図する。
暗黙のWAI-ARIAセマンティクスは、以下のセクションにおける、ホスト言語のセマンティクスと競合する、衝突解決手続きに影響を与える。したがって、暗黙のWAI-ARIAセマンティクスは、ホスト言語仕様またはCore Accessibility API Mappings [core-aam-1.1]などの規範的仕様で定義する必要がある。
7.5 ホスト言語のセマンティクスとの競合§WAI-ARIAのロール、ステート、およびプロパティは、これらのセマンティクスをもつネイティヴホスト言語の要素が使用不可であり、一般に自身のネイティヴセマンティクスを持たない要素で使用される場合に、セマンティック情報を付加することを意図する。それらもまた同様であるが非同一のセマンティクスを持つ要素に使用できる（たとえば、ネストされたリストがツリー構造を表すために使用できる）。再意図される要素のネイティヴプレゼンテーションが必要とされるスタイルおよびまたはスクリプトの量を減少させるため、この方法は、WAI-ARIAの実装を持たない古いブラウザー用のフォールバック戦略の一部にすることができる。以下に概説する場合を除き、ユーザーエージェントは、ホスト言語のセマンティクスを使用するよりもむしろ、アクセシビリティAPIに要素を公開する方法を定義するために、WAI-ARIAセマンティクスを常に使用しなければならない。
WAI-ARIAがネイティヴセマンティクスを上書きすることが期待されるこれら通常の状況に加えて、WAI-ARIAを上書きすることが不適切である要素が存在する。これは、同一のホスト言語のセマンティクスが存在するため、WAI-ARIAを必要としないため、またはWAI-ARIA由来のセマンティクスが直接ホスト言語のセマンティクスと競合するためであるかもしれない。同一のロールのセマンティクスと値をもつホスト言語における機能が使用可能である、かつ著者がホスト言語の機能を使用しないようにするための説得力のある理由がない場合、著者は、WAI-ARIAをもつ他の要素を再利用するよりもむしろ、ホスト言語の機能を使用すべきである。
ホスト言語は、ロールに対応する暗黙のWAI-ARIAセマンティクスを持つ機能を持つことができる。WAI-ARIAロールが与えられる場合、ロールがホスト言語によってネイティヴ要素で明示的に禁止されているWAI-ARIAステートおよびプロパティを必要としない限り、ユーザーエージェントは、処理のためにネイティヴセマンティックでなく、WAI-ARIAロールのセマンティックを使用しなければならない。ロールに対する値は、ステートおよびプロパティに対する値と同じように競合せず（たとえば、HTML 'checked'属性と'aria-checked'属性が競合する値を持つだろう）、著者は、通常は再利用されない要素でWAI-ARIAロールすら提供するための正当な理由があると予想される。
WAI-ARIAステートおよびプロパティが、同じ暗黙のWAI-ARIAセマンティックを持つホスト言語の機能と対応する場合、WAI-ARIAの機能を使用することが特に問題となるかもしれない。WAI-ARIAの機能およびホスト言語の機能が両方とも提供されるが、それらの値が同期しない場合、ユーザーエージェントおよび支援技術は、使用すべき値を知ることができない。したがって、支援技術に相反するステートとプロパティを提供しないように、その要素のネイティヴ属性と競合する各ホスト言語要素上のWAI-ARIA属性の使用箇所で、ホスト言語は明示的に宣言しなければならない。ホスト言語が指定された要素に対するネイティヴ属性と競合する直接セマンティックで存在するだろうWAI-ARIA属性を宣言する場合、ユーザーエージェントは、WAI-ARIA属性を無視しなければならず、代わりに同一の暗黙のセマンティックを持つホスト言語属性を使用しなければならない。
ホスト言語は、WAI-ARIAで上書きできない機能を文書化してもよい（これは「強いネイティヴセマンティクス」と呼ばれる）。これは、セマンティクスがWAI-ARIAで変更された場合、処理が不確実になる場所の機能だけでなく、暗黙のWAI-ARIAセマンティクスを持つ機能でもある。WAI-ARIAロールが強いネイティヴセマンティクスをもつ要素で使用される場合、適合性チェッカーはエラーまたは警告を通知してもよいが、ネイティヴホスト言語セマンティックが恒久的にpresentationalでない限り、アクセシビリティAPIに要素を公開する際に、ユーザーエージェントは依然としてWAI-ARIAロールのセマンティック値を使用しなければならない。
ネイティヴ機能のWAI-ARIA上書きに例外を作成するためのホスト言語の機会は、ホスト言語機能の固有の処理をもつ潜在的な著者のエラーまたは問題を回避することを意味する。1つの機能を変更するが他の機能がアクセシビリティAPIにどのような影響を与えるか明確ではないかもしれない、ホスト言語とWAI-ARIAは類似だが同一の機能でない機能を提供する際、著者エラーが発生するかもしれない。固有の処理は、ARIA機能に応じて合理的に変更することができず、ARIAが許可された予測できない結果につながる、はるかに単純なレンダリングとアクセシビリティAPIへ公開する、機能が処理される方法を参照する。このような状況で、ホスト言語がWAI-ARIAの範囲を限定するための十分な理由がある。しかし、この規定は、使用されなくてもよいという、機能ごとに文書化することにより、WAI-ARIAの使用をホスト言語に禁止するための包括的許可を与えるものではない。ホスト言語は、コンテンツを効果的に処理するために重要である場合にのみ、ARIAの使用に制限を作成すべきである。
特定のARIA機能は、アクセシビリティAPIで完全なモデルを構築するために重要である。そのような機能は、ネイティヴホスト言語のセマンティクスと競合すると期待されない （機能はセマンティクスを補完するかもしれないが）。したがって、ホスト言語は次のARIA機能の使用を防ぐ強いネイティヴセマンティクスを宣言してはならない：
7.6 ステートおよびプロパティ属性の処理§ステートおよびプロパティ属性はホスト言語に含まれており、したがって、属性の値型の表現に対する構文は、ホスト言語によって管理される。値で定義される値の型ごとに、ホスト言語から適切な値の型が使用される。WAI-ARIAの値型とさまざまなホスト言語の値型との間の推奨される対応は、WAI-ARIAの値型の言語へのマッピングに挙げられる。これは、WAI-ARIAをサポートする新しいホスト言語に対応するための非規範的マッピングである。
リストの値型―ID参照リストおよびトークンリスト―は、提供される与えられた型の複数の値を許可する。値は、スペース文字、カンマなどの、リスト属性に対するホスト言語によって認識される区切り文字で区切られる。ある言語がさまざまな区切り文字を許可するかもしれない一方で、一部の言語は、特定の単一の区切り文字を要求するかもしれない。
グローバルなステートおよびプロパティは、ホスト言語における任意の要素でサポートされる。しかし、著者は、明示的なWAI-ARIAロールとして定義される、または適切なWAI-ARIAロールと一致するホスト言語の暗黙WAI-ARIAセマンティックによって定義されるかのいずれかで、ステートまたはプロパティをサポートするロールをもつ要素上で非グローバルステートおよびプロパティのみを使用しなければならない。role属性がサポートするWAI-ARIAステートおよびプロパティを含む、要素、セマンティクスおよび要素の動作に追加される場合、ロールの動作によって増強または上書きされる。ユーザーエージェントは、明示的なWAI-ARIAロールとして定義される、または適切なWAI-ARIAロールと一致するホスト言語WAI-ARIAセマンティックで定義されるかのいずれかで、ステートまたはプロパティをサポートするロールをもたない要素で使用される非グローバルステートおよびプロパティを無視しなければならない。たとえば、aria-valuetext属性はprogressbarで使用されるかもしれない。
WAI-ARIAロールは、"サポートされる"または"必要とされる"として修飾されるステートおよびプロパティが関連付けられている。comboboxロールでサポートされるプロパティの例は、aria-autocompleteである。プロパティは、指定されたcomboboxが自動補完機能を実装するかもしれないし、しないかもしれないために、この場合"サポートされる"に指定される。対照的に、comboboxロールは、ロールが拡張可能であることを示すためにaria-expandedステートを要求する。コンボボックスは、開いているか閉じているかのいずれかである子孫listboxを持つ。listboxが開いている場合、comboboxはその展開された状態である。そうでなければ折りたたまれる。
WAI-ARIAロールが使用される場合、DOMに存在しないサポートされるステートおよびプロパティは、デフォルト値に従って処理される。comboboxの例を踏まえ、欠損するaria-autocomplete属性は、自動補完を提供しないcomboboxを意味し、aria-autocomplete="none"と同等である。
しかし、不在である必要とされるステートおよびプロパティは、著者の誤りである。欠落している必要とされるステートおよびプロパティは、あたかも存在しており、かつ必ずしもそのデフォルト値でない暗黙の中立値を持つのように扱われる。たとえば、aria-expandedのデフォルト値は、展開可能でも折りたたみ可能でもないことを意味する、undefinedである。しかし、それはcomboboxの場合に適用されない。この場合、aria-expandedは、comboboxの展開可能/折りたたみ可能の性質を伝えるために必要とされる。このように、comboboxロールのaria-expandedの暗黙の値は、展開可能（そして現在は折りたたまれている）を意味する、falseである。各WAI-ARIAロールに関連付けられた特性表は、ステートまたはプロパティが欠損している場合に、そのロールのコンテキストで使用するためのステートまたはプロパティの値を指定する"ロールに対する暗黙の値"項目を持つ。
暗黙WAI-ARIAセマンティクスを持つ要素は、対応するロールでサポートされるWAI-ARIAステートおよびプロパティの完全なセットをサポートする。したがって、ステートおよびプロパティを設定する際に、著者はロールを省略してもよい。ロールは、要素の暗黙WAI-ARIAロールを変更する必要がある場合にのみ必要とされる。
ステートおよびプロパティは、DOMに存在するが、その値として0長さの文字列（""）を持つこともある。これは、ステートおよびプロパティの不在と等価である。ユーザーエージェントは、ステートおよびプロパティが不在の属性を扱うのと同じ""の値を持つ属性としてそのステートおよびプロパティを扱うべきである。サポートされるステートおよびプロパティの場合、これはデフォルト値に対応するが、必須属性である場合、著者のエラーを通知し、ロールに対する暗黙の値が使用される。
A. スキーマ§この章は非規範的である。
WAI-ARIAロール、ステート、およびプロパティは、WAI-ARIA属性を使用してコンテンツの検証をサポートするための多数の機械可読な形式で利用可能である。しかし、WAI-ARIAは確定していないので、これらのファイルは予告なく変更する場合がある。Todo: Remove disclaimers about not final at rec.
ライブコンテンツがこれらの文書型を使用することは適切ではない。これらは、開発、評価、検証ツールでローカル使用をサポートするために、ダウンロードのためにのみ利用できるようされる。W3Cのサーバーから直接これらのバージョンを使用すると、読み込みを防ぐ、自動閉塞を引き起こすかもしれない。
コンテンツでスキーマを使用する必要がある場合、過度のDTDトラフィックを回避するためのガイドラインに従う。たとえば、使用するたびにスキーマにフェッチしないようにキャッシングプロキシを使用するか、ソフトウェアがXMLカタログのような、ローカルキャッシュを使用することを保証する。
A.1 ロールの実装§RDFで表現されるWAI-ARIAのためのタクソノミーはhttp://www.w3.org/WAI/ARIA/schemata/aria-1.rdfから入手できる。
A.2 WAI-ARIA属性モジュール§このモジュールは、モジュール化されたDTDに含めることができるモジュールとしてWAI-ARIA属性を宣言する。このモジュールを使用するサンプルXHTML DTDは以下の通りである。WAI-ARIA属性は名前空間内になく、属性名は既存の属性との衝突の可能性を減らすために"aria-"で始まることに注意する。
このモジュールは、http://www.w3.org/MarkUp/DTD/aria-attributes-1.modから入手できる。
A.3 XHTML plus WAI-ARIA DTD§このDTDはXHTML 1.1を拡張し、WAI-ARIAステートおよびプロパティ属性をすべての要素に追加する。広範なキーボードのサポートを提供し、上記のフォーカスナビゲーションセクションに適合するために、DTDはまた、より広い要素のセットにtabindex属性を追加する。
これは正式な文書型ではなく、WAI-ARIAをサポートする将来の正式なXHTML DTDによって廃止されるかもしれない。
XHTML 1.1 plus WAI-ARIA DTDは、http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtdから入手できる。
このXHTMLファミリーマークアップ言語を使用して記述された文書は、上記のDTDを使用して検証することができる。文書の著者がそのような検証を容易にしたい場合、著者は文書の先頭に次の宣言を含めることができる：
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN" "http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">
しかし、このDOCTYPEが文書中に存在する場合、ほとんどのユーザーエージェントはHTMLではなくむしろ汎用XMLとして文書を扱うことに注意すること。これは、文書をDTDで定義される名前付き文字エンティティをサポートすることができないようにさせる（たとえば、©）。したがって著者は、XMLにおける定義済みエンティティの外で名前付きエンティティの使用を避ける必要がある（[xml11]、4.6節）。
上記の問題を回避するために、著者は、上記のDOCTYPE宣言を省略することができる。これは、ユーザーエージェントに名前付き文字エンティティのサポートと同様に内蔵のARIAのサポートをもつ汎用HTMLとして文書を処理させる。しかし、これはユーザーエージェントにCSSレンダリングに影響を与える"quirks"モードに入るようにさせ、適合性チェッカーに追加されたARIAの属性に文書を失敗させる。
名前付き文字エンティティのサポートおよびquirksモードの問題を回避するために、著者は、HTMLに対して次の汎用DOCTYPE宣言を代わりに使用することができる：
<!DOCTYPE html>
しかし、これは依然として文書が適合性チェッカーによって検証されることを保証するものではない。
A.4 XHTML+ARIAのためのSGMLオープンカタログエントリー§この節は、XHTML+ARIA 1.0のための公開識別子のSGMLオープンカタログフォーマット定義[SGML-CATALOG]を含む。
-- .......................................................................... -- -- File catalog ............................................................ -- -- XHTML+ARIA Catalog Data File Revision: $Revision: 1.40 $ See "Entity Management", SGML Open Technical Resolution 9401 for detailed information on supplying and using catalog data. This document is available from OASIS at URL: <http://www.oasis-open.org/html/tr9401.html> -- -- .......................................................................... -- -- SGML declaration associated with XHTML .................................. -- OVERRIDE YES SGMLDECL "xml1.dcl" -- :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -- -- XHTML+ARIA modules .............................................. -- PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN" "xhtml-aria-1.dtd" PUBLIC "-//W3C//ENTITIES XHTML ARIA Attributes 1.0//EN" "aria-attributes-1.mod" -- End of catalog data ..................................................... -- -- .......................................................................... --A.5 WAI-ARIA属性XMLスキーマモジュール§
このモジュールは、モジュール化されたスキーマに含めることができるXMLスキーマモジュールとしてWAI-ARIA属性を宣言する。WAI-ARIA属性は名前空間内になく、属性名は既存の属性との衝突の可能性を減らすために"aria-"で始まることに注意する。
このモジュールは、http://www.w3.org/MarkUp/SCHEMA/aria-attributes-1.xsdから入手できる。
A.6 HTML 4.01 plus WAI-ARIA DTD§このスタンドアロンDTDは、role属性だけでなく、WAI-ARIAステートおよびプロパティ属性をHTML4.01のすべての要素に追加する。より広いキーボードサポートを提供するために、DTDはまた、要素の広いセットにtabindex属性を付加する。
DTDは、HTML 4.01暫定DTDに基づいて、そのスタンドアロンのファイルにするために必要なすべてのエンティティの参照が含まれている。これは公式のW3C DTDではなく、HTML 4.01の派生著作物を考慮すべきである。
このマークアップ言語を用いて書かれた文書は、上記のDTDを使用して検証することができる。文書の著者がそのような検証を容易にしたい場合、著者は文書の先頭に次の宣言を含めることができる：
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML+ARIA 1.0//EN" "http://www.w3.org/WAI/ARIA/schemata/html4-aria-1.dtd">
しかし、このDOCTYPEが文書中に存在する場合、ほとんどのユーザーエージェントはHTMLではなくむしろ汎用XMLとして文書を扱うことに注意すること。これは、文書をDTDで定義される名前付き文字エンティティをサポートすることができないようにさせる（たとえば、©）。したがって著者は、XMLにおける定義済みエンティティの外で名前付きエンティティの使用を避ける必要がある（[xml11]、4.6節）。
上記の問題を回避するために、著者は、上記のDOCTYPE宣言を省略することができる。これは、ユーザーエージェントに名前付き文字エンティティのサポートと同様に内蔵のARIAのサポートをもつ汎用HTMLとして文書を処理させる。しかし、これはユーザーエージェントにCSSレンダリングに影響を与える"quirks"モードに入るようにさせ、適合性チェッカーに追加されたARIAの属性に文書を失敗させる。
名前付き文字エンティティのサポートおよびquirksモードの問題を回避するために、著者は、HTMLに対して次の汎用DOCTYPE宣言を代わりに使用することができる：
<!DOCTYPE html>
しかし、これは依然として文書が適合性チェッカーによって検証されることを保証するものではない。
HTMLワーキンググループは、WAI-ARIAをHTML5に組み入れている。HTMLにおけるWAI-ARIAの公式サポートは、HTML5仕様で提供される。このDTDは、DTD検証を必要とするがHTML 5を使用しないアプリケーションのための解決策の橋渡しとしてのみ利用可能になる。
このモジュールは、http://www.w3.org/WAI/ARIA/schemata/html4-aria-1.dtdから入手できる。
B. WAI-ARIAの値型の言語へのマッピング§この章は非規範的である。
注
HTML 5でtrue/false値の推奨されるマッピングは、HTML 5真偽値型を使用する代わりに、trueおよびfalseの許容値をもつキーワードおよび列挙属性を使用する。
下記の表は、WAI-ARIAステートおよびプロパティ型とHTML 5、XMLスキーマデータ型[xmlschema-2]、SVG、およびSGMLからの属性型間との推奨されるマッピングを提供する。
下記に記載されない言語は、言語で定義される適切な値型を持つかもしれない。そうでない場合、我々は、汎用XML言語のためのXMLスキーマデータ型を勧める。スキーマの代わりにDTDを使用する文書は、自動的に検証することができず、WAI-ARIA属性の追加の処理を必要とする。
C. 変更ログ：WAI-ARIA 1.0勧告からの実質的な変更点§aria-describedat after much group deliberation.aria-orientation now defaults to undefined, and is allowed on more roles with implicit defaults defined per role.radio no longer inherits from option, just from checkbox. radio now adds aria-posinset and aria-setsize.aria-posinset and aria-setsize to tab.none role.aria-selected from "supported" to "required" attribute list for option role.rowgroup to subclass structure instead of group.aria-modal attribute.text role.searchbox role.switch role.aria-current attribute.region a type of landmark. Add requirement that authors MUST give a region a brief label that describes the purpose of the content it contains. Remove the accessible name property from the section role. Change the superclass role from region to section for the following roles: alert, grid, landmark, list, log, status, and tabpanel. Remove region as a superclass role of article, making document the only superclass role of article.aria-placeholder attribute.aria-colcount, aria-rowcount, aria-colindex, aria-rowindex, aria-colspan, and aria-rowspan.cell and table roles for non-interactive tables. Made gridcell and grid subclasses of cell and table respectively. Removed widget as one of the immediate superclasses of columnheader and rowheader. Headers that subclass gridcell will still inherit the supported properties of widget.aria-kbdshortcuts. Note that his has subsequently been replaced by aria-keyshortcuts.aria-roledescription attribute.aria-readonly as a supported property of checkbox, menuitemcheckbox, menuitemradio, and switch. Because this property should not apply to radio, radio was made a subclass of input.aria-valuemin, aria-valuemax, and aria-valuenow when they are required for roles scrollbar, slider, and spinbutton.aria-level a required attribute for heading with an implicit value of 2.aria-readonly as a supported property of: combobox, listbox, radiogroup, slider, and spinbutton.aria-errormessage attribute.-1 as a valid value for aria-setsize as a means to indicate that the set size is unknown and should not be calculated by user agents.term role.aria-readonly and aria-required SHOULD NOT be used or exposed on columnheader or rowheader when those headers descend from a non-interactive table.figure role.feed role; made aria-posinset and aria-setsize supported properties of article; changed aria-busy so that it could be applied to all elements rather than limited to live regions; added normative requirement that authors MUST set aria-busy to true if changes to a rendered widget would result in that widget missing required owned elements during the update process.application from landmark to structure; removed the accessible name requirement from document.list as a superclass of menu and listbox, making it a related concept of each. Removed directory as a superclass of tablist.input as a superclass of scrollbar and select.aria-grabbed and aria-dropeffect as planned for deprecation.aria-orientation on combobox.aria-details attribute.aria-describedat which has been made obsolete by aria-details.aria-errormessage content is not hidden and is included in a container that exposes the content to the user.spinbutton: Default for aria-valuenow is 0. There is no minimum value for aria-valuemin and no maximum value for aria-valuemax.true from spinbutton; make spinbutton a subclass of composite.widget as a (possible) superclass of separator. Add aria-valuemax, aria-valuemin, aria-valuenow, and aria-valuetext as supported properties of separator.true from menuitem and treeitem.password. The ARIA Working Group agreed to move the password role to ARIA 2.0. Note that the content is currently only commented out until we branch for ARIA 1.1.aria-valuenow a required property, and remove aria-expanded as a supported state, of focusable separator elements.aria-roledescription. Add several normative requirements for authors, user agents, and assistive technologies.aria-details regarding exposure of content from a MUST to a SHOULD.aria-keyshortcuts (as a replacement for the aria-kbdshortcuts which was introduced on 12-Jun-2015.password role.aria-haspopup from boolean to token. Supported values are: true, false, menu, listbox, tree, grid, and dialog.combobox to include tree, grid, and dialog. In addition, the implicit value for aria-haspopup for role combobox was changed from true to listbox.aria-describedby, aria-label, aria-labelledby.aria-posinset and aria-setsize as supported properties of menuitem.aria-activedescendant as a supported property of application.text. The ARIA Working Group agreed to move the text role to ARIA 2.0. Note that the content is currently only commented out until we branch for ARIA 1.1.true to checkbox, menuitem, menuitemcheckbox, menuitemradio, option, radio, spinbutton, switch, tab, and treeitem. (N.B. See subsequent items as some of this is being undone as the result of further discussions within the working group.)この章は非規範的である。
次の人は、この文書の開発に貢献した。
D.1 発行時点のARIA WGでアクティブな参加者§この出版物は、契約番号ED-OSE-10-C-0067のもとで米国教育省・障害者リハビリテーション研究所（NIDILRR）の政府資金によって一部賄われている。この出版物の内容は、必ずしも米国教育省の見解や政策を反映するものではなく、また商品名、商用製品、組織の言及は米国政府による支持を意味するものではない。
E. 参考文献§ E.1 規範規格§RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4