Jump to Table of Contents Pop Out Sidebar

WAI-ARIA オーサリング・プラクティス 1.1

W3C ワーキング・グループ・ノート

このバージョン:
https://www.w3.org/TR/2019/NOTE-wai-aria-practices-1.1-20190207/
最後に公開された(最新の)バージョン:
https://www.w3.org/TR/wai-aria-practices-1.1/
編集者の最後(最新)の草案:
https://w3c.github.io/aria-practices/
前のバージョン:
https://www.w3.org/TR/2018/NOTE-wai-aria-practices-1.1-20180726/
編集者:
(Facebook)
(University of Illinois)
(Adobe)
Michiel Bijl (Invited Expert)
(W3C)
以前の編集者:
Joseph Scheuhammer (Inclusive Design Research Centre, OCAD University) (Editor until October 2014)
Lisa Pappas (SAS) (Editor until October 2009)
Rich Schwerdtfeger (IBM Corporation) (Editor until October 2014)

要約

このドキュメントは、リッチ・インターネット・アプリケーションを開発するために、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日」によって、管理されます。

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の効果のような、より一般的なトピックスをカバーします。

2. リード・ミー・ファースト

2.1 ARIA無しのほうが、悪いARIAよりも良い

機能的に、ARIAのrole、state、propertyは、支援技術に関して、CSSに似ています。 スクリーン・リーダー・ユーザにとっては、ARIAは、非視覚的経験のレンダリングを制御します。 誤ったARIAは、対応する非視覚的な体験についての潜在的な破壊的効果により、視覚的な体験を間違って伝えます。

本書に含まれるすべてのガイダンスやARIAを使用する前に、以下の2つの根本的な原則を理解することに時間を費やしてください。

原則1: roleは、約束です。

コード:

        <div role="button">注文</div>
           

上記のコードは、この<div>の作者が、キーボードとして期待されるキー・ボード・インタラクションを提供するJavaScriptを組み込むことを、約束しています。HTMLの入力要素と異なり、ARIAのroleは、ブラウザに、キーボードの動作やスタイリングを生じさせたりはしません。

そのroleの約束を実現せずにroleを使用することは、注文を破棄しショッピング・カードを空にするような「注文」ボタンを作ることに似ています。

このガイドの目的の1つは、それぞれのARIAのroleに関して、期待された振舞いを定義することです。

原則2: ARIAは、パワーと危険を生み出すため、姿を消すこともでき、拡張することもできます。

情報の支援技術が必要とするユーザインタフェース要素の意味と目的は、アクセシビリティ・セマンティックスと言います。 支援技術の観点から、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>
      

2.2 ブラウザと支援技術サポート

このガイドからシステムに対してコードを使う前に、支援技術との互換性のテストを必ずおこなってください。 このガイドの目的は、ARIAの仕様で定義されたように、適切なARIA1.1の使用方法を描くことです。デザイン・パターン、参考例、サンプル・コードは、ブラウザや支援技術でのARIA1.1のサポートのギャップにより生じる問題に対処するためのコード・テクニックは、意図的に記述も実装もしていません。 このため、対象者の中で関連している各ブラウザと支援技術の全ての組み合わせにより、実装を徹底的にテストすることが、賢明です。

同様に、このガイドのJavaScriptとCSSは、これを書いている時点で、Chrome、Firefox、インターネットエクスプローラ、およびSafariの最新のバージョンと互換性があるように書かれています。 特に、いくつかのJavaScriptとCSSは、インターネット・エクスプローラ・バージョン10か、それより早いものに関しては、正しく機能しないかもしれません。

ARIA・ワーキング・グループと他の貢献者がエラーを見逃したケースを除き、特定のブラウザや支援技術で上手く動作しない、このガイドの例は、ブラウザか支援技術のバグをデモンストレーションしています。 このため、ブラウザや支援技術の開発者は、ARIA1.1に関するサポートの品質を評価する助けとして、このガイドのコードを利用することが出来ます。

2.3 モバイルとタッチ・サポート

現在、このガイドは、どの例がモバイル・ブラウザやタッチ・インタフェースと互換性があるかは、示しません。 いくつかの例が、モバイルとタッチのサポートを拡張するような特定の機能を含んでいるとき、いくつかのARIAの機能はどんなモバイルブラウザでもサポートされません。 さらに、複数のモバイル・ブラウザで動作するタッチ・インタフェースを提供するための標準的なアプローチは、まだ存在しません。

タッチとモバイルのサポートについてのさらなるガイダンスは、ガイドの今後のリリースに向けて、計画されます。

3. デザイン・パターンとウィジェット

このセクションは、一般的なリッチ・インターネット・アプリケーション・パターンとウィジェットを、WAI-ARIAのrole、state、propertyを適用し、キーボード・サポートを実装することによって、アクセシブルにする方法をデモンストレーションします。

3.1 アコーディオン(表示/非表示機能を伴ったセクション)

アコーディオンは、インタラクティブな見出しが垂直に積み重ねられたものです。それぞれの見出しには、セクションの内容を代表するタイトル、抜粋、サムネイルが含まれています。 見出しは、ユーザが関連する内容のセクションを表示したり隠したりできるように、コントロールとして機能します。 アコーディオンは、一般的に、複数のコンテンツのセクションをシングル・ページに表示するとき、スクロールの必要性を軽減するために使用されます。

アコーディオンを理解するための用語:

アコーディオン・ヘッダー:
セクションの内容を代弁するラベルやサムネイルで、いくつかの実装によりセクションの内容を表示し、隠すためのコントロールとしても提供されています。
アコーディオン・パネル:
アコーディオン・ヘッダーに関連づけられたコンテンツのセクションです。

いくつかのアコーディオンには、常にアコーディオン・ヘッダーに隣接して目に見える追加要素があります。 例えば、アコーディオン・ヘッダーに対応するセクションに適用されるアクションへのアクセスを提供するため、メニュー・ボタンが、それぞれのアコーディオン・ヘッダーに、ついているかもしれません。 そして、いくつかの場合には、隠された内容の抜粋も、視覚的に表示されているかもしれません。

アコーディオンの例:: 3つのセクションに分割された領域を、アコーディオンを使って、1度に1つのセクションを表示するようにしています。

キーボード・インタラクション

  • エンターまたはスペース:
    • フォーカスが折りたたまれたパネルのヘッダーにあるとき、対応するパネルを開きます。 もし、実装が、一つのパネルだけ開くことを許していて、他のパネルが開かれるなら、そのパネルを閉じます。
    • フォーカスが開いたパネルのヘッダーにあるとき、もし実装が閉じることをサポートしているなら、そのパネルを閉じます。 いくつかの実装では、常に一つのパネルが開かれていることを要求し、一つのパネルだけが開くことを許します。そして、それらは、閉じる機能をサポートしません。
  • タブ:フォーカスを次のフォーカス可能な要素に移動します。アコーディオンの全てのフォーカス可能な要素はページのタブ・シーケンスの中に含まれます。
  • シフト+タブ:フォーカスを一つ前のフォーカス可能な要素に移動します。アコーディオンの全てのフォーカス可能な要素はページのタブ・シーケンスの中に含まれます。
  • 下向き矢印 (任意): アコーディオン・ヘッダーの上にフォーカスがあるなら、フォーカスは次のヘッダーに移動します。 フォーカスが最後のアコーディオン・ヘッダーにあるなら、何もしないか、最初のアコーディオン・ヘッダーに移動します。
  • 上向き矢印: (任意): フォーカスがアコーディオン・ヘッダーにあるなら、フォーカスを前のアコーディオン・ヘッダーに移動します。 最初のアコーディオン・ヘッダーの上にフォーカスがあるなら、何もしないか、フォーカスを最後のアコーディオン・ヘッダーに移動します。
  • ホーム (任意): アコーディオン・ヘッダーの上にフォーカスがあるとき、フォーカスを最初のアコーディオン・ヘッダーに移動します。
  • エンド (任意): アコーディオン・ヘッダーの上にフォーカスがあるとき、フォーカスは最後のアコーディオン・ヘッダーに移動します。

WAI-ARIAのRole、State、Property:

  • それぞれのアコーディオン・ヘッダーのタイトルが、role=buttonのある要素に含まれています。
  • それぞれのアコーディオン・ヘッダ button は、aria-levelについての値を持つ、role=headingとした要素で括られます。aria-levelは、そのページの情報アーキテクチャを適切に表現しています。
    • もし、ネイティブなホスト・ランゲージが、暗黙のheadingaria-lebelのある要素を持っているなら、例えば、HTMLのヘッディング・タグのようなものであれば、ネイティブなホスト・ランゲージが利用されるかもしれません。
    • button要素は、heading要素内の唯一の要素です。 すなわち、他の視覚的に存在し続ける要素があるなら、それらは、heading要素内には含まれていません。
  • もし、アコーディオン・ヘッダーと関連づいているアコーディオン・パネルが視覚的に見えるなら、ヘッダーbutton要素は、aria-expandedを、trueにセットしています。 もし、パネルが表示されていないなら、aria-expandedは、falseにセットされています。
  • アコーディオン・ヘッダー button 要素は、アコーディオン・パネルの内容を含む要素のIDにセットされたaria-controlsを、持っています。
  • もし、アコーディオン・ヘッダーのあるアコーディオン・パネルが表示されていて、アコーディオンが、閉じられることが許されていないなら、そのヘッダー button 要素は、aria-disabledtrueにセットしています。
  • 任意となりますが、パネルの内容をもつコンテナーとして提供されている要素には何れも、role=regionaria-labelledbyがあります。これらは、パネルの表示をコントロールするボタンを参照する値を伴っています。
    • ランドマーク領域を不用意に増やすようなシチュエーションでrole=regionを使用するのは避けてください。例えば、同時に開くことのできるパネルが、おおよそ6つ以上になるようなアコーディオンです。
    • パネルがヘッディング要素や入れ子のアコーディオンを含んでいるとき、role=regionは、特に、スクリーン・リーダ・ユーザが構造を認識するのに役立ちます。

3.2 アラート

role=alertは、ユーザのタスクを邪魔することなくユーザの注意を引き付ける方法で、簡潔で重要なメッセージを表示する要素です。 動的にレンダリングされたアラートは、ほとんどのスクリーン・リーダーによって、自動的にアナウンスされ、いくつかのOSでは、アラート音を鳴らすかもしれません。 このとき、スクリーン・リーダーは、ページの読み込みが完了する前にページ上に存在するアラートについては、ユーザーに知らせないので、注意が必要です。

アラートは、作業中のユーザーの能力を妨げることなく、潜在的にタイミングを重視する重要な情報の提供を意図しているため、キーボード・フォーカスに影響を及ぼさないことは、非常に重要です。 アラート・ダイアログは、ワーク・フローの邪魔をしないようなシチュエーションを想定してデザインすることが、大切です。

また、自動的に消えてしまうアラートのデザインは、避けることが重要です。 あまりに直ぐに消えてしまうアラートは、WCAG 2.0 success criterion 2.2.3への不適合につながる可能性があります。 デザインで考慮しておくべき、他のこととしては、アラートで邪魔されることが、多いかどうかです。 頻繁に邪魔されることは、視覚的かつ認知的に障害のある人の使いやすさを阻害し、これは、WCAG 2.0 success criterion 2.2.4への適合をより難しくしてしまいます。

アラートの例

キーボード・インタラクション

アラート(WAI-ARIAのライブ・リージョン)は、どんなキーボード・インタラクションも必要としません。

WAI-ARIAのRole、States、Property

ウィジェットは、role=alertを持ちます。

3.3 アラートとメッセージ・ダイアログ

アラート・ダイアログは、モーダル・ダイアログであり、重要なメッセージを把握して、応答を取得するというユーザのワーク・フローを邪魔します。 ここでの例は、確認を促す動作とエラーメッセージの確認を含んでいます。 role=alertdialogは、支援技術やブラウザが、アラート・ダイアログを他のダイアログとは別に、識別できるようにします。そのため、支援技術やブラウザは、システムのアラート音を再生するなど、アラート・ダイアログに特別な機能を選択肢として用意しています。

アラート・ダイアログの例: アラート・ダイアログをデモンストレーションする確認メッセージ

キーボード・インタラクション

モーダル・ダイアログ・パターンに関するキーボード・インタラクションの部分を見てください。

WAI-ARIAのRole、States、Property

  • ダイアログの全ての要素(アラート・メッセージと全てのダイアログ・ボタンを含みます)をコンテンツとしてもっている要素は、role=alertdialogを持っています。
  • role=alertdialogを持つ要素は、以下の何れかを持っています。
    • もし、ダイアログが目に見えるタイトルを持ってるなら、ダイアログのタイトルを含む要素に関連づいているaria-labelledbyの値。
    • ダイアログが目に見えるタイトルを持っていない場合は、aria-labelの値。
  • role=alertdialogを持つ要素は、アラート・メッセージを含む要素に関連づいているaria-describedbyの値のセットを持っています。

3.5 ボタン

ボタンは、ユーザにアクションやイベントのトリガーを提供するウィジェットです。フォームの送信、ダイアログを開く、アクションのキャンセル、削除操作など。 ボタンがダイアログを開くことをユーザに伝える一般的な合意は、「...」(省略記号)をボタン・ラベルに付け加えることです。例としては、「名前をつけて保存...」です。

普通のボタンのウィジェットに加えて、WAI-ARIAは他に2つのタイプのボタンをサポートします:

注意

ボタンとして実行された動作は、リンクの機能と、明らかに異なります(後の「リンク・パターン」を見てください)。 その概観とウィジェットのroleが、提供する機能に合致していることは、重要です。 それにもかかわらず、要素は、しばしば、リンクの見た目を持っていますが、ボタンの機能を実行します。 そのような場合、要素にrole=buttonを指定することは、支援技術のユーザがその要素の機能を理解することを助けます。 なんにせよ、見た目のデザインを、その機能とARIAのroleに合うように調整することが、より良い解決策となります。

ボタンの例: クリック可能なHTMLのdiv要素とspan要素の例です。アクセシブルなコマンドとトグル・ボタンとしています。

キーボード・インタラクション

ボタンがフォーカスを持っているとき:

  • スペース: ボタンをアクティブにします。
  • エンター: ボタンをアクティブにします。
  • ボタンのアクティブ化に続いて、フォーカスは、ボタンの動作の種類に応じて、動作します。例えば:
    • もし、ダイアログを開くなら、フォーカスは、ダイアログの中に移動します。(「ダイアログ・パターン」を、見てください。)
    • ダイアログのコンテキストで実施される機能が、論理的に異なる要素につながるのでなければ、もし、ボタンをアクティブにすることで、ダイアログを閉じるなら、フォーカスは、基本的には、ダイアログを開いたボタンに戻ります。 例えば、ダイアログの中でキャンセル・ボタンを押した時、そのダイアログを開いたボタンにフォーカスが戻ります。 しかしながら、もし、ダイアログが、そのダイアログを開いたページが削除されたことを、確認しているなら、フォーカスは論理的に新しいコンテキストに移動するでしょう。
    • もし、ボタンが現在のコンテキストを手放さないなら、フォーカスは基本的に、動作後、そのボタンに残っているでしょう。例えば、「適用」とか「再計算」ボタンです。
    • ボタンの動作が、コンテキストの変化を示す(例えば、ウィザードで、次のステップに移動したり、別の検索基準を加えるような)場合、しばしば、そのアクションの開始場所にフォーカスを移動するのが、適切だったりします。
    • もし、ボタンがショートカット・キーで動くなら、通常、フォーカスはショートカット・キーが動かされたコンテキストに残っています。 例えば、Alt + Uが"Up"ボタンとしてアサインされていて、これを押すと、リストの中の現在フォーカスのある項目を、リストの中でより上の位置に移動するとします。そのリストの中にフォーカスがあるときAlt+Uを押しても、そのリストからはフォーカスは移動しないでしょう。

WAI-ARIAのRole、States、Property

  • ボタンは、ボタンとしてのroleを持ちます。
  • buttonは、アクセシブルなラベルを持ちます。 デフォルトでは、アクセシブルな名前は、ボタン要素の中のテキスト・コンテンツから、生成されます。 しかしながら、aria-labelledbyaria-labelで提供することもできます。
  • もし、ボタンの機能に関する説明が存在するなら、ボタンの要素は、aria-describedbyに、その説明を含む要素のIDを指定します。
  • ボタンに関連するアクションが利用できない場合は、ボタンは、aria-disabled=trueとします。
  • もし、ボタンがトグル・ボタンであれば、aria-pressedの状態を指定します。 ボタンのトグルがオンになっていれば、このステータスの値は、trueとし、オフの場合は、ステータスはfalseとします。

3.7 チェックボックス

WAI-ARIAは、チェックボックスのウィジェットの2つのタイプをサポートします:

  1. デュアル・ステート: チェックボックスの最も一般的なタイプであり、ユーザは2つの選択肢の間でそれで切り換えることができます。--チェックされているか、チェックされていないかです。
  2. トリ・ステート:このタイプのチェックボックスは、部分的なチェックとして追加された3番目の状態をサポートします。

トリ・ステート・チェックボックスで一般的なものは、ソフトのインストーラーで見ることが出来ます。単一のトリ・ステート・チェックボックスが、インストール・オプションのグループ全体を表現したり、コントロールするのに、使われます。 グループの中のそれぞれのオプションは、デュアル・ステート・チェックボックスで、オンとオフを個別に切り替えることが出来ます。

ユーザは、トリ・ステート・チェックボックスを使うことで、グループ内のすべてのオプションの変更を、一つの動作で行うことが出来ます:

キーボード・インタラクション

チェックボックスにフォーカスがあるとき、スペースを押すと、チェックボックスの状態は変化します。

WAI-ARIAのRole、States、Property

  • チェックボックスには、checkboxのroleがあります。
  • チェックボックスには、以下のうちの1つの方法で提供される、アクセシブルなラベルがあります:
    • role=checkboxとなっている要素に含まれた、目に見えるテキスト。
    • role=checkboxとなっている要素にセットされたaria-labelledbyの値で関連づけられている、目に見えるテキスト。
    • role=checkboxとなっている要素にセットされたaria-label
  • チェックされると、チェックボックスの要素は、aria-checkedの状態をtrueにセットします。
  • チェックされないと、チェックボックスの要素は、aria-checkedの状態をfalseにセットします。
  • 部分的にチェックされると、チェックボックスの要素は、aria-checkedの状態をmixedにセットします。
  • もし、目に見えるラベルを伴った論理的な一つのグループとして複数のチェックボックスを提示するなら、それらのチェックボックスは、role=groupと指定された要素で括られます。そして、role=groupと指定された要素は、ラベルを含む要素のIDと関連づいた aria-labelledbyプロパティが設定されます。
  • もし、チェックボックスやチェックボックスのグループに関連した、静的な補足の説明テキストを表示するなら、チェックボックスやチェックボックスのグループには、その説明テキストを含む要素のIDと関連づいたaria-describedbyプロパティを設定します。

3.8 コンボ・ボックス

コンボボックスは、2つの異なった要素の組み合わせで作られたウィジェットです。:1)1行のテキストボックスと2)ユーザがテキストボックスの値を指定するのを助けるために組み込まれたポップアップ要素です。 ポップアップは、リストボックスグリッドツリー、もしくは、ダイアログかもしれません。 また、多くの実装では、3つめの任意の要素を含んでいます。--テキストボックスに隣接したグラフィカルなボタンで、ポップアップが利用できることを示します。 もし選択肢が利用可能なら、ボタンを押すと、ポップアップが表示されます。

ポップアップは、デフォルトで隠されており、それを表示するトリガーとなる状態は、それぞれの実装で、指定されています。いくつかの可能性のあるポップアップを表示する状態は、以下を含みます。:

コンボボックス・ウィジェットは、2種類のシナリオの内の1つで、1行のテキストボックスの値を設定するのに、役立ちます。

  1. テキストボックスの値は、事前に定義された複数の許容値から、選択されなければなりません。例えば、位置のフィールドは、正しい位置の名前を含まなければなりません。 リストボックスとメニューボタンのパターンもこのシナリオで役立つことに注意してください。;コンボボックスと、その代替のパターンとの違いは、以下で説明されます。
  2. テキストボックスは、どんな任意の値も含むかもしれませんが、可能な値をユーザに示すのに、有利です。例えば、検索フィールドは、ユーザの時間を節約するために、似たような、あるいは、以前に実施した検索を示すかもしれません。

提示された選択肢と、選択肢が表示される方法の本質は、オートコンプリート動作と呼ばれます。 コンボボックスは、オートコンプリートの4つのフォームのうちの1つを持つことができます:

  1. オートコンプリート無し:ポップアップが開くとき、それに含まれる値は、テキストボックスに入力された文字とは、関係ありません。 例えば、ポップアップは、最近入力された値のセットを示し、その選択肢は、ユーザが入力したようには、変化しません。
  2. 手動選択を伴ったリスト・オートコンプリート: ポップアップが開くとき、テキストボックスに入力された文字と同じか、または論理的に対応する値が表示されます。 ユーザがポップアップの値を選択しない場合、ユーザが入力した文字列がテキストボックスの値になるでしょう。
  3. 自動選択を伴ったリスト・オートコンプリート: ポップアップが開くとき、テキストボックスに入力された文字と同じか、または論理的に対応する値が表示されます。そして、最初の選択肢が、選択されたものとして、自動的に強調されます。 ユーザが異なった提案を選ぶか、テキストボックスの文字列を変えない場合、コンボボックスがフォーカスを失うときに、自動的に選択された選択肢がテキストボックスの値になります。
  4. インライン・オートコンプリートがあるリスト: これは、1つの付加的な機能がある自動選択を伴ったリストと同じです。ユーザによって入力されていない選択肢の一部分が、テキストボックスの入力カーソルの後に、インラインで現れます(完成ストリング)。このインラインの完成ストリングは、視覚的に強調され、選択状態となっています。

どんなフォームのリスト・オートコンプリートでも、ユーザの入力に応じて、ポップアップは表示されたり、消えたりするでしょう。 例えば、もし、ユーザが2つの文字列を入力すると、5つの選択肢が表示され、続いて、3つめの文字が入力されて、どの選択肢にも合致しなくなると、ポップアップは閉じられてしまい、インラインの完成ストリングも消えます。

視覚的にコンパクトで、離散値のセットから一つの値を選択できるようにするウィジェットを、構築するときは、リストボックスか、メニュー・ボタンのどちらかが、実装して、使用するのに、より簡単です。 リストボックスとメニュー・ボタンの両方と、コンボボックスを区別するための機能は、コンボボックスの値が編集領域に表示されることです。 このように、コンボボックスは、リストボックスとメニュー・ボタンの両方が欠いている一つの機能、すなわち、クリップボードにコピーする値のいくつか、もしくはすべてを選択できる能力を、ユーザに提供できることです。 コンボボックスとメニュー・ボタンのウィジェットの両方と、リストボックス・ウィジェットを区別する特徴は、やり直し機能を提供できる能力があることです。 多くの実装において、ユーザは、コンボボックスやメニューで許された値のセットをナビゲートしてから、エスケープを押すことで、ナビゲートする前にウィジェットがもっていた値に戻すことを決断することが出来ます。 対照的に、リストボックスをナビゲートすることは、直ぐにその値を変更し、エスケープはアンドゥ機能を提供しません。

注意

グリッドやツリー、ダイアログをポップアップするコンボボックスのオプションは、ARIA1.1で紹介されていました。 ARIA 1.1の仕様で作成された変更も、テキストボックスとポップアップを独立して認識できる要素として、支援技術が提示可能なコード・パターンのサポートを追加します。 ARIA1.0と1.1の両方のパターンが、以下のセクションで記述されます。 支援技術のサポートが十分であれば、ARIA1.1のパターンがお勧めとなりますが、ARIA1.0のパターンを軽視する計画は、全くありません。

キーボード・インタラクション

  • タブ: ページのタブ順序内に、テキストボックスがあります。
  • 注意: ポップアップ・インディケータ・アイコンやボタン(もし存在しているなら)と、ポップアップと、ポップアップの子や孫は、ページのタブ順序からは、外れています。
テキストボックス・キーボード・インタラクション

フォーカスが、テキストボックスにあるとき:

  • 下矢印: もし、ポップアップが利用可能で、フォーカスをポップアップ内に移動させるなら:
    • もし、オートコンプリートの動作のために、下矢印が押される前に、選択肢が自動的に選択されるなら、フォーカスは、自動的に選択された選択肢に従い、選択肢に配置されます。
    • さもなければ、ポップアップの中の最初のフォーカス可能な要素に配置されます。
  • 上矢印 (任意): もし、ポップアップが利用可能なら、ポップアップの最後のフォーカス可能な要素に配置します。
  • エスケープ: ポップアップが表示されているなら、ポップアップを消します。任意ですが、テキストボックスをクリアします。
  • エンター: もし、オートコンプリートの選択肢が自動的に選択されているなら、入力カーソルをテキストボックスの許可された値の最後に配置するか、値に関するデフォルトのアクションを実行することを、選択肢に許可してください。 例えば、メッセージング・アプリケーションにおいて、デフォルトのアクションは、許可された値をメッセージの受信者のリストに追加し、ユーザが他の受信者を追加することができるように、テキストボックスをクリアしておくことかもしれません。
  • 文字キー: テキストボックスに文字を入力します。いくつかの実装では、ある文字を不正とみなしたり、その入力を阻止したりするかもしれません。注意してください。
  • デバイスプラットホームに適切な標準の1行テキスト編集キー(以下の「注意」を参照してください)。
  • Alt+下矢印(任意): もし、ポップアップが利用可能で、表示されていないなら、フォーカスを動かさずにポップアップを表示します。
  • ALt+上矢印 (任意): もし、ポップアップが表示されているなら:
    1. もし、ポップアップがフォーカスを含んでいるなら、フォーカスをテキストボックスに戻します。
    2. ポップアップを閉じます。
注意

