From 809773ff6d4569758f09bbebd99ef5855e80e371 Mon Sep 17 00:00:00 2001 From: Momdo Nakamura Date: Sat, 6 Jan 2024 19:35:00 +0900 Subject: [PATCH] =?UTF-8?q?[wai-aria-1.2]=20=E8=AA=A4=E5=AD=97=E8=84=B1?= =?UTF-8?q?=E5=AD=97=E3=81=AE=E4=BF=AE=E6=AD=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- wai-aria-1.2/index.html | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/wai-aria-1.2/index.html b/wai-aria-1.2/index.html index 458df207..405828db 100644 --- a/wai-aria-1.2/index.html +++ b/wai-aria-1.2/index.html @@ -968,7 +968,7 @@

Accessible Rich Internet Applications (WAI-ARIA) 1.

この文書は2021年11月2日のW3Cプロセス文書によって管理される。 -

+

献辞

このバージョンのARIA仕様を、この文書全体を通じて貢献したCarolyn MacLeodに捧げる。彼女は落ち着きと賢明さをもって我々の仕事に彩りを与えた。彼女の早すぎる死は、コミュニティによって長く惜しまれるだろう。

@@ -1037,7 +1037,7 @@

Accessible Rich Internet Applications (WAI-ARIA) 1.

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

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

-

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

+

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

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

@@ -1126,7 +1126,7 @@

Accessible Rich Internet Applications (WAI-ARIA) 1.
非推奨
-

非推奨のロール、ステートまたはプロパティは、新しい構築物または変更状況によって時代遅れされており、かつWAI-ARIA仕様の将来のバージョンで削除されるかもしれないものである。ユーザーエージェントは、下位互換性のために非推奨として識別される項目のサポートを継続することを勧める。詳細については、適合性セクションの非推奨要件を参照のこと。

+

非推奨のロール、ステートまたはプロパティは、新しい構築物または変更状況によって時代遅れとなっており、かつWAI-ARIA仕様の将来のバージョンで削除されるかもしれないものである。ユーザーエージェントは、下位互換性のために非推奨として識別される項目のサポートを継続することを勧める。詳細については、適合性セクションの非推奨要件を参照のこと。

デスクトップフォーカスイベント
@@ -1313,7 +1313,7 @@

Accessible Rich Internet Applications (WAI-ARIA) 1.

技術の進化により、以前に定義された機能よりもよりよい動作をする、ユースケースを満たすための新しい方法が時には利用可能になる。しかし、先行した機能の既存の実装のため、その機能は、以前の適合コンテンツをレンダリングすることなく、適合モデルから削除することはできない。この場合、古い機能は"deprecated"（非推奨）としてマークされる。これは、その機能が適合モデルで許可され、ユーザーエージェントによってサポートされることが期待されるが、著者が新しいコンテンツにその機能を使用しないことが勧められることを示す。仕様の将来のバージョンにおいて、機能がもはや広く使用されない場合、その機能は削除され、もはやユーザーエージェントによってサポートされることが期待できないだろう。

-

4. Using WAI-ARIA

+

4. WAI-ARIAを使用する

支援技術が、文書の一部の後ろにあるセマンティックスを決定できない場合、またはユーザーが効果的に使用可能な方法で文書のすべての部分に移動できない場合、複雑なウェブアプリケーションはアクセシブルでなくなる（WAI-ARIA Authoring Practicesを参照）。WAI-ARIAは、セマンティックスをロール（ユーザーインターフェイス要素を定義する種類）と、ロールでサポートされるステートおよびプロパティに分割する。

著者は、要素がすでにステートおよびプロパティに適切な暗黙のWAI-ARIAセマンティックスを持たない限り、ライフサイクルの間に、WAI-ARIAロールおよび適切なステートおよびプロパティ（aria-*属性）に文書内の要素を関連付ける必要がある。ロール属性は、ホスト言語要素の暗黙的なロールよりも優先されると同時に、このような場合において同等のホスト言語のステートおよびプロパティは、競合を避けるために優先される。

@@ -3821,7 +3821,7 @@

em

feedロール

スクロールがarticleにリストのいずれかの端に追加させるまたは端から削除させるかもしれない場所でarticleのスクロール可能なlist。

-

feedは、ユーザーが読むようにより多くのコンテンツを読み込むことによって無限にスクロールし続けるかもしれないリッチコンテンツのストリームを介して読み込みとスクロールの両方をするためのカーソル読み込みブラウズモードを使用することを、スクリーンリーダーなどの文書閲覧モードを持つ支援技術のユーザーにできるようにする。feedにおいて、支援技術は、ユーザーがページを閲覧するように新しいコンテンツを追加し視覚的にコンテンツを配置するアプリケーションを有効する、ユーザーエージェントのフォーカスを移動することによってユーザーの読み取りカーソルの動きの信号とともにウェブアプリケーションを提供する。feedはまた、支援技術が読み取りの混乱またはパフォーマンスの低下をすることなく、より確実に読み取り表示を更新できるように追加および削除が発生する場合に、著者に支援技術を告知させる。

+

