Copyright © 2015-2019 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
このドキュメントは、リッチ・インターネット・アプリケーションを開発するために、WAI-ARIA1.1 [WAI-ARIA]の使い方を提供します。 ほとんどの開発者にとって、WAI-ARIAの仕様だけでは、明白でないかもしれない考慮点に関して記述し、WAI-ARIAのrole、state、およびpropertyを使用する、ウィジェット、ナビゲーション、アクセシブルな動作を作るためのアプローチをお勧めします。 このドキュメントは、主にウェブ・アプリケーションのデベロッパーに向けられていますが、ガイダンスは、また、ユーザー・エージェントや支援技術の開発者にも、利用できるものになっています。
このドキュメントは、WAI-ARIA Overviewで説明されたWAI-ARIAシリーズの一部です。
このセクションは、公開された時点での、このドキュメントのステータスについて、説明します。他のドキュメントが、このドキュメントに取って代わるかもしれません。現在のW3Cの刊行物のリストと、最新のテクニカル・リポートは、W3C・テクニカル・リポート・インデックス（https://www.w3.org/TR/）で、参照することが出来ます。
これは、アクセシブル・リッチ・インターネット・ワーキング・グループによるWAI-ARIA Authoring Practices1.1、ワーキング・グループ・ノートです。Accessible Rich Internet Applications 1.1 W3C Recommendation[wai-aria-1.1]をサポートするもので、技術仕様に最適となるような（でも仕様を理解するのに重要となるような）詳細のアドバイスと例を提供します。
「WAI-ARIA Authoring Practices 1.1」は、「WAI-ARIA1.1 Recommendation」にタイミングを合わせるために、以前は、2017年の12月にワーキング・グループ・ノートとして公開され、その後、デザイン・パターンと例を追加して、2018年の7月に公開されました。それ以来、グループは、WAI-ARIA1.1のサポートを改良するために、より多くのデザイン・パターンを加え、他のデザイン・パターンと例の多くの品質を、向上させています。変更の詳細は、チェンジ・ログに記述してあります。これとは別に、WAI-ARIA Authoring Practices1.2は、WAI-ARIA1.2に向けた、このドキュメントにプラスで追加された機能仕様での改善点を含みます。
コメントをするには、「W3C ARIA-practices GitHub repository」にファイルするか、もし、上手くいかないなら、「public-aria@w3.org (comment archive)」にメールしてください。
このドキュメントはAccessible Rich Internet Applications Working Groupによって、Working Group Noteとして発表されました。
Working Group Noteとしての公開はW3C Membershipによる裏書きを含意しません。これは、ドラフト・ドキュメントであり、いつでも、アップデートされたり、置き換えられたり、時代遅れとなってしまうかもしれません。処理中の作業では無いものとして、このドキュメントを引用するのは、不適切です。
このドキュメントはW3C Patent Policyの下で活動するグループによって製作されました。
このドキュメントは、「W3C Process Document 2018年2月1日」によって、管理されます。
このセクションは、参考情報であり、制約を課すものではありません。
WAI-ARIA Authoring Practicesは、アクセシブルなリッチ・インターネット・アプリケーションを作成するために、WAI-ARIA1.1を使用する方法を理解するためのガイドです。 WAI-ARIAの適切な適用についてのガイダンスを提供し、お勧めのWAI-ARIA使用パターンについて記述し、それらの背後にある概念を説明します。
リッチでダイナミックなウェブサイトを作るのに使用されていた言語、例えば、HTML、JavaScript、CSSやSVGなどは、支援技術（AT）を使ったり、キーボードナビゲーションに依存するユーザーにとって使いやすいとされるサイトを作るために必要な機能は、ネイティブには、含んでいません。 W3C Web Accessibility Initiative's (WAI) Accessible Rich Internet Applications working group (ARIA WG) は、W3Cの標準化活動を通じて、これらの不足を扱っています。 WAI-ARIA Overviewは、WAI-ARIAに関する追加の背景を提供し、これらの活動を要約し、WAI-ARIAスイートに含まれる他のドキュメントをリスティングしています。
簡潔なリード・ミー・ファースト
の後、共通のウィジェットに関するARIAのインプリメンテーション・パターンを紹介し始めます。
期待される動作を列挙し、動作可能なコードを使って、それらの動作をデモンストレーションします。
インプリメンテーション・パターンと例は、後のガイダンス・セクションで、サポートする概念に関しての詳細な説明に及びます。
ガイダンス・セクションは、ARIAランドマーク、キーボード・インタフェースの実践、グリッドやテーブル・プロパティ、role presentationの効果のような、より一般的なトピックスをカバーします。
機能的に、ARIAのrole、state、propertyは、支援技術に関して、CSSに似ています。 スクリーン・リーダー・ユーザにとっては、ARIAは、非視覚的経験のレンダリングを制御します。 誤ったARIAは、対応する非視覚的な体験についての潜在的な破壊的効果により、視覚的な体験を間違って伝えます。
本書に含まれるすべてのガイダンスやARIAを使用する前に、以下の2つの根本的な原則を理解することに時間を費やしてください。
コード:
<div role="button">注文</div>
上記のコードは、この<div>の作者が、キーボードとして期待されるキー・ボード・インタラクションを提供するJavaScriptを組み込むことを、約束しています。HTMLの入力要素と異なり、ARIAのroleは、ブラウザに、キーボードの動作やスタイリングを生じさせたりはしません。
そのroleの約束を実現せずにroleを使用することは、注文を破棄しショッピング・カードを空にするような「注文」ボタンを作ることに似ています。
このガイドの目的の1つは、それぞれのARIAのroleに関して、期待された振舞いを定義することです。
情報の支援技術が必要とするユーザインタフェース要素の意味と目的は、アクセシビリティ・セマンティックスと言います。 支援技術の観点から、ARIAは、重要なアクセシビリティ・セマンティックを使って、作成者にHTMLやSVGの要素をドレスアップさせる能力を提供します。この重要なアクセシビリティ・セマンティックは、他の方法では、支援技術が、確実には引き出せないものです。
ARIAのいくつかは、コートに似ています。オリジナルのセマンティックやコンテンツを、隠したり、書き換えたりするためです。
<a role="menuitem">支援技術は、この部分をリンクでは無く、メニューのアイテムとして理解します。</a>
<a aria-label="支援技術のユーザーは、「リンク・テキスト」では無く、このaria-labelの内容にだけ気づくことができます。">リンク・テキスト</a>
一方で、ARIAのいくつかの用途は、サスペンダーかベルトに似ています。 オリジナル・コンテンツに不可欠なサポートを提供する意味を加えます。
<button aria-pressed="false">音を消す。</button>
これが、ARIAのパワーです。 支援技術が確実に解釈できる方法で、作成者は、ほぼどんなユーザインタフェースも記述できるようになります。
これはまた、ARIAの危険な一面でもあります。 作者は、うっかり、アクセシビリティのセマンティックを書き換えることができます。
<table role="log">
<!--
支援技術のユーザーが、テーブルとして認識できないテーブルです。
Logのroleがブラウザに、これはテーブルでは無くログであることを、伝えます。
-->
</table>
<ul role="navigation">
<!-- これは、ナビゲーションの領域で、リストではありません。 -->
<li><a href="uri1">nav link 1</li>
<li><a href="uri2">nav link 2</li>
<!-- エラーです! この上のリストは、リンクではありません! -->
</ul>
このガイドからシステムに対してコードを使う前に、支援技術との互換性のテストを必ずおこなってください。 このガイドの目的は、ARIAの仕様で定義されたように、適切なARIA1.1の使用方法を描くことです。デザイン・パターン、参考例、サンプル・コードは、ブラウザや支援技術でのARIA1.1のサポートのギャップにより生じる問題に対処するためのコード・テクニックは、意図的に記述も実装もしていません。 このため、対象者の中で関連している各ブラウザと支援技術の全ての組み合わせにより、実装を徹底的にテストすることが、賢明です。
同様に、このガイドのJavaScriptとCSSは、これを書いている時点で、Chrome、Firefox、インターネットエクスプローラ、およびSafariの最新のバージョンと互換性があるように書かれています。 特に、いくつかのJavaScriptとCSSは、インターネット・エクスプローラ・バージョン10か、それより早いものに関しては、正しく機能しないかもしれません。
ARIA・ワーキング・グループと他の貢献者がエラーを見逃したケースを除き、特定のブラウザや支援技術で上手く動作しない、このガイドの例は、ブラウザか支援技術のバグをデモンストレーションしています。 このため、ブラウザや支援技術の開発者は、ARIA1.1に関するサポートの品質を評価する助けとして、このガイドのコードを利用することが出来ます。
現在、このガイドは、どの例がモバイル・ブラウザやタッチ・インタフェースと互換性があるかは、示しません。 いくつかの例が、モバイルとタッチのサポートを拡張するような特定の機能を含んでいるとき、いくつかのARIAの機能はどんなモバイルブラウザでもサポートされません。 さらに、複数のモバイル・ブラウザで動作するタッチ・インタフェースを提供するための標準的なアプローチは、まだ存在しません。
タッチとモバイルのサポートについてのさらなるガイダンスは、ガイドの今後のリリースに向けて、計画されます。
このセクションは、一般的なリッチ・インターネット・アプリケーション・パターンとウィジェットを、WAI-ARIAのrole、state、propertyを適用し、キーボード・サポートを実装することによって、アクセシブルにする方法をデモンストレーションします。
ネイティブのHTMLのform要素と異なり、ブラウザは、ARIAでアクセシブルにしたグラフィカル・ユーザー・インタフェース（GUI）のコンポーネントのためには、キーボード・サポートは提供しません。; 制作者は、自分のコードのために、キーボード・サポートを提供しなければなりません。 このセクションは、ウェブ・ページの機能（メニューやグリッドなど）やインタラクティブなコンポーネント（ツールバーやダイアログなど）を、キーボードで操作可能にするための原則や方法を説明します。 フォーカスの管理の基礎と一緒に、このセクションは、キーボードに頼っている人々に、それ以外のデバイスで利用可能な体験と同じくらい効率的で楽しいと感じるような体験を提供することを目指して、ガイダンスを提供します。
このセクションは以下をカバーします:
このセクションを完成させるための作業は、「issue 217」によって追跡されます。
キーボードで操作するとき、良い経験となる2つの基礎は、キーボード・フォーカスの位置を簡単に見つけられることと、ナビゲーション・キーを押した後でフォーカスがどこに移動したかを見つけられることです。 以下の要件が、ウェブ・ページがユーザーにこれらの能力を提供する範囲へ、影響を及します。
時折、ページ内の2つの要素が同時にフォーカスを持っているように見えることがあるかもしれません。 例えば、複数選択のリスト・ボックスで、一つのオプションが選択されているとき、それは灰色になっているかもしれません。 しかし、フォーカス・インジケータは、まだ、他のオプションに移動することができて、選択することもできるかもしれません。 同様に、ユーザーがタブリストでタブをアクティブにするとき、選択された状態がタブにセットされ、見た目は変化します。 しかしながら、ユーザはまだ操作することができます。そのタブがその選択された見た目と状態を保持したまま、フォーカス・インジケータをページの別の場所に移動することができます。
フォーカスと選択は、まったく異なります。 キーボード・ユーザーの視点からは、フォーカスはポインタで、マウス・ポインタのようなものです。それは、ナビゲーションの経路を追跡します。 いつの場合もフォーカスは、一つの位置にしか存在せず、全ての操作が、そのフォーカスの位置で実施されます。 一方で、選択は、リスト・ボックス、ツリー、タブリストのようないくつかのウィジェットで、実行される操作です。 もし、ウィジェットが単一選択のみをサポートしているなら、１つの項目しか選択されず、多くの場合、選択状態は、単に、フォーカスがウィジェットの中を移動するとき、フォーカスに追随するでしょう。 つまり、いくつかのウィジェットでは、フォーカスを動かすと、選択操作も実行することになります。 しかしながら、ウィジェットが複数選択をサポートするなら、一つ以上の項目が選択状態になり、フォーカスを移動させるキーは選択操作を実行しません。 いくつかの複数選択のウィジェットは、フォーカスの移動と選択を変更することの両方のキー・コマンドをサポートしますが、それらのキーは、普通のナビゲーション・キーとは異なっています。 最終的に、選択された要素が含まれるウィジェットからフォーカスが離れるとき、選択状態は、維持されたままとなります。
開発者の視点からは、違いはシンプルです。フォーカスのある要素は、アクティブな要素（document.activeElement）です。
選択された要素は、aria-selected="true"となっている要素です。
フォーカスと選択状態に関して、デザイナーと開発者にとって最も重要な問題は以下になります。：
タブリストや単一選択リストボックスのような、一つの要素だけが選択されているようなコンポジット・ウィジェットの場合、フォーカスを移動することは、フォーカスのある要素を選択された要素にすることにも、なります。 これは、「フォーカス追随の選択」と呼ばれます。フォーカス追随の選択は、しばしば、ユーザーにとって有益となりますが、いくつかの状況では、アクセシビリティに非常に有害になります。
例えば、タブリストでは、選択状態が、表示されているパネルを示すために使われます。 そして、タブリストで選択状態がフォーカスに追随するとき、フォーカスをタブからタブへ移動させることは、自動的に、表示されるパネルを変更することになります。 もし、パネルの内容が、DOMの中に存在するなら、新しいパネルを表示することは、ほぼ瞬時に起こっています。 6つのタブのうち4番目のタブを表示したいキーボード・ユーザーは、右矢印キーを3回、素早く押すことで、表示することが出来ます。 そして、それらを通じたナビゲーションによってタブのラベルを理解するような、スクリーン・リーダーのユーザーは、少しも待たずに効率的にリスト全体を読み通すことができます。
しかしながら、もし、新しいパネルを表示することが、ネットワーク・リスエストと、場合によってはページリフレッシュを引き起こすなら、自動的なフォーカスの選択の効果は、キーボードとスクリーン・リーダーのユーザーにとって破壊的な経験をもたらす可能性があります。 この場合、ユーザーは、フォーカスのそれぞれの動作で結構な待ち時間を経験することになるので、4番目のタブを表示したり、リストを読み通すことは、退屈で時間を消費するタスクになってしまいます。 さらに、もし、新しいタブを表示することが、ページをリフレッシュするなら、ユーザーは新しいページが読み込まれるのを待っているだけでなく、タブ・リストにフォーカスが戻ることも待たなければなりません。
選択がフォーカスに追随しないとき、ユーザーは、エンターやスペースを押して、要素の選択状態を変更します。
「5.1 基本的なフォーカス・ナビゲーションの慣習（5.1 Fundamental Keyboard Navigation Conventions）」で説明したように、全てのインタラクティブなUIコンポーネントは、キーボードで利用できる必要があります。これは、タブ・シーケンスにそれらを含めるか、タブ・シーケンスの中のコンポーネントからそれらをアクセシブルにする（例えば、コンポジット・コンポ―ネントの一部）かのどちらかで、最も上手く実現されます。このセクションはタブ・シーケンスの構築と管理を扱い、それにつづくセクションが、コンポーネントに含まれているフォーカス可能な要素をキーボードでアクセシブルにすることをカバーします。
HTMLのtabindexとSVGのtabindex属性は、タブ・シーケンスに要素を追加したり、要素を取り除いたりするために使用することが出来ます。 また、tabindexの値は、タブ・シーケンスの順序に影響を及ぼすことができます。製作者は、この目的のためには、tabindexを使うわないよう、強くアドバイスされていますが...
macOSの場合を除き、HTMLでは、デフォルトのタブ・シーケンスは、リンクとHTMLのform要素のみを含みます。macOSの場合、form要素だけが含まれます。macOSシステムの設定には、タブ・キーで、全てのフォーカス可能な要素にフォーカスを移動できるようにするキーボード設定があります。
タブ・シーケンスの要素のデフォルトの順番は、DOMの要素の順番になります。 また、DOMの順序は、スクリーン・リーダーの読み上げの順番も、決定します。 キーボードのタブ・シーケンスとスクリーン・リーダーの読み上げ順序を、「5.2 認識できて予測できるキーボード・フォーカス（5.2 Discernible and Predictable Keyboard Focus）」で記述したように、論理的かつ、予測可能に、調整を維持し続けることは、非常に重要です。 また、現在すべてのブラウザで利用可能な読み上げ順序による整列を維持している間、タブ・シーケンスの順番を操るもっとも確実な方法は、DOMの要素を再アレンジすることです。
tabindex属性の値には、以下の効果があります。
「5.1 基本的なフォーカス・ナビゲーションの慣習（5.1 Fundamental Keyboard Navigation Conventions）」で説明されるように、タブ・シーケンスには、コンポジット・UI・コンポーネントのフォーカス可能な要素を一つだけ、含むべきです。 いったん、コンポジットなコンポーネントがフォーカスを持てば、ユーザーは、タブとシフト＋タブ以外のキーで、フォーカス可能な要素間でフォーカスを移動させることができるようになります。 制作者は、コンポジットの中で、どのキーでフォーカスを移動できるようにするのか、自由に選択することができますが、「3. デザイン・パターンとウィジェット（3. Design Patterns and Widgets）」でデモンストレーションしている一般的なGUIオペレーティング・システムの似たコンポーネントに組み込まれているのと同じキーを使うことが、アドバイスされています。
タブのイベントの結果としてフォーカスを受け取るとき、コンポジットのどこにフォーカスをセットするかは、コンポジットの種類によります。通常、以下のうちの一つになります。
以下のセクションでは、コンポジット要素の中でのフォーカス管理について、2つの戦略を説明します。ロービング・タブインデックスを作成する方法と、aria-activedescendantプロパティを使う方法の2つです。
コンポジット・UI・コンポーネントで、フォーカスを管理するためにロービング・タブインデックスを使用するとき、タブ・シーケンスに含まれる要素は、"0"のタブインデックスを持ち、コンポジットに含まれる他の全てのフォーカス可能な要素は、"-1"のタブ・インデックスを持ちます。 ロービング・タブインデックス・ストラテジーのアルゴリズムは、以下のとおりです。
tabindex="0"をセットし、それに含まれる他のすべての要素にtabindex="-1"をセットします。tabindex="0"を持っている要素に、tabindex="-1"を設定します。
tabindex="0"をセットしてください。tabindex="0"のある要素に、フォーカス（element.focus()）をセットしてください。tabindex="0"を持っているかどうかをチェックします。
もし、持っていないなら、ターゲットの要素にtabindex="0"をセットし、前にtabindex="0"を持っていた要素に、tabindex="-1"をセットします。
フォーカスを管理するために、aria-activedescendantではなく、むしろ、ロービング・タブインデックスを使用するメリットは、ユーザー・エージェントが、新しくフォーカスを受け取った要素を、ビューの中にスクロールすることです。
もし、コンポーネントのコンテナが、aria-activedescendantをサポートするARIAのroleを持っているなら、tabindex属性を操作し、コンテナ内のフォーカス可能な要素間でDOMのフォーカスを動かすことは、不要になります。代わりに、コンテナ要素だけが、タブシーケンスに含まれる必要があります。コンテナにDOMフォーカスがあるとき、コンテナの上のaria-activedescendantの値は、支援技術に、ウィジェット内でアクティブになっている要素を、伝えます。DOMフォーカスが、aria-activedescendantプロパティを持つ要素に存在したとしても、支援技術は、関連する要素を、フォーカスのある要素としてアクティブとみなすことになります。そして、aria-activedescendantの値が変わるとき、支援技術は、DOMフォーカスが実際に移動したときと同じように受け取るフォーカス変化のイベントを受け取ります。
フォーカスを管理するaria-activedescendantメソッドを使うステップは、以下のようになります。
aria-activedescendant="IDREF"を持ちます。参照される要素は、以下に記載のあるDOMリレーションシップ要件を満たす必要があります。aria-activedescendantの仕様は、aria-activedescendant属性をもつフォーカスのある要素と、その属性の値によってアクティブとして参照される要素の間のDOMリレーションシップに、重要な制限を配置しています。以下の3つの条件の1つを満たさなければなりません。
デフォルトで、ディセイブルのHTMLのinput要素は、タブ・シーケンスから削除されます。ほとんどの場合、通常、ディセイブルのインタラクティブ要素は、フォーカスできなくなることが、期待されます。しかしながら、ディセイブルの要素がフォーカス可能であるということが、一般的という場合もいくつかあります。特に、コンポジット・ウィジェットの中で存在します。例えば、「3.15 メニュー、もしくは、メニュー・バー（3.15 Menu or Menu bar）」のパターンで、デモンストレーションされているように、矢印キーでメニューをナビゲーションするとき、ディセイブルの項目は、フォーカス可能です。
ディセイブルの要素から、フォーカスを取り除くことは、ユーザーに、利益と不利益の両方を提供することが可能です。キーボード・ユーザーがディセイブルな要素をスキップできるようにすると、タスクの完了までに必要な多くのキー押下を減らします。しかしながら、ディセイブルな要素へのフォーカス移動を防ぐことは、フォーカスの移動で「見ている」スクリーン・リーダー・ユーザーから、それらの存在を隠してしまうことになります。
制作者は、ディセイブルな要素にフォーカスをあてることについて、一貫した慣習を採用するように推奨されます。このガイドの例は、以下の慣習を採用します。これらは、両方の一般的な方法を反映し、競合する項目のバランスをとることを試みます。
キーボード・フォーカスの経路にディセイブルな要素を含む影響を緩和する一つのデザイン・テクニックは、「5.9 キーボード・ショートカット（5.9 Keyboard Shortcuts）」に記載したような適切なキーボード・ショートカットを採用することです。
以下のキー・アサインは、慣習上、関連している機能が適切であれば、どんな状況でも仕様することが出来ます。WindowsやLinuxといったプラットフォームに関連づけられたアサインが実装され、macOSで動作しているブラウザーで使用されている間、macOSデバイスで動作しているブラウザーでmacOSのアサインに置き換えられることは、ユーザーにとって、キーボード・インタフェースをより発見可能で、直感的にする場合があります。いくつかの場合、システムやブラウザのキーボードが衝突することを避ける手助けともなりえます。
| ファンクション | Windows/Linuxキー | macOSキー |
|---|---|---|
| コンテキスト・メニューの表示 | Shift + F10 | |
| クリップボードへのコピー | Control + C | Command + C |
| クリップボードからの貼り付け | Control + V | Command + V |
| クリップボードへの切り取り | Control + X | Command + X |
| 最後のアクションを元に戻す | Control + Z | Command + Z |
| アクションをやり直す | Control + Y | Command + Shift + Z |
効果的にデザインされていれば、要素にフォーカスをあてたり、ウィジェットをアクティブにしたり、その両方を実施するようなキーボード・ショートカットは、ページやサイトでよく使われる機能のユーザビリティを大幅に高めることができます。このセクションは、いくつかのキーボード・ショートカット・デザインと、その効果に最も影響を及ぼす実装要件のいくつかを扱います。以下のようなものを含みます。：
このセクションは、どの要素と機能にキーボード・ショートカットをアサインし、どのような動作をそれぞれのショートカットに提供するかについて決定するときの要件を、以下に説明します。：
キーボード・ショートカットをアサインする前に、ショートカットをアサインする機能を、キーボード・ショートカット無しでも、確実にキーボード・アクセスを可能にしておくことが重要です。言い換えれば、キーボード・ショートカットのターゲットとなりうるすべての要素は、以下に記載したメソッドを使ったキーボードで、フォーカス可能になっている必要があります。
キーボード・ショートカットは、ナビゲーションによるアクセスの代用としては、使いません。これは、完全なキーボード・アクセスに不可欠です。理由は、以下になります。：
以下の慣習は、キーボード・ショートカットのために最も有利な動作を理解する助けになるかもしれません。
このセクションのための内容を作成する仕事は、issue 219で追跡されます。
キーボード・インタフェースを設計するときの最初のゴールは、基本的なキーボード・ナビゲーション・サポートだけを備え、シンプルで、効率的で、操作が直感的であることです。もし、キーボード・インタフェースの基本的な操作が、非効率的であるなら、基本的な設計の問題（次善のレイアウトやコマンド構造のような）を、キーボード・ショートカットを実装することによって、補完しようと努力することでは、ユーザーのフラストレーションを削減できないでしょう。この実用的な意義は、最も上手く設計されたユーザー・インタフェースにおいて、最適なユーザービリティを生み出すためにキーボード・ショートカットでアクセシブルにする必要のある機能のパーセンテージは、あまり高くないということです。多くの簡単なユーザインタフェースでは、キーボード・ショートカットは完全に余計である場合があります。そして、あまりに多くのキーボード・ショートカットのあるユーザー・インタフェースでは、過剰なショートカットは、最も役に立つ機能を、より思い出し難くするという認知的な負荷を生みだします。
キーボード・ショートカットをアサインする場所を決める時は、以下を考慮してください：
ショートカットに割り当てるキーを選択するときは、考慮すべき要件が非常にたくさんあります。
学習と記憶をサポートするキー・ショートカットの体系を設計する方法は、このガイドの範囲を超えています。キー・ショートカットの体系が大きく無ければ、ブラウザのような一般的なソフトウェアから身近なコンセプトを真似ることは、おそらく十分です。同様に、ローカライズが重要である間、それを扱う方法を記載することは、そのトピックに特化された他のリソースに残されています。
このセクションの残りでは、キー割り当ての競合に関連する要件と懸案のバランスをとるためのガイダンスを提供します。もし、キーの割り当てが、ユーザーのオペレーティング・システムやブラウザーや支援技術の機能に割り当てられたキーで競合を引き起こさないなら、それは、通常、理想的なことです。競合は、ユーザーにとって不可欠な機能への効率的なアクセスをブロックすることになり、競合の完全な嵐が、ユーザーを捉えることになります。同時に、意図的な競合が、役に立つといういくつかの事情があります。さらに、多種多様なオペレーティング・システム、ブラウザ、支援技術のキーが提供されており、競合がなくなっていないということを確信することは、ほとんど不可能です。そのため、意図的であろうと、未知であろうとに関わらず、競合の影響を緩和する戦略を採用することも重要です。
以下のセクションでは、メタ・キーは、Windows互換キーボードのWindowsキーと、MacOS互換キーボードのコマンド・キーになります。
アプリケーションとウィンドウの管理や、ディスプレイ、音のコントロールのようなシステム・レベルの機能を実行するキーの競合を避けることは、不可欠です。一般には、以下のタイプの割り当てを控えることで、実現できます。
さらに、一般に、ブラウザを含むほとんどのアプリケーションがサポートする重要なアプリケーション・レベルの機能がいくつか存在します。これらは以下が有ります。:
支援技術は、何千ものキーの割り当てをまとめて取り扱いますが、競合を避けることは、比較的簡単です。その理由は、支援技術が、オペレーティング・システムとアプリケーションの両方で競合を避けるキー割り当ての体系を開発しなければならなかったためです。キー・コマンドを一意に定義する修飾として特定のキーをハイジャックすることで、実現しています。例えば、多くの支援技術は、Caps Lockを、修飾として使用します。
以下のタイプの割り当てに関わらないようにすることで、支援技術をキーの競合から逸らすようにしています。
ブラウザのキーボードの体系の中で、かなりの類似性があり、その体系の中のパターンは、均質性を欠いています。その結果、ブラウザのキー割り当ての競合をさけることは、より難しくなっています。競合の影響が、キーボードでアクセス可能なメニューとキーボード・ショートカットのように、ほとんどすべての機能に2つの経路を利用できることによって、ときどきは、緩和されていても、よくつかう機能のショートカットとの競合を避けることは、重要です。以下の機能のショートカットとの競合を避けることに特別な注意を払ってください。：
キーの競合を避けることは、通常、望ましいのですが、意図的にブラウザの機能と競合することが、許容できる、もしくは、望ましくさえあるという状況があります。これは、以下のように、状況が組み合わさったとき、生じる可能性があります。：
例えば、フォーカスがエディタにあるときに利用可能な保存機能を考えてください。ほとんどのブラウザが使用するのは…続きます…
グリッドやテーブルを、十分に提示し、説明するためには、グリッド・パターンやテーブル・パターンに記述されたroleを使用しているヘッダー、行、セルを解析することに加え、支援技術が、以下を決定可能である必要があります。:
ブラウザは、レンダリングされたDOMにもとづくグリッドやテーブルの行と列の数で、自動的にアクセシビリティ・ツリーを装着します。しかしながら、データ・セットが、それが十分にレンダリングされるには、あまりに大きいというような場合、DOMがグリッドやテーブル全体を含まないという状況が多々あります。さらに、スキップされた列や行とデータがどのようにソートされているかというような、この情報のいくつかは、DOMストラクチャからは伝達されることができません。
以下のセクションは、ARIAがグリッドとテーブルのアクセシビリティのために提供している、以下のプロパティをどのように使うべきか、説明しています。
| プロパティ | 定義 |
|---|---|
aria-colcount |
table、grid、またはtreegridの列の総数を定義します。 |
aria-rowcount |
table、grid、またはtreegridの行の総数を定義します。 |
aria-colindex |
|
aria-rowindex |
|
aria-colspan |
table、grid、またはtreegridの中で、セルかグリッドセルによって、結合された列の数を定義します。
|
aria-rowspan |
table、grid、またはtreegridの中で、セルかグリッドセルによって、結合だれた行の数を定義します。
|
aria-sort |
行や列のアイテムが昇順か降順でソートされているかどうかを示します。 |
aria-rowcountとaria-rowindexの使用DOMストラクチャで示される行の数が、テーブル、グリッド、ツリーグリッドで利用可能な行の総数ではないとき、aria-rowcountプロパティは、利用可能な行の総数を伝えるために利用され、DOMに存在する行のインデックスのリストを識別するために、aria-rowindexプロパティとともに指定されます。
aria-rowcountは、table、grid、またはtreegridのroleといっしょに、要素に指定されます。その値は、ヘッダーの行を含む、利用可能な行の総数と等しい整数です。もし、行の総数が分からなければ、-1の値を指定してかまいません。-1の値を使用することは、より多くの行が、供給可能なサイズを指定することなく、DOMに含まれていて利用可能であることを示します。
aria-rowcountが、table、grid、またはtreegridで使用されるとき、aria-rowindexプロパティの値は、その子孫の行のそれぞれで、すべての見出し行も含んで、指定されます。aria-rowindexの値は、以下のような整数です。 :
aria-rowindexの値よりも、大きい。警告! aria-rowindexの値が無かったり、矛盾していることは、支援技術の動作の効果に打撃を与えるかもしれません。例えば、aria-rowindexに無効な値を指定したり、テーブルのすべての行ではなく、いくつかにそれをセットすることは、スクリーン・リーダーの表の読み上げ機能が、行をスキップしたり、単にその機能を停止する原因となりえます。
以下のコードで、仮想的なクラスのリストを含む表でのaria-rowcountとaria-rowindexのプロパティの使用をデモンストレーションします。
<!--マークアップでは、4行が示されていますが、aria-rowcountは、支援技術に実際のグリッドのサイズが463列であると伝えています。-->
<table role="grid" aria-rowcount="463">
aria-label="ヒストリー101の学生勤務表"
<thead>
<tr aria-rowindex="1">
<th>姓</th>
<th>名</th>
<th>E-mail</th>
<th>専攻</th>
<th>副専攻</th>
<th>学年</th>
</tr>
</thead>
<tbody>
<!--aria-rowindexは、支援技術に、この行が、463行のグリッドの中の51行であることを伝えています。-->
<tr aria-rowindex="51">
<td>ヘンダーソン</td>
<td>アラン</td>
<td>ahederson56@myuniveristy.edu</td>
<td>ビジネス</td>
<td>スペイン語</td>
<td>3年</td>
</tr>
<!--aria-rowindexは、支援技術に、この行が、463行のグリッドの中の52行であることを、伝えています。-->
<tr aria-rowindex="52">
<td>ヘンダーソン</td>
<td>アリス</td>
<td>ahederson345@myuniveristy.edu</td>
<td>エンジニアリング</td>
<td>無し</td>
<td>2年</td>
</tr>
<!--aria-rowindexは、支援技術に、この行が、463行のグリッドの中の53行であることを、伝えています。-->
<tr aria-rowindex="53">
<td>ヘンダーソン</td>
<td>アンドリュー</td>
<td>ahederson75@myuniveristy.edu</td>
<td>総合</td>
<td>無し</td>
<td>1年</td>
</tr>
</tbody>
</table>
aria-colcountとaria-colindexの使用DOM構造によって示される列の数が、テーブル、グリッド、ツリーグリッドなどで利用可能な列の総数でない場合、aria-colcountプロパティは、利用可能な列の総数を伝えるために使用し、DOMで提示される列のインデックスを認識するために、aria-colindexプロパティに一緒に指定します。
aria-colcountは、tableやgrid、treegridのroleを持つ要素に指定されます。その値は、有効な列の総数と同じ整数です。もし、列の総数が分からないなら、-1を指定してかまいません。-1の値を使用することは、より多くの列が、供給可能なサイズを指定することなく、DOMに含まれていて利用可能であることを示します。
aria-colcountが、tableやgridやtreegridで使用されるとき、aria-colindexプロパティの値は、その子孫の行のそれぞれか、それぞれの子孫の行のすべてのセルに指定され、それは、以下の示すように列が連続しているかどうかに依存しています。aria-colindexの値は、以下のような整数です。 :
警告! aria-colindexの値が無かったり、矛盾していることは、支援技術の動作の効果に打撃を与えるかもしれません。例えば、適切ではないaria-colindexの値を指定したり、行のすべてのセルではなく、そのいくつかにセットしていることは、スクリーン・リーダーのテーブル読み上げ機能が、セルを読み飛ばしたり、単純にその機能を止めてしまうということを引き起こす可能性があります。
aria-colindexの使用行のすべてのセルが、連続した整数で、列のインデックスの数を持っているとき、aria-colindexを、行の要素に、その最初の列のインデックス・ナンバーと同じ値で、セットすることができます。そして、ブラウザは、行のそれぞれのセルの列の番号を、計算するでしょう。
以下のコードは、16の列のグリッドを示しており、2列目から5列目が、ユーザーに表示されます。列が隣接しているので、aria-colindexは、それぞれの行に配置することが出来ます。
<div role="grid" aria-colcount="16">
<div role="rowgroup">
<div role="row" aria-colindex="2">
<span role="columnheader">名</span>
<span role="columnheader">姓</span>
<span role="columnheader">会社</span>
<span role="columnheader">住所</span>
</div>
</div>
<div role="rowgroup">
<div role="row" aria-colindex="2">
<span role="gridcell">フレッド</span>
<span role="gridcell">ジャクソン</span>
<span role="gridcell">Acme, Inc.</span>
<span role="gridcell">123 Broad St.</span>
</div>
<div role="row" aria-colindex="2">
<span role="gridcell">サラ</span>
<span role="gridcell">ジェームス</span>
<span role="gridcell">Acme, Inc.</span>
<span role="gridcell">123 Broad St.</span>
</div>
…
</div>
</div>
aria-colindexの使用行のセルが、連続していない整数で、列のインデックス・ナンバーを持つとき、aria-colindexは、行のそれぞれのセルに指定する必要があります。以下の例は、オンラインのグレード・ブックのためのグリッドを示しており、最初の2列が学生の名前を含み、後の列が成績を含んでいます。この例では、学生の名前を含む最初の2列が示されますが、成績の列は、10列から13列を示すためにスクロールされています。3列から9列は、表示されておらず、DOMにも存在しません。
<table role="grid" aria-rowcount="463" aria-colcount="13">
aria-label="「歴史101」に関する学生の成績"
<!--aria-rowcountとaria-colcountは、支援技術に、グリッドの実際のサイズが、463行で13列であることを伝えています。これは、マークアップで見られる行と列の数ではありません。-->
<thead>
<tr aria-rowindex="1">
<!--aria-colindexは、続く列が、全体の1列目と2列目を示していることを、支援技術に伝えています。-->
<th aria-colindex="1">姓</th>
<th aria-colindex="2">名</th>
<!--aria-colindexは、続く列が、成績のデータ全体を10、11、12、13列目で示していることを、支援技術のユーザーに、伝えています。-->
<th aria-colindex="10">宿題 4</th>
<th aria-colindex="11">クイズ 2</th>
<th aria-colindex="12">宿題 5</th>
<th aria-colindex="13">宿題 6</th>
</tr>
</thead>
<tbody>
<tr aria-rowindex="50">
<!--すべてのセルは、aria-colindex属性を定義する必要があります。-->
<td aria-colindex="1">ヘンダーソン</td>
<td aria-colindex="2">アラン</td>
<td aria-colindex="10">8</td>
<td aria-colindex="11">25</td>
<td aria-colindex="12">9</td>
<td aria-colindex="13">9</td>
</tr>
<tr aria-rowindex="51">
<td aria-colindex="1">ヘンダーソン</td>
<td aria-colindex="2">アリス</td>
<td aria-colindex="10">10</td>
<td aria-colindex="11">27</td>
<td aria-colindex="12">10</td>
<td aria-colindex="13">8</td>
</tr>
<tr aria-rowindex="52">
<td aria-colindex="1">ヘンダーソン</td>
<td aria-colindex="2">アンドリュー</td>
<td aria-colindex="10">9</td>
<td aria-colindex="11">0</td>
<td aria-colindex="12">29</td>
<td aria-colindex="13">8</td>
</tr>
</tbody>
</table>
aria-colspanとaria-rowspanの使用によるセル結合の定義tableのテーブル要素以外の要素を使用して作られているテーブル、グリッド、ツリーグリッドに関しては、aria-rowspanとaria-colspanのプロパティで、行や列を定義します。
aria-colspanの値は、以下のいずれかの整数です。:
aria-rowspanの値は、以下のいずれかの整数です。:
以下の例のグリッドには、2行の見出しがあります。最初の2つの列には、見出しの両方の行にかかる見出しがあります。その後の6つの列は、最初の行の見出しを3つのペアにグルーピングされています。3つのペアはそれぞれ、2列を結合しています。
<div role="grid" aria-rowcount="463">
aria-label="「歴史101」に関する学生の成績"
<div role="rowgroup">
<div role="row" aria-rowindex="1">
<!--ヘッダー・セルが1つ以上の行や列を結合しているとき、aria-rowspanと、aria-colspanは、
支援技術に、セルの見出しの情報を、正しいデータで提供します。-->
<span role="columnheader" aria-rowspan="2">姓</span>
<span role="columnheader" aria-rowspan="2">名</span>
<span role="columnheader" aria-colspan="2">テスト1</span>
<span role="columnheader" aria-colspan="2">テスト2</span>
<span role="columnheader" aria-colspan="2">ファイナル</span>
</div>
<div role="row" aria-rowindex="2">
<span role="columnheader">点数</span>
<span role="columnheader">成績</span>
<span role="columnheader">点数</span>
<span role="columnheader">成績</span>
<span role="columnheader">トータル</span>
<span role="columnheader">成績</span>
</div>
</div>
<div role="rowgroup">
<div role="row" aria-rowindex="50">
<span role="cell">ヘンダーソン</span>
<span role="cell">アラン</span>
<span role="cell">89</span>
<span role="cell">B+</span>
<span role="cell">72</span>
<span role="cell">C</span>
<span role="cell">161</span>
<span role="cell">B-</span>
</div>
<div role="row" aria-rowindex="51">
<span role="cell">ヘンダーソン</span>
<span role="cell">アリス</span>
<span role="cell">94</span>
<span role="cell">A</span>
<span role="cell">86</span>
<span role="cell">B</span>
<span role="cell">180</span>
<span role="cell">A-</span>
</div>
<div role="row" aria-rowindex="52">
<span role="cell">ヘンダーソン</span>
<span role="cell">アンドリュー</span>
<span role="cell">82</span>
<span role="cell">B-</span>
<span role="cell">95</span>
<span role="cell">A</span>
<span role="cell">177</span>
<span role="cell">B+</span>
</div>
</div>
</div>
注意:HTMLのtable要素を使うとき、行と列の結合を定義するには、 thとtdの要素のrowspanとcolspan属性を使って、ネイティブなセマンティックを使ってください
aria-sortでのソート順序の提示行や列がソートされているとき、ソートの方法を示すため、aria-sortプロパティが、列や行の見出しに適用できます。以下のテーブルは、使用できるaria-sortの値を記述しています。
| 値 | 説明 |
|---|---|
ascending |
データは昇順でソートされます。 |
descending |
データは降順でソートされます。 |
other |
データは、昇順でも降順でもないアルゴリズムでソートされます。 |
none |
デフォルト（ソートは適用されません。） |
ARIAが、複数のソート・キーのあるデータ・セットのために、ソートのレベルを示す方法を提供していないことに注意するのは、重要です。したがって、1つ以上の列や行にnone以外の値で、aria-sortを適用するには、制限があります。
以下の例のグリッドは、aria-sortを使用し、Quiz2の最も高いスコアから最も低いスコアへソートされた行を示しています。
<table role="grid" aria-rowcount="463" aria-colcount="13"
aria-label="「歴史101」に関する学生の成績">
<thead>
<tr aria-colindex="10" aria-rowindex="1">
<th>宿題4</th>
<!--aria-sortは、Quiz2の見出しをもつ列がグリッドの行をソートするために使用されていることを示しています。-->
<th aria-sort="descending">クイズ2</th>
<th>宿題5</th>
<th>宿題6</th>
</tr>
</thead>
<tbody>
<tr aria-colindex="10" aria-rowindex="50">
<td>8</td>
<td>30</td>
<td>9</td>
<td>9</td>
</tr>
<tr aria-colindex="10" aria-rowindex="51">
<td>10</td>
<td>29</td>
<td>10</td>
<td>8</td>
</tr>
<tr aria-colindex="10" aria-rowindex="52">
<td>9</td>
<td>9</td>
<td>27</td>
<td>6</td>
</tr>
<tr aria-colindex="10" aria-rowindex="53">
<td>9</td>
<td>10</td>
<td>26</td>
<td>8</td>
</tr>
<tr aria-colindex="10" aria-rowindex="54">
<td>9</td>
<td>7</td>
<td>24</td>
<td>6</td>
</tr>
</tbody>
</table>
presentationによるセマンティックの意図的な隠蔽ARIAは主にセマンティックを表現するために使われますが、要素のセマンティックを支援技術から隠しておくことが役立つことも、しばしば存在します。これは、role="presentation"で、実施されます。これはその要素が表示されるためだけに使われていることを宣言しており、そのため、いかなるアクセシビリティのセマンティックも持っていません。また、ARIA1.1の仕様は、role="none"を含んでおり、これは、presentationの同義語として提供されています。
例えば、タブのウィジェットがHTMLのulを使って作られていることを考えてください。
<ul role="tablist">
<li role="presentation">
<a role="tab" href="#">Tab 1</a>
</li>
<li role="presentation">
<a role="tab" href="#">Tab 2</a>
</li>
<li role="presentation">
<a role="tab" href="#">Tab 3</a>
</li>
</ul>
リストは、タブリストとして宣言されているので、リストの項目は、リストの文脈には存在しません。もし、支援技術が、これらのリスト項目を描くなら、ユーザーは混乱させられるでしょう。role="presentation"をliに適用することは、ブラウザに、アクセシビリティ・ツリーからこれらの要素を外すように伝えることになります。その結果、支援技術は、リスト項目の要素に気づかなくなり、タブ要素を、タブリストの直の子どもとしてみます。
role="presentation"の一般的な使い方には、以下の3つがあります。:
presentation"の効果role="presentation"が要素に指定されているとき、もし、ブラウザがrole="presentation"を無視する状況（「7.2 role="presentation"が無視されるようになる状況（7.2 Conditions That Cause Role presentation to be Ignored）」）が存在しないなら、以下の3つの効果があります。
display: noneでスタイリングされていたり、aria-hidden="true"をもっているような場合は、除きます。presentationが、ul、ol要素に適用されるなら、それぞれの子どものli要素は、role="presentation"を引き継ぎます。これは、ARIAが、listitem要素は親のlist要素を持つことを必要としているためです。そして、li要素は、支援技術には、提示されませんが、それらのli要素の中に含まれる要素（入れ子のリストを含みます）は、支援技術に見えます。presentationが、table要素に適用されるなら、子孫であるcaption、thead、tbody、tfooter、tr、th、td要素が、role="presentation"を継承し、このように、支援技術には、提示されません。しかし、thとtdの要素の中の要素（入れ子のテーブルを含みます）は、支援技術に提示されます。presentation"が無視されるようになる状況もし、適用されている要素について、以下の何れかが本当なら、ブラウザはrole="presentation"を無視し、そのために効果もありません。:
tabindex属性を持っている場合。aria-labelpresentation"の効果をデモンストレーションする例このコード:
<ul role="presentation">
<li>生年月日:</li>
<li>1月1日, 3456年</li>
</ul>
ブラウザで分析されると、ブラウザのアクセシビリティ・ツリーに依存しているスクリーン・リーダーや他の支援技術の認識は、以下と同じようになります。
<div>生年月日:</div>
<div>1月1日, 3456年</div>
プラットフォーム・アクセシビリティAPIで表現される、テキストだけを含むことができるユーザー・インターフェース・コンポーネントが存在します。例えば、アクセシビリティAPIは、ボタンに含まれるセマンティックな要素を表現する方法を持っていません。この制限に対処するために、WAI-ARIAは、ブラウザが、自動的にrole="presentation"を、セマンティックな子をサポートすることができないroleを持つ要素のすべての子孫の要素に、適用することを必要とします。
The roles that require all children to be presentational are:すべての子が表示のみにする必要があるroleは、以下となります。：
例えば、以下のタブ要素（見出しを含みます）を考えてください。
<li role="tab"><h3>私のタブのタイトル</h3></li>
WAI-ARIAは、タブの子孫は表示のみになって欲しいので、以下のコードが同等になります。
<li role="tab"><h3 role="presentation">私のタブのタイトル</h3></li>
スクリーン・リーダーのようにアクセシビリティAPIを頼りとする技術を使うすべての人の見解からは、上のコードは以下と同等になるので、見出しは存在しません。
<li role="tab">私のタブのタイトル</li>
これが、何をするか、詳細な説明は、role="presentation"のセクション（「7. role=presentationによるセマンティックの意図的な隠蔽（Intentionally Hiding Semantics with the presentation Role）」）を、見てください。
以下も、参照してください。:
以下も、参照してください。:
最初にお読みください。の
ブラウザーと支援技術サポートのセクション。
報告集。
報告集。
デザイン・パターンセクション。
以下も、参照してください。:
以下も参照してください。:
「WAI-ARIA Authoring Practices1.1」は、「Authoring Practices Task Force」全体の仕事であり、重要な仕事に貢献し、価値あるフィードバックを提供するオープン・ソース・コミュニティを通じた、多くの人々からの成果でもありつつ、バージョン1.1の内容やコードの大部分を明確に提供した以下の人々に感謝します。
この公開は、the Department of EducationのU.S.Federal funds, National Institute on Disability, Independent Living, Rehabilitation Research (NIDILRR)から、一部資金が提供されました。当初の契約番号は、ED-OSE-10-C-0067で、現在の契約番号は、HHSP23301500054Cです。この公開の内容は、the Department of Educationの視点や政策を、必ずしも反映するというわけではありません、そして、商号、商品、または組織の言及は米国政府による裏書きを含意しません。