デバイスプラットホームに適切な標準の1行テキスト編集キー:

  1. 入力、カーソル移動、選択、そして、テキストを操作するためのキーを含めてください。
  2. 編集機能のための標準的なキーの割り振りは、デバイス・オペレーティング・システムに依存します。
  3. テキスト編集機能を提供するために最も手堅いアプローチは、ブラウザをあてにすることです。ブラウザは、テキスト入力可能なHTMLのインプットや、contenteditableというHTML属性の要素のために、キーを提供しています。
  4. 重要: これらを実施するために使用されたキーのイベントを取り込むことによって、JavaScriptが、ブラウザの提供するテキスト編集機能を邪魔しないことを確認してください。
リストボックス・ポップアップ・キーボード・インタラクション

フォーカスがリストボックス・ポップアップにあるとき:

  • エンター:ポップアップを閉じ、選択された値をテキストボックスに表示し、値の最後に入力カーソルを表示します。これにより、フォーカスのあるオプションが選択されたことになります。
  • エスケープ: ポップアップを閉じ、テキストボックスにフォーカスを戻します。任意ですが、テキストボックスをクリアします。
  • 右矢印: ポップアップを閉じることなく、フォーカスをテキストボックスへ戻してください。そして、入力カーソルを一文字、右へ移動させてください。もし、入力カーソルが最も右の文字にあるなら、カーソルは動かしません。
  • 左矢印: ポップアップを閉じずにテキストボックスへフォーカスを戻し、入力カーソルを1文字、左に移動します。 入力カーソルが一番左の文字にある場合は、カーソルは、動かしません。
  • すべての文字キー: ポップアップを閉じずにテキストボックスにフォーカスを戻し、文字を入力します。
  • バックスペース (任意): フォーカスをテキストボックスに戻し、カーソルの前の文字を削除します。
  • 削除 (任意): フォーカスをテキストボックスに戻し、もし選択肢が選ばれていたら選択状態を解除します。そして、もしインラインのオートコンプリートの文字列が表示されているなら削除します。
  • 下向き矢印: フォーカスを次の選択肢に移動し、選択状態にします。もし、フォーカスが最後の選択肢にあるなら、フォーカスをテキストボックスに戻すか、何もしないようにします。
  • 上向き矢印: フォーカスを前の選択肢に移動し、選択状態にします。もし、フォーカスが最初の選択肢にあるなら、フォーカスをテキストボックスに戻すか、何もしないようにします。
  • ホーム (任意): フォーカスを最初の選択肢に移動し、選択状態とするか、フォーカスをテキストボックスに戻し、最初の文字にカーソルを移動します。
  • エンド (任意): 最後の選択肢にフォーカスを移動するか、フォーカスをテキストボックスに戻して、最後の文字の後にカーソルを表示します。
注意
  1. DOMフォーカスは、コンボボックスのテキストボックスに維持された状態とし、なおかつ、支援技術のフォーカスは、5.6.2 Managing Focus in Composites Using aria-activedescendant(aria-activedescendantを使用しているコンポーネントでのフォーカス・マネージメント)」に記述されているように、aria-activedescendantを使用しているリストボックス内で移動されます。
  2. 選択はリストボックス内のフォーカスに従います。リストボックスは、テキストボックスの値として、一度に、一つの値の選択だけが許されます。
グリッド・ポップアップ・キーボード・インタラクション

グリッド・ポップアップでは、それぞれの選択肢が、単一のセルか、行全体のどちらかによって、表現されているかもしれません。グリッド・デザインのこの側面がキーボード・インタラクション・デザインにどう影響するか、そして、フォーカスの動きに反応して、選択状態が移動する方法に関しては、以下の「注意」をみてください。

  • エンター: ポップアップを閉じて、テキストボックスの選択されている値と置き換え、入力カーソルを値の最後に移動します。これにより、現在、選択されている選択肢を受け入れます。
  • エスケープ: ポップアップを閉じ、フォーカスをテキストボックスに移動します。任意ですが、テキストボックスの内容をクリアします。
  • すべての文字: ポップアップを閉じずにフォーカスをテキストボックスに戻し、文字を入力します。
  • バックスペース (任意): フォーカスをテキストボックスに戻し、カーソルの前の文字を削除します。
  • デリート (任意): もし、選択肢が選択されていたら、選択状態を無くし、フォーカスをテキストボックスに戻します。そして、もし、表示されているなら、インラインのオートコンプリートも無くします。
  • 右矢印: 1セル、右にフォーカスを移動します。任意ですが、もし、行の右端のセルにフォーカスがあるなら、次の行の最初のセルに移動してもかまいません。フォーカスが、グリッドの最後のセルにあるなら、何もしないか、テキストボックスにフォーカスを戻します。
  • 左矢印: 1セル、左にフォーカスを移動します。任意ですが、もしフォーカスが行の一番左にあるときは、フォーカスは、前の行の最後のセルに移動してもかまいません。もし、フォーカスがグリッドの最初のセルにあるときは、何もしないか、テキストボックスにフォーカスを戻します。
  • 下矢印: フォーカスを1セル、下に移動します。もし、フォーカスがグリッドの最後の行にあるなら、何もしないか、テキストボックスにフォーカスを戻します。
  • 上矢印: フォーカス1セルを上げます。もしフォーカスがグリッドの最初の行にあるなら、何もしないか、テキストボックスにフォーカスを戻します。
  • ページ・ダウン (任意): フォーカスを、作成者が決めた行数だけ、下に移動し、通常はスクロールしているので、現在見えている行の下のほうの行が、見えている行の最初になります。もし、フォーカスがグリッドの最後の行に存在するなら、フォーカスは動かしません。
  • ページ・アップ (任意): フォーカスを、作成者が決めた行数だけ、上に移動し、通常はスクロールしているので、現在見えている行の上のほうの行が、見えている行の最後になります。フォーカスがグリッドの最初の行にあるばあい、フォーカスは動かしません。
  • ホーム (任意): いづれか
    • フォーカスのある行で、最初のセルにフォーカスを移動します。あるいは、もし、グリッドが1行あたり3セルより少ないか、1行あたりに複数の選択肢があるなら、グリッドの最初のセルに移動しても構いません。
    • テキストボックスにフォーカスを戻し、カーソルを最初の文字に配置します。
  • エンド (任意): いづれか
    • フォーカスのある行で、最後のセルにフォーカスを移動します。あるいは、もし、グリッドが1行あたり3セルより少ないか、1行あたりに複数の選択肢があるなら、グリッドの最後のセルに移動しても構いません。
    • フォーカスをテキストボックスに戻し、カーソルを最後の文字に配置します。
  • コントロール + ホーム (任意): 最初の行にフォーカスを移動します。
  • コントロール + エンド (任意): 最後の行にフォーカスを移動します。
注意
  1. DOMフォーカスは、コンボボックスのテキストボックスで保持され、支援技術のフォーカスは、5.6.2 Managing Focus in Composites Using aria-activedescendant(aria-activedescendantを使用しているコンポーネントでのフォーカス・マネージメント)に記述されているように、aria--activedescendantを使っているグリッドの中で動きます。
  2. グリッドは、テキストボックスの値として、一度に、一つの値の選択だけを許します。
  3. グリッド・ポップアップでは、選択肢のそれぞれが、単一のセルか行全体のどちらかで表示されていて構いません。デザインのこの局面は、フォーカスと選択の動作に影響します。:
    1. もし、すべてのセルが、異なった選択肢を含むなら:
      • 選択はフォーカスに従うので、フォーカスを含むセルが選択されます。
      • 通常、水平の矢印キーのナビゲーションは、1つの行から別の行へ回り込みます。
      • 通常、垂直の矢印キーのナビゲーションは、1つの列から別の列へ回り込みます。
    2. もし、すべての行内のセルが、同じ選択肢について伝えているなら:
      • フォーカスのある行が選択されるか、同じ行のいづれかのセルにフォーカスがあるときに、選択肢のあるセルが選択されるかのどちらかをおこなう。
      • 水平な(矢印)キーのナビゲーションは、1つの行から別の行へ回り込んでもかまいません。
      • 垂直な矢印キーのナビゲーションは、1つの列から別の列には回り込みません。
ツリー・ポップアップ・キーボード・インタラクション

ツリー・ポップアップのいくつかの実装では、すべて、もしくは、一部の親ノードは、暗示的なカテゴリー・ラベルとして機能するかもしれないので、選択可能な値とはならないかもしれません。 デザインのこの側面が、フォーカスの動きに反応してどのように選択を動かすことに影響するかに関しては、以下の「注意」を参照してください。

垂直に方向づけられたツリー・ポップアップにフォーカスがあるとき:

  • エンター: ポップアップを閉じて、テキストボックス内に選択された値を配置し、入力カーソルを値の最後に配置します。これにより、この選択された値を受け入れます。
  • エスケープ: ポップアップを閉じて、フォーカスをテキストボックスへ戻します。任意ですが、テキストボックスの内容をクリアします。
  • すべての文字: ポップアップを閉じずにフォーカスをテキストボックスに戻し、文字を入力します。
  • 右矢印:
    • フォーカスが閉じたノードにあるときは、ノードを開きます。フォーカスと選択は移動しません。
    • フォーカスが開いたノードにあるときは、フォーカスを最初の子ノードに移動し、もしそれが選択可能なら、選択します。
    • フォーカスがエンド・ノードにあるときは、何もしません。
  • 左矢印:
    • フォーカスが開いたノードにあるときは、ノードを閉じます。
    • フォーカスが子ノードにあって、その子ノードが、エンド・ノードか閉じたノードのどちらかでもある場合、その親ノードがフォーカス可能なら、親ノードにフォーカスを移動します。
    • フォーカスがルート・ノードにあって、そのノードが、エンド・ノードか閉じたノードのどちらかでもある場合、何もしません。
  • 下矢印: ノードを閉じたり、開いたりせず、次のノードがフォーカス可能であれば、そのノードにフォーカスを移動します。選択可能であれば、選択状態にします。
  • 上矢印: ノードを閉じたり、開いたりせず、次のノードがフォーカス可能であれば、そのノードにフォーカスを移動します。選択可能であれば、選択状態にします。
  • ホーム: ノードを開いたり、閉じたりせず、ツリーの最初のノードにフォーカスを移動し、選択可能であれば、選択状態にします。
  • エンド: ノードを開いたりせず、最後のノードにフォーカスを移動し、選択可能であれば、選択状態にします。
注意
  1. DOMフォーカスは、コンボボックスのテキストボックスで保持され、支援技術のフォーカスは、5.6.2 Managing Focus in Composites Using aria-activedescendant(aria-activedescendantを使用しているコンポーネントでのフォーカス・マネージメント)に記述されているように、aria--activedescendantを使っているツリーの中で動きます。
  2. ツリーは、テキストボックスの値として、一度に、一つの値の選択だけを許します。
  3. ツリー・ポップアップでは、すべて、もしくは、一部のノードは、選択可能な値では無いかもしれません。それらは、選択肢のカテゴリー・ラベルとして機能しているかもしれません。もし、選択可能な値ではないノードにフォーカスが動くときは、以下の何れかとします:
    • 選択可能なノードにフォーカスが移動するまで、前に選択されていたノードを選択されたままにします。
    • 選択された値はありません。
    • どちらの場合でも、ユーザが、値が選択されているかどうかを簡単に見ることができるように、フォーカスは選択状態と視覚的に区別できるようにします。
  4. もし、ツリーのノードが、水平にアレンジされるなら:
    1. 下矢印は、上で書いた右矢印のように動き、逆もまた、同様です。
    2. 上矢印は、上で書いた左矢印のように動き、逆もまた、同様です。
ダイアログ・ポップアップ・キーボード・インタラクション

ダイアログ・ポップアップにフォーカスがあるとき:

  • ポップアップを閉じて、フォーカスをテキストボックスに戻すのに、2つの方法があります。:
    1. ダイアログ内で、テキストボックスの値を指定するようなアクション、例えば、実行ボタンなどを実施します。
    2. 例えば、エスケープを押すか、ダイアログのキャンセル・ボタンを実行して、ダイアログをキャンセルします。キャンセルは、テキストボックスの値を変更すること無しに、テキストボックスへフォーカスを戻すか、テキストボックスにフォーカスを戻して、テキストボックスをクリアするか、いづれかを行います。
  • ダイアログは、モーダル・ダイアログ・パターンで定義されたキーボード・インタラクションを実装します。
注意

他のコンボボックス・ポップアップと異なり、ダイアログは、aria-activedescendantをサポートしないので、DOMフォーカスは、テキストボックスからダイアログに移動します。

WAI-ARIAのRole、States、Property

最初に、ARIA1.1のパターンと、ARIA1.0パターンで異なるrole、state、propertyに関するガイダンスを、以下に記述します。その後のガイダンスは、両方のパターンに適用されます。

  • ARIA1.1パターンを実装するコンボボックスの場合:
    • コンボボックスのコンテナとして機能する要素は、role=comboboxと指定されています。
    • role=comboboxと指定された要素は、role=textboxかrole=searchboxの何れかが指定してあるテキストボックス要素を含むか、所有しています。
    • コンボボックスが視覚的に目に見えるとき、コンボボックスの要素は、role=listboxtreegriddialogとしていされた要素を含むか、所有しています。
    • コンボボックス・ポップアップがlistbox以外のroleを持っているなら、role=comboboxの要素は、aria-haspopupを、ポップアップ・タイプに対応した値に設定しています。つまり、aria-haspopupは、gridtreedialogに設定されています。role=comboboxとした要素は、潜在的なlistboxaria-haspopupの値を持っていることに、注意してください。
    • コンボボックス・ポップアップが目に見えているとき、テキストボックスの要素は、aria-controlsを、コンボボックス・ポップアップ要素を参照する値にセットしています。
  • ARIA1.0パターンを実装するコンボボックスの場合:
    • テキストボックスとして機能する要素は、role=comboboxを持っています。
    • コンボボックス・ポップアップが目に見えているとき、role=comboboxの要素は、aria-ownsをrole=listboxの要素を参照する値にセットしています。
    • role=comboboxの要素は、listboxaria-haspopupの値を持っています。role=comboboxとした要素は、潜在的なlistboxaria-haspopupの値を持っていることに、注意してください。
  • テキストボックス要素は、aria-multiline=falseの値を持っています。 デフォルトのaria-multilineの値は、falseであることに注意してください。
  • コンボボックス・ポップアップが目に見えないとき、role=comboboxの要素はaria-expandedfalseにセットします。ポップアップ要素が目に見える時は、aria-expanded=trueになります。role=comboboxとなっている要素は、aria-expanded=falseのデフォルト値を持っていることに注意してください。
  • コンボボックスがフォーカスを受けるとき、DOMフォーカスは、テキストボックス要素に配置されます。
  • リストボックス、グリッド、ツリーポップアップの子孫にフォーカスがあるとき、DOMフォーカスはテキストボックスに残っていて、テキストボックスは、aria-activedescendantを、ポップアップ内のフォーカスのあたっている要素を参照する値に設定します。
  • リストボックス、グリッドや、ツリー・ポップアップを伴ったコンボボックスでは、選択肢の値が現在選択されている値として視覚的に示されているとき、その値を含むoptiongridcellrowtreeitemは、aria-selectedtrueにセットします。
  • もし、コンボボックスが視覚的なラベルを持っているなら、role=comboboxとなっている要素は、aria-labelledbyを、ラベリングの要素を参照する値にセットします。さもなければ、コンボボックス要素は、aria-labelで、ラベルを提供します。
  • テキストボックス要素は、aria-autocompleteを、そのオートコンプリート動作に対応する値にセットします。
    • none: ポップアップが表示されたとき、それが含む選択肢の値は、テキストボックスに入力された文字に関係無く、同じです。
    • list: ポップアップが表示されたとき、テキストボックスに入力された文字を、完成したか、もしくは、論理的に対応した値を表示します。
    • both: ポップアップが表示されたとき、テキストボックスに入力された文字を、完成したか、もしくは、論理的に対応した値を表示します。加えて、選択された提案の一部で、ユーザーに入力されていない部分が、(完成ストリング Completion Stringとして知られていますが、)テキストボックスの入力カーソルの後にインラインで現れます。インラインの完成ストリング(Completion String)は、視覚的に強調され、選択状態となっています。
注意
  1. 以下にリスティングしたポップアップに使われているパターンに関する、role、state、propertyのドキュメントを参照するとき、コンボックスは単一選択のウィジェットであることを、覚えていてください。このウィジェットでは、選択状態は、ポップアップ内で、常にフォーカスに従っています。
  2. ポップアップ要素に関するrole、state、propertyは、個別のデザイン・パターンで定義されています。

3.9 ダイアログ(モーダル)

ダイアログは、メイン・ウィンドウか他のダイアログ・ウィンドウのどちらかに重ねて表示されたウィンドウです。モーダル・ダイアログの下のウィンドウは、不活性です。すなわち、ユーザはアクティブなダイアログ・ウィンドウの外では、その内容を操作することはできません。アクティブなダイアログ以外の不活性な部分は、視覚的に不明瞭にしたり、薄暗くしたりするので、内容を理解するのは困難です。そして、いくつかの実装では、不活性な内容を操作しようとすると、ダイアログが閉じるようになっています。

非モーダル・ダイアログのように、モーダル・ダイアログはそれらのタブ・シーケンスを含んでいます。すなわち、タブシフト・タブは、ダイアログの外では、フォーカスを動かしません。しかしながら、ほとんどの非モーダル・ダイアログと異なって、モーダル・ダイアログは、ダイアログ・ウィンドウを閉じることなく、ダイアログの外でキーボード・フォーカスを動かすような手段は提供していません。

role = alertdialogは、特別な場合のダイアログroleで、特に、ユーザの注意を簡潔で重要なメッセージに向けさせるためのものです。その使い方は、「3.3 アラートとメッセージ・ダイアログ」で記述しています。

モーダル・ダイアログの例

キーボード・インタラクション

以下の記述では、タブ可能要素という用語は、tabindex値が0以上のすべての要素を示します。ただし、1以上の値は、使用しないことが強く勧められていることに、注意してください。

  • ダイアログが開くとき、フォーカスはダイアログの中の要素に移動します。初期状態のフォーカスの位置に関しては、以下の注意を見てください。
  • タブ:
    • ダイアログ内の次のタブ可能要素にフォーカスを移動します。
    • もし、フォーカスが、ダイアログの中の最後のタブ可能要素にあるなら、ダイアログの中の最初のタブ可能要素にフォーカスを移動します。
  • シフト + タブ:
    • ダイアログ内の前のタブ可能要素にフォーカスを移動します。
    • もし、フォーカスが、ダイアログの中の最初のタブ可能要素にあるなら、ダイアログの中の最後のタブ可能要素にフォーカスを移動します。
  • エスケープ: ダイアログを閉じます。
注意
  1. ダイアログが開くとき、フォーカスの位置は、コンテンツの内容とサイズに依存します。
    • どんな場合でも、フォーカスはダイアログに含まれた要素に移動します。
    • 他の方法が好ましい状況でなければ、最初、フォーカスは一番目のフォーカス可能要素に配置します。
    • もし、最初のインタラクティブな要素にフォーカスが存在することで、スクロールして内容が表示からはみ出ることになってしまうほど、コンテンツが大きいなら、ダイアログの一番上の静的な要素(例えば、ダイアログのタイトルや最初の段落)に、tabindex=-1を追加することをお勧めします。そして、最初はその要素にフォーカスしてください。
    • もし、ダイアログが、簡単には逆戻りできないプロセスの最後のステップ(例えば、データの削除や、銀行の処理を完了するというような)を含んでいるなら、特に、やり直し操作が難しいか、不可能な場合は、被害が最少となるようなアクションにフォーカスをセットするのが良いでしょう。「3.3 Alert and Message Dialogs」は、しばしば、そのような事情で、使われます。
    • もし、ダイアログが、追加情報を提供しているか、処理を続けているかのどちらかのように、インタラクションを制限されているなら、OKボタンや続くボタンのように最も頻繁に使用されているような要素へフォーカスをセットするのが良いでしょう。
  2. ダイアログが閉じられるとき、そのダイアログが呼び出された要素にフォーカスを戻します。ただし、次の何れかでもない場合です。
    • 呼び出した要素がもはや存在しない場合。そのため、フォーカスは、論理的なワーク・フローを提供する他の要素に配置されています。
    • ときおり、異なる要素へのフォーカスをより論理的な選択となるようにすることができるような、以下のコンディションを、ワーク・フロー・デザインは含みます。
      1. ユーザが再度、ダイアログを直ぐに呼び出すという必要が、かなりありそうも無い場合。
      2. ダイアログで完了したタスクが、ワークフローのサブシーケンスに直接関係している場合。
      例えば、グリッドには、行を加えるためのボタンを含む、関連したツールバーがあります。「行追加」ボタンは、行の数を入力するダイアログを開きます。ダイアログが閉じた後に、フォーカスは最初の新しい行の最初のセルに配置されます。
  3. すべてのダイアログのタブのシーケンスに、role=buttonと指定された目に見える要素で、ダイアログを閉じるもの(例えば、閉じるアイコンやキャンセルボタンのような)を含むことを、強くお勧めします。

WAI-ARIAのRole、States、Property

  • ダイアログのコンテナーとして提供される要素はrole=dialogを持っています。
  • ダイアログを操作するのに必要とされるすべての要素は、role=dialogを持つ要素の子孫です。
  • ダイアログのコンテナー要素はaria-modaltrueにします。
  • ダイアログは、以下の何れかを持ちます:
    • 目に見えるダイアログのタイトルを参照しているaria-labelledbyプロパティ値。
    • aria-labelで指定されたラベル。
  • 任意ですが、dialogのroleを持つ要素には、aria-describedbyプロパティをセットします。これは、ダイアログの主な目的やメッセージを記述した内容を含む、ダイアログ内の要素を指し示すために行います。説明の要素を指定することは、スクリーン・リーダーに、ダイアログのタイトルと、ダイアログが開いたときの最初のフォーカス要素に沿って、その説明をアナウンスすることを可能とします。
注意
  • aria-modaltrueにセットしてダイアログをモーダルにマーキングすることは、いくつかの支援技術の利用者がダイアログの外からその内容を見えてしまうことを防ぎます。このため、もし、ダイアログがモーダルにマークされているのに、他のユーザには、モーダルとして動作しないとなると、それらの技術を使うユーザは、厳しい否定的な分岐を体験するでしょう。したがって、以下の両方の場合のみ、ダイアログをモーダルにマークしてください:
    1. アプリケーション・コードが、すべてのユーザを、外部からのコンテンツとのすべてのインタラクションから、隔離している。
    2. 視覚的なスタイリングが、コンテンツを外部から、隠している。
  • ARIA1.1によって紹介されたaria-modeプロパティは、ダイアログの外のコンテンツがアクティブでないことを支援技術に知らせるために、aria-hiddenを置き換えます。しかしながら、aria-hiddenがダイアログの外部のコンテンツを支援技術のユーザにとって非アクティブな状態にするために使用されているような、過去のダイアログの実装では、以下のことが、重要になります。
    1. aria-hiddenは、非アクティブなレイヤーを含むそれぞれの要素に、trueをセットします。
    2. ダイアログの要素は、aria-hidden=trueとなっている、どんな要素の子孫でもありません。

3.10 ディスクロージャ(開/閉)

ディスクロージャは、コンテンツの一部を視覚的にコントロールするbuttonです。コントロールされているコンテンツが隠れているとき、しばしば、典型的なプッシュボタンとして、ボタンを押すことで、追加のコンテンツが表示されそうなヒントとして、右向きの矢印や三角のマークをつけて、スタイリングされています。コンテンツが目に見えているときは、矢印や三角は、一般的に、下向きの矢印や三角です。

キーボード・インタラクション

ディスクロージャ・コントロールがフォーカスを持っているとき:

  • エンター: ディスクロージャ・コントロールをアクティブにして、ディスクロージャのコンテンツの表示/非表示を切り替えます。
  • スペース: ディスクロージャ・コントロールをアクティブにして、ディスクロージャのコンテンツの表示/非表示を切り替えます。

WAI-ARIAのRole、States、Property

  • コンテンツを開/閉する要素は、role=buttonを持っています。
  • コンテンツが目に見えているとき、role=buttonの要素は、aria-expandedtrueに設定します。コンテンツが目に見えていない時は、それをfalseに設定します。
  • 任意ですが、role=buttonの要素は、開/閉されるすべてのコンテンツを含む要素を参照するように、aria-controlsを設定します。

3.11 フィード

feedは、ページ内で、ユーザがスクロールするような、新たなセクションを自動的に読み込む領域のことです。フィードのコンテンツの一部は、article要素に表示されます。なので、フィードは、しばしば、無限にスクロールして現れるような、動的なリストとして考えることができます。

フィードを、ユーザがスクロールする(例えば、grid)ようなローディングデータをサポートする他のARIAパターンと、大きく区別する特徴は、フィードが構造であって、ウィジェットでは無いということです。したがって、スクリーン・リーダーのようなリーディング・モードのある支援技術は、フィードの内容とインタラクトするとき、リーディング・モードをデフォルトとします。しかしながら、他のほとんどのWAI-ARIAの構造と異なり、フィードは、ウェブ・ページと支援技術の間で、相互運用性のある契約を確立します。この契約は、支援技術の利用者が記事を読み、記事の前や後ろにジャンプできるようにスクロール・インタラクションを支配し、リーディング・モード中に新しい記事を読み込むための確実なトリガーとなります。

例えば、買い物サイトの製品ページは、一度に5個の製品を表示する関連商品のセクションがあるかもしれません。ユーザがスクロールするとき、より多くの製品が、要求され、DOMに読み込まれます。静的なデザインが、さらなる5つの製品を読み込むために、次へボタンを含んでいる間に、動的な実装は、ユーザがスクロールするときにより多くのデータを自動的に読み込むようになっていて、ユーザの体験をより簡単にし、最初の5つの製品の提示より多くのものを見ることに関連した無駄を減少します。しかし、残念ながら、ウェブ・ページが、スクロール・イベントに基づき、動的にコンテンツを読み込むとき、ユーザビリティと相互運用性は、支援技術のユーザにとって、難しいものにしてしまう可能性があります。