feedは、ユーザーが読むようにより多くのコンテンツを読み込むことによって無限にスクロールし続けるかもしれないリッチコンテンツのストリームを介して読み込みとスクロールの両方をするためのカーソル読み込みブラウズモードを使用することを、スクリーンリーダーなどの文書閲覧モードを持つ支援技術のユーザーにできるようにする。feedにおいて、支援技術は、ユーザーエージェントのフォーカスを移動することによってユーザーの読み取りカーソルの動きの信号とともにウェブアプリケーションを提供し、ユーザーがページを閲覧するときにアプリケーションが新しいコンテンツを追加したり、視覚的にコンテンツを配置したりすることを可能にする。feedはまた、支援技術が読み取りの混乱またはパフォーマンスの低下をすることなく、より確実に読み取り表示を更新できるように追加および削除が発生する場合に、著者に支援技術を告知させる。

たとえば、各articleがテキスト、リンク、画像と同様に共有やコメントのためのウィジェットをもつニュース記事を含む場所で、ニュース記事のストリームを提示するためにfeedを使用することができる。スクリーンリーダーのユーザーは、各ニュース記事を読み取って対話し、記事から記事へスクリーンリーダーの読み取りカーソルを移動するので、必要に応じて各記事は、表示にスクロールし、そして新しい記事は読み込まれる。

feedは、子がロールarticleを持つコンテナー要素である。articlesがfeedの片方または両方の端に追加または削除される場合、著者は、変更が作成される前にfeed要素上でaria-busyをtrueに設定し、変更が完了した後にこれをfalseに設定すべきである。著者は、feedの真ん中でarticlesを挿入または削除を避けるべきである。この要件は、支援技術がfeed内で読み取りカーソルを移動するためにユーザーコマンドと同時に発生するfeedコンテンツにおける変化に正常に対応するのを助ける。

著者は、ユーザーエージェントのフォーカスがarticleまたはその子孫要素のいずれかで設定される場合に、フォーカス可能なfeedで各articleを作成し、アプリケーションがビューにarticleをスクロールすることを保証すべきである。たとえば、HTMLで、各article要素は、-1または0のいずれかのtabindex値を持つべきである。

@@ -10518,7 +10518,7 @@

combobox、searchbox、またはtextboxに対するユーザーの意図した値の1つ以上の予測の表示をトリガーできるかどうかを示し、予測が行われた場合にその予測の表示方法を指定する。

aria-autocompleteプロパティは、動的にユーザーのテキスト入力の完了を手助けする場合に、textbox、searchbox、またはcomboboxが利用するインタラクションモデルのタイプを表す。これは、2つのモデルを区別する：テキスト入力内の値完了予測を提示するインラインモデル（aria-autocomplete="inline"）と、テキスト入力に隣接してポップアップする個別に可能な値のコレクションを提示するリストモデル（aria-autocomplete="list"）。入力は、同じ時間（aria-autocomplete="both"）で両方のモデルを提供することが可能である。

aria-autocompleteプロパティは、input要素の予測挙動を記述するのに限定される。著者は、入力要素がどの提案もユーザーによって提供される特定の入力に依存しない1つ以上の入力提案を提供する場合に、aria-autocompleteへの値の指定を省略するまたは、noneにaria-autocompleteを設定するかのいずれかにすべきである。たとえば、aria-autocompleteの値がnoneであるコンボボックスは、ユーザーの入力に基づくリストの任意のフィルタリングなしで5つの最近使用した検索用語をリストすることによって示唆される値を表示する検索フィールドである。aria-autocompleteをサポートするロールをもつ要素は、noneのaria-autocompleteのデフォルト値を持つ。

-

インライン提案が入力でユーザー型として作成される場合、フィールドの値を完了するために提案されたテキストは、入力カーソルの後にフィールドに動的に出現し、かつユーザーがフィールドをそのままにしてフォーカスをもたらすアクションを実行する場合、提案される値は入力の値として受け入れられる。要素がinlineまたはbothに設定されるaria-autocompleteを持つ場合、著者は、テキストの自動で提案される一部が選択されたテキストとして提示されることを保証すべきである。これは、ユーザーの入力と自動提案とを区別することを支援技術に可能させ、提案が所望の値でない場合には、提案を簡単に削除する、または入力し続けることでその提案を置換することを可能する。

+

インライン提案が入力でユーザー型として作成される場合、フィールドの値を完了するために提案されたテキストは、入力カーソルの後にフィールドに動的に出現し、かつユーザーがフィールドをそのままにしてフォーカスをもたらすアクションを実行する場合、提案される値は入力の値として受け入れられる。要素がinlineまたはbothに設定されるaria-autocompleteを持つ場合、著者は、テキストの自動で提案される一部が選択されたテキストとして提示されることを保証すべきである。これは、支援技術がユーザーの入力と自動提案とを区別することを可能にし、提案が所望の値でない場合には、ユーザーが入力し続けることで、その提案を簡単に削除する、またはその提案を置換することを可能にする。