フィード・パターンは、ウェブ・ページと支援技術の間に、以下の相互運用性の合意を確立することで、支援技術のリーディング・モードのインタラクションをより、信頼できるものにすることが出来ます。

  1. フィードの状況によって、ウェブ・ページのコードは、以下に責任を持ちます。
    • DOMフォーカスを含む記事に基づくコンテンツの適切な視覚的スクロール。
    • DOMフォーカスを含む記事に基づくフィード記事の読み込みや削除。
  2. フィードの状況によって、リーディング・モードをそなえた支援技術は、以下に責任を持ちます。
    • 記事の要素か、その子孫の一つが確実にDOMフォーカスを持っているようにすることで、リーディング・カーソルを含む記事を示します。
    • DOMフォーカスを次の記事や前の記事に移動させるために、リーディング・モード・キーを提供します。
    • リーディング・カーソルとDOMフォーカスを、既に参照したフィードの最後や、フィードの最初の前に移動させるために、リーディング・モード・キーを提供します。

このように、フィード・パターンを実装することは、スクリーン・リーダーが確実に読み上げ、リーディング・モードで待機しているときに、フィードの読み込みを開始することを可能にします。

フィードパターンの他の機能は、支援技術のユーザが、簡単に拾い読みできるようにするということです。ウェブ・ページの作者は、アクセシブルな名前と各記事のための説明の両方を、提供するかもしれません。タイトルやメインのコンテンツを提供する記事の中の要素を識別することによって、支援技術は、ユーザが記事から記事へジャンプすることを可能にし、どの記事に注意を向けるべきかを効率よく判断できるようにする機能を提供します。

フィード・パターンの実現例

キーボード・インタラクション

フィード・パターンは、デスクトップのGUIウィジェットに基づいてはいないので、role=feedは、どの十分に確立しているキーボードの慣習にも関連づいていません。以下をサポートするか、似たインタフェースが、お勧めです。

フォーカスがフィードの中にあるとき:

  • ページ・ダウン: 次の記事へフォーカスを移動します。
  • ページ・アップ: 前の記事へフォーカスを移動します。
  • コントロール+エンド: フォーカスを、フィードの後の最初のフォーカス可能な要素に移動します。
  • コントロール+ホーム: フォーカスを、フィードの前の最初のフォーカス可能な要素に移動します。
注意
  1. コンベンション(慣習)の不足のため、簡単に見つけることができるキーボード・インターフェース・ドキュメントを提供することは、特に重要です。
  2. いくつかの場合、フィードは、入れ子にされたフィードを含んで構いません。 例えば、ソーシャル・メディアのフィードの記事は、その記事に関するコメントのフィードを含んでかまいません。 入れ子のフィードをナビゲートするために、ユーザは始めに入れ子のフィードに、フォーカスを移動します。 入れ子のフィードのナビゲーションをサポートするためのオプションは、以下になります。:
    • ユーザーは、タブで、フォーカスを、記事を含むコンテンツから入れ子のフィードに移動します。 もし、記事が多くの数のリンク、ボタン、その他のウィジェットを含んでいるなら、これは、遅いかもしれません。
    • 記事に含まれた要素から、入れ子のフィードの中の最初のアイテムへ、フォーカスを移動するために、キーを提供します。例えば、Alt+ページ・ダウンです。
    • 外側のフィードを読み続けるためには、Control+Endで、外側のフィードの次の記事にフォーカスを移動します。
  3. フィードの記事が、上記で示されたキーを使用するウィジェットを含むという、まれな状況では、 フィード・ナビゲーション・キーは、含まれたウィジェットを操作するでしょう。そして、ユーザは、フィードをナビゲートするためにフィード・ナビゲーション・キーを利用する要素にフォーカスを移動する必要があります。

WAI-ARIAのRole、States、Property

  • フィードの記事のセットを含む要素は、role=feedを持っています。
  • もし、フィードが目に見えるタイトルを持っているなら、feedの要素は、タイトルを含む要素を参照するaria-labelledbyを持っています。 さもなければ、feedの要素は、aria-labelで指定されたラベルを持っています。
  • フィードのコンテンツのそれぞれのユニットは、role=articleと指定された要素に含まれています。 フィードの中のすべてのコンテンツは、article要素に含まれます。
  • それぞれのarticle要素は、識別可能なラベルを提供することができる記事の中の要素を参照するaria-labelledbyを持っています。
  • 任意ですが、それぞれのarticle要素は、メインの内容として提供される記事の中で、一つかそれ以上の要素を参照しているaria-describedbyを持つことを強く推奨します。
  • それぞれのarticle要素は、aria-posinsetを、フィード内での位置を表す値にセットします。
  • それぞれのarticle要素は、aria-setsizeを、読み込み済みの記事の合計か、フィード内の合計のどちらかを示す値にセットします。どちらの値をセットするかについては、どちらの値が、ユーザの助けになると考えられるかに依存します。 もし、フィードの合計が未定ならば、aria-setsizeの値を-1として表現することができます。
  • article要素がfeedコンテナーに追加されるか、そこから削除されるとき、もし、オペレーションが、複数のDOMオペレーションを要求しているなら、アップデート操作の間中、feed要素はaria-busytrueにセットします。オペレーションが完了するか、その変化がいくつかの支援技術ユーザに目に見えるもので無い可能性があるとき、aria-busyfalseにセットすることが、非常に重要であることに注意してください。

3.12 グリッド : インタラクティブな表形式データとレイアウトコンテナ

グリッド・ウィジェットは、ユーザが情報やインタラクティブな要素をナビゲーションすることを可能にするコンテナーで、方向のナビゲーション・キー(矢印、ホームエンドなど)の使用を含んでいます。 フレキシブルなキーボード・ナビゲーションを提供するジェネリックなコンテナ・ウィジェットとして、それは様々なニーズに役立つことができます。 チェックボックスやナビゲーション・リンクのコレクションの集まりと同じくらい単純で、すべての機能を備えたスプレッド・シート・アプリケーションを作るのと同じくらい複雑な目的で使用することが出来ます。 role=gridで、要素の論理的な構造を説明し、表現するとき、「行」や「列」という言葉が、WAI-ARIA属性の名前と支援技術によって使用されている間、要素に対してrole=gridを使うことは、必ずしも視覚的な見た目が表になっているということを意味するわけではありません。

表である内容を提示するときには、このgrid・パターンかテーブル・パターンのどちらかを実装することになりますが、以下の要件を考慮してください。

grid・パターンの用途は大きく2つのカテゴリに分類されます。表形式の情報(データ・グリッド)と他のウィジェットにグルーピングされるもの(レイアウト・グリッド)です。たとえ、データ・グリッドとレイアウト・グリッドの両方が、同じARIAのrole、state、propertyを採用していたとしても、それらの内容や直面する要件の目的での違いが、キーボード・インタラクション・デザインで考慮されることが重要です。これらの要件を扱うために、以下の2つのセクションの説明は、データとレイアウトのグリッドのキーボードインタラクションを別にしています。

  • レイアウト・グリッドの例: それぞれ、ナビゲーション・リンクのコレクション、メッセージの受取人リスト、検索結果のリストを含むレイアウトウィジェットとして使用されている3種類のグリッドの実装例です。
  • データ・グリッドの例: コンテンツ編集やソート、列を非表示にするといった表形式の情報提示に関する機能を含む3種類のグリッドの実装例です。
  • 高度なデータグリッドの例: 行と列のセクションを含む、典型的なスプレッドシートと同等の動作と機能をもつグリッドの例です。

表形式の情報提示のためのデータ・グリッド

gridは、列見出しや行見出しのある表形式の情報を表示するために使用することが出来ます。 もし、表形式の情報が編集可能だったり、インタラクティブであるなら、grid・パターンは特に役に立ちます。 例えば、静的な表でデータを提示したり、タブ・シーケンスにリンクを含めたりするよりも、データの要素がより多くの情報にリンクしているときは、grid・パターンの実装は、ページのより短いタブ・シーケンスと同じくらい、直感的で効率的なキーボード・ナビゲーションのグリッド・コンテンツをユーザに提供します。 また、gridは、セルの編集や、選択、カット、コピー、ペーストなどの機能を、提供するかもしれません。

グリッドでは、セルの内容は編集可能かどうかやインタラクティブかどうかに関わらず、あらゆるセルが、フォーカス可能な要素を含んでいたり、それ自身がフォーカス可能であったりします。 1つの例外があります。: 行や列のヘッダーセルが、ソートやフィルターなどの機能を提供していないなら、フォーカス可能である必要はありません。 すべてのセルがキーボード・フォーカスを受け取ったり、含んだりできることが重要です。その理由は、ユーザがグリッドとインタラクトしているときは、スクリーン・リーダーは、通常、ドキュメント・リーディング・モードよりもむしろ、アプリケーション・リーディング・モードになっているということです。 アプリケーション・モードになっている間、スクリーン・リーダーのユーザは、フォーカス可能な要素だけを聞いており、それには、フォーカス可能な要素のラベルが含まれます。 したがって、スクリーン・リーダのユーザは、グリッドに含まれる要素(それがフォーカス不可能であったり、行や列にラベル付けしていなかったりして、)を、気付かずに、見落としているかもしれません。

データグリッドのためのキーボード・インタラクション

以下のキーは、グリッドのセルの間でフォーカスを動かすことで、グリッド・ナビゲーションを提供します。 グリッドの実装は、グリッドの要素がフォーカスを受け取ったとき、これらのキー・コマンドを利用可能にします。例えば、Tabでフォーカスをグリッドに移動したときです。

  • 右矢印: フォーカスを右に1セル、動かします。フォーカスが、行で一番右のセルにあるなら、フォーカスは動きません。
  • 左矢印: フォーカスを左に1セル、動かします。フォーカスが、行で一番左のセルにあるなら、フォーカスは動きません。
  • 下矢印: フォーカスを下に1セル、動かします。フォーカスが、列で一番下のセルにあるなら、フォーカスは動きません。
  • 上矢印: フォーカスを上に1セル、動かします。フォーカスが、列で一番上のセルにあるなた、フォーカスは動きません。
  • ページ・ダウン: フォーカスを、ページ作成者が決めた行の数だけ、下に移動します。通常は、現在見えている行の中で一番下の行をスクロールし、最初の目に見える行の一つになります。もし、フォーカスがグリッドの最後の行にあるなら、フォーカスは移動しません。
  • ページ・アップ: フォーカスを、ページ作成者が決めた行の数だけ、上に移動します。通常は、現在見えている行の中で一番上の行をスクロールし、最後の目に見える行の一つになります。もし、フォーカスがグリッドの最初の行にあるなら、フォーカスは移動しません。
  • ホーム: フォーカスを含む行の、最初のセルにフォーカスを移動します。
  • エンド: フォーカスを含む行の、最後のセルにフォーカスを移動します。
  • コントロール+ホーム: 最初の行の最初のセルに、フォーカスを移動します。
  • コントロール+エンド: 最後の行の最後のセルに、フォーカスを移動します。
注意
  • 上記のグリッド・ナビゲーション・キーで、フォーカスを動かすとき、フォーカスがセルの中の要素に位置するのか、グリッド・セルに位置するのかは、セルの内容によります。「Whether to Focus on a Cell Or an Element Inside It(セルにフォーカスをあてるのか、その中の要素にあてるのか)」を、見てください。
  • 矢印キーのようなナビゲーション・キーが、セルからセルへ、フォーカスを移動している間は、コンボボックスを操作することやセルの中のキャレットを編集するようなことは出来ません。この機能性が必要であるなら、「Editing and Navigating Inside a Cell(セル内での編集とナビゲーション)」を見てください。
  • ナビゲーション機能で、もっと動的に行や列をDOMに追加することができるなら、control + Endのようなグリッドの最初や最後にフォーカスを移動させるようなキー・イベントは、フォーカスを、バック・エンド・データの最後の利用可能な行よりもむしろ、DOMの最後の行に移動するかもしれません。

もし、グリッドがセルや行や列の選択をサポートするなら、以下のキーが、これらの機能に共通に利用することが出来ます。

  • コントロール+スペース: フォーカスを含む列を選択します。
  • シフト+スペース: フォーカスを含む行を選択します。もし、グリッドが、行を選択するための列を含んでいるなら、このキーは、フォーカスがチェックボックスに無いときは、チェックボックスをチェックするためのショートカットとして提供されます。
  • コントロール+A: すべてのセルを選択します。
  • シフト+右矢印:: 選択範囲を右に1セル、大きくします。
  • シフト+左矢印: 選択範囲を左に1セル、大きくします。
  • シフト+下矢印: 選択範囲を下に1セル、大きくします。
  • シフト+上矢印: 選択範囲を上に1セル、大きくします。
注意

切り取り、コピー、ペーストのキーアサインに関しては、「5.8 Key Assignment Conventions for Common Functions(5.8 共通の機能のためのキー・アサインの慣習)」を見てください。

ウィジェットをグルーピングするためのレイアウト・グリッド

リンクやボタン、チェックボックスのようなインタティブな要素をグルーピングするために、grid・パターンを使うことができます。グリッド全体の中で、一つの要素だけが、タブシーケンスに含まれるので、グリッドによるグルーピングは、ページでタブがストップする数を劇的に減少させることができます。もし、要素のリストを通じてスクロールすることが、それらの要素よりもっと多くのデータセット(ショッピング・サイトで商品が連続的なリストで表示されているような)を読み込むなら、これは、特に貴重です。このようなリストの要素がタブ・シーケンスにあるなら、キーボード・ユーザは効果的に、リストの中に閉じ込められてしまうでしょう。グループ内のどの要素もhoverで現れる要素と関連しているなら、grid・パターンは、ユーザ・インタフェースのそれらのコンテクスチュアルな要素へのキーボード・アクセスの提供にも、役立ちます。

データを提示するのに使用されるgridと異なり、レイアウトに使用されるグリッドは、行や列をラベリングするために必ずしも見出しとなるセルを持っているわけでは無く、単一の行か単一の列だけを含んでいるかもしれません。複数の行と列があったとしても、単一で、論理的に同一な要素のセットを提示するかもしれません。例えば、メッセージの受取人のリストが、グリッドになっていて、それぞれのセルに受取人へのリンクを含んでいるかもしれません。グリッドは、最初に、単一の行を持っていても、その後で、受取人が追加されるとき、複数の列にラップしてかまいません。そのような状況では、グリッド・ナビゲーション・キーもまた、ユーザが、右矢印下矢印のどちらかをおして最初から最後までリストを読めるように、ラップしてかまいません。このタイプのフォーカスのラッピング動作が、レイアウト・グリッドでとても役立つものになりる一方で、もし、データ・グリッドで使用するなら、特に支援技術を利用している人は、方向が分からなくなってしまうでしょう。

なぜなら、矢印キーは、gridの中で、フォーカスを移動させるために使用されるので、もし、それを含むコンポーネントが、操作のために矢印キーを必要としないなら、gridは両方を構築して使うことがより簡単です。もし、セルがリストボックスのような要素を含むなら、グリッド・ナビゲーションの機能を復元するためのコマンドと同様に、リストボックスをフォーカスしアクティブにするための追加のキー・コマンドが必要となります。このニーズをサポートするためのアプローチは、「Editing and Navigating Inside a Cell(セル内での編集とナビゲーション)」のセクションで説明されます。

レイアウト・グリッドのためのキーボード・インタラクション

以下のキーは、グリッドのセルの中でフォーカスを動かすことによって、グリッド・ナビゲーションを提供します。グリッドの実装は、グリッドの要素がフォーカスを受け取った時、これらのキー・コマンドを利用可能にします。例えば、ユーザーが、Tabで、フォーカスをグリッドへ移動したときです。

  • 右矢印: フォーカスをセル1つ、右に移動します。任意ですが、フォーカスが、その行の一番右にある場合は、フォーカスは、次の行の最初のセルに移動してかまいません。もし、グリッドの最後のセルにフォーカスがあるなら、フォーカスは動きません。
  • 左矢印: フォーカスをセル1つ、左に移動します。任意ですが、フォーカスが、その行の一番左にある場合は、フォーカスは、前の行の最後のセルに移動してかまいません。もし、グリッドの最初のセルにフォーカスがあるなら、フォーカスは動きません。
  • 下矢印: フォーカスを、セル1つ、下に移動します。任意ですが、フォーカスが、その列の一番下にあるなら、フォーカスは次の列の一番上のセルに移動してかまいません。もし、フォーカスが、グリッドの最後のセルにあるなら、フォーカスは動きません。
  • 上矢印: フォーカスを、セル1つ、上に移動します。任意ですが、フォーカスが、その列の一番上にあるなら、フォーカスは前の列の一番下のセルに移動してかまいません。もし、フォーカスが、グリッドの最初のセルにあるなら、フォーカスは動きません。
  • ページ・ダウン(任意): 制作者が決めた行数分、フォーカスを下に移動しますが、通常は、今、表示されている行の中で一番下の行を、スクロールで、一番上に表示されるようにします。もし、フォーカスが、グリッドの最後の行にあるなら、フォーカスは動きません。
  • ページ・アップ(任意): 制作者が決めた行数分、フォーカスを上に移動しますが、通常は、今、表示されている行の中で、一番上の行を、スクロールで、一番下に表示されるようにします。もし、フォーカスが、グリッドの最初の行にあるなら、フォーカスは動きません。
  • ホーム: フォーカスを、フォーカスを含む行の最初のセルに移動します。任意ですが、グリッドが、1列しかないか、1行に3セル未満しかない場合は、代わりに、フォーカスは、グリッドの最初のセルに移動してかまいません。
  • エンド: フォーカスを、フォーカスを含む行の最後のセルに移動します。任意ですが、グリッドが、1列しかないか、1行に3セル未満しかない場合は、代わりに、フォーカスは、グリッドの最後のセルに移動してかまいません。
  • コントロール+ホーム(任意): フォーカスを、最初の行の最初のセルに移動します。
  • コントロール+エンド (任意): フォーカスを、最後の行の最後のセルに移動します。
注意
  • 上記のグリッド・ナビゲーション・キーが、フォーカスを動かすとき、フォーカスをセルの中の要素にセットするか、グリッドのセルにセットするかは、セルのコンテンツに依ります。「Whether to Focus on a Cell or an Element Inside It(セルにフォーカスをあてるのか、その中の要素にあてるのか)」を参照してください。
  • 矢印キーのようなナビゲーション・キーが、フォーカスを、セルからセルへ移動している間、コンボボックスを操作したり、編集用のキャレットをセル内で移動させるようなことは、利用不可能にします。もし、この機能が必要なら、「Editing and Navigating Inside a Cell(セル内での編集とナビゲーション)」を参照してください。
  • もし、ナビゲーション機能が、DOMへ動的に行や列を追加できるなら、control + Endのようなグリッドの最初や最後にフォーカスを移動させるキー・イベントは、フォーカスを、バックエンド・データの、利用可能な最後の行ではなく、むしろ、DOMの最後の行に移動してかまいません。

レイアウト・グリッドが、セルの選択を要求する機能を提供することは、珍しいでしょう。もし、そうしたなら、一般的に、以下のキーが、これらの機能のために、使用されます。

  • コントロール + スペース: フォーカスを含む列を、選択します。
  • シフト + スペース: フォーカスを含む行を、選択します。もし、グリッドが、行選択のためのチェックボックスの列を含んでいるなら、このキーは、フォーカスがチェックボックスに無い時に、チェックボックスを選択するためのショートカットを、提供します。
  • コントロール + A: すべてのセルを選択します。
  • シフト + 右矢印: 選択範囲を、右に1セル拡張します。
  • シフト + 左矢印: 選択範囲を、左に1セル拡張します。
  • シフト + 下矢印: 選択範囲を、下に1セル拡張します。
  • シフト + 上矢印: 選択範囲を、上に1セル拡張します。
注意

切り取り、コピー、ペーストのキーアサインに関しては、「5.8Key Assignment Conventions for Common Functions(5.8 共通の機能のためのキー・アサインの慣習)」を見てください。

キーボード・インタラクション -- フォーカスの設定と、セル内のナビゲート

このセクションは、データ・グリッド・パターンとレイアウト・グリッド・パターンの両方で共有されるキーボード・インタラクション・デザインの2つの重要な側面を、記述します。

  1. グリッド・ナビゲーションのキー・イベントに反応して、セルとセルの中の要素と、どちらがフォーカスを受け取るようにするのか。
  2. グリッド・ナビゲーションのキーが、セルの中の要素をインタラクションするために使えるようにするには。
セルにフォーカスをあてるのか、その中の要素にあてるのか

福祉支援技術のユーザにとって、グリッドをナビゲートするときの体験品質は、セルが何を含んでいるかと、キーボード・フォーカスがどこにセットされるかの両方に、深く関連しています。例えば、もし、セルにボタンが含まれていて、グリッド・ナビゲーション・キーが、ボタンの代わりにセルにフォーカスを置いたなら、スクリーン・リーダーは、ボタンのラベルを読み上げますが、ボタンが存在することは、ユーザーに伝えません。

最適なセルのデザインとフォーカス動作の組み合わせが、2つあります:

  1. セルは、矢印キーを必要としない1つのウィジェットを含み、グリッド・ナビゲーション・キーは、フォーカスをそのウィジェットにセットします。そのようなウィジェットの例として、リンク、ボタン、メニューボタン、トグル・ボタン、ラジオ・ボタン(ラジオ・グループではない。)、スウィッチ、チェックボックス。
  2. セルは、テキストか、一つのグラフィックを含み、グリッド・ナビゲーション・キーは、フォーカスをそのセルにセットします。

ウィジェット、テキスト、グラフィックの、どんな組み合わせが、一つのセルに入っていたにせよ、これらの2つのセル・デザインとフォーカス動作パターンのうち、どちらかをフォローしていなければ、そのグリッドは、製作者やユーザ、あるいはその両方に複雑さをあたえてしまいます。以下の例のセクションに含まれる実装例は、他のセル・デザインを可能な限りアクセシブルにするために、いくつかの戦略を示しますが、もっとも広くアクセシブルな体験は、上記の2パターンを摘要することによって、実現されうるでしょう。

セル内での編集とナビゲーション

矢印キーのようなナビゲーション・キーが、セルからセルへフォーカスを動かしているとき、コンボボックスを操作したり、セルの中で編集用のキャレットを動かすようなアクションを実施することは不可能です。もし、セルが以下のものを含んでいるなら、ユーザは、グリッド・ナビゲーションとして、セルの中の要素を操作するために使われるキーを必要とするでしょう。

  1. 編集可能なコンテンツ
  2. 複数のウィジェット
  3. ラジオ・グループやスライダーのような、インタラクション・モデルの中で矢印キーを利用するウィジェット

以下は、グリッド・ナビゲーションの機能をディセイブルにしたり、アクティブにしたりするための共通のキーボードの慣習です。

  • エンター: グリッド・ナビゲーションをディセイブルにし、:
    • もし、セルが編集可能なコンテンツを含むなら、テキストボックスのような入力フィールドにフォーカスを配置します。もし、入力が1行のテキスト・フィールドなら、その後にEnterを押して、グリッド・ナビゲーションを元に戻すか、そばのセルの入力フィールドにフォーカスを移動します。
    • もし、セルが一つかそれ以上のウィジェットを含むなら、フォーカスを最初のウィジェットに配置します。
  • F2:
    • もし、セルが編集可能なコンテンツを含むなら、テキストボックスのような入力フィールドにフォーカスを配置します。その後に、F2を押して、グリッド・ナビゲーションの機能を元に戻します。
    • もし、セルが、1つかそれ以上のウィジェットを含むなら、最初のウィジェットにフォーカスを配置します。その後に、F2を押して、グリッド・ナビゲーションの機能を元に戻します。
  • 英数字: もし、セルが編集可能なコンテンツを含むなら、テキストボックスのような入力フィールドにフォーカスを配置します。

グリッド・ナビゲーションがディセイブルになっているとき、慣習的なナビゲーション動作の変化は、以下があります:

  • エスケープ: グリッド・ナビゲーションを、戻します。もし、コンテンツが編集されていたなら、その編集も元に戻してもかまいません。
  • 右矢印、または、下矢印: セルが複数のウィジェットを含むなら、セル内の次のウィジェットへフォーカスを移動し、任意ですが、もし、最後のウィジェットにフォーカスがあるなら、最初のウィジェットに移動します。そうでなければ、フォーカスのあるウィジェットに、キー・イベントをパスしてください。
  • 左矢印、または、上矢印: もし、セルが複数のウィジェットを含むなら、セル内の前のウィジェットへフォーカスを移動し、任意ですが、もし、最初のウィジェットにフォーカスがあるなら、最後のウィジェットに移動します。そうでなければ、フォーカスのあるウィジェットに、キー・イベントをパスしてください。
  • タブ: グリッドの次のウィジェットにフォーカスを移動します。 任意ですが、フォーカスは一つのセルの中で循環するか、グリッドの中で循環してかまいません。
  • シフト + タブ: グリッドの一つ前のウィジェットにフォーカスを移動します。任意ですが、フォーカスは一つのセルの中で循環するか、グリッドの中で循環してかまいません。

WAI-ARIAのRole、States、Property

  • グリッド・コンテナは、role=gridを持っています。
  • それぞれの行のコンテナは、role=rowをもっていて、grid要素かrole=rowgroupと指定された要素のDOMの子孫であるか、それらによって所有されています。
  • それぞれのセルは、row要素の子孫かそれに所有されていて、以下のroleの一つを持っています。:
    • columnheader:セルが、列のタイトルか、見出し情報を持っている場合。
    • rowheader:セルが、行のタイトルか、見出し情報を持っている場合。
    • gridcell:セルが、列や行の見出し情報を持っていない場合。
  • ユーザ・インタフェース内でグリッドのラベルとして提供される要素があるなら、aria-labelledbyが、ラベルの要素を参照する値を伴って、グリッド要素にセットされます。さもなければ、ラベルは、aria-labelを使って、グリッド要素に指定されます。
  • もし、グリッドが、キャプションや説明を持っているなら、その説明を含む要素を参照する値で、aria-describedbyをグリッド要素に指定します。
  • もし、グリッドがソート機能を提供するなら、グリッドとテーブルのプロパティのセクションで説明されるように、ヘッダーのセルのソートされた行や列の要素でaria-sortを適切な値に指定します。
  • もし、グリッドが選択をサポートするなら、セルや行が選択されているとき、選択された要素はaria-selected=trueにします。 もし、グリッドが列選択をサポートしたり、列が選択されているなら、列の全てのセルは、aria-selected=trueにします。
  • もし、グリッドがコンテンツの編集機能を提供し、ある状況で編集機能をディセイブルにするかもしれないセルを含んでいるなら、編集がディセイブルとなっているセルでaria-readonly=trueにするかもしれません。 もし、すべてのセルに関して編集機能がディセイブルになっているなら、aria-readonly=trueを、グリッド要素に指定します。 編集機能を提供しないグリッドは、そのどの要素にも、aria-readonly属性は含みません。
  • もし、いくつかの行や列がDOMの中で隠されていたり、存在しない場合があったとき、例えば、スクロールするときにデータが動的に読み込まれたり、グリッドが行や列を隠すための機能を提供するようなとき、以下のプロパティが、グリッドやテーブルのプロパティのセクションで記述されるように適用されます。
  • もし、グリッドが、複数の行か列をspanしたセルを、含んでいて、role=gridが、HTMLのtable要素に適用されていないなら、グリッドとテーブルのプロパティで説明されるように、aria-rowspanaria-colspanが適用されなければならない。
注意
  • もし、role=gridと指定のある要素が、HTMLの表の要素であれば、HTML要素はARIAのセマンティックを暗示しているので、行や列にARIAのroleを使用することは、必要ありません。 例えば、HTMLの<TR>は、role=rowを暗示しています。 複数の行か列をspanしたセルを含むHTMLのtableから構築されたgridは、HTMLのrowspancolspanを使用しなければならず、aria-rowspanaria-colspanを使ってはいけません。
  • もし、aria-ownsを通じて、行やセルがグリッドに含まれているなら、DOMの子孫も、aria-owns属性に含まれること無しに、grid要素のDOMの子孫の後で、支援技術に提示されることになります。

3.14 リストボックス

リストボックスのウィジェットは、選択肢のリストを提示し、ユーザがそこから、1つ、もしくは、複数選択できるようにします。一つの選択肢を選ぶことが許されているものが、単一選択リストボックスで、複数の選択肢を選択できるものが、複数選択リストボックスです。

スクリーン・リーダーがリストボックスを提示するとき、そのリストのそれぞれの選択肢の名前と状態と位置を表すでしょう。選択肢の名前は、ブラウザによって計算された文字列となり、通常は、option要素の内容から得られます。単純な文字列として、名前はセマンティックな情報を何も含んでいません。その結果、もし、選択肢がセマンティックな要素(例えば、見出しのような)を含んでいる場合は、スクリーン・リーダーのユーザーは、そのセマンティックにアクセスする手段を持たないでしょう。さらに、role=listboxによって支援技術に伝えられるインタラクションのモデルは、選択肢の中の要素とのインタションは、サポートしていません。リストボックスのウィジェットのこれらの特性のため、リンクやボタン、チェックボックスのような、インタラクティブな要素のリストを提示するためにアクセシブルな方法を提供していません。インタラクティブなリストを提示するには、gridパターンを参照してください。

あまりに長い選択肢の名前を避けることは、スクリーン・リーダーのユーザーの理解と知覚を容易にします。選択肢が読まれるとき、選択肢の名前全体が、単一のスピーチ単位として、読まれます。一回のキーの押下の結果として、あまりに多くの情報が読み上げられてしまうと、理解することが、非常に困難になります。長い名前は、ユーザーが、通常、選択肢全体を再度、読む必要が生じるので、中断している読み上げの影響が増強され、知覚を抑制します。そして、もし、ユーザーが読まれている内容を理解できないなら、リストボックスのウィジェットの内容に関しては、文字、単語、あるいは、フレーズでその名前を読むことが、多くのスクリーン・リーダーのユーザーにとって、難しい操作になるかもしれません。

それぞれの選択肢の名前が同じ単語やフレーズで始まるような選択肢のセットも、キーボードとスクリーン・リーダーのユーザーのユーザビリティをかなり低下させる可能性があります。 特定の選択肢を見つけるためにリストを通じてスクロールすることは、各オプションに関してユニークなことを聞く前に、同じ単語やフレーズを繰り返し聞かねばならず、スクリーン・リーダーのユーザーにとって、過度に時間がかかるようになります。 例えば、もし、都市を選ぶためのリストボックスが、それぞれの都市の名前に、国の名前が先行してつくようになっていて、それぞれの国に多くの都市が存在する場合、スクリーンリーダーのユーザーは、国名を聞かなければならないでしょう。 そのようなシナリオでは、2つのリストボックスを用意して、1つは国のため、1つは都市のためとするほうが良いでしょう。

キーボード・インタラクション

垂直に作られたリストボックスの場合:

  • 単一選択リストボックスが、フォーカスを受け取るとき:
    • もし、リストボックスがフォーカスを受け取る前に、選択肢が何も選択されていなければ、最初の選択肢がフォーカスを受け取ります。任意ですが、最初の選択肢は、自動的に選択されるかもしれません。
    • もし、リストボックスがフォーカスを受け取る前に、選択肢が選択されているなら、フォーカスは選択された選択肢にセットされます。
  • 複数選択のリストボックスがフォーカスを受け取るとき:
    • もし、リストボックスがフォーカスを受け取る前に、選択肢が何も選択されていなければ、最初の選択肢にフォーカスをセットし、選択状態での自動的な変更は何もありません。
    • もし、リストボックスがフォーカスを受け取る前に、1つかそれ以上の選択肢を選択しているなら、選択されているリストの最初の選択肢に、フォーカスをセットします。
  • 下向きの矢印: 次の選択肢にフォーカスを移動します。任意ですが、単一選択のリストボックスの場合、選択状態もフォーカスと一緒に移動してもかまいません。
  • 上向きの矢印: 前の選択肢にフォーカスを移動します。任意ですが、単一選択のリストボックスの場合、選択上程もフォーカスと一緒に移動してかまいません。
  • ホーム (任意): 最初の選択肢に、フォーカスを移動します。任意ですが、単一選択のリストボックスの場合、選択状態は、フォーカスと一緒に移動してかまいません。このキーのサポートは、5つ以上の選択肢があるリストで、強く推奨します。
  • エンド (任意): 最後の選択肢に、フォーカスを移動します。任意ですが、単一選択のリストボックスの場合、選択状態はフォーカスを一緒に移動してかまいません。このキーのサポートは、5つ以上の選択肢があるリストで、強く推奨します。
  • タイプアヘッドは、全てのリストボックス、特に7つ以上の選択肢のあるリストボックスに関して推奨されます:
    • 文字の入力: 入力されたキーで始まる名前の選択肢で、次にあるものに、フォーカスを移動します。
    • 素早く複数の文字を入力: 入力された文字列で始まる名前の選択肢で、次にあるものに、フォーカスを移動します。
  • 複数選択: 制作者は、複数選択をサポートする2つのインタラクション・モデルの何れかを実装してかまいません:推奨のモデルは、リストをナビゲートする間、ユーザーに、シフトコントロールのような、変更キーの使用を要求しないものです。あるいは、その代替のモデルとしては、選択状態を失くすことをさけるために、ナビゲートの時に変更キーを押すことを要求することです。
    • おすすめの選択モデル -- 修飾キーを保持することは必要ではありません:
      • スペース: フォーカスのある選択肢の選択状態を変更します。
      • シフト + 下矢印 (任意): 次の選択肢にフォーカスを移動させるか、選択状態に切り替えます。
      • シフト + 上矢印 (任意): 前の選択肢にフォーカスを移動させるか、選択状態に切り替えます。
      • シフト + スペース (任意): 最後に選択した選択肢から、フォーカスのある選択肢まで、連続して選択します。
      • コントロール + シフト + ホーム(任意): フォーカスのある選択肢と、最初の選択肢までのすべての選択肢を選択します。任意ですが、最初の選択肢まで、フォーカスを移動します。
      • コントロール + シフト + エンド (任意): フォーカスのある選択肢と、最後の選択肢までのすべての選択肢を選択します。任意ですが、最後の選択肢まで、フォーカスを移動します。
      • コントロール + A (任意): 任意ですが、もし、すべての選択肢が選択されている状態なら、全ての選択肢を非選択状態にしてもかまいません。
    • 代替の選択モデル -- シフトコントロールの変更キー無しで、フォーカスを移動することは、フォーカスのあるノードを除き、全て選択されたノードを、非選択にします:
      • シフト + 下矢印: 次の選択肢へフォーカスを移動するか、選択状態を切り換えます。
      • シフト + 上矢印: 前の選択肢へフォーカスを移動するか、選択状態を切り換えます。
      • コントロール + 下矢印: 選択状態を変えずに、フォーカスを次の選択肢に移動します。
      • コントロール + 上矢印: 選択状態を変えずに、フォーカスを前の選択肢に移動します。
      • コントロール + スペース フォーカスのある選択肢の選択状態を変更します。
      • シフト + スペース(任意): 最後に選択した選択肢から、フォーカスのある選択肢まで、連続して選択します。
      • コントロール + シフト + ホーム(任意): フォーカスのある選択肢から、最初の選択肢までの全ての選択肢を選択します。任意ですが、フォーカスを最初の選択肢に移動します。
      • コントロール + シフト + エンド(任意): フォーカスのある選択肢から、最後の選択肢までの全ての選択肢を選択します。任意ですが、フォーカスを最後の選択肢に移動します。
      • コントロール + A(任意): リストの全ての選択肢を選択します。任意ですが、全ての選択肢が選択されているなら、全ての選択肢を非選択にしてもかまいません。
注意
  1. DOMフォーカス(アクティブな要素)は、機能的に、選択状態とは異なります。 詳細に関しては、フォーカスと選択状態の違いに関するこの記述(「5.3 Focus VS Selection and the Perception of Dual Focus」)を見てください。
  2. role=listboxは、aria-activedescendantプロパティをサポートします。このプロパティは、キーボード・ナビゲーションを実装するときに、いくつかのoptionの要素間でDOMフォーカスを動かすために、代替手段を提供します。詳細に関しては、「5.6.2 Managing Focus in Composites Using aria-activedescendant」を見てください。
  3. 任意ですが、単一選択のリストボックスでは、フォーカスを動かすことで、その前に選択されている選択肢を非選択にして、新たにフォーカスのある選択肢を選択してかまいません。 選択のこのモデルは、「選択状態は、フォーカスに続く」として、知られています。 「選択状態は、フォーカスに続く」とすることは、いくつかの状況で非常に役立つ可能性があり、他の場合では、アクセシビリティを大幅に低下させる可能性があります。 追加ガイダンスに関しては、「5.4 Deciding When to Make Selection Automatically Follow Focus」を見てください。
  4. もし、すべての選択肢を選択状態にしたり、非選択にすることが、重要な機能であるなら、これらのアクションに異なるコントロールを実装すること(例えば、「すべて選択」ボタンや「すべて解除」ボタンなど)が、アクセシビリティを、大幅に改良します。
  5. もし、リストボックスの選択肢が、水平にアレンジされるなら:
    1. 右矢印が上記で説明されているのと同じように、下矢印も動作します。逆もまた、同じです。
    2. 左矢印が上記で説明されているのと同じように、上矢印も動作します。逆もまた、同じです。

WAI-ARIAのRole、States、Property

  • すべてのリストボックスの選択肢を含んでいるか、所有している要素は、role=listboxを持っています。
  • リストボックスの選択肢はそれぞれ、role=optionを持っていて、role=listboxのある要素のDOMの子孫であるか、リストボックスの要素のaria-ownsプロパティによって参照されます。
  • もしリストボックスが、他のウィジェットの一部で無ければ、そのリストボックスは、role=listboxのある要素のaria-labelledbyで参照される視覚的なラベルを持っています。
  • 単一選択のリストボックスでは、選択された選択肢は、aria-selectedtrueになります。
  • もし、リストボックスが複数選択をサポートするなら:
    • role=listboxのある要素が、aria-multiselectabletrueになります。
    • すべての選択された選択肢で、aria-selectedtrueになります。
    • 選択されていない全ての選択肢は、aria-selectedfalseになります。
  • ユーザーがスクロールするときのダイナミックなローディングのために、もし、利用可能な選択肢の完璧なセットが、DOMに存在しないなら、それらのaria-setsizearia-posinset属性は、適切に設定されます。
  • もし、選択肢が水平にアレンジされるなら、role=listboxのある要素は、aria-orientationhorizontalに設定します。listboxaria-orientationのデフォルトの値は、verticalです。

3.17 ラジオ・グループ

ラジオ・グループは、ラジオ・ボタンとして知られているチェック可能なボタンのセットです。1度に1とつまでのボタンをチェックすることができます。ユーザーが、ワークフローのあるポイントを通り過ぎる前に、必ずボタンの一つをチェックするようにするため、いくつかの実装は、チェック無しの状態の全てのボタンのセットを初期化してかまいません。

キーボード・インタラクション

ツールバーに含まれないラジオ・グループについて:

このセクションは、多くのラジオ・グループのために実装されたキーボード・インタラクションを説明します。 ツールバーの中で入れ子になったラジオ・グループの特別なケースに関しては、以下のセクションで記載したキーボード・インタラクションを使用してください。

  • タブシフト + タブ: ラジオ・グループの中、もしくは、外にフォーカスを移動してください。フォーカスをラジオ・グループの中に移動するときは、?:
    • もし、ラジオ・ボタンがチェックされているなら、フォーカスは、チェックされたボタンにセットします。
    • もし、ラジオ・ボタンのいずれもチェックされていないなら、フォーカスは、グループの中の最初のラジオ・ボタンにセットします。
  • スペース:もし、フォーカスのあるラジオ・ボタンがまだ、チェックされていないなら、そのボタンがチェックされます。
  • 右矢印下向きの矢印: グループの中の次のラジオ・ボタンにフォーカスを移動し、そのまえのフォーカスのあったボタンのチェックを外し、新しくフォーカスのあたったボタンをチェックします。 もし、最後のボタンにフォーカスがあるなら、フォーカスは、最初のボタンに移動します。
  • 左矢印上向きの矢印: グループの中の一つ前のラジオ・ボタンにフォーカスを移動し、そのまえのフォーカスのあったボタンのチェックを外し、新しいフォーカスのあたったボタンをチェックします。 もし、最初のボタンにフォーカスがあるなら、フォーカスは、最後のボタンに移動します。
注意

上記で説明している基本的なフォーカスの動作は、ネイティブなHTMLのラジオ・グループに関していくつかのブラウザーが提供する動作とは、若干異なります。 いくつかのブラウザの場合、もし、ラジオ・ボタンが選択されていないなら、シフト + タブでラジオ・グループにフォーカスを移動させると、最初のラジオ・ボタンの代わりに、最後のラジオ・ボタンにフォーカスが配置されるでしょう。

ツールバーに含まれているラジオ・グループについて:

矢印キーは、ツールバーの要素間をナビゲートするために用いられ、タブキーは、ツールバーの中、あるいは外へフォーカスを移動するために使用されるので、ラジオ・グループがツールバーの中で入れ子になっているとき、そのラジオ・グループのキーボード・インタラクションは、ツールバーの外にあるラジオ・グループのそれとは、少し異なります。例えば、ユーザは、ラジオ・ボタンの選択状態を変えることなく、ラジオ・ボタンを含むすべてのツールバーの要素をナビゲートできる必要があります。そのため、ツールバーのラジオ・ボタンを矢印キーでナビゲートするときは、チェックされたボタンは、変更しません。ツールバーの中で入れ子になっているラジオ・グループのキーボードのインタラクションは、以下のようになります。

  • スペース: もし、フォーカスのあるラジオ・ボタンがチェックされていないなら、現在、チェックされているラジオ・ボタンのチェックを外し、フォーカスのあるラジオ・ボタンをチェックします。さもなければ、何もしません。
  • エンター (任意): もし、フォーカスのあるラジオ・ボタンがチェックされていないなら、現在、チェックされているラジオ・ボタンのチェックを外し、フォーカスのあるラジオ・ボタンをチェックします。さもなければ、何もしません。
  • 右矢印:
    • フォーカスがラジオ・ボタンにあって、ラジオ・ボタンがラジオ・グループの中で最後のボタンでは無い場合、フォーカスを次のラジオ・ボタンに移動します。
    • フォーカスがラジオ・グループの最後のラジオ・ボタンにあって、そのラジオボタンが、ツールバーの最後の要素では無い場合、フォーカスをツールバーの中の次の要素に移動します。
    • フォーカスがラジオ・グループの最後のラジオ・ボタンにあって、そのラジオボタンが、ツールバーの最後の要素でもある場合、フォーカスをツールバーの最初の要素に移動します。
  • 左矢印:
    • フォーカスがラジオ・ボタンにあって、そのラジオ・ボタンがラジオ・グループの最初のラジオ・ボタンでは無い場合、フォーカスは、前のラジオ・ボタンに移動します。
    • フォーカスがラジオ・グループの最初のラジオ・ボタンにあって、そのラジオ・ボタンがツールバーの最初の要素では無い場合、フォーカスをツールバーの中の前の要素に移動します。
    • フォーカスがラジオ・グループの最初のラジオ・ボタンにあって、そのラジオ・ボタンが、ツールバーの最初の要素でもある場合、フォーカスを、ツールバーの最後の要素に移動します。
  • 下矢印 (任意): フォーカスを、ラジオ・グループの中の次のラジオ・ボタンに移動します。もし、フォーカスがラジオ・グループの最後のラジオ・ボタンにあるなら、フォーカスをグループの最初のラジオ・ボタンに移動します。
  • 上矢印 (任意): フォーカスを、ラジオ・グループの中の前のラジオ・ボタンに移動します。もし、フォーカスがラジオ・グループの最初のラジオ・ボタンにあるなら、フォーカスをグループの最後のラジオ・ボタンに移動します。
注意

ツールバーのラジオ・ボタンは、よりトグル・ボタンに見える方法で、柔軟にスタイリングされます。例に関しては、「シンプルなエディターのツールバーの例(Simple Editor Toolbar Example)」を参照してください。

WAI-ARIAのRole、States、Property

  • ラジオ・ボタンは、role=radiogroupのある要素に含まれるか、所有されています。
  • それぞれのラジオ・ボタンの要素は、role=radioを持っています。
  • もし、ラジオ・ボタンがチェックされているなら、radio要素は、aria-checkedtrueにセットします。もし、チェックされていないなら、aria-checkedfalseにセットします。
  • それぞれのradio要素は、その内容でラベリングされるか、aria-labelledbyで参照される視覚的に見えるラベルを持っているか、aria-labelで指定されるラベルを持っているかの何れかになります。
  • radiogroup要素は、aria-labelledbyで参照される視覚的に見えるラベルを持っているか、aria-labelで指定されたラベルを持っています。
  • もし、ラジオ・グループかラジオ・ボタンの何れかについて、追加の情報を提供している要素が存在するなら、それらの要素は、radiogroup要素かradio要素と、aria-describedbyプロパティによって、関連づけられます。

3.18 スライダー

スライダーは、与えられた範囲の中から、ユーザーが値を選択するという入力です。スライダーには、通常、スライダーのつまみが有ります。これは、スライダーの値を変更するためにバーやトラックに沿って動かすことが出来ます。

キーボード・インタラクション

  • 右矢印: 1ステップ、スライダーの値を増加します。
  • 上矢印: 1ステップ、スライダーの値を増加します。
  • 左矢印: 1ステップ、スライダーの値を減少させます。
  • 下矢印: 1ステップ、スライダーの値を減少させます。
  • ホーム: 範囲内で許されている最初の値にスライダーをセットします。
  • エンド: 範囲内で許されている最後の値にスライダーをセットします。
  • ページ・アップ (任意): 上矢印で増加させるよりも大きい量で、増加させます。
  • ページ・ダウン (任意): 下矢印で減少させるよりも大きい量で、減少させます。
注意
  1. フォーカスは、スライダ―(マウス・ユーザーが動かすビジュアル・オブジェクトで、ツマミとしても知られています。)に配置します。
  2. いくつかの状況では、上記のキーに関して、値の変更の方向を逆にする(例えば、上矢印で、値を減少させる)ことは、より直感的な経験を作り出すかもしれません。

WAI-ARIAのRole、States、Property

  • フォーカス可能なスライダー・コントロールとして提供される要素は、role=sliderを持っています。
  • スライダー要素は、aria-valuenowプロパティを、スライダーの現在の値を示している小数値にセットします。
  • スライダー要素は、aria-valueminプロパティを、スライダーの許容できる最少の値を示す小数値にセットします。
  • スライダー要素は、aria-valuemaxプロパティを、スライダーの許容できる最大の値を示す小数値にセットします。
  • もし、aria-valuenowの値がユーザー・フレンドリーで無いなら(例えば、曜日を番号で示している場合など)、aria-valuetextプロパティは、スライダの値を理解しやすくする文字列にセットします(例えば、”月曜日”など)。
  • もし、スライダーが目に見えるラベルを持っているなら、スライダー要素のaria-labelledbyで、参照されます。さもなければ、スライダー要素は、aria-labelで提供されるラベルを持ちます。
  • If the slider is vertically oriented, it has aria-orientation set to vertical. The default value of aria-orientation for a slider is horizontal.

3.19 スライダー(複数のつまみ)

複数のつまみのスライダは、2つかそれ以上のつまみのあるスライダです。関連する値のグループ内で、それぞれ、値をセットします。 例えば、製品の検索では、2つのつまみのあるスライダは、ユーザーが検索のための最低額と最高額をセットすることを可能にするでしょう。 多くの2つまみのスライダーの場合、ある範囲について最小値と最大値をセットするときのように、つまみは、お互いを通過できません。 例えば、価格帯を選択するとき、範囲の下端を指定するつまみの最大値は、範囲の上側の値をセットするつまみの現在の値で、制限されます。 逆に、上端のつまみの最小値は、下端のつまみの現在の値に制限されます。 しかしながら、いくつかの複数つまみのスライダーでは、それぞれのつまみは、他のつまみの値に依存しない値をセットします。

マルチ親指スライダーの例: 飛行機とホテルの予約のために価格帯を決める2つまみのスライダーを示します。

キーボード・インタラクション

  • それぞれのつまみは、ページ・タブ・シーケンスに存在し、単一のつまみのスライダーと同じキーボード・インタラクションを持っています。
  • タブの順序は、スライダー内でのつまみの値や視覚的な位置に関係無く、一定のままにしておきます。例えば、もし、つまみの値が、他のつまみの一つを飛び越えるような変化があっても、タブの順序は変化しません。

WAI-ARIAのRole、States、Property

  • フォーカス可能なスライダーのつまみとして機能する各要素は、role=sliderを持っています。
  • それぞれのスライダー要素は、 aria-valuenowプロパティを、スライダーの現在の値を示す小数値にセットします。
  • それぞれのスライダー要素は、aria-valueminプロパティを、スライダーの許容できる最少の値を示す小数値にセットします。
  • それぞれのスライダー要素は、aria-valuemaxプロパティを、スライダーの許容できる最大の値を示す小数値にセットします。
  • 他のスライダーの範囲(例えば、最小値や最大値)が、スライダーの現在の値に依存しているとき、依存しているスライダーのaria-valueminaria-valuemaxの値は、値が変化したときに、アップデートされます。
  • もし、aria-valuenowの値がユーザー・フレンドリーで無いなら(例えば、曜日を番号で示している場合など)、aria-valuetextプロパティは、スライダの値を理解しやすくする文字列にセットします(例えば、”月曜日”など)。
  • もし、スライダーが目に見えるラベルを持っているなら、スライダー要素のaria-labelledbyで、参照されます。さもなければ、スライダー要素は、aria-labelで提供されるラベルを持ちます。
  • もし、スライダーが縦方向になっているなら、aria-orientationは、verticalにセットします。スライダのaria-orientationのデフォルトの値は、horizontalです。

3.20 スピンボタン

スピンボタンは入力ウィジェットで、その値を、離散値の値のセットや範囲に制限します。 例えば、ユーザがアラームをセットできるようにするウィジェットでは、スピンボタンはユーザに1時間のあいだの分に関して、0~59までの数を選択できるようにするでしょう。

スピンボタンは、しばしば、3つのコンポーネントを持っています。現在の値を表示するテキスト・フィールド、増加ボタン、減少ボタンを含みます。テキスト・フィールドは、通常、唯一フォーカスがあたる部分です。値を増やしたり、減らしたりする機能は、キーボードの矢印キーでアクセス可能にするからです。また、通常、テキスト・フィールドは、ユーザが値を直接編集することを可能にします。

もし、範囲が大きいなら、スピンボタンは、小さいステップと大きいステップの両方で、値を変化させることができるようにしてもかまいません。 例えば、アラームの例の場合、ユーザーが、上矢印下矢印によって、1分づつ動かすことができ、ページ・アップページ・ダウンで10づつ動かすことができるようにしても、構いません。

スピンボタンの例を開発する作業は、issue125で追跡されます。