要素がlistまたはbothに設定されるaria-autocompleteを持つ場合、著者は次の両方の条件が満たされることを保証しなければならない：

  1. 要素は、提案される値のコレクションを含む要素を参照するaria-controlsで指定される値を持つ。
    2. @@ -11334,7 +11334,7 @@

    aria-invalidがfalseに設定されるか、aria-invalid属性が設定されないかのいずれかである。著者は、現在有効なオブジェクトに対してaria-errormessageを使用してもよいが、含まれるメッセージが適切ではないため、aria-errormessageによって参照される要素が非表示の場合のみである。

    aria-errormessageが適切な場合、著者はコンテンツが隠されておらず、ユーザーがエラーメッセージにナビゲートして調査することができるようすることを保証しなければならない。同様に、aria-errormessageが適切でない場合、著者は、コンテンツが非表示であるか、aria-errormessage属性もしくはその値を除去するかのいずれかを保証しなければならない。

    ユーザーエージェントは、falseのaria-invalid値をもつオブジェクトに対してaria-errormessageを公開してはならない。

    -

    著者は、aria-liveプロパティを適用するか、alertなどのライブリージョンロールのいずれかを使用して、ライブリージョとともに新らたにレンダリングされたエラーメッセージに注意を喚起してもよい。ライブリージョンは、ユーザーが無効な値を入力した後にエラーメッセージが表示されたときに適切である。

    +

    著者は、aria-liveプロパティを適用するか、alertなどのライブリージョンロールのいずれかを使用して、ライブリージョンとともに新らたにレンダリングされたエラーメッセージに注意を喚起してもよい。ライブリージョンは、ユーザーが無効な値を入力した後にエラーメッセージが表示されたときに適切である。

    典型的なメッセージは何が間違っているかを説明し、ユーザーに何が必要かを知らせる。たとえば、エラーメッセージは、無効な時刻：時刻は午前9時から午後5時の間でなければならない。かもしれない。テキスト入力object上のaria-invalidへの変更、およびエラーメッセージのテキストを含む要素上のaria-liveへの変更に注目する：

    @@ -13442,7 +13442,7 @@

    8.4 暗黙のWAI-ARIAセマンティックス

    ホスト言語がオブジェクトに対してネイティヴセマンティックスを欠く場合、WAI-ARIAは、オブジェクトに関するセマンティック情報を提供するように設計されている。とはいえ、WAI-ARIAは多数のホスト言語のために追加のセマンティックスを提供するよう設計されている。さらに、長い期間をかけてホスト言語は進化し、WAI-ARIAの機能に対応して新しいネイティヴな機能を提供することができる。そのため、WAI-ARIAセマンティックスがホスト言語のセマンティックスと冗長であるような多数の状況がある。

    -

    このホスト言語の機能は、「暗黙のWAI-ARIAセマンティックス」を持つとみなすことができる。暗黙のWAI-ARIAセマンティックスを持つ機能のユーザーエージェント処理は、WAI-ARIAの機能の処理と同様だろう。その処理はホスト言語の機能とWAI-ARIAの機能との間の構文上の違いにより同一ではないかもしれないが、一般に、ユーザーエージェントはアクセシビリティAPIに同一の情報を公開するだろう。暗黙のWAI-ARIAセマンティックスを持つ機能は、必須の所有される要素、必須のステートやプロパティなど、WAI-ARIAの構造的要件を満たし、提供される明示的なWAI-ARIAセマンティックスを必要しない。暗黙のWAI-ARIAロールをもつ要素で、著者はまた、WAI-ARIAロールの明確な指示の必要なしにそのロールでサポートされるWAI-ARIAステートおよびプロパティを使用することができる。

    +

    このホスト言語の機能は、「暗黙のWAI-ARIAセマンティックス」を持つとみなすことができる。暗黙のWAI-ARIAセマンティックスを持つ機能のユーザーエージェント処理は、WAI-ARIAの機能の処理と同様だろう。その処理はホスト言語の機能とWAI-ARIAの機能との間の構文上の違いにより同一ではないかもしれないが、一般に、ユーザーエージェントはアクセシビリティAPIに同一の情報を公開するだろう。暗黙のWAI-ARIAセマンティックスを持つ機能は、必須の所有される要素、必須のステートやプロパティなど、WAI-ARIAの構造的要件を満たし、提供される明示的なWAI-ARIAセマンティックスを必要としない。暗黙のWAI-ARIAロールをもつ要素で、著者はまた、WAI-ARIAロールの明確な指示の必要なしにそのロールでサポートされるWAI-ARIAステートおよびプロパティを使用することができる。

    たとえば、チェックボックスやラジオボタンなど、機能性をもつ要素がすでに存在する場合、ホスト言語のネイティヴセマンティックスを使用する。WAI-ARIAマークアップは、（たとえば、aria-requiredに必要であることを示す）ネイティヴセマンティックスを増強するためにのみ使用されることを意図する、または要素の標準機能をから別の用途にセマンティックスを変更するために使用されることを意図する。

    暗黙のWAI-ARIAセマンティックスは、以下のセクションにおける、ホスト言語のセマンティックスと競合する、衝突解決手続きに影響を与える。したがって、暗黙のWAI-ARIAセマンティックスは、ホスト言語仕様またはCore Accessibility API Mappingsなどの規範的仕様で定義する必要がある。