キーボード・インタラクション

  • 上矢印: 値を増やします。
  • 下矢印: 値を減らします。
  • ホーム: もし、スピンボタンが、最小値を持っているなら、最小値にセットします。
  • エンド: もし、スピンボタンが最大値を持っているなら、最大値にセットします。
  • ページ・アップ (任意): 上矢印より大きく、値を増やします。
  • ページ・ダウン (任意): 下矢印より大きく、値を減らします。
  • もし、スピンボタン・テキスト・フィールドが、直接値を編集できるようにするなら、以下のキーをサポートします。:
    • デバイスのプラットフォームに適する、標準的な1行のテキスト編集キー(以下の「注意」を参照してください。)。
    • 印刷可能な文字: テキストボックスに文字を入力します。多くの実装が、値のある一部の文字を入力可能とし、他の文字は全て入力できないようにしていることに注意してください。例えば、時間と分のスピンボックスは、0から59の整数、コロン「:」、そして、「AM」「PM」の文字だけを、入力できるようにするでしょう。他の文字の入力の場合、どの文字であっても、テキスト・フィールドの内容や、スピンボタンの値は変化しません。
注意
  1. 操作の間、フォーカスはテキスト・フィールドに残っています。
  2. デバイスのプラットフォームに適する、標準的な1行のテキスト編集キー:
    1. 入力、カーソル移動、選択、および、テキスト操作のためのキーを含めます。
    2. 編集機能のための標準的なキーの割り当ては、デバイス・オペレーティング・システムに依存します。
    3. テキスト編集機能を提供するための最も確実な方法は、ブラウザを頼りにすることです。HTMLのテキスト・タイプの入力要素や、HTMLのcontenteditable属性のために、ブラウザは、それらの編集機能を提供します。
    4. 重要: テキスト編集機能のキーのキー・イベントを奪い取ることで、JavaScriptが、ブラウザが提供するテキスト編集機能を邪魔しないように気をつけてください。

WAI-ARIAのRole、States、Property

  • スピンボタンとして機能するフォーカス可能な要素は、role=spinbuttonを持っています。これは、通常、テキスト入力をサポートする要素です。
  • スピンボタン要素は、aira-valuenowプロパティを、スピンボタンの現在の値を示す小数値にセットします。
  • もし、スピンボタン要素の最小値が分かっているなら、スピンボタンの要素は、aria-valueminプロパティを、スピンボタンのとりうる最小値を示す小数値にセットします。
  • もし、スピンボタン要素の最大値が分かっているなら、スピンボタンの要素は、aria-valuemaxプロパティを、スピンボタンのとりうる最大値を示す小数値にセットします。
  • もし、aria-valuenowの値がユーザー・フレンドリーで無いなら(例えば、曜日を番号で示している場合など)、aria-valuetextプロパティは、スライダの値を理解しやすくする文字列にセットします(例えば、”月曜日”など)。
  • もし、スピンボタンが目に見えるラベルを持っているなら、スピンボタンのaria-labelledbyで、参照されます。さもなければ、スピンボタンは、aria-labelで提供されるラベルを持ちます。
  • もし、値が、許容範囲を超えるなら、スピンボタンの要素は、aria-invalidtrueにセットします。ほとんどの実装は、不正な値の入力を防止しますが、いくつかの場合には、全ての不正な入力をブロックすることが現実的ではないことに、注意してください。

3.21 テーブル

HTMLのtable要素のように、WAI-ARIAテーブルは、1つかそれ以上のセルを含む行をいくつか含んだ静的な表の構造です。それは、インタラクティブなウィジェットではありません。 したがって、そのセルは、フォーカスがあたるわけでもなく、選択することが出来るわけでもありません。 グリッドパターンは、表構造を持っている対話的なウィジェットを作るために、使用されます。

しかしながら、テーブルは、情報と対話的なウィジェットの組み合わせを提示するために、しばしば使用されます。 テーブルはウィジェットでは無いので、テーブルに含まれた各ウィジェットは、ページ・タブ・シーケンスで、個別にストップする場所となります。 もし、ウィジェットの数が大きいなら、グリッドは他のウィジェットを含むことができる合成ウィジェットなので、テーブルをグリッドに置き換えることで、ページ・タブ・シーケンスを劇的に少なくすることが出来ます。

注意

ネイティブの同等のホスト・ランゲージを持つ他のWAI-ARIAのroleのように、製作者は、可能な時はいつでも、HTMLのtableの要素を使用することが、強く推奨されます。 role=tableは、WAI-ARIA 1.1の新機能であり、このことが特に重要になります。 このため、対象となる利用者が使う可能性のあるブラウザと支援技術の組み合わせで、実装をきちんとテストすることを、お勧めします。

テーブルの例: ARIAのテーブルがHTMLのdivspanの要素で出来ています。

キーボード・インタラクション

適用することはありません。

WAI-ARIAのRole、States、Property

  • テーブル・コンテナは、role=tableをもっています。
  • それぞれの行コンテナは、role=rowを持ち、table要素かrole=rowgroupのDOMの子孫か、あるいは、それらによって所有されています。
  • それぞれのセルは、row要素の子孫か、それによって所有されており、以下のroleの一つを持っています。:
    • もし、セルが、列に関するタイトルやヘッダーの情報を含んでいるなら、columnheaderを。
    • もし、セルが、行に関するタイトルやヘッダーの情報を含んでいるなら、rowheaderを。
    • もし、セルが、列や行のヘッダーの情報を含んでいないなら、cellを。
  • もし、テーブルのラベルとして機能するユーザ・インタフェースに要素が存在するなら、aria-labelledbyを、ラベリングの要素への参照値といっしょに、table要素にセットします。 もし、そうでなければ、aria-labelを使って、table要素にラベルを指定します。
  • もし、テーブルが、キャプションや説明を持っているなら、aria-describedbyを、その説明を含む要素への参照値といっしょに、table要素にセットします。
  • もし、テーブルが、ソート可能な列や行を含んでいるなら、「6. Grid and Table Properties(6. グリッドとテーブルのプロパティ)」のセクションに記載されているように、aria-sortを、ソートされた列や行のヘッダー・セルの要素の適切な値に、セットします。
  • もし、いくつかの行や列がDOMで隠されたり、表示されていないという状態があるなら、例えば、行や列を隠すためのページにウィジェットがあるような場合は、「6. Grid and Table Properties(6. グリッドとテーブルのプロパティ)」のセクションに記載されているように、以下のプロパティが適用されます。
  • もし、テーブルが、複数の行や、複数の列を結合しているセルを含むなら、aria-rowspanaria-colspanを、「6. Grid and Table Properties(6. グリッドとテーブルのプロパティ)」のように適用します。
注意

もし、行かセルが、aria-ownsによって、テーブルに含まれていて、DOMの子孫もaria-owns属性に含まれていないなら、その行かセルは、table要素のDOMの子孫の後で、支援技術に提示されるでしょう。

3.22 タブ・コントロール

タブ・コントロールは、階層化されたコンテンツのセクションの集まりで、タブ・パネルとして知られており、一度に一つのパネルが表示されます。それぞれのタブ・パネルは、関連するタブ要素を持っており、アクティブになるとそのパネルを表示します。タブ要素のリストは、現在表示されているパネルの縁そって配置され、ほとんどの場合、上になります。

このデザイン・パターンを説明するために、以下の用語が使われます。:

「タブ・コントロール」、「タブ・インタフェース」
タブ要素の集まりと、それに関連するタブパネルのことです。
「タブ・リスト」
tablist要素に含まれたタブ要素の集まりです。
「タブ」
タブ・リストの要素で、タブ・パネルの一つのラベルとして提供され、そのタブを表示するためにアクティブにされます。
「タブパネル」
タブと関連づけられた内容を含む要素です。

タブ・インタフェースを初期化するとき、1つのタブ・パネルが表示され、その関連するタブは、アクティブであるようにスタイリングされます。ユーザーが、他のタブ要素のうちの一つをアクティブにするとき、その前に表示されていたタブ・パネルは隠され、アクティブになったタブと関連しているタブ・パネルが、見えるようになります。そして、そのタブは、「アクティブ」であると、認識されます。

キーボード・インタラクション

タブ・リストについて:

  • タブ: フォーカスが、タブ・リストに移動したとき、フォーカスをアクティブなtab要素に配置します。タブ・リストがフォーカスを含んでいるとき、フォーカスは、タブ・リストの外で、ページ・タブ・シーケンスの次の要素に、移動します。一般的には、タブ・パネルの中の最初のフォーカス可能な要素か、タブ・パネル自体のどちらかです。
  • フォーカスが、水平に並んだタブ・リストのタブ要素にあるときは、以下のようにします。:
    • 左矢印: 前のタブにフォーカスを移動します。 もし、フォーカスが最初のタブにあるなら、最後のタブにフォーカスを移動します。 任意ですが、新たにフォーカスされたタブをアクティブにします(以下の注意を参照ください。)。
    • 右矢印: 次のタブにフォーカスを移動します。 もし、フォーカスが最後のタブ要素にあるなら、フォーカスを最初のタブに移動します。 任意ですが、新たにフォーカスされたタブをアクティブにします(以下の注意を参照ください。)。
  • フォーカスが、水平、もしくは、垂直に構成されたタブリストのタブにあるときは、以下のようにします。:
    • スペース、もしくは、エンター: もし、自動的にフォーカスをアクティブにしないなら、タブをアクティブにします。
    • ホーム (任意): フォーカスを最初のタブに移動します。任意ですが、新たにフォーカスされたタブをアクティブにします(以下の注意を参照ください。)。
    • エンド (任意): フォーカスを最後のタブに移動します。任意ですが、新たにフォーカスされたタブをアクティブにします(以下の注意を参照ください。)。
    • シフト + F10: もし、タブが関連するポップ・アップ・メニューを持っているなら、メニューを開きます。
    • 削除 (任意): もし、削除が許容されているなら、現在のタブ要素と関連するタブ・パネルを削除する(か、閉じる)ようにし、フォーカスをその次のタブに移動します。そして、任意ですが、新たにフォーカスされたタブをアクティブにします(以下の注意を参照ください。)。もし、削除されたタブの後にタブが存在しないなら、例えば、左から右に水平に配置されたタブ・リストで、一番右のタブが削除されたような場合は、削除されたタブの手前のタブにフォーカスを配置し、任意ですが、そのタブをアクティブにします。もし、アプリケーションが全てのタブが削除されることを許容し、ユーザーが、タブ・リストで最後に残ったタブを削除する場合、アプリケーションは、フォーカスを、論知的なワーク・フローを提供する他の要素に移動させます。
注意
  1. タブ・コントロールが、フォーカスを受け取ったとき、関連しているタブ・パネルが表示されているかぎり、長い待ち時間を必要とせず、自動的にアクティブになるのが望ましい。一般的に、これは、タブ・パネルのコンテンツが、予め読み込まれている必要があります。さもなければ、自動的にアクティブにする機能は、フォーカスの動きを遅くします。これは、タブ・リストを効果的にナビゲートするユーザーの能力を、かなり妨げます。追加ガイダンスに関しては、「5.4 Deciding When to Make Selection Automatically Follow Focus」を見てください。
  2. もし、タブ・リストのタブが、垂直になっているなら:
    1. 下矢印が、上記の右矢印の説明のように動作します。
    2. 上矢印が、上記の左矢印の説明のように動作します。
  3. もし、タブ・リストが水平なら、下矢印上矢印は、上記のようにする必要は無く、たとえタブ・リストの中にフォーカスがあったとしてもそれらのキーは普通のブラウザのスクロール機能を提供することができます。

WAI-ARIAのRole、States、Property

  • タブ・コントロールの内容を提供する要素は、role=tablistを持っています。
  • タブとして提供されるそれぞれの要素は、role=tabを持ち、role=tablistのある要素を含んでいます。
  • Each element that contains the content panel for a tab has role tabpanel. tabの内容パネルを含む要素は、それぞれ、role=tabpanelを持っています。
  • もし、タブ・リストが視覚的なラベルを持っているなら、role=tablistのある要素は、aria-labelledbyの値を、そのラベルの要素を参照するようにセットしています。 Otherwise, the tablist element has a label provided by aria-label. さもなければ、tablist要素に、aria-labelで提供されているラベルをセットします。
  • role=tabのあるそれぞれのタブは、tabpanel要素を参照するaria-controlsプロパティを持っています。
  • アクティブなtab要素は、aria-selectedtrueにセットし、全ての他のタブの要素は、aria-selectedfalseにセットします。
  • role=tabpanelのあるそれぞれの要素には、関連するtab要素を参照するaria-labelledbyプロパティがあります。
  • tab要素がポップアップメニューを持っているなら、menutrueにセットされたaria-haspopupプロパティがあります。
  • もし、tablist要素が垂直になっているなら、aria-orientationプロパティは、verticalにセットします。tablist要素のaria-orientationプロパティのデフォルトの値は、horizontalです。

3.23 ツールバー

ツールバーは、ボタン、メニューボタン、チェックボックスのようなコントロールのセットをグルーピングするためのコンテナです。

コントロールの集まりが、視覚的に、グループとして表示されているとき、role=toolbarは、スクリーン・リーダー・ユーザーにグループの存在と目的を伝えるために使うことができます。また、コントロールをツールバーにグルーピングすることは、キーボード・インターフェースにおいて、タブ・キーでの停止箇所の数を減少させるのに、効果的な方法となりえます。

ツールバー・ウィジェットの利益を最適化するために:

ツールバーの例: フォーカスの管理に「roving tabindex」を使用し、トグル・ボタン、ラジオ・ボタン、メニュー・ボタン、スピン・ボタン、チェックボックス、リンクを含む、いくつかのタイプのコントロールを含みます。(「roving tabindex」は、5.6.1に記載がある。5.6.1に記載のフォーカス管理方法を、「roving tabindex」と名付けているように見える。現段階で訳しにくいので、このままで、表記。)

キーボード・インタラクション

  • タブシフト + タブ: フォーカスをツールバーの中、もしくは外に移動します。フォーカスがツールバーの中に移動するとき:
    • もし、初めてフォーカスがツールバーの中に移動するなら、フォーカスは、ディセイブルになっていない最初のコントロールにセットします。
    • もし、ツールバーが以前にフォーカスを持っていたなら、任意ですが、フォーカスは最後にフォーカスのあったコントロールにセットします。さもなければ、ディセイブルではない最初のコントロールにセットします。
  • 水平なツールバー(デフォルト):
    • 左矢印: フォーカスを前のコントロールに移動します。 任意ですが、フォーカスの動作は、最初の要素から最後の要素に回ってもかまいません。
    • 右矢印: フォーカスを次のコントロールに移動します。 任意ですが、フォーカスの動作は、最後の要素から最初の要素に回ってもかまいません。
  • ホーム (任意): フォーカスを最初の要素に移動します。
  • エンド (任意): フォーカスを最後の要素に移動します。
注意
  1. もし、ツールバーの項目が垂直に並べられるなら:
    1. 下矢印は、上記の右矢印の説明のように、動作します。
    2. 上矢印は、上記の左矢印の説明のように、動作します。
  2. 基本的に、キーボードで操作しているときは、ディセイブルの要素は、フォーカスがあたりません。しかしながら、機能の見つけやすさが非常に重要であるような状況では、スクリーン・リーダーのユーザーはその存在を意識している傾向があるので、ディセイブルのコントロールにフォーカスがあたるほうが役立つかもしれません。追加のガイダンスとして、「5.7 ディセイブルのコントロールのフォーカス5.7 Focusability of disabled controls)」を参照してください。
  3. ツールバーへの迅速なアクセスが重要なアプリケーション、例えば、テキスト・エディターで編集領域から、ツールバーへアクセスするような場合、関連するコンテキストから対応するツールバーへフォーカスを移動するには、文書化されたショートカット・キーが推奨されます。

WAI-ARIAのRole、States、Property

  • ツールバーのコンテナとして機能する要素は、role=toolbarを持っています。
  • もし、ツールバーが目に見えるラベルを持っているなら、ツールバー要素のaria-labelledbyで、参照されるようにします。さもなければ、ツールバー要素は、aria-labelで提供されるラベルを持ちます。
  • もし、コントロールが垂直に並んでいるなら、ツールバー要素は、aria-orientationverticalにセットします。デフォルトの方向は、水平です。

3.24 ツールチップ・ウィジェット

注意: このデザイン・パターンは審議中です。 タスク・フォースの合意はまだありません。進捗状況と議論が、[issue 128]に保存してあります。

ツールチップはポップアップで、要素がキーボード・フォーカスやマウスのホバーを受け取ったとき、要素に関連する情報を表示します。通常、少し遅れて表示され、エスケープが押されるか、マウスが離れたときに、消えます。

ツールチップ・ウィジェットはフォーカスを受け取りません。フォーカス可能な要素を含むホバーは、非モーダル・ダイアログを使用することで、可能です。

ツールチップの例を開発する作業は、[issue 127]で参照できます。

キーボード・インタラクション

エスケープ: ツールチップを消します。

注意
  1. ツールチップが表示されている間は、トリガーとなる要素にフォーカスを残しておきます。
  2. もし、トリガーとなる要素がフォーカスを受け取ったときに、ツールチップが表示されるなら、フォーカス(onBlur)がもうないときは、ツールチップは消えます。もし、ツールチップが、マウス・オーバーで表示されるなら、マウスが違う場所に移動したとき、ツールチップは消えます。

WAI-ARIAのRole、States、Property

  • ツールチップのコンテナとして機能する要素は、role=tooltipを持っています。
  • ツールチップのトリガーとなる要素は、aria-describedbyで、ツールチップ要素を参照するようにします。

3.25 ツリー・ビュー

ツリー・ビューのウィジェットは、階層リストを提供します。階層構造のどの項目も、子の項目を持っている可能性があり、その子の項目を表示したり、隠したりするために、子の項目を展開したり、折りたたんだりすることになります。例えば、フォルダーやファイルを表示するためにツリー・ビューを使うファイル・システムのナビゲーションでは、フォルダーを示す項目は、そのフォルダの内容(ファイルやフォルダ、その両方になると思いますが)を明らかにするために、展開することができます。

ツリー・ビューを理解するための用語:

ノード
ツリー内の1項目
ルート・ノード
ツリーのベースとなるノードです。1つかそれ以上の子のノードを持ちますが、親のノードは持っていません。
子ノード
親を持つノードです。ルート・ノードでは無いノードは、どれも子ノードです。
エンド・ノード
子ノードを、まったく持っていないノードです。エンド・ノードは、ルート・ノードか、子ノードの何れかとなります。
親ノード
1つかそれ以上の子ノードを持つノードです。開いたり(展開したり)、閉じたり(折りたたんだり)できます。
開いたノード
子ノードが目に見えるように、展開された親ノードです。
閉じたノード
子ノードが目に見えないように、折りたたまれた親ノードです。

ツリーを操作するためにキーボードを使うとき、目に見えるキーボードのインジケータが、どのノードにフォーカスがあたっているかを、ユーザーに知らせます。もし、あるアクションのためにユーザーが一つの項目を選択できるツリーなら、そのツリーは、単一選択ツリーとなります。また、単一選択ツリーのいくつかの実装では、フォーカスのある項目は、選択状態を持っています。これは、選択状態がフォーカスに追随することで知られています。しかしながら、複数選択ツリーの場合は、ユーザーが、あるアクションのために、1つ以上の項目を選択できるようになっており、選択状態は、常に、フォーカスから独立しています。例えば、典型的なファイル・システムのナビゲーションでは、ユーザーは、コピーや移動のような操作で、どんな数のファイルを選択するにしてもフォーカスを動かすことは可能です。ビジュアル・デザインが、選択状態の項目と、フォーカスのある項目とを、識別できることは、重要です。その他の詳細に関しては、フォーカスと選択の違いの説明(「5.3 フォーカス 対 選択、そして、二重フォーカスの知覚(5.3 Focus VS Selection and the Perception of Dual Focus)」)と、「5.4 選択を自動的にフォーカスに追随させるという決断(5.4 Deciding When to Make Selection Automatically Follow Focus)」を参照してください。

キーボード・インタラクション

垂直方向のツリーに関して:

  • 単一選択ツリーがフォーカスを受け取るとき:
    • もし、ツリーがフォーカスを受け取る前に、どのノードも選択されていないなら、最初のノードにフォーカスをセットしてください。
    • もし、ツリーがフォーカスを受け取る前に、ノードが選択されているなら、その選択されているノードにフォーカスをセットしてください。
  • 複数選択ツリーがフォーカスを受け取るとき
    • もし、ツリーがフォーカスを受け取る前に、どのノードも選択されていないなら、最初のノードにフォーカスをセットしてください。
    • もし、ツリーがフォーカスを受け取る前に、1つか、それ以上のノードが選択されているなら、フォーカスは、選択されたノードの最初のフォーカスにセットしてください。
  • 右矢印:
    • フォーカスが閉じたノードにあるとき、ノードを開きます。フォーカスは移動しません。
    • フォーカスが開いたノードにあるとき、フォーカスを最初の子ノードに移動します。
    • フォーカスがエンド・ノードにあるとき、何もしません。
  • 左矢印:
    • フォーカスが開いたノードにあるとき、ノードを閉じます。
    • フォーカスが子ノードにあって、その子ノードが、エンド・ノードか、閉じたノードでもある場合、フォーカスは、その親のノードに移動します。
    • フォーカスがルート・ノードにあって、そのルート・ノードが、エンド・ノードか、閉じたノードでもある場合、何もしません。
  • 下矢印: ノードを開いたり閉じたりせず、フォーカスを、フォーカス可能な次のノードに移動します。
  • 上矢印: ノードを開いたり閉じたりせず、フォーカスを、フォーカス可能な前のノードに移動します。
  • ホーム: ノードを開いたり閉じたりせず、フォーカスを、ツリーの最初のノードに移動します。
  • エンド: ノードを開かずに、フォーカスを、フォーカス可能なツリーの最後のノードに移動します。
  • エンター: ノードを動作させます。すなわち、そのノードのデフォルトのアクションを実行します。親ノードの場合、1つ可能なデフォルトのアクションは、ノードを開くか閉じることです。選択状態がフォーカスに追随しない単一選択ツリーの場合(以下の「注意」を参照)、デフォルトのアクションは、通常、フォーカスのあるノードを選択することです。
  • すべてのツリーでのタイプ-アヘッドの推奨(特に、ルート・ノードが7つ以上あるツリーで推奨):
    • 文字の入力: 入力された文字で始まる名前のノードで、次のノードに、フォーカスを移動します。
    • 素早く複数の文字をタイプした場合: 入力された文字列で始まる名前のノードで、次のノードに、フォーカスを移動します。
  • * (任意): 現在のノードと同じレベルのすべての兄弟のノードを開きます。
  • 複数選択ツリーでの選択: 制作者は、複数選択をサポートする2つのインタラクション・モデルのうち、どちらを実装してもかまいません。:推奨のモデルは、リストを操作している間に、ユーザーが、シフトコントロールのような、修飾キーを押しておく必要が無いモデルです。もう一つのモデルは、選択状態を失くさないように、操作中、ユーザーが、修飾キーを押しておかなければ良いモデルです。
    • お勧めの選択モデル -- フォーカスを動かしている間、修飾キーを押しておくことは、必要ではない。:
      • スペース: フォーカスのあるノードの選択状態を切り替えます。
      • シフト + 下矢印(任意): フォーカスを次のノードに移動し、選択状態を切り替えます。
      • シフト + 上矢印 (任意): フォーカスを前のノードに移動し、選択状態を切り替えます。
      • シフト + スペース (任意): 最後に選択したノードから現在のノードまでを連続して選択します。
      • コントロール + シフト + ホーム (任意): フォーカスのあるノードと、最初のノードまでの全てのノードを選択します。任意ですが、フォーカスを最初のノードに移動します。
      • コントロール + シフト + エンド (任意): フォーカスのあるノードと、最後のノードまでの全てのノードを選択します。フォーカスのあるノードと、最後のノードまでの全てのノードを選択します。任意ですが、フォーカスを最後のノードに移動します。
      • コントロール + A (任意): ツリーの全てのノードを選択します。また、任意ですが、もし、すべてのノードが選択されているなら、全てのノードを非選択状態にします。
    • もう一つの選択モデル -- フォーカスのあるノードを除き、ShiftControlの修飾キーを押さずにフォーカスを動かすと、全ての選択済みのノードが、非選択になります。
      • シフト + 下矢印: フォーカスを次のノードに移動し、選択状態を切り替えます。
      • シフト + 上矢印: フォーカスを前のノードに移動し、選択状態を切り替えます。
      • コントロール + 下矢印: 選択状態を変えずに、フォーカスを次のノードに移動します。
      • コントロール + 上矢印: 選択状態を変えずに、フォーカスを前のノードに移動します。
      • コントロール + スペース: フォーカスのあるノードの選択状態を切り替えます。
      • シフト + スペース (任意): 最後に選択したノードから現在のノードまでを連続して選択します。
      • コントロール + シフト + ホーム (任意): フォーカスのあるノードと、最初のノードまでの全てのノードを選択します。任意ですが、フォーカスを最初のノードに移動します。
      • コントロール + シフト + エンド (任意): フォーカスのあるノードと、最後のノードまでの全てのノードを選択します。任意ですが、フォーカスを最後のノードに移動します。
      • コントロール + A (任意): ツリーの全てのノードを選択します。また、任意ですが、もし、すべてのノードが選択されているなら、全てのノードを非選択状態にします。
注意
  1. DOMフォーカス(アクティブな要素)は、機能的に、選択状態とは異っています。より詳細は、フォーカスと選択の違いの説明(「5.3 フォーカス 対 選択、そして、二重フォーカスの知覚(5.3 Focus VS Selection and the Perception of Dual Focus)」)を参照してください。
  2. role=treeは、aria-activedescendantプロパティをサポートします。これは、キーボードナビゲーションを実装するとき、treeitem要素の間でDOMフォーカスを動かすための代替手段を提供します。詳細に関しては、「5.6.2 aria-activedescendantを使用するコンポジットでのフォーカス管理(5.6.2 Managing Focus in Composites Using aria-activedescendant)」を参照してください。
  3. 単一選択ツリーの場合、フォーカスを動かすことで、任意ですが、前に選択していたノードは非選択にして、新たにフォーカスのあるノードを選択してもかまいません。この選択モデルは、「フォーカス追随選択(selection follows focus)」として知られています。フォーカス追随選択を持つことは、いくつかの状況では、とても役立ちますが、その他の場合には、アクセシビリティを著しく低下させる可能性もあります。追加のガイダンスに関しては、「5.4 選択を自動的にフォーカスに追随させるという決断(5.4 Deciding When to Make Selection Automatically Follow Focus)」を参照してください。
  4. もし、すべてのノードを選択したり、非選択にすることが、重要な機能である場合は、独立したコントロールをこれらのアクションに実装する(「全選択」「全解除」ボタンなどを設ける)と、アクセシビリティを大幅に改善します。
  5. もし、ツリーのノードが水平に並べられるなら:
    1. 下矢印が、上記の右矢印のように動作し、逆もまた同様です。
    2. 上矢印が、上記の左矢印のように動作し、逆もまた同様です。

WAI-ARIAのRole、States、Property

  • すべてのツリーのノードは、role=treeのある要素に含まれているか、所有されています。
  • ツリーのノードとして機能する各要素は、role=treeitemを持っています。
  • 各ルート・ノードは、role=treeのある要素に含まれているか、tree要素にセットされたaria-ownsプロパティで参照されます。
  • 各親ノードは、role=groupのある要素を含むか、または所有しています。
  • 各子ノードは、role=groupのある要素によって、含まれているか、所有されています。子ノードの親として機能するノードによって、含まれているか、所有されています。
  • 親ノードとして機能する、role=treeitemのある各要素は、そのノードが閉じているときは、aria-expandedを、falseにセットします。また、そのノードが、開いているときは、trueにセットします。エンド・ノードは、aria-expanded属性を持ちません。なぜなら、もし、持っていた場合、支援技術に親ノードとして、間違って伝えられてしまうかもしれないからです。
  • もし、ツリーが一つ以上のノードの選択をサポートするなら、role=treeのある要素は、aria-multiselectabletrueにセットします。さもなければ、aria-multiselectableは、falseにセットされているか、デフォルトの値としてfalseが適用されます。
  • もし、ツリーが複数選択をサポートしないなら、aria-selectedは、選択されたノードに関してtrueにセットされ、ツリー内の他のどのノードにも存在しません。
  • もし、ツリーが複数選択をサポートするなら:
    • すべての選択されたノードは、aria-selectedtrueにセットします。
    • 選択可能だけれども選択されていないすべてのノードは、aria-selectedfalseにセットします。
    • もし、ツリーが選択可能でないノードを含んでいるなら、それらのノードは、aria-selectedの状態を持ちません。
  • role=treeの要素は、aria-labelledbyで参照可能な目に見えるラベルか、aria-lebelで指定された値のどちらかを持ちます。
  • もし、ユーザーがツリーの中でフォーカスを移動させたり、スクロールしたりするような動的なローディングのせいで、利用可能なノードの完全なセットが、DOMに存在しないなら、それぞれのノードは、aria-levelaria-setsizearia-posinsetが指定されます。
  • もし、tree要素が、水平方向に並んでいるなら、aria-orientationを、horizontalにセットします。ツリーのaria-orientationのデフォルトの値は、verticalです。
注意

もし、aria-ownsが、コンテナーのDOMの子でない要素を含むためにツリー・コンテナーにセットされるなら、それらの要素は、それらが参照される系列で、かつ、DOMの子であるすべての項目の後に、読み込み順に現れるでしょう。フォーカスを管理するスクリプト(台本)は、視覚的なフォーカスの順序が、この支援技術の読み込み順序に合致することを保証しなければなりません。

3.26 ツリーグリッド

エディターの注意

このパターンは、APG1.1のリリース2で、初めてのものです。issue793で、フィードバックを提供してください。

ツリーグリッド・ウィジェットは、表形式の情報(編集可能だったり、インタラクティブだったりします。)で構成された階層的なデータ・グリッドを提供します。階層構造のどの行にも、子の行を含めることができ、子のある行は、その子を表示したり、隠したりするために展開したり、折りたたんだりすることができます。例えば、e-mailのディスカッション・リストで、メッセージとメッセージへの回答を表示するために使用されるtreegridの場合、回答が含まれるメッセージは、回答を表示するように展開できる行に表示されます。

ツリーグリッドの場合、行とセルの両方が、フォーカス可能になります。すべての行とセルは、そのそれぞれが編集可能、もしくは、インタラクティブのいずれかであろうとなかろうと関係無く、フォーカス可能な要素を含むか、それ自身がフォーカス可能です。1つの例外があります: もし、コラムの見出しが、ソートやフィルタのような機能を提供しないなら、フォーカス可能とする必要はありません。すべてのセルがキーボード・フォーカスを受け取ったり、含んだりできることが大切であるという1つの理由は、ユーザーがグリッドを操作しているとき、スクリーン・リーダーは、通常、ドキュメント・リーディング・モードでは無く、アプリ-ケーション・リーディング・モードになっているためです。アプリケーション・モードのとき、スクリーン・リーダーのユーザーは、フォーカス可能な要素と、そのラベルの要素だけを聞きます。そのため、スクリーン・リーダーのユーザーは、フォーカスされなかったり、行や列にラベルが無いtreegridに含まれる要素は、知らないうちに見落としてしまうかもしれません。

treegridを操作するためにキーボードを使うとき、視覚的なキーボード・インジケータは、ユーザーに、どの行や列がフォーカスされているかを知らせます。もし、treegridで、ユーザーがアクションのために1項目を選択できるなら、それは、単一選択treegridであり、また、フォーカスのある項目は、選択された状態を持ちます。しかしながら、複数選択treegridの場合、それは、ユーザーが1つのアクションについて、複数の行や列を選択することができるので、選択状態は、フォーカスから独立しています。例えば、階層的なe-mailディスカッション・グリッドの場合、ユーザーは、削除や移動のようなアクションのために、どの行でも選択できるように、フォーカスを移動することが出来ます。視覚的なデザインが、選択された項目と、フォーカスのある項目の違いを識別できるようにすることは、重要です。その他の詳細に関しては、フォーカスと選択の違いに関するこの記述を見てください(「5.3 フォーカス 対 選択、そして、二重フォーカスの知覚(5.3 Focus VS Selection and the Perception of Dual Focus)」)。

  • E-Mail受信トレイtreegridの例: e-mailの受診トレイを操作するツリーグリッドです。「行優先」、「セル優先」、「セルのみ」の、3つのキーボード・ナビゲーション・モデルをデモンストレーションします。

キーボード・インタラクション

以下のキーは、グリッドの行とセルの中でフォーカスを動かすことによって、treegridの操作を提供します。グリッドの要素が、フォーカスを受け取ったとき、例えば、ユーザーが、Tabでグリッドにフォーカスを移動した後などのように、treegridの実装は、これらのキー・コマンドを利用可能にします。 フォーカスをグリッドに動かすと、最初のセルか、最初の行に、フォーカスがあたるようにしてかまいません。 フォーカスがセルに移動するか行に移動するかは、製作者の好みと、行のフォーカスがサポートされているかどうかに依存します(いくつかのtreegridは、フォーカスを行に提供しないかもしれないので)。

  • エンター: もし、セルのみフォーカスが有効になっていて、フォーカスが、aria-expanded プロパティのある最初にセルに存在するなら、その子の行を開くか閉じるかします。そうでないなら、セルのデフォルトのアクションを実行します。
  • タブ: もし、フォーカスを含む行が、フォーカス可能な要素(例えば、入力欄、ボタン、リンクなど)を含むなら、その行の次の入力にフォーカスを移動します。もし、フォーカスが、その行の最後のフォーカス可能な要素に存在するなら、フォーカスをtreegridウィジェットから出して、次のフォーカス可能な要素へ移動します。
  • 右矢印:
    • もし、フォーカスが、折りたたまれた行にあるなら、その行を展開します。
    • もし、フォーカスが、展開している行にあるか、子の行を持っていない行に存在するなら、その行の最初のセルにフォーカスを移動します。
    • もし、フォーカスが、行の最も右のセルにあるなら、フォーカスは動きません。
    • もし、フォーカスが、それ以外のセルにあるなら、フォーカスを右に一つだけ移動します。
  • 左矢印:
    • もし、展開された行にフォーカスがあるなら、行を折りたたみます。
    • もし、折りたたまれた行や子の行を持たない行に、フォーカスがあるなら、フォーカスは移動しません。
    • もし、フォーカスが行の最初のセルに存在し、行フォーカスがサポートされているなら、フォーカスを行へ移動します。
    • もし、フォーカスが行の最初のセルに存在し、行フォーカスはサポートされていないなら、フォーカスは動きません。
    • もし、フォーカスが、それ以外のセルになるなら、フォーカスを左に一つだけ移動します。
  • 下矢印:
    • もし、フォーカスが行にあるなら、フォーカスを1行、下に移動します。もし、フォーカスが最後の行にあるなら、フォーカスは、移動しません。
    • もし、フォーカスがセルにあるなら、フォーカスを1セル、下に移動します。もし、フォーカスが列の最後のセルにあるなら、フォーカスは、移動しません。
  • 上矢印:
    • もし、フォーカスが行にあるなら、フォーカスを1行、上に移動します。もし、フォーカスが最初の行にあるなら、フォーカスは移動しません。
    • もし、フォーカスがセルにあるなら、フォーカスを1セル、上に移動します。もし、フォーカスが列の一番上にあるなら、フォーカスは移動しません。
  • ページ・ダウン:
    • もし、フォーカスが行にあるなら、製作者が決定した行数分だけ、フォーカスを下に移動します。通常は、そのとき見えている行の中で、一番下の行がスクロールし、それが、見えている行の一番最初のものになります。もし、フォーカスが最後の行にあるなら、フォーカスは移動しません。
    • もし、フォーカスがセルにあるなら、製作者が決定したセル数だけ、フォーカスを下に移動します。通常は、そのとき見えている行の中で、一番下の行がスクロールし、それが、見えている行の一番最初のものになります。もし、フォーカスが最後の行にあるなた、フォーカスは移動しません。
  • ページ・アップ:
    • もし、フォーカスが行にあるなら、製作者が決定した行数分だけ、フォーカスを上に移動します。通常は、そのとき見えている行の中で、一番上の行がスクロールし、それが、見えている行の一番下のものになります。もし、フォーカスが最初の行にあるなら、フォーカスは移動しません。
    • もし、フォーカスがセルにあるなら、製作者が決定したセル数だけ、フォーカスを上に移動します。通常は、そのとき見えている行の中で、一番上の行がスクロールし、それが、見えている行の一番下のものになります。もし、フォーカスが最初の行にあるなら、フォーカスは移動しません。
  • ホーム:
    • もし、フォーカスが行にあるなら、フォーカスを最初の行に移動します。もし、フォーカスが最初の行の中にあるなら、フォーカスは移動しません。
    • もし、フォーカスがセルにあるなら、フォーカスは、行の最初のセルに移動します。もし、フォーカスが行の最初のセルの中にあるなら、フォーカスは移動しません。
  • エンド:
    • もし、フォーカスが行にあるなら、フォーカスを最後の行に移動します。もし、フォーカスが最後の行の中にあるなら、フォーカスは移動しません。
    • もし、フォーカスがセルにあるなら、フォーカスは、行の最後のセルに移動します。もし、フォーカスが行の最後のセルの中にあるなら、フォーカスは移動しません。
  • コントロール + ホーム:
    • もし、フォーカスが行にあるなら、フォーカスを最初の行に移動します。 もし、フォーカスが最初の行の中にあるなら、フォーカスは移動しません。
    • もし、フォーカスがセルにあるなら、フォーカスを列の最初のセルに移動します。 もし、フォーカスが最初の行の中にあるなら、フォーカスは移動しません。
  • コントロール + エンド:
    • もし、フォーカスが行にあるなら、フォーカスを最後の行に移動します。 もし、フォーカスが最後の行の中にあるなら、フォーカスは移動しません。
    • もし、フォーカスがセルにあるなら、フォーカスを列の最後のセルに移動します。 もし、フォーカスが最後の行の中にあるなら、フォーカスは移動しません。
注意
  • 上記のtreegrid操作のナビゲーション・キーがフォーカスを移動するとき、フォーカスがセルの中の要素にセットされるのか、セルにセットされるのかは、セルの内容によります。「Whether to Focus on a Cell Or an Element Inside It(セルにフォーカスをあてるのか、その中の要素にあてるのか)」を、見てください。
  • 矢印キーのようなナビゲーション・キーがフォーカスをセルからセルへ移動している間は、コンボボックスの操作や、セルの中でのIカーソルの移動のようなことは、利用することができません。この機能性が必要であるなら、「Editing and Navigating Inside a Cell(セル内での編集とナビゲーション)」を見てください。
  • もし、ナビゲーションの機能が、より多くの行や列をDOMへ動的に追加することができるなら、グリッドの開始場所や終了場所にフォーカスを移動するキーイベント(例えば、コントロール + エンド)は、バックエンド・データの利用可能な最後の行ではなく、むしろ、DOMの最後の行に、フォーカスを移動してかまいません。

もし、ツリーグリッドがセル、行、列の選択をサポートするなら、以下のキーが、一般的に、これらの機能に利用されます。

  • コントロール + スペース:
    • もし、フォーカスが行にあるなら、全てのセルを選択します。
    • もし、フォーカスがセルにあるなら、フォーカスを含む列を選択します。
  • シフト + スペース:
    • もし、フォーカスが行にあるなら、行を選択します。
    • もし、フォーカスがセルにあるなら、フォーカスを含む行を選択します。もし、ツリーグリッドが、行を選択するためのチェックボックスのある列を持っているなら、このキーは、フォーカスがそのチェックボックスに無いときに、チェックボックスをチェックするためのショートカットとして提供することができます。
  • コントロール + A: すべてのセルを選択します。
  • シフト + 右矢印:
    • もし、フォーカスが行にあるなら、選択範囲は変更しません。
    • もし、フォーカスがセルにあるなら、右に1セル分、選択範囲を広げます。
  • シフト + 左矢印:
    • もし、フォーカスが行にあるなら、選択範囲は変更しません。
    • もし、フォーカスがセルにあるなら、左に1セル分、選択範囲を広げます。
  • シフト + 下矢印:
    • もし、フォーカスが行にあるなら、次の行に含まれるセルすべてを選択範囲に含めます。
    • もし、フォーカスがセルにあるなら、下に1セル分、選択範囲を広げます。
  • シフト + 上矢印:
    • もし、フォーカスが行にあるなら、前の行に含まれるセルすべてを選択範囲に含めます。
    • もし、フォーカスがセルにあるなら、上に1セル分、選択範囲を広げます。
注意

切り取り、コピー、ペーストのキーアサインに関しては、「5.8 Key Assignment Conventions for Common Functions5.8 共通の機能のためのキー・アサインの慣習」を見てください。

WAI-ARIAのRole、States、Property

  • ツリーグリッド・コンテナは、role=treegridを持っています。
  • それぞれの行コンテナはrole=rowを持ち、treegrid要素かrole=rowgroupのある要素のDOMの子孫となっているか、それらに所有されているかのいずれかとなります。
  • 各セルは、row要素のDOMの子孫となっているか、row要素に所有されており、以下のroleのうち、1つを持っています。:
    • columnheader もし、セルが、列に関するタイトルやヘッダの情報を含んでいるなら。
    • rowheader もし、セルが、行に関するタイトルやヘッダの情報を含んでいるなら。
    • gridcell もし、セルが、列や行のヘッダの情報を含んでいないなら。
  • 子の行を表示したり隠したりするために、展開したり折りたたんだりできるrowは、親の行です。それぞれの親のrowは、aria-expandedの状態を、row要素かrowに含まれるセルにセットします。子の行が表示されていないときは、aria-expandedfalseにセットされ、子の行が表示されているときは、trueにセットされます。子の行の表示をコントロールしない行は、aria-expanded属性を持ちません。なぜなら、もし、持ってしまうなら、それらは、支援技術に対して、誤って、親の行としての説明を伝えてしまうからです。
  • もし、ツリーグリッドが、1つ以上の行かセルの選択をサポートするなら、それは、複数選択ツリーグリッドであり、role=treegridのある要素は、aria-multiselectabletrueにセットします。さもなければ、それは、単一選択のツリーグリッドであり、aria-multiselectableは、falseにセットされるか、falseがデフォルト値としてセットされます。
  • もし、ツリーグリッドが、単一選択のツリーグリッドであるなら、選択された行やセルで、aria-selectedtrueにセットされ、ツリーグリッドの他の行やセルには存在しません。
  • もし、ツリーグリッドが、複数選択のツリーグリッドであるなら:
    • すべての選択された行やセルは、aria-selectedtrueにセットします。
    • 選択されていない、すべての行とセルは、aria-selectedfalseにセットします。
  • もし、ツリーグリッドのラベルとして機能する要素が、ユーザー・インタフェースに存在するなら、aria-labelledbyが、ラベルの要素への参照値をもつグリッド要素に、セットされます。さもなければ、aria-labelを使って、ラベルが、グリッド要素に指定されます。
  • もし、ツリーグリッドがキャプションや説明を持っているなら、aria-describedbyが、説明を含む要素への参照値をもつグリッド要素にセットされます。
  • もし、ツリーグリッドが、ソート機能を提供するなら、グリッドとテーブルのプロパティ(「6. Grid and Table Properties(6. グリッドとテーブルのプロパティ)」)のセクションで説明されているとおり、aria-sortは、適切な値をソートされた列や行のヘッダー・セル要素にセットします。
  • もし、ツリーグリッドが、コンテンツ編集機能を提供し、ある状況で編集機能をディセイブルにする可能性のあるセルを含んでいるなら、編集がディセイブルになっているセルでは、aria-readonlytrueにセットされます。もし、すべてのセルで編集機能がディセイブルになっているなら、それぞれのセルでaria-readonlytrueにセットする代わりに、treegrid要素のaria-readonlytrueにセットして構いません。コンテンツ編集機能のあるセルを提供しないツリーグリッドは、どの要素にも、aria-readonly属性は含めません。
  • もし、いくつかの行や列が、隠れていたり、DOMに存在しない状況、例えば、データがスクロールと同時に動的に読み込まれたり、グリッドが行や列を隠す機能を提供するようなら、グリッドとテーブルのプロパティ(「6. Grid and Table Properties(6. グリッドとテーブルのプロパティ)」)のセクションで説明されているとおり、以下のプロパティが、適用されます。
  • もし、ツリーグリッドが、複数の行や複数の列に跨るセルを含み、role=treegridがHTMLのtable要素に適用されないなら、グリッドとテーブルのプロパティ(「6. Grid and Table Properties(6. グリッドとテーブルのプロパティ)」)のセクションで説明されているとおり、aria-rowspanaria-colspanが、 適用されます。
注意
  • 複数の行や複数の列に跨るセルを含むtable要素から生成されたtreegrid は、HTMLのrowspancolspanを使用しなければならず、aria-rowspanaria-colspanを使ってはいけません。
  • もし、行やセルがaria-ownsを通じてツリーグリッドに含まれているなら、それらは、DOMの子孫もaria-owns属性に含まれない限り、treegrid要素のDOMの子孫の後で、支援技術に提示されます。

3.27 ウィンドウ・スプリッタ―

注意: ARIA1.1は、セパレーターのroleに変更を紹介したので、フォーカス可能なとき、ウィジェットとして動作します。このパターンが、ARIA1.1の仕様に合致するように修正されている間、委員会は、ARIA1.1の仕様に合致する機能的な例が完成するまで、レビューを終了しないでしょう。このパターンの進行状況は、issue 129で、追跡されます。

ウィンドウ・スプリッタ―は、ウィンドウの、2つのセクションやペインの間を動かすことができるセパレーターです。ユーザーは、ウィンドウの中の相対的なペインのサイズを、変更できます。ウィンドウ・スプリッタ―は、可変か、固定のいずれでも構いません。可変のスプリッタ―は、可能な範囲でどの位置にも調整できる一方で、固定のスプリッタ―は、2つのポジションの間で、切り替わります。

ウィンドウ・スプリッタ―は、ペインの1つのサイズ(このパターンでは、プライマリー・ペインと呼ばれます。)を表現する値を持っています。スプリッタ―が、その最少値を持っているとき、プライマリー・ペインは、その最少のサイズを持ち、セカンダリー・ペインは、その最大のサイズを持ちます。また、スプリッタ―は、プライマリー・ペインの名前に合致したアクセシブルな名前を持ちます。

例えば、読書アプリケーションを考えてみてください。これは、プライマリー・ペインに目次を表示し、セカンダリー・ペインは、その本のセクションから内容を表示します。2つのペインは、「目次」とラベリングされた垂直なスプリッタ―で区切られています。目次のペインが最大のサイズを持っているとき、そのスプリッタ―は、100の値を持ち、目次が、完璧に折りたたまれているとき、スプリッタ―は0の値を持ちます。

「プライマリー・ペイン」という用語は、その重要性や、ペイン内のコンテンツの目的を、表すわけでは無いことに注意してください。

ウィンドウ・スプリッタ―のウィジェットの例を開発する作業は、「issue 130」で、追跡されます。

キーボード・インタラクション

  • 左矢印: 垂直なスプリッタ―を左に移動します。
  • 右矢印: 垂直なスプリッタ―を右に移動します。
  • 上矢印: 水平なスプリッタ―を上に移動します。
  • 下矢印: 水平なスプリッタ―を下に移動します。
  • エンター: もし、プライマリー・ペインが折りたたまれていなければ、ペインを折りたたみます。もし、ペインが折りたたまれていれば、スプリッタ―をその前の位置に戻します。
  • ホーム (任意): プライマリー・ペインが可能な範囲で最少サイズとなる位置に、スプリッタ―を移動します。これは、プライマリー・ペインを完璧に折りたたんでかまいません。
  • エンド (任意): プライマリー・ペインが可能な範囲で最大サイズとなる位置に、スプリッタ―を移動します。これは、セカンダリー・ペインを完璧に折りたたんでかまいません。
  • F6 (任意): ウィンドウ・ペインを通じて、循環します。
注意

固定サイズのスプリッターは、矢印キーの実装を省略します。

WAI-ARIAのRole、States、Property

  • フォーカス可能なスプリッタ―として機能する要素は、role=separatorを持ちます。
  • セパレーターの要素は、aria-valuenowプロパティを、セパレーターの現在の位置を示す10進数の値にセットします。
  • セパレーターの要素は、aria-valueminプロパティを、プライマリー・ペインが最小サイズとなる位置を示す10進数の値にセットします。通常、これは0です。
  • セパレーターの要素は、aria-valuemaxプロパティを、プライマリー・ペインが最大サイズとなる位置を示す10進数の値にセットします。通常、これは100です。
  • もし、プライマリー・ペインに目に見えるラベルがあるなら、それは、セパレーター要素のaria-labelledbyで参照されます。さもなければ、セパレーターの要素は、aria-labelで提供されるラベルを持ちます。
  • セパレーターの要素は、プライマリー・ペインを参照するaria-controlsを持ちます。

4. ランドマーク・リージョン

ARIAランドマークroleは、ウェブページの構成と構造を特定するための協力な方法を提供します。ページのセクションを分類しラベリングすることで、レイアウトを通じて視覚的に伝えられる構造についての情報が、プログラム的に表現されることを可能にします。スクリーン・リーダーは、ページの重要なセクションへのキーボードナビゲーションを提供するために、ランドマークroleを利用します。また、ランドマーク・リージョンは、「スキップ・リンク」の目標として使用され、キーボード・ナビゲーションを拡張するためにブラウザの拡張機能によって使用されます。

支援技術のユーザーがページのレイアウトの意味を理解することを簡単にするために、HTML5の領域区分の要素やARIAランドマークroleが、どのように使われるのかを、このセクションは説明します。

4.1 HTML5の領域区分の要素

いくつかのHTML5領域区分要素は、自動的にARIAランドマーク・リージョンを生成します。そして、ページの論理的なビューを、支援技術のユーザーに提供するためには、HTML5領域区分要素を使うことの効果を理解することが重要です。HTML5要素のroleとのマッピングに関するより詳しい情報は、「ARIA in HTML(http://www.w3.org/TR/html-aria/)」を参照してください。

HTML5領域区分要素に関するデフォルトのランドマークrole
HTML5要素 デフォルト・ランドマークrole
aside complementary(=補足の)
footer contentinfobody要素のなかで)
header bannerbody要素のなかで)
main main
nav navigation
section regionaria-labelledbyaria-labelを使っているアクセシブルな名前を持っているとき)

4.2 ランドマーク・デザインの一般原則

ページのすべての知覚可能な内容を、ランドマーク・リージョンの一つに含め、それぞれのランドマーク・リージョンに意味的に重要なroleを提供することは、支援技術のユーザーが、彼らの必要性に関連した情報を見逃すことのないようにする最も効果的な方法の一つです。

ステップ1: 論理構造を特定してください。

ステップ2: それぞれのエリアにランドマークroleを割り当ててください。

ステップ3: ラベル・エリア

4.3 ランドマーク・ロール

4.3.1 バナー

bannerランドマークは、ウェブサイト内のそれぞれのページの最初で、サイトのコンテンツの方向性を示します。通常、サイトのコンテンツの方向性を示す内容としては、サイト・スポンサーのロゴやマーク、そのサイト独自の検索ツールなどとなります。バナーは、たいてい、ページの一番上に存在し、通常、横幅全部に跨ります。

  • 各ページは、1つのbannerランドマークを持つことが可能です。
  • bannerランドマークは、トップ・レベルのランドマークであるべきです。
  • ページが、入れ子になったdocument、かつ/または、applicationのroleを含む場合(例えば、通常、iframeframe要素の使用によります)、それぞれのdocumentapplicationのroleは、一つのbannerランドマークを持ってかまいません。
  • もし、一つのページが、複数のbannerランドマークを含むなら、そのそれぞれは、固有のラベルを持っているべきです(「ステップ3: ラベル・エリア」を見てください。)。
HTML5テクニック
  • コンテキストがbody要素であるとき、HTML5の header要素は、bannerランドマークを定義します。
  • 以下の要素のいずれかの子孫であれば(HTML Accessibility Mappings(HTML Accessibility API Mappings(https://w3c.github.io/html-aam/)[HTML-AAM]))を見てください。)、HTML5のheader要素は、bannerランドマークとは考えられません。
    • article
    • aside
    • main
    • nav
    • section
ARIAテクニック

もし、HTML5の header要素テクニックが使われていないなら、bannerランドマークを定義するために、role="banner"属性を使うべきです。

Bannerランドマークの例

4.3.2 Complementary(補足)

complementaryランドマークは、ドキュメントを支援するセクションで、DOM階層構造でメインの内容と同じレベルで補足するように設計されていますが、メインの内容から切離れても重要なままで残っています。

  • complementaryランドマークは、トップ・レベルのランドマークであるのが望ましい(例えば、他のどのランドマークにも含まれていません。)
  • もし、補足的な内容が、メインの内容と関連しないなら、より一般的なrole(例えば、region)が、割り当てられるべきです。
  • もし、一つのページが、複数のcomplementaryランドマークを含むなら、そのそれぞれは、固有のラベルを持っているべきです(「ステップ3: ラベル・エリア」を見てください。)。
HTML5テクニック

complementaryランドマークを定義するために、HTML5のaside要素を使います。

ARIAテクニック

HTML5のaside要素テクニックが使われないなら、complementaryランドマークを定義するために、role="complementary"属性を使ってください。

Complementaryランドマークの例

4.3.3 Contentinfo

contentinfoランドマークは、ウェブサイト内の各ページの一番下(通常は、「フッター」と呼ばれ、著作権情報やプライバシー・ポリシー、アクセシビリティ・ポリシーのような情報を含みます)にある共通情報を、識別する方法です。

  • 各ページは、一つのcontentinfoランドマークを持つことができます。
  • contentinfoランドマークは、トップ・レベルのランドマークであるべきです。
  • ページが、入れ子になったdocument、かつ/または、applicationのroleを含む場合(例えば、通常、iframeframe要素の使用によります)、それぞれのdocumentapplicationのroleは、一つのcontentinfoランドマークを持ってかまいません。
  • もし、1つのページが、複数のcontentinfoランドマークを含むなら、そのそれぞれは、固有のラベルを持っているべきです(「ステップ3: ラベル・エリア」を見てください。)。
HTML5テクニック
  • コンテキストがbody要素であるとき、HTML5の footer要素は、contentinfoランドマークを定義します。
  • 以下の要素のいずれかの子孫であれば(HTML Accessibility Mappings(HTML Accessibility API Mappings(https://w3c.github.io/html-aam/)[HTML-AAM])を見てください。)、HTML5の footer要素は、contentinfoランドマークとは考えられません。:
    • article
    • aside
    • main
    • nav
    • section
ARIAテクニック

もし、HTML5の footer要素テクニックが使われていないなら、contentinfoランドマークを定義するために、role="contentinfo"属性を使うべきです。

Contentinfoランドマークの例

4.3.4 Form

formランドマークは、全体としてフォームを形成する項目やオブジェクトの集まりを含む領域であることを示します。他に適する名前のランドマーク(例えば、メインや検索など)が存在しないときに使用します。

  • そのフォームが、検索機能のために使用されるときは、formランドマークの代わりに、searchランドマークを使用します。
  • formランドマークは、ユーザがそのフォームの目的を理解しやすくなるようなラベルを持つべきです。
  • formランドマークのラベルは、全てのユーザに見えるべきです(例えば、h1-h6要素)。
  • もし、1つのページが、複数のformランドマークを含むなら、そのそれぞれは、固有のラベルを持っているべきです(「ステップ3: ラベル・エリア」を見てください。)。
  • 可能であるときはいつも、HTMLドキュメントのformランドマークに含まれたコントロールは、以下のようなネイティブのホスト・セマンティックを使うべきです。:
    • button
    • input
    • select
    • textarea
HTML5テクニック

HTML5のform要素が、アクセシブルな名前(例えば、aria-labelledbyaria-labeltitle)を持っているときは、HTML5のform要素がformランドマークを定義します。

ARIAテクニック

role="form"を、ページの中の領域を特定するために使用します。個々のフォーム・フィールドを特定するためには、使わないでください。

formランドマークの例

4.3.5 Main

mainランドマークは、ページのメインの内容を特定します。

  • 各ページは、一つのmainランドマークを持つべきです。
  • mainランドマークは、トップ・レベルのランドマークであるべきです。
  • ページが、入れ子になったdocument、かつ/または、applicationのroleを含む場合(例えば、通常、iframeframe要素の使用によります)、それぞれのdocumentapplicationのroleは、一つのmainランドマークを持ってかまいません。
  • もし、1つのページが、複数のmainランドマークを含むなら、そのそれぞれは、固有のラベルを持っているべきです(「ステップ3: ラベル・エリア」を見てください。)。
HTML5テクニック

mainランドマークを定義するために、HTMLのmain要素を使用します。

ARIAテクニック

もし、HTML5のmain要素のテクニックが使用されていないなら、mainランドマークを定義するためにrole="main"属性を使用してください。

mainランドマークの例

4.3.6 Navigation

Navigationランドマークは、ウェブサイトやページ内容のナビゲーションのために使用されるリンク・グループ(例えばリンク・リスト)を特定する方法を提供します。

  • もし、1つのページが、複数のnavigationランドマークを含むなら、そのそれぞれは、固有のラベルを持っているべきです(「ステップ3: ラベル・エリア」を見てください。)。
  • もし、navigationランドマークが、そのページに別のnavigationランドマークとして、同じセットのリンクを持っているなら、それぞれのnavigationランドマークに同じラベルを使用します。
HTML5テクニック

navigationランドマークを定義するために、HTML5のnav要素を使用します。

ARIAテクニック

もし、HTML5のnav要素のテクニックが使用されていないなら、navigationランドマークを定義するために、role="navigation"属性を使用します。

navigationランドマークの例

4.3.7 Region(領域)

regionランドマークは、そのページの中で、ユーザをナビゲートすることが非常に重要な内容を含む、知覚可能なセクションです。

  • regionランドマークは、ラベルを持たなければなりません。
  • もし、1つのページが、複数のregionランドマークを含むなら、そのそれぞれは、固有のラベルを持っているべきです(「ステップ3: ラベル・エリア」を見てください。)。
  • 名付けられたランドマークが適切に内容を説明していないようなコンテンツを識別できるように、regionランドマークを使うことができます。
HTML5テクニック

HTML5のsection要素は、アクセシブルな名前(例えば、aria-labelledbyaria-labeltitleregionランドマークを定義します。

ARIAテクニック

HTML5のsection要素のテクニックが使用されていないなら、regionランドマークを定義するために、role="region"属性を使用します。

regionランドマークの例

5. キーボード・インターフェースの開発

ネイティブのHTMLのform要素と異なり、ブラウザは、ARIAでアクセシブルにしたグラフィカル・ユーザー・インタフェース(GUI)のコンポーネントのためには、キーボード・サポートは提供しません。; 制作者は、自分のコードのために、キーボード・サポートを提供しなければなりません。 このセクションは、ウェブ・ページの機能(メニューやグリッドなど)やインタラクティブなコンポーネント(ツールバーやダイアログなど)を、キーボードで操作可能にするための原則や方法を説明します。 フォーカスの管理の基礎と一緒に、このセクションは、キーボードに頼っている人々に、それ以外のデバイスで利用可能な体験と同じくらい効率的で楽しいと感じるような体験を提供することを目指して、ガイダンスを提供します。

このセクションは以下をカバーします:

  1. ARIAデザイン・パターンで使用されている一般的なフォーカス動作の基本原理の理解。
  2. 視覚的なフォーカス、予測可能なフォーカスの動作、キーボード・フォーカスと選択状態の識別の維持。
  3. コンポーネント間のキーボード・フォーカスの動作の管理(例えば、タブシフト + タブが押されたときのフォーカスの動作)。
  4. 複数のフォーカス可能な要素を含むコンポーネント内でのキーボード・フォーカスの動作の管理(例えば、ラジオ・ボタン、メニュー、リストボックス、ツリー、グリッドのようなウィジェットの中でのプログラムによるフォーカス提示の2つの異なる方法について、など)。
  5. ディセイブルのインタラクティブ要素を、フォーカス可能とするときの判断。
  6. キーボード・ショートカットの割り当てと明確化。支援技術、ブラウザ、OSでのキーボード・コマンドの競合の問題を回避する方法を含む。

5.1 基本的なフォーカス・ナビゲーションの慣習

ARIA roles, states, propertiesは、マイクロソフトのWindows、マックOS、GNOMEを含む人気のデスクトップのGUIコンポーネント間でシェアされたアクセシビリティの動作や機能を形づくります。同様に、ARIAデザイン・パターンは、それらのプラットフォームからユーザーの期待とキーボードの慣習を借り、ウェブ全体でキーボード・インタフェースの学習や効率的な操作を簡単にする目的で、共通の慣習を着実に取り込んでいきます。

ウェブ・ページがアクセシブルであるために、全てのインタラクティブな要素は、キーボードで操作できなければなりません。 加えて、ARIAデザイン・パターンで記述されているような伝統的な共通のGUIキーボード・インタフェースになっている一貫したアプリケーションは、特に、支援技術のユーザーにとって重要です。 例えば、ツリーを操作しているスクリーン・リーダー・ユーザーを考えてください。 ちょうど、親近感のあるビジュアル・スタイルが、ユーザーがマウスでツリーの下階層を表示する方法を見つける手助けとなるように、ARIA属性は、ツリーに音を与え、デスクトップのツリーを感じさせます。 そして、スクリーン・リーダーのユーザーは、右矢印キーを押すことが折りたたまれたノードを開くことを、普通に予測するでしょう。 スクリーン・リーダーは、その要素がツリーであることを知っているので、初心者のユーザーに操作方法を説明することもできます。 同様に、音声認識ソフトウェアは、ツリーを展開したり折りたたんだりするためのコマンドを実行することが出来ます。なぜなら、音声認識ソフトウェアは、その要素をツリーとして認識し、適切なキーボード・コマンドを実行することができるからです。 ARIAのツリー・パターン(「3.24 ツリー・ビュー(3.24 Tree View)」)に記載されているGUIキーボードの一般的な動作を、ツリーに実装すれば、このすべてが可能です。

すべてのプラットフォームを通じて共通となる最も重要で一般的なキーボード・ナビゲーションは、タブシフト + タブが、フォーカスを一つのUIコンポーネントから別のコンポーネントへ移動させることです。この間、他のキー(主に矢印キー)は、複数のフォーカス可能な要素を含むコンポーネントの内側でフォーカスを移動させます。 タブを押すときにフォーカスが辿る経路は、タブ・シーケンスやタブ・リングとして知られています。

複数のフォーカス可能な要素を含むUIコンポーネントの一般的な例は、ラジオ・グループ、タブ・リスト、メニュー、グリッドです。 例えば、ラジオ・グループは複数のラジオ・ボタンを含み、それぞれ、フォーカスが可能です。 しかしながら、ラジオボタンの1つだけが、タブ・シーケンスに含まれています。 タブを押すことで、グループのラジオ・ボタンにフォーカスを移動した後、矢印キーを押すと、グループ内のラジオ・ボタンの間で、フォーカスが移動します。そして、タブを押すと、ラジオ・グループからフォーカスが外れて、タブ・シーケンス内での次の要素に移動します。

ARIAの仕様は、コンポジット(合成)・ウィジェット(「composite(abstract role)(http://www.w3.org/TR/wai-aria-1.1/#composite)」)として、複数のフォーカス可能な要素を含む離散的なUIコンポーネントについて言及します。 コンポジットの中のフォーカス移動をコントロールするプロセスが、フォーカス管理と呼ばれます。 以下は、フォーカス管理をデモする実装例を含んだARIAデザイン・パターンです。:

5.2 認識できて予測できるキーボード・フォーカス

このセクションを完成させるための作業は、「issue 217」によって追跡されます。

キーボードで操作するとき、良い経験となる2つの基礎は、キーボード・フォーカスの位置を簡単に見つけられることと、ナビゲーション・キーを押した後でフォーカスがどこに移動したかを見つけられることです。 以下の要件が、ウェブ・ページがユーザーにこれらの能力を提供する範囲へ、影響を及します。

  1. フォーカス・インジケータ―の視認性: ユーザは、ビジュアル・デザインの他の特徴と、キーボード・フォーカス・インジケーターを簡単に区別できる必要があります。ちょうど、マウス・ユーザが、マウス・ポインタを見つける手助けとして、マウスを動かす可能性があるように、キーボード・ユーザは、動作を見るためにナビゲーション・キーを押す可能性があります。もし、フォーカスの移動に対応した視覚的な変化が、小さければ、多くのユーザーはフォーカスの軌跡を見失って、操作することも難しくなるでしょう。制作者は、ブラウザが提供するデフォルトのフォーカス・インジケータに頼るようにアドバイスされます。もし、デフォルトを書き換えるなら...
  2. フォーカスの保持: アクティブな(document.activeElementが、Nullで無いか、body要素で無い)ユーザー・インターフェース内に常にコンポーネントが存在し、アクティブな要素がビジュアル・フォーカス・インジケータを持っていることが、不可欠です。制作者は、現在のアクティブな要素に影響するイベントを管理する必要があり、フォーカスは、目に見えた状態のまま、論理的に移動します。例えば、もし、ユーザーが、ダイアログを閉じたり、リストから項目を削除するような破壊的な操作を実施するなら、そのアクティブな要素は、DOMから、隠されるか、削除されるかもしれません。もし、それらのイベントが、ダイアログを開くボタンにフォーカスをセットしたり、削除された項目の次のリストの項目にフォーカスをセットするように、管理されていなければ、ブラウザはフォーカスをbody要素に移動し、実際に、ユーザー・インタフェース内でフォーカスを見失います。
  3. 動きの予測可能性: ナビゲーション・キーが押された後でフォーカスがどこに配置されたかをユーザーがどれくらい簡単に予測できるが、キーボード・インタフェースのユーザビリティに強く影響を及ぼします。予測可能性を最適化するようないくつかの可能なアプローチは、以下を含みます。:
    • ページの言語の読む順序に従うパターンでフォーカスを移動します。 例えば、左から右の順の言語の場合、左から右、そして上から下へフォーカスを移動するようなタブ・シーケンスを生成します。
    • フォーカスを他のセクションに移動する前に、タブ・シーケンスに、ページのセクションの全ての要素を組み込みます。 例えば、左サイド・バー、センター領域、右サイド・バーにコンテンツを含む複数の列のページの場合、フォーカスがセンター領域の最初のフォーカス可能な要素に移動する前に、左のサイドバーの全ての要素をカバーするように、タブ・シーケンスを構築します。
    • タブ・シーケンス内で2つの連続した要素間の距離が顕著であるとき、戻ったと知覚されるような動きは割けます。 例えば、左から右への言語のページで、メインのコンテンツの右下の最後の要素から、左のサイドバーの一番上の要素にジャンプすることは、特に、狭い視野のユーザーには予測することができなくなり、追跡するのが難しくなってしまいます。
    • サイト全体で、一貫したパターンに従います。 似たページが、似たフォーカスの動きのパターンを持っているとき、キーボードの経験は、より予測可能になります。
    • 以下のようなケースを除き、ページが読み込まれるときは、フォーカスを初期化しません。:
      • そのページが提供する機能が、ページが読み込まれた後で、ほとんどすべてのユーザーが直ぐに使う、単一かつ主要な機能である場合。
      • どんなユーザーも、よくそのページを使用する可能性がある場合。

5.3 フォーカス 対 選択、そして、二重フォーカスの知覚

時折、ページ内の2つの要素が同時にフォーカスを持っているように見えることがあるかもしれません。 例えば、複数選択のリスト・ボックスで、一つのオプションが選択されているとき、それは灰色になっているかもしれません。 しかし、フォーカス・インジケータは、まだ、他のオプションに移動することができて、選択することもできるかもしれません。 同様に、ユーザーがタブリストでタブをアクティブにするとき、選択された状態がタブにセットされ、見た目は変化します。 しかしながら、ユーザはまだ操作することができます。そのタブがその選択された見た目と状態を保持したまま、フォーカス・インジケータをページの別の場所に移動することができます。

フォーカスと選択は、まったく異なります。 キーボード・ユーザーの視点からは、フォーカスはポインタで、マウス・ポインタのようなものです。それは、ナビゲーションの経路を追跡します。 いつの場合もフォーカスは、一つの位置にしか存在せず、全ての操作が、そのフォーカスの位置で実施されます。 一方で、選択は、リスト・ボックス、ツリー、タブリストのようないくつかのウィジェットで、実行される操作です。 もし、ウィジェットが単一選択のみをサポートしているなら、1つの項目しか選択されず、多くの場合、選択状態は、単に、フォーカスがウィジェットの中を移動するとき、フォーカスに追随するでしょう。 つまり、いくつかのウィジェットでは、フォーカスを動かすと、選択操作も実行することになります。 しかしながら、ウィジェットが複数選択をサポートするなら、一つ以上の項目が選択状態になり、フォーカスを移動させるキーは選択操作を実行しません。 いくつかの複数選択のウィジェットは、フォーカスの移動と選択を変更することの両方のキー・コマンドをサポートしますが、それらのキーは、普通のナビゲーション・キーとは異なっています。 最終的に、選択された要素が含まれるウィジェットからフォーカスが離れるとき、選択状態は、維持されたままとなります。

開発者の視点からは、違いはシンプルです。フォーカスのある要素は、アクティブな要素(document.activeElement)です。 選択された要素は、aria-selected="true"となっている要素です。

フォーカスと選択状態に関して、デザイナーと開発者にとって最も重要な問題は以下になります。:

5.4 選択を自動的にフォーカスに追随させるという決断

タブリストや単一選択リストボックスのような、一つの要素だけが選択されているようなコンポジット・ウィジェットの場合、フォーカスを移動することは、フォーカスのある要素を選択された要素にすることにも、なります。 これは、「フォーカス追随の選択」と呼ばれます。フォーカス追随の選択は、しばしば、ユーザーにとって有益となりますが、いくつかの状況では、アクセシビリティに非常に有害になります。

例えば、タブリストでは、選択状態が、表示されているパネルを示すために使われます。 そして、タブリストで選択状態がフォーカスに追随するとき、フォーカスをタブからタブへ移動させることは、自動的に、表示されるパネルを変更することになります。 もし、パネルの内容が、DOMの中に存在するなら、新しいパネルを表示することは、ほぼ瞬時に起こっています。 6つのタブのうち4番目のタブを表示したいキーボード・ユーザーは、右矢印キーを3回、素早く押すことで、表示することが出来ます。 そして、それらを通じたナビゲーションによってタブのラベルを理解するような、スクリーン・リーダーのユーザーは、少しも待たずに効率的にリスト全体を読み通すことができます。

しかしながら、もし、新しいパネルを表示することが、ネットワーク・リスエストと、場合によってはページリフレッシュを引き起こすなら、自動的なフォーカスの選択の効果は、キーボードとスクリーン・リーダーのユーザーにとって破壊的な経験をもたらす可能性があります。 この場合、ユーザーは、フォーカスのそれぞれの動作で結構な待ち時間を経験することになるので、4番目のタブを表示したり、リストを読み通すことは、退屈で時間を消費するタスクになってしまいます。 さらに、もし、新しいタブを表示することが、ページをリフレッシュするなら、ユーザーは新しいページが読み込まれるのを待っているだけでなく、タブ・リストにフォーカスが戻ることも待たなければなりません。

選択がフォーカスに追随しないとき、ユーザーは、エンタースペースを押して、要素の選択状態を変更します。

5.5 コンポーネントの間のキーボードナビゲーション(タブ・シーケンス)

5.1 基本的なフォーカス・ナビゲーションの慣習(5.1 Fundamental Keyboard Navigation Conventions)」で説明したように、全てのインタラクティブなUIコンポーネントは、キーボードで利用できる必要があります。これは、タブ・シーケンスにそれらを含めるか、タブ・シーケンスの中のコンポーネントからそれらをアクセシブルにする(例えば、コンポジット・コンポ―ネントの一部)かのどちらかで、最も上手く実現されます。このセクションはタブ・シーケンスの構築と管理を扱い、それにつづくセクションが、コンポーネントに含まれているフォーカス可能な要素をキーボードでアクセシブルにすることをカバーします。

HTMLのtabindexSVGのtabindex属性は、タブ・シーケンスに要素を追加したり、要素を取り除いたりするために使用することが出来ます。 また、tabindexの値は、タブ・シーケンスの順序に影響を及ぼすことができます。製作者は、この目的のためには、tabindexを使うわないよう、強くアドバイスされていますが...

macOSの場合を除き、HTMLでは、デフォルトのタブ・シーケンスは、リンクとHTMLのform要素のみを含みます。macOSの場合、form要素だけが含まれます。macOSシステムの設定には、タブ・キーで、全てのフォーカス可能な要素にフォーカスを移動できるようにするキーボード設定があります。

タブ・シーケンスの要素のデフォルトの順番は、DOMの要素の順番になります。 また、DOMの順序は、スクリーン・リーダーの読み上げの順番も、決定します。 キーボードのタブ・シーケンスとスクリーン・リーダーの読み上げ順序を、「5.2 認識できて予測できるキーボード・フォーカス(5.2 Discernible and Predictable Keyboard Focus)」で記述したように、論理的かつ、予測可能に、調整を維持し続けることは、非常に重要です。 また、現在すべてのブラウザで利用可能な読み上げ順序による整列を維持している間、タブ・シーケンスの順番を操るもっとも確実な方法は、DOMの要素を再アレンジすることです。

tabindex属性の値には、以下の効果があります。

tabindexが存在しないか、または、正しい値がありません:
要素には、デフォルトのフォーカスの動作があります。 HTMLの場合、HREF属性をもっているフォーム・コントロールとアンカーだけが、タブ・シーケンスに、含まれています。
tabindex="0"
その要素は、DOM内の位置に基づき、タブ・シーケンスに含まれます。
tabindex="-1"
その要素は、タブ・シーケンスに含まれませんが、element.focus()でフォーカスが可能です。
tabindex=[1以上32767以下の整数]:
制作者は、これらの値を使わないように強く、アドバイスされています。 その要素は、tabindexの値に基づき、サブ・シーケンス内に配置されます。 tabindexの値が0の要素と、デフォルトでフォーカス可能な要素は、tabindexが1かそれ以上のtabindexの要素の後で、シーケンスの中に配置されます。

5.6 コンポーネントの中でのキーボード・ナビゲーション

5.1 基本的なフォーカス・ナビゲーションの慣習(5.1 Fundamental Keyboard Navigation Conventions)」で説明されるように、タブ・シーケンスには、コンポジット・UI・コンポーネントのフォーカス可能な要素を一つだけ、含むべきです。 いったん、コンポジットなコンポーネントがフォーカスを持てば、ユーザーは、タブシフト+タブ以外のキーで、フォーカス可能な要素間でフォーカスを移動させることができるようになります。 制作者は、コンポジットの中で、どのキーでフォーカスを移動できるようにするのか、自由に選択することができますが、「3. デザイン・パターンとウィジェット(3. Design Patterns and Widgets)」でデモンストレーションしている一般的なGUIオペレーティング・システムの似たコンポーネントに組み込まれているのと同じキーを使うことが、アドバイスされています。

タブのイベントの結果としてフォーカスを受け取るとき、コンポジットのどこにフォーカスをセットするかは、コンポジットの種類によります。通常、以下のうちの一つになります。

以下のセクションでは、コンポジット要素の中でのフォーカス管理について、2つの戦略を説明します。ロービング・タブインデックスを作成する方法と、aria-activedescendantプロパティを使う方法の2つです。

5.6.1 ロービング・タブインデックスを使ったコンポーネント内でのフォーカス管理

コンポジット・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ではなく、むしろ、ロービング・タブインデックスを使用するメリットは、ユーザー・エージェントが、新しくフォーカスを受け取った要素を、ビューの中にスクロールすることです。

5.6.2 aria-activedescendantを使用するコンポジットでのフォーカス管理

もし、コンポーネントのコンテナが、aria-activedescendantをサポートするARIAのroleを持っているなら、tabindex属性を操作し、コンテナ内のフォーカス可能な要素間でDOMのフォーカスを動かすことは、不要になります。代わりに、コンテナ要素だけが、タブシーケンスに含まれる必要があります。コンテナにDOMフォーカスがあるとき、コンテナの上のaria-activedescendantの値は、支援技術に、ウィジェット内でアクティブになっている要素を、伝えます。DOMフォーカスが、aria-activedescendantプロパティを持つ要素に存在したとしても、支援技術は、関連する要素を、フォーカスのある要素としてアクティブとみなすことになります。そして、aria-activedescendantの値が変わるとき、支援技術は、DOMフォーカスが実際に移動したときと同じように受け取るフォーカス変化のイベントを受け取ります。

フォーカスを管理するaria-activedescendantメソッドを使うステップは、以下のようになります。

  • aria-activedescendantをサポートする役割を持っているコンテナ要素が、読み込まれたり、生成されるときは、以下のことを確実にしてください。:
  • コンテナ要素が、DOMフォーカスを受け取ったとき、アクティブな要素に視覚的なフォーカス・インジケータを描画し、アクティブな要素が確実にビューの中にスクロールされるようにします。
  • コンポジット・ウィジェットが、フォーカスを含み、ユーザーが、ウィジェット内でフォーカスを動かすようなナビゲーションキー(矢印キーのような)を押すとき:
    • 支援技術にアクティブとして報告されるべき要素と関連しているコンテナのaria-activedescendantの値を変えます。
    • 視覚的なフォーカスのインジケータを動かします。もし、必要なら、アクティブな要素をビューの中にスクロールします。
  • もし、ユーザーが次にタブシフト + タブでコンポジットにフォーカスを移動するとき、デザインが特定の要素にフォーカスをあてることを呼び出すなら、コンポジットがフォーカスを失うときに、aria-activedescendantがそのターゲットの要素を参照しているかどうかチェックします。もし、そうなっていなければ、aria-activedescendantがそのターゲットの要素を参照するようにセットします。

aria-activedescendantの仕様は、aria-activedescendant属性をもつフォーカスのある要素と、その属性の値によってアクティブとして参照される要素の間のDOMリレーションシップに、重要な制限を配置しています。以下の3つの条件の1つを満たさなければなりません。

  1. アクティブとして参照される要素は、フォーカスのある参照要素のDOM子孫です。
  2. フォーカスのある参照要素は、アクティブとして参照される要素のIDを含むaria-ownsプロパティについて指定された値を持ちます。
  3. フォーカスのある参照要素は、role=textboxを持ち、aria-controlsプロパティを持ちます。aria-controlsプロパティは、aria-activedescendantと以下のいずれかをサポートするroleのある要素を参照します。:
    1. アクティブとして参照される要素は、コントロールされる要素の子孫です。
    2. コントロールされる要素は、アクティブとして参照される要素のIDを含むaria-ownsプロパティについて指定された値を持ちます。

5.7 ディセイブルのコントロールのフォーカス

デフォルトで、ディセイブルのHTMLのinput要素は、タブ・シーケンスから削除されます。ほとんどの場合、通常、ディセイブルのインタラクティブ要素は、フォーカスできなくなることが、期待されます。しかしながら、ディセイブルの要素がフォーカス可能であるということが、一般的という場合もいくつかあります。特に、コンポジット・ウィジェットの中で存在します。例えば、「3.15 メニュー、もしくは、メニュー・バー(3.15 Menu or Menu bar)」のパターンで、デモンストレーションされているように、矢印キーでメニューをナビゲーションするとき、ディセイブルの項目は、フォーカス可能です。

ディセイブルの要素から、フォーカスを取り除くことは、ユーザーに、利益と不利益の両方を提供することが可能です。キーボード・ユーザーがディセイブルな要素をスキップできるようにすると、タスクの完了までに必要な多くのキー押下を減らします。しかしながら、ディセイブルな要素へのフォーカス移動を防ぐことは、フォーカスの移動で「見ている」スクリーン・リーダー・ユーザーから、それらの存在を隠してしまうことになります。

制作者は、ディセイブルな要素にフォーカスをあてることについて、一貫した慣習を採用するように推奨されます。このガイドの例は、以下の慣習を採用します。これらは、両方の一般的な方法を反映し、競合する項目のバランスをとることを試みます。

  1. 利用可能な時にタブ・シーケンスに存在するエレメントに関しては、ディセイブルのとき、タブ・シーケンスからそれらを取り除きます。
  2. 以下のコンポジット・ウィジェット要素に関しては、ディセイブルのときも、フォーカス可能を維持します。:
  3. ツールバーに含まれた要素は、もし、見つけやすさが心配なら、フォーカス可能にします。 ここに、この判断を助けるための2つの例があります。
    1. リストの項目を移動、削除、追加するためのボタンがツールバーにあって、「Up」「Down」「追加」「削除」のボタンが含まれているとします。リストの最初の項目が選択されているとき、「Up」ボタンはディセイブルになり、フォーカスは不可能とします。「Down」ボタンの存在があれば、「Up」ボタンの見つけやすさは、心配する必要はありません。
    2. 編集ソフトのツールバーは、クリップボードが空だったり、クリップボードの現在の値に機能を適用できずディセイブルになるようなスペシャル・スマート・貼り付け機能を含んでいます。もし、それらの機能を見つける能力が、主にツールバーでのそれらの存在によるものなら、ディセイブルのボタンをフォーカス可能にし続けることは、役に立っているのかもしません。

キーボード・フォーカスの経路にディセイブルな要素を含む影響を緩和する一つのデザイン・テクニックは、「5.9 キーボード・ショートカット(5.9 Keyboard Shortcuts)」に記載したような適切なキーボード・ショートカットを採用することです。

5.8 共通の機能のためのキー・アサインの慣習

以下のキー・アサインは、慣習上、関連している機能が適切であれば、どんな状況でも仕様することが出来ます。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

5.9 キーボード・ショートカット

効果的にデザインされていれば、要素にフォーカスをあてたり、ウィジェットをアクティブにしたり、その両方を実施するようなキーボード・ショートカットは、ページやサイトでよく使われる機能のユーザビリティを大幅に高めることができます。このセクションは、いくつかのキーボード・ショートカット・デザインと、その効果に最も影響を及ぼす実装要件のいくつかを扱います。以下のようなものを含みます。:

  1. キーボード・ショートカットがどのようにキーボード・インタフェースを補強し、特定のショートカットがフォーカスを移動するのか、機能を実行するのか、その両方なのかを、理解します。
  2. キー・アサインを生成し、支援技術、ブラウザー、オペレーティング・システムで、アサインが衝突することを避けます。
  3. キー・アサインを公表し記録します。

5.9.1 キーボード・ショートカットの範囲と動作のデザイン

このセクションは、どの要素と機能にキーボード・ショートカットをアサインし、どのような動作をそれぞれのショートカットに提供するかについて決定するときの要件を、以下に説明します。:

  1. ナビゲーションを通じた発見を保証します。キーボード・ショートカットは、標準キーボード・アクセスを置き換えるのではなく、機能アップします。
  2. 以下の動作から、効果的に選択します。:
    1. ナビゲーション:フォーカスを要素に移動します。
    2. アクティベーション:フォーカスを持たず、目に見えていない要素と関連している操作を実施します。
    3. ナビゲーションとアクティベーション:フォーカスを要素に移動することと、アクティベートすることの両方を実施します。
  3. 効率性と認知的負荷のバランスをとること:あまりに多くのショートカットが認知的な不可を増加させ、経験を見だす可能性がある一方で、ショートカットの不足は、効率性を減少させる可能性があります。
5.9.1.1 ナビゲーションによるベーシック・アクセスの確保

キーボード・ショートカットをアサインする前に、ショートカットをアサインする機能を、キーボード・ショートカット無しでも、確実にキーボード・アクセスを可能にしておくことが重要です。言い換えれば、キーボード・ショートカットのターゲットとなりうるすべての要素は、以下に記載したメソッドを使ったキーボードで、フォーカス可能になっている必要があります。

キーボード・ショートカットは、ナビゲーションによるアクセスの代用としては、使いません。これは、完全なキーボード・アクセスに不可欠です。理由は、以下になります。:

  1. 機能とそのショートカットを見つけやすくする主な手段は、ターゲット要素をフォーカス可能とし、要素自体でキー・アサインを明らかにすることです。
  2. もし、キーボードを頼りにしている人が、インタフェースを使うために必要なキーを学ぶために、ドキュメントを読まなければならないなら、技術的にはそのインタフェースは、いくつかのアクセシビリティ規格を満たすかもしれないが、実際には、そのようなドキュメントが存在することを知っていて、時間の余裕もあり、大切な情報を維持する能力のある一部の人だけにとって、アクセシブルとなっています。
  3. キーボード・インタフェースに依存する全てのデバイスが、キーボード・ショートカットをサポートできるわけではありません。
5.9.1.2 適切なショートカット動作の選択

以下の慣習は、キーボード・ショートカットのために最も有利な動作を理解する助けになるかもしれません。

  • ナビゲーションをより効率的なものにする(例えば、ユーザーが押さなければならないTabや矢印キーの回数を少なくする。)ことが、主目的であるとき、フォーカスを動かします。この動作は、ショートカットを、テキストボックス、ツールバー、コンポジット(リストボックス、ツリー、グリッド、メニューバー)に、割り当てる時、一般的に期待されます。また、この動作は、メイン・コンテンツや補足的なランドマーク・セクションのように、ページのセクションへフォーカスを移動するのにも、役立ちます。
  • 機能のターゲットとなる状況がフォーカスを含むとき、フォーカスを動かすことなく、要素をアクティブにします。この挙動は、コマンドボタンや、メニューからアクセスできる「保存」という選択肢のように、表示されていない要素に関連する機能に対して、最も一般的なものです。例えば、もし、フォーカスが、リストボックスの選択肢に存在し、ツールバーには、選択肢を移動や削除するボタンを含んでいるなら、ユーザーがツールバーの1つのボタンに関してキー・ショートカットを押したとき、リストボックスのフォーカスをそのままにしておくことが、最も有益です。実行された動作の確認を提供し、複数のコマンドの実行をより効率的なものとするので、スクリーン・リーダー・ユーザーには、この動作が、特に重要である場合があります。例えば、スクリーン・リーダー・ユーザーが「Up」ボタンのショートカットを押したとき、フォーカスはそのままなので、ユーザーはリストの中での選択肢の新しい位置を聞くことが出来るでしょう。同様に、ユーザーがオプションを削除するショートカットを押したとき、ユーザーはリストの次のオプションを聞くことができ、すぐにもう一度削除のショートカットを押すかどうか判断できます。
  • ショートカットのターゲットが単一の機能を持ち、その機能の状況がターゲットと同じであるとき、フォーカスを移動し、アクティブにします。ショートカットが、メニューやダイアログを開くボタンや、チェックボックス、ナビゲーションのリンクかボタンにアサインされているとき、この動作は、一般的です。
5.9.1.3 ショートカットを加える場所の選択

このセクションのための内容を作成する仕事は、issue 219で追跡されます。

キーボード・インタフェースを設計するときの最初のゴールは、基本的なキーボード・ナビゲーション・サポートだけを備え、シンプルで、効率的で、操作が直感的であることです。もし、キーボード・インタフェースの基本的な操作が、非効率的であるなら、基本的な設計の問題(次善のレイアウトやコマンド構造のような)を、キーボード・ショートカットを実装することによって、補完しようと努力することでは、ユーザーのフラストレーションを削減できないでしょう。この実用的な意義は、最も上手く設計されたユーザー・インタフェースにおいて、最適なユーザービリティを生み出すためにキーボード・ショートカットでアクセシブルにする必要のある機能のパーセンテージは、あまり高くないということです。多くの簡単なユーザインタフェースでは、キーボード・ショートカットは完全に余計である場合があります。そして、あまりに多くのキーボード・ショートカットのあるユーザー・インタフェースでは、過剰なショートカットは、最も役に立つ機能を、より思い出し難くするという認知的な負荷を生みだします。

キーボード・ショートカットをアサインする場所を決める時は、以下を考慮してください:

  1. 執筆中です。

5.9.2 キーボード・ショートカットの割り当て

ショートカットに割り当てるキーを選択するときは、考慮すべき要件が非常にたくさんあります。

  • ショートカットを学びやすく、思い出しやすくするために、ニーモニック(例えば、「Save」はコントロール + Sとするなど)を使うか、論理的なパターンや空間的なパターンに従うようにします。
  • 利用可能なキーや、それらの動作についての違い、ニーモニックに影響を及ぼす可能性のある言語の問題を含め、インタフェースをローカライズします。
  • 支援技術、ブラウザ、オペレーティング・システムによって使われるキー割り当ての競合を避け、管理します。

学習と記憶をサポートするキー・ショートカットの体系を設計する方法は、このガイドの範囲を超えています。キー・ショートカットの体系が大きく無ければ、ブラウザのような一般的なソフトウェアから身近なコンセプトを真似ることは、おそらく十分です。同様に、ローカライズが重要である間、それを扱う方法を記載することは、そのトピックに特化された他のリソースに残されています。

このセクションの残りでは、キー割り当ての競合に関連する要件と懸案のバランスをとるためのガイダンスを提供します。もし、キーの割り当てが、ユーザーのオペレーティング・システムやブラウザーや支援技術の機能に割り当てられたキーで競合を引き起こさないなら、それは、通常、理想的なことです。競合は、ユーザーにとって不可欠な機能への効率的なアクセスをブロックすることになり、競合の完全な嵐が、ユーザーを捉えることになります。同時に、意図的な競合が、役に立つといういくつかの事情があります。さらに、多種多様なオペレーティング・システム、ブラウザ、支援技術のキーが提供されており、競合がなくなっていないということを確信することは、ほとんど不可能です。そのため、意図的であろうと、未知であろうとに関わらず、競合の影響を緩和する戦略を採用することも重要です。

注意

以下のセクションでは、メタ・キーは、Windows互換キーボードのWindowsキーと、MacOS互換キーボードのコマンド・キーになります。

5.9.2.1 オペレーティング・システムのキーの競合

アプリケーションとウィンドウの管理や、ディスプレイ、音のコントロールのようなシステム・レベルの機能を実行するキーの競合を避けることは、不可欠です。一般には、以下のタイプの割り当てを控えることで、実現できます。

  1. 修飾キー(Shift、Ctrl、Altなど)+ タブエンタースペースエスケープの組み合わせ。
  2. メタ・キー + 他の全ての単一キーの組み合わせ(例外がありますが、これらのキーは、オペレーティングシステムのバージョンによって変化する可能性があるので、リスクを伴います。)。
  3. Alt + ファンクション・キーの組み合わせ。

さらに、一般に、ブラウザを含むほとんどのアプリケーションがサポートする重要なアプリケーション・レベルの機能がいくつか存在します。これらは以下が有ります。:

  1. ズーム
  2. コピー/ペースト
  3. ... 続きます...
5.9.2.2 支援技術のキーの競合

支援技術は、何千ものキーの割り当てをまとめて取り扱いますが、競合を避けることは、比較的簡単です。その理由は、支援技術が、オペレーティング・システムとアプリケーションの両方で競合を避けるキー割り当ての体系を開発しなければならなかったためです。キー・コマンドを一意に定義する修飾として特定のキーをハイジャックすることで、実現しています。例えば、多くの支援技術は、Caps Lockを、修飾として使用します。

以下のタイプの割り当てに関わらないようにすることで、支援技術をキーの競合から逸らすようにしています。

  1. Caps Lock + キーの他の全ての組み合わせ
  2. Insert + 他のキーの全ての組み合わせ
  3. Scroll Lock + 他のキーの全ての組み合わせ
  4. macOS only: Control+Option + 他のキーの全ての組み合わせ
5.9.2.3 ブラウザのキーの競合

ブラウザのキーボードの体系の中で、かなりの類似性があり、その体系の中のパターンは、均質性を欠いています。その結果、ブラウザのキー割り当ての競合をさけることは、より難しくなっています。競合の影響が、キーボードでアクセス可能なメニューとキーボード・ショートカットのように、ほとんどすべての機能に2つの経路を利用できることによって、ときどきは、緩和されていても、よくつかう機能のショートカットとの競合を避けることは、重要です。以下の機能のショートカットとの競合を避けることに特別な注意を払ってください。:

  1. アドレスか位置のバー
  2. 通知バー
  3. ページ・リフレッシュ
  4. ブックマークと履歴機能
  5. 機能を見つける
5.9.2.4 意図的なキーの競合

キーの競合を避けることは、通常、望ましいのですが、意図的にブラウザの機能と競合することが、許容できる、もしくは、望ましくさえあるという状況があります。これは、以下のように、状況が組み合わさったとき、生じる可能性があります。:

  • ウェブ・アプリケーションには、ブラウザの機能に似ていて、頻繁に使用される機能がある場合です。
  • ユーザーがしばしば、ウェブ・アプリケーションの機能を実行したくなるような場合です。
  • ユーザーがめったにブラウザの機能を実行しないような場合です。
  • ブラウザの機能を使うために、効率的な代替の経路がある場合です。

例えば、フォーカスがエディタにあるときに利用可能な保存機能を考えてください。ほとんどのブラウザが使用するのは…続きます…

6. グリッドとテーブルのプロパティ

グリッドやテーブルを、十分に提示し、説明するためには、グリッド・パターンテーブル・パターンに記述されたroleを使用しているヘッダー、行、セルを解析することに加え、支援技術が、以下を決定可能である必要があります。:

ブラウザは、レンダリングされたDOMにもとづくグリッドやテーブルの行と列の数で、自動的にアクセシビリティ・ツリーを装着します。しかしながら、データ・セットが、それが十分にレンダリングされるには、あまりに大きいというような場合、DOMがグリッドやテーブル全体を含まないという状況が多々あります。さらに、スキップされた列や行とデータがどのようにソートされているかというような、この情報のいくつかは、DOMストラクチャからは伝達されることができません。

以下のセクションは、ARIAがグリッドとテーブルのアクセシビリティのために提供している、以下のプロパティをどのように使うべきか、説明しています。

グリッドとテーブルのプロパティの定義
プロパティ 定義
aria-colcount tablegrid、またはtreegridの列の総数を定義します。
aria-rowcount tablegrid、またはtreegridの行の総数を定義します。
aria-colindex
  • tablegrid、またはtreegridの中での列の総数に対するセルの位置を定義します。
  • 注意: 0で無く、1で開始します。
aria-rowindex
  • tablegrid、またはtreegridの中での行の総数に対するセルの位置を定義します。
  • 注意: 0で無く、1で開始します。
aria-colspan tablegrid、またはtreegridの中で、セルかグリッドセルによって、結合された列の数を定義します。
aria-rowspan tablegrid、またはtreegridの中で、セルかグリッドセルによって、結合だれた行の数を定義します。
aria-sort 行や列のアイテムが昇順か降順でソートされているかどうかを示します。

6.1 aria-rowcountaria-rowindexの使用

DOMストラクチャで示される行の数が、テーブル、グリッド、ツリーグリッドで利用可能な行の総数ではないとき、aria-rowcountプロパティは、利用可能な行の総数を伝えるために利用され、DOMに存在する行のインデックスのリストを識別するために、aria-rowindexプロパティとともに指定されます。

aria-rowcountは、tablegrid、またはtreegridのroleといっしょに、要素に指定されます。その値は、ヘッダーの行を含む、利用可能な行の総数と等しい整数です。もし、行の総数が分からなければ、-1の値を指定してかまいません。-1の値を使用することは、より多くの行が、供給可能なサイズを指定することなく、DOMに含まれていて利用可能であることを示します。

aria-rowcountが、tablegrid、またはtreegridで使用されるとき、aria-rowindexプロパティの値は、その子孫の行のそれぞれで、すべての見出し行も含んで、指定されます。aria-rowindexの値は、以下のような整数です。 :

  1. 1と同じかそれ以上です。
  2. 前のどの行のaria-rowindexの値よりも、大きい。
  3. もし、セルが複数の行を結合しているなら、その結合で最初の行のインデックスにセットします。
  4. 行の総数と同じか、それ以下です。

警告! aria-rowindexの値が無かったり、矛盾していることは、支援技術の動作の効果に打撃を与えるかもしれません。例えば、aria-rowindexに無効な値を指定したり、テーブルのすべての行ではなく、いくつかにそれをセットすることは、スクリーン・リーダーの表の読み上げ機能が、行をスキップしたり、単にその機能を停止する原因となりえます。

以下のコードで、仮想的なクラスのリストを含む表でのaria-rowcountaria-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>
      

6.2 aria-colcountaria-colindexの使用

DOM構造によって示される列の数が、テーブル、グリッド、ツリーグリッドなどで利用可能な列の総数でない場合、aria-colcountプロパティは、利用可能な列の総数を伝えるために使用し、DOMで提示される列のインデックスを認識するために、aria-colindexプロパティに一緒に指定します。

aria-colcountは、tablegridtreegridのroleを持つ要素に指定されます。その値は、有効な列の総数と同じ整数です。もし、列の総数が分からないなら、-1を指定してかまいません。-1の値を使用することは、より多くの列が、供給可能なサイズを指定することなく、DOMに含まれていて利用可能であることを示します。

aria-colcountが、tablegridtreegridで使用されるとき、aria-colindexプロパティの値は、その子孫の行のそれぞれか、それぞれの子孫の行のすべてのセルに指定され、それは、以下の示すように列が連続しているかどうかに依存しています。aria-colindexの値は、以下のような整数です。 :

  1. 1と同じか、それ以上です。
  2. セルに指定するときは、同じ行の中の前のセルに指定されたどの値よりも大きい値です。
  3. もし、セルが複数の列を結合しているなら、その結合の最初の列のインデックスにセットします。
  4. 列の総数に同じか、それ以下です。

警告! aria-colindexの値が無かったり、矛盾していることは、支援技術の動作の効果に打撃を与えるかもしれません。例えば、適切ではないaria-colindexの値を指定したり、行のすべてのセルではなく、そのいくつかにセットしていることは、スクリーン・リーダーのテーブル読み上げ機能が、セルを読み飛ばしたり、単純にその機能を止めてしまうということを引き起こす可能性があります。

6.2.1 列のインデックスが連続しているときの、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>

6.2.2 列のインデックスが連続していないときの、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>

        

6.3 aria-colspanaria-rowspanの使用によるセル結合の定義

tableのテーブル要素以外の要素を使用して作られているテーブル、グリッド、ツリーグリッドに関しては、aria-rowspanaria-colspanのプロパティで、行や列を定義します。

aria-colspanの値は、以下のいずれかの整数です。:

  1. 1か、それ以上。
  2. そのセルが、同じ行で次のセルを重複する値よりも小さい値。

aria-rowspanの値は、以下のいずれかの整数です。:

  1. 0か、それ以上。
  2. 0は、そのセルが、その行のグループの残りの行を全て結合することを意味します。
  3. そのセルが、同じ列で次のセルを重複する値よりも小さい値。

以下の例のグリッドには、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要素を使うとき、行と列の結合を定義するには、 thtdの要素のrowspancolspan属性を使って、ネイティブなセマンティックを使ってください

6.4 aria-sortでのソート順序の提示

行や列がソートされているとき、ソートの方法を示すため、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>

      

7. role=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つがあります。:

  1. 装飾的な画像を隠します。これは、画像にnullのaltテキストを提供することと同じです。
  2. テーブルのセマンティックが意味のある関係性を伝えない状況で、レイアウトに使用されているテーブルのtableセマンティックを抑制します。
  3. 上記の例に存在するタブリスト、メニュー、ツリーのようなコンポジット・ウィジェットの構造の中で親の無い要素に介入するようなセマンティックを排除します。

7.1 role="presentation"の効果

role="presentation"が要素に指定されているとき、もし、ブラウザがrole="presentation"を無視する状況(「7.2 role="presentation"が無視されるようになる状況(7.2 Conditions That Cause Role presentation to be Ignored)」)が存在しないなら、以下の3つの効果があります。

  1. その要素が実装されているARIAのroleと、そのroleと関連するすべてのARIAの状態とプロパティが、支援技術から隠されます。
  2. その要素に含まれているテキスト(例えば、インナー・テキスト)や、そのすべての子孫の要素のインナーテキストも同じく、支援技術に見えるように残します。もちらん、テキストが明確に隠されている場合、例えば、display: noneでスタイリングされていたり、aria-hidden="true"をもっているような場合は、除きます。
  3. 子孫が表示上の要素の文脈を必要とするのでなければ、それぞれの子孫の要素のrole、state、propertyは、支援技術に見えたまま残ります。例えば:
    • もし、presentationが、ulol要素に適用されるなら、それぞれの子どものli要素は、role="presentation"を引き継ぎます。これは、ARIAが、listitem要素は親のlist要素を持つことを必要としているためです。そして、li要素は、支援技術には、提示されませんが、それらのli要素の中に含まれる要素(入れ子のリストを含みます)は、支援技術に見えます。
    • 同様に、もし、presentationが、table要素に適用されるなら、子孫であるcaptiontheadtbodytfootertrthtd要素が、role="presentation"を継承し、このように、支援技術には、提示されません。しかし、thtdの要素の中の要素(入れ子のテーブルを含みます)は、支援技術に提示されます。

7.2 role="presentation"が無視されるようになる状況

もし、適用されている要素について、以下の何れかが本当なら、ブラウザはrole="presentation"を無視し、そのために効果もありません。:

7.3 role="presentation"の効果をデモンストレーションする例

このコード:

        <ul role="presentation">
          <li>生年月日:</li>
          <li>1月1日, 3456年</li>
        </ul>
      

ブラウザで分析されると、ブラウザのアクセシビリティ・ツリーに依存しているスクリーン・リーダーや他の支援技術の認識は、以下と同じようになります。

        <div>生年月日:</div>
          <div>1月1日, 3456年</div>
      

8. 子孫を表示のみにすることで、自動的にセマンティックを隠すrole

プラットフォーム・アクセシビリティ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)」)を、見てください。

A. 索引

B. 変更履歴

B.1 「January 2019 Publication of Note Release 3」での変更点

以下も、参照してください。:

B.2 「July 2018 Publication of Note Release 2」での変更点

以下も、参照してください。:

B.3 「「December 2017 Publication as Note」での変更点」での変更点

以下も、参照してください。:

B.4 「June 2017 Working Draft」での変更点

以下も参照してください。:

C. 謝辞

C.1 バージョン1.1への主な貢献

WAI-ARIA Authoring Practices1.1」は、「Authoring Practices Task Force」全体の仕事であり、重要な仕事に貢献し、価値あるフィードバックを提供するオープン・ソース・コミュニティを通じた、多くの人々からの成果でもありつつ、バージョン1.1の内容やコードの大部分を明確に提供した以下の人々に感謝します。

C.2 ARIA Authoring Practices Task Forceで活発な参加者

C.3 他のコメンターとバージョン1.1への貢献者

C.4 有効な資金提供者

この公開は、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の視点や政策を、必ずしも反映するというわけではありません、そして、商号、商品、または組織の言及は米国政府による裏書きを含意しません。

D. 参考

D.1 引用規格

[HTML-AAM]
HTMLアクセシビリティAPIマッピング1.0。. Steve Faulkner; Alexander Surkov; Scott O'Hara; Bogdan Brinza; Jason Kiss; Cynthia Shelly. W3C. 31 January 2019. W3C Working Draft. URL: https://www.w3.org/TR/html-aam-1.0/
[WAI-ARIA]
アクセシブル・リッチ・インターネット・アプリケーション(WAI-ARIA)1.1. Joanmarie Diggs; Shane McCarron; Michael Cooper; Richard Schwerdtfeger; James Craig. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-1.1/