From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- .../web/accessibility/accessibility_faq/index.html | 26 + .../index.html | 185 ++++++ .../web/accessibility/aria/aria_guides/index.html | 26 + .../aria/aria_live_regions/index.html | 227 +++++++ .../index.html | 32 + .../accessibility/aria/aria_techniques/index.html | 216 +++++++ .../using_the_alert_role/index.html | 145 +++++ .../using_the_alertdialog_role/index.html | 86 +++ .../index.html | 46 ++ .../index.html | 89 +++ .../using_the_aria-invalid_attribute/index.html | 128 ++++ .../using_the_aria-label_attribute/index.html | 61 ++ .../using_the_aria-labelledby_attribute/index.html | 143 +++++ .../index.html | 89 +++ .../using_the_aria-relevant_attribute/index.html | 31 + .../using_the_aria-required_attribute/index.html | 79 +++ .../using_the_aria-valuemax_attribute/index.html | 73 +++ .../using_the_aria-valuemin_attribute/index.html | 67 ++ .../using_the_aria-valuenow_attribute/index.html | 73 +++ .../using_the_aria-valuetext_attribute/index.html | 64 ++ .../using_the_button_role/index.html | 123 ++++ .../using_the_checkbox_role/index.html | 63 ++ .../using_the_group_role/index.html | 124 ++++ .../aria_techniques/using_the_link_role/index.html | 97 +++ .../aria_techniques/using_the_log_role/index.html | 90 +++ .../using_the_presentation_role/index.html | 53 ++ .../using_the_progressbar_role/index.html | 74 +++ .../using_the_radio_role/index.html | 53 ++ .../using_the_slider_role/index.html | 135 ++++ .../using_the_status_role/index.html | 82 +++ .../using_the_toolbar_role/index.html | 45 ++ .../web/accessibility/aria/forms/alerts/index.html | 153 +++++ .../aria/forms/basic_form_hints/index.html | 121 ++++ files/ja/web/accessibility/aria/forms/index.html | 17 + .../aria/forms/multipart_labels/index.html | 41 ++ files/ja/web/accessibility/aria/index.html | 126 ++++ .../accessibility/aria/roles/alert_role/index.html | 70 ++ .../aria/roles/application_role/index.html | 108 ++++ .../aria/roles/article_role/index.html | 114 ++++ .../aria/roles/banner_role/index.html | 97 +++ .../accessibility/aria/roles/cell_role/index.html | 199 ++++++ .../aria/roles/complementary_role/index.html | 114 ++++ .../aria/roles/contentinfo_role/index.html | 147 +++++ .../aria/roles/dialog_role/index.html | 166 +++++ .../aria/roles/document_role/index.html | 94 +++ .../accessibility/aria/roles/feed_role/index.html | 124 ++++ .../aria/roles/figure_role/index.html | 148 +++++ .../accessibility/aria/roles/form_role/index.html | 171 +++++ .../accessibility/aria/roles/grid_role/index.html | 715 +++++++++++++++++++++ .../aria/roles/heading_role/index.html | 114 ++++ files/ja/web/accessibility/aria/roles/index.html | 72 +++ .../accessibility/aria/roles/list_role/index.html | 115 ++++ .../aria/roles/listbox_role/index.html | 211 ++++++ .../aria/roles/listitem_role/index.html | 113 ++++ .../accessibility/aria/roles/main_role/index.html | 131 ++++ .../aria/roles/navigation_role/index.html | 151 +++++ .../aria/roles/region_role/index.html | 138 ++++ .../accessibility/aria/roles/role_img/index.html | 125 ++++ .../accessibility/aria/roles/row_role/index.html | 231 +++++++ .../aria/roles/rowgroup_role/index.html | 163 +++++ .../aria/roles/search_role/index.html | 122 ++++ .../aria/roles/switch_role/index.html | 187 ++++++ .../accessibility/aria/roles/table_role/index.html | 154 +++++ .../aria/roles/textbox_role/index.html | 130 ++++ .../aria/web_applications_and_aria_faq/index.html | 302 +++++++++ files/ja/web/accessibility/aria/widgets/index.html | 10 + .../accessibility/aria/widgets/overview/index.html | 72 +++ .../ja/web/accessibility/at_development/index.html | 55 ++ files/ja/web/accessibility/community/index.html | 19 + files/ja/web/accessibility/index.html | 57 ++ files/ja/web/accessibility/index/index.html | 11 + .../index.html | 171 +++++ .../mobile_accessibility_checklist/index.html | 92 +++ .../accessibility/understanding_wcag/index.html | 58 ++ .../understanding_wcag/operable/index.html | 319 +++++++++ .../understanding_wcag/perceivable/index.html | 357 ++++++++++ .../understanding_wcag/robust/index.html | 85 +++ .../understanding_wcag/understandable/index.html | 259 ++++++++ 78 files changed, 9574 insertions(+) create mode 100644 files/ja/web/accessibility/accessibility_faq/index.html create mode 100644 files/ja/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.html create mode 100644 files/ja/web/accessibility/aria/aria_guides/index.html create mode 100644 files/ja/web/accessibility/aria/aria_live_regions/index.html create mode 100644 files/ja/web/accessibility/aria/aria_screen_reader_implementors_guide/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_alert_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_alertdialog_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-activedescendant_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-invalid_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-labelledby_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-orientation_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-relevant_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-required_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuemax_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuemin_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuenow_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuetext_attribute/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_button_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_checkbox_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_group_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_link_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_log_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_presentation_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_progressbar_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_radio_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_slider_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_status_role/index.html create mode 100644 files/ja/web/accessibility/aria/aria_techniques/using_the_toolbar_role/index.html create mode 100644 files/ja/web/accessibility/aria/forms/alerts/index.html create mode 100644 files/ja/web/accessibility/aria/forms/basic_form_hints/index.html create mode 100644 files/ja/web/accessibility/aria/forms/index.html create mode 100644 files/ja/web/accessibility/aria/forms/multipart_labels/index.html create mode 100644 files/ja/web/accessibility/aria/index.html create mode 100644 files/ja/web/accessibility/aria/roles/alert_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/application_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/article_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/banner_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/cell_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/complementary_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/contentinfo_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/dialog_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/document_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/feed_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/figure_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/form_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/grid_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/heading_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/index.html create mode 100644 files/ja/web/accessibility/aria/roles/list_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/listbox_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/listitem_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/main_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/navigation_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/region_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/role_img/index.html create mode 100644 files/ja/web/accessibility/aria/roles/row_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/rowgroup_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/search_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/switch_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/table_role/index.html create mode 100644 files/ja/web/accessibility/aria/roles/textbox_role/index.html create mode 100644 files/ja/web/accessibility/aria/web_applications_and_aria_faq/index.html create mode 100644 files/ja/web/accessibility/aria/widgets/index.html create mode 100644 files/ja/web/accessibility/aria/widgets/overview/index.html create mode 100644 files/ja/web/accessibility/at_development/index.html create mode 100644 files/ja/web/accessibility/community/index.html create mode 100644 files/ja/web/accessibility/index.html create mode 100644 files/ja/web/accessibility/index/index.html create mode 100644 files/ja/web/accessibility/keyboard-navigable_javascript_widgets/index.html create mode 100644 files/ja/web/accessibility/mobile_accessibility_checklist/index.html create mode 100644 files/ja/web/accessibility/understanding_wcag/index.html create mode 100644 files/ja/web/accessibility/understanding_wcag/operable/index.html create mode 100644 files/ja/web/accessibility/understanding_wcag/perceivable/index.html create mode 100644 files/ja/web/accessibility/understanding_wcag/robust/index.html create mode 100644 files/ja/web/accessibility/understanding_wcag/understandable/index.html (limited to 'files/ja/web/accessibility') diff --git a/files/ja/web/accessibility/accessibility_faq/index.html b/files/ja/web/accessibility/accessibility_faq/index.html new file mode 100644 index 0000000000..75086f73e4 --- /dev/null +++ b/files/ja/web/accessibility/accessibility_faq/index.html @@ -0,0 +1,26 @@ +--- +title: Accessibility FAQ +slug: Web/Accessibility/Accessibility_FAQ +tags: + - Accessibility +translation_of: Web/Accessibility/FAQ +--- +

Mozilla のアクセシビリティについて、どこから始めたらよいですか?
+Mozilla Accessibility Project
+


+現在ブラウザでサポートされている組み込みアクセシビリティ機能は何ですか?
+Firefox's Built-in Accessibility Features
+


+どの支援技術が Firefox や Thunderbird をサポートしていますか?
+Assistive Technology Compatibility - Windows, Linux, UNIX, Mac OS X のための支援技術についてのドキュメントと、Firefox 1.5.0.5 以降および Thunderbird 1.5.0.5 以降での互換性。
+


+わたしの Mozilla 拡張機能をアクセシブルにするには何をしたらよいですか?
+一般的には、Accessible Toolkit Checklist を使用します。XUL によるインタフェースデザインについては、XUL accessibility guidelines +{{ mediawiki.external('http://www.mozilla.org/access/xul-guidelines Accessibile XUL Authoring Guidelines') }}をご覧ください。
+


+わたしは、Firefox が提供する良いアクセシビリティ機能の促進を手助けすることに興味があります。どうしたらよいですか?
+Firefox Accessibility Advocates に参加してください。
+

+
+
+{{ languages( { "en": "en/Accessibility_FAQ" } ) }} diff --git a/files/ja/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.html b/files/ja/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.html new file mode 100644 index 0000000000..5b176c9fb1 --- /dev/null +++ b/files/ja/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.html @@ -0,0 +1,185 @@ +--- +title: アクセシブルな Web アプリケーションやウィジェットの概要 +slug: Web/Accessibility/An_overview_of_accessible_web_applications_and_widgets +tags: + - ARIA + - Accessibility + - Guide + - Web apps + - Widget +translation_of: Web/Accessibility/An_overview_of_accessible_web_applications_and_widgets +--- +

Web は変化しています。静的でページに基づくサイトは、次第に動的でデスクトップスタイルの、JavaScript や AJAX を多用する Web アプリケーションに置き換えられています。デザイナーは JavaScript、HTML、CSS を組み合わせて、驚くような新しいウィジェットやコントロールのすべてを作り上げています。この変化は Web の応答性やユーザビリティを劇的に向上させる可能性を秘めていますが、多くのユーザはアクセシビリティのギャップにより閉め出されてしまう恐れがあります。JavaScript は伝統的に、スクリーンリーダーなどの支援技術のユーザに対してアクセシブルではないと言われてきましたが、現在はさまざまなユーザに対してアクセシブルな動的 Web ユーザインターフェイスを作成するための手段があります。

+ +

問題点

+ +

ほとんどの JavaScript ツールキットは、よく知られたデスクトップインターフェイスの動作を模倣する、クライアントサイドのウィジェットのライブラリを提供します。スライダー、メニューバー、ファイルリストビューなどを JavaScript、CSS、HTML の組み合わせにより構築できます。HTML 4 の仕様はこれらの種類のウィジェットを意味的に表すタグを内蔵していないため、一般的に開発者は <div> や <span> といった汎用の要素を使用します。これはデスクトップによく似たもののように見えますが、支援技術が使用するのに値する意味的な情報は、たいていマークアップ内にありません。Web ページ上の動的コンテンツは、どのような理由であれ画面を見ることができないユーザにとって特に問題になる可能性があります。株価表示、Twitter のフィード更新、進捗の表示やそれらに似たコンテンツは、支援技術 (AT) が認識できないかもしれない方法で DOM を変更します。ここが、ARIA が必要になるところです。

+ +

例 1: ARIA でラベルをつけずに作成したタブウィジェットのマークアップ。ウィジェットの外観や機能を示す情報は、マークアップ内にありません。

+ +
<!-- これはタブウィジェットです。マークアップだけを見て、どのようにしてわかるのでしょうか?-->
+<ol>
+  <li id="ch1Tab">
+    <a href="#ch1Panel">Chapter 1</a>
+  </li>
+  <li id="ch2Tab">
+    <a href="#ch2Panel">Chapter 2</a>
+  </li>
+  <li id="quizTab">
+    <a href="#quizPanel">Quiz</a>
+  </li>
+</ol>
+
+<div>
+  <div id="ch1Panel">Chapter 1 content goes here</div>
+  <div id="ch2Panel">Chapter 2 content goes here</div>
+  <div id="quizPanel">Quiz content goes here</div>
+</div>
+ +

例 2: タブウィジェットはどのようにして視覚的にスタイルが設定されるのでしょうか。ユーザはそれを視覚的に認識するでしょう。しかし、支援技術向けに機械が読み取れる意味の情報はありません。
+ Screenshot of the tabs widget

+ +

ARIA

+ +

W3C の Web Accessibility Initiative から生まれた WAI-ARIA こと Accessible Rich Internet Applications 仕様は、スクリーンリーダーのような支援技術が必要とする、欠けているセマンティクスを追加する手段です。ARIA はマークアップに特別な属性を追加することで、開発者が自身のウィジェットをより詳しく説明することを可能にします。ARIA は動的な Web アプリケーションにおいて、標準の HTML タグとデスクトップスタイルのコントロールとの間にあるギャップを埋めるように設計されており、ほとんどのよく知られた UI ウィジェットの動作を示す役割や状態を与えます。

+ +

ARIA 仕様書は 3 種類の属性に分けられています: ロール、ステート、プロパティです。ロールは HTML 4 において他の方法で利用できないウィジェット、例えばスライダー、メニューバー、タブ、ダイアログなどを説明します。プロパティはこれらのウィジェットの特徴、例えばドラッグ可能、必須の要素がある、関連づけられたポップアップがあるなどを説明します。ステートは要素について支援技術に伝える現在の対話状態、例えばビジー、無効、選択中、非可視などを説明します。

+ +

ARIA の属性はブラウザによって自動的に解釈され、オペレーティングシステムのネイティブなアクセシビリティ API に変換されるように設計されています。ARIA が提供されていると、支援技術は独自の JavaScript コントロールについて、デスクトップにおける同等物と同じ方法で、認識および対話ができます。支援技術のユーザが Web ベースのアプリケーションを使用するときに、デスクトップアプリケーションの動作に関するあらゆる知識を適用できますので、以前の Web アプリケーションより一貫したユーザエクスペリエンスをもたらす可能性を秘めています。

+ +

例 3: ARIA の属性を追加したタブウィジェットのマークアップ。

+ +
<!-- *これら* はタブです!-->
+<!-- タブリストや各タブを表すために、role 属性を追加しました。-->
+<ol role="tablist">
+  <li id="ch1Tab" role="tab">
+    <a href="#ch1Panel">Chapter 1</a>
+  </li>
+  <li id="ch2Tab" role="tab">
+    <a href="#ch2Panel">Chapter 2</a>
+  </li>
+  <li id="quizTab" role="tab">
+    <a href="#quizPanel">Quiz</a>
+  </li>
+</ol>
+
+<div>
+  <!-- タブのパネルを表すために追加した role および aria-labelledby 属性に注目してください。-->
+  <div id="ch1Panel" role="tabpanel" aria-labelledby="ch1Tab">Chapter 1 content goes here</div>
+  <div id="ch2Panel" role="tabpanel" aria-labelledby="ch2Tab">Chapter 2 content goes here</div>
+  <div id="quizPanel" role="tabpanel" aria-labelledby="quizTab">Quiz content goes here</div>
+</div>
+
+ +

ARIA は Firefox、Safari、Opera、Chrome、Internet Explorer といった主要なブラウザの最新バージョンでサポートされています。オープンソースの NVDA や Orca スクリーンリーダーなど、多くの支援技術も ARIA をサポートしています。jQuery UI、YUI、Google Closure、Dojo Dijit などの JavaScript ウィジェットライブラリも、次第に ARIA のマークアップを導入しています。

+ +

表現の変化

+ +

動的な表現の変化には、コンテンツを表示させたり隠したりすることはもちろん、コンテンツの外見を変える (不正なデータを囲む赤色のボーダー、チェックされたチェックボックスの背景色を変えるなど) ために CSS を使用することも含みます。

+ +

状態の変化

+ +

ARIA に、UI ウィジェットの現在の状態を定義する属性があります。例えば以下のとおりです (これだけではありません):

+ + + +

(ARIA のすべてのステートの一覧については、ARIA のステートとプロパティの一覧をご覧ください。)

+ +

開発者は UI ウィジェット要素の状態を示すために ARIA のステートを使用して、ステートの変化に基づく視覚的外見の変更に (スクリプトを使用して要素のクラス名を変更するのではなく) CSS の属性セレクタを使用しましょう。

+ +

注意: この例(http://www.oaa-accessibility.org/example/25/) はもう利用できません。状況が変わったので、W3C ARIA オーサリングプラクティスガイドの例 (www.w3.org/TR/wai-aria-practices-1.1/examples/checkbox/checkbox-1/checkbox-1.html) を見てください。

+ +

Open Ajax Alliance の Web サイトに、ARIA のステートに基づく CSS 属性セレクタの例があります。この例では、動的なメニューシステムによる WYSIWYG エディタのインターフェイスを示しています。フォントフェイススなどのメニューで現在選択されている項目は、他のアイテムと視覚的に区別されます。例の中で関係する部分を、以下で説明します。

+ +

この例でメニュー用の HTML は、例 1a で示す形式になっています。7 行目と 13　行目で、メニュー項目の選択状態を表すために aria-checked プロパティを使用していることに注意してください。

+ +

例 1a: 選択可能なメニュー用の HTML (http://www.oaa-accessibility.org/example/25/ をもとに改作)。

+ +

可視性の変化

+ +

コンテンツの可視性を変えるとき (例えば要素を隠したり表示したりする)、開発者は aria-hidden プロパティの値を変更するとよいでしょう。先に説明した手法を、display:none を使用して要素を視覚的に隠すという CSS を示すために使用しましょう。

+ +

Open Ajax Alliance の Web サイトに、可視性の制御に aria-hidden を使用するツールチップの例があります。この例では、入力フィールドに関する指示を収めたツールチップを持つシンプルな Web フォームの例を示しています。例の中で関係する部分を、以下で説明します。

+ +

この例でツールチップ用の HTML は、例 2a で示す形式になっています。9 行目で aria-hidden を true に設定しています。

+ +

例 2a: ツールチップ用の HTML (http://www.oaa-accessibility.org/example/39/ をもとに改作)。

+ +
<div class="text">
+    <label id="tp1-label" for="first">First Name:</label>
+    <input type="text" id="first" name="first" size="20"
+           aria-labelledby="tp1-label"
+           aria-describedby="tp1"
+           aria-required="false" />
+    <div id="tp1" class="tooltip"
+         role="tooltip"
+         aria-hidden="true">Your first name is a optional</div>
+</div>
+
+ +

このマークアップ用の CSS を例 2b で示します。ここでは独自のクラス名を使用せず、1 行目で aria-hidden 属性の状態のみを使用していることに注意してください。

+ +

例 2b: 状態を示すための、属性セレクタ (http://www.oaa-accessibility.org/example/39/ より)。

+ +
div.tooltip[aria-hidden="true"] {
+  display: none;
+}
+
+ +

>aria-hidden プロパティを更新するための JavaScript は、例 2c で示す形式になっています。このスクリプトは >aria-hidden 属性しか更新しないことに注意してください (2 行目)。独自のクラス名の追加や削除は不要です。

+ +

例 2c: aria-hidden 属性を更新する JavaScript (http://www.oaa-accessibility.org/example/39/ に基づく)。

+ +
var showTip = function(el) {
+  el.setAttribute('aria-hidden', 'false');
+}
+ +

ロールの変化

+ +
作成中
+ +

ARIA によって開発者は、誤った意味を持っていたり意味が存在しない要素に対して意味的なロールを宣言することができます。例えばメニューを作るために順番付けがないリストを使用するとき、{{HTMLElement("ul")}} に menubar の role を、各々の {{HTMLElement("li")}} に menuitem の role を与えるべきです。

+ +

要素の role を変更するべきではありません。代わりに元の要素を削除して、新たな role の要素で置き換えてください。

+ +

例えば "インライン編集" ウィジェットについて考えてみましょう: これはコンテキストを切り替えることなく、ユーザがその場でひとまとまりのテキストを編集できるコンポーネントです。このコンポーネントは、テキストの編集はできませんがアクティブが可能な "閲覧" モードと、テキストの編集が可能な "編集" モードがあります。開発者は、ARIA の role を button に設定した読み取り専用の text 型 {{HTMLElement("input")}} 要素で "閲覧" モードを実装して、要素を書き換え可能にするとともに "閲覧" モードの role 属性を削除する ({{HTMLElement("input")}} は自身のロールを意味として持っているため) ことで "編集" モードに切り替えようと考えるでしょう。

+ +

これを行ってはいけません。代わりに role が button である {{HTMLElement("div")}} や {{HTMLElement("span")}} といった、まったく別の要素を使用して "閲覧" モードを、また text 型の {{HTMLElement("input")}} 要素を要して "編集" モードを実装してください。

+ +

非同期のコンテンツ変更

+ +
作成中です。Live Regions もご覧ください。
+ +

キーボードナビゲーション

+ +

開発者は、独自のウィジェットを作成する際にキーボードのサポートを見落とすことがよくあります。さまざまなユーザにとってアクセシブルにするために、すべての Web アプリケーションやウィジェットはマウスを必要とせずにキーボードでも操作できるようにするべきです。実際、通常これはデスクトップにおける同様のウィジェットがサポートする慣習への準拠度を向上させて、Tab、Enter、スペース、矢印キーのあらゆる利点を獲得します。

+ +

伝統的に、Web におけるキーボードナビゲーションは Tab キーに限定されてきました。ユーザはページ内の各リンク、ボタン、フォームへ順番にフォーカスを当てるために Tab キーを、逆順に進むために Shift-Tab を押します。これは一次元、つまり一度に 1 つの要素で、進むまたは戻るナビゲーションです。かなり分量の多いページでは、キーボードのみ使用するユーザは必要なセクションへアクセスするまでに何度も Tab キーを押さなければなりません。Web においてデスクトップスタイルのキーボード操作の慣習を実装すると、多くのユーでナビゲーションが劇的に高速化する可能性があります。

+ +

以下は、ARIA が有効な Web アプリケーションでどのようなキーボードナビゲーションが動作すべきかの概要です:

+ + + +

従って前出のタブウィジェットの例では、ユーザが Tab および Shift+Tab キーを使用してウィジェットのコンテナ (マークアップにおける <ol>) に出入りするナビゲーションを行えるとよいでしょう。キーボードのフォーカスがコンテナ内に入ったら、矢印キーで各々のタブ (<li> 要素) を行き来できるとよいでしょう。ここからは、プラットフォームによって慣習が異なります。Windows では、ユーザが矢印キーを押すと自動的に次のタブがアクティブ化されます。Mac OS X では、ユーザは次のタブをアクティブ化するために Enter またはスペースキーを押します。キーボードでナビゲーション可能な JavaScript ウィジェット作成の包括的なチュートリアルで、このような動作を JavaScript で実装する方法を説明します。

+ +

デスクトップスタイルのキーボードナビゲーションの慣習に関する詳細として、包括的な DHTML style guide があります。これは、ARIA がサポートする各種ウィジェットで動作すべきキーボードナビゲーションは何かの概要を示します。W3C でもさまざまなウィジェット向けのキーボードナビゲーションやショートカットの慣習を収めた、ARIA Best Practices の有用なドキュメントを提供しています。

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/aria_guides/index.html b/files/ja/web/accessibility/aria/aria_guides/index.html new file mode 100644 index 0000000000..3bebf397dd --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_guides/index.html @@ -0,0 +1,26 @@ +--- +title: ARIA ガイド +slug: Web/Accessibility/ARIA/ARIA_Guides +tags: + - ARIA +translation_of: Web/Accessibility/ARIA/ARIA_Guides +--- +

Accessible Rich Internet Applications (ARIA) は障がいのある人にとってウェブをもっとアクセシブルにする方法です。それに従ういくつかのガイドラインは、ウィジェットの配置のためのドラッグアンドドロップのように、よりよいアクセシビリティを保証します。

+ + diff --git a/files/ja/web/accessibility/aria/aria_live_regions/index.html b/files/ja/web/accessibility/aria/aria_live_regions/index.html new file mode 100644 index 0000000000..15bffb8945 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_live_regions/index.html @@ -0,0 +1,227 @@ +--- +title: ARIA ライブリージョン +slug: Web/Accessibility/ARIA/ARIA_Live_Regions +tags: + - ARIA + - Accessibility + - ariaLive +translation_of: Web/Accessibility/ARIA/ARIA_Live_Regions +--- +

JavaScript を使うと、検索結果のリストを瞬時に更新する、もしくはユーザーの操作を必要としないような控えめなアラートや通知を表示するなど、ページ全体をリロードせずにページの一部を動的に変更することができます。 これらの変更は通常ページを見ることのできるユーザーにとっては視覚的に明らかですが、支援技術ユーザーにとっては明確ではないかもしれません。ARIA ライブリージョンはこのギャップを埋め、動的なコンテンツの変更を支援技術により通知できるやり方で、プログラムによって表出させる方法を提供します。

+ +
+

注記: 支援技術はライブリージョンへのコンテンツの動的な変更を通知します。ライブリージョンはブラウザーと支援技術が認識できるように最初から（かつ空で）存在しなければなりません。続いて後に起こる変更は通知されます。

+ +

単に読み込まれた最初のマークアップに aria-live 属性もしくは 特化したライブリージョン role （例えば role="alert" など）を含めても何も効果はありません。

+ +

aria-live 属性もしくは特化した role をドキュメントへ動的に追加しても支援技術による通知は発生しません (その時点で支援技術はまだライブリージョンを認識していないので、変更を監視することができません)。

+ +

常にライブリージョンが最初からドキュメントに存在することを確認して動的なコンテンツの追加／変更をしてください。

+
+ +

単純なライブリージョン

+ +

ページのリロードなしに更新される動的なコンテンツは、ほとんどの場合領域もしくはウィジェットのどちらかです。 対話的でないシンプルなコンテンツの変更は、ライブリージョンとして記されるべきです。以下は、関連する ARIA ライブリージョンプロパティと説明の一覧です。

+ +
    +
  1. aria-live: aria-live=POLITENESS_SETTING はスクリーンリーダーがライブリージョンの更新処理の優先度を設定するために使われます。設定は off、polite、 assertive で、デフォルトは off です。この属性は間違いなく最も重要な属性です。
    2. +
  2. +

    aria-controls: aria-controls=[IDLIST] は領域とそれをコントロールするものを関連付けるために使用されます。領域は div の id のように識別され、スペースを用いて複数の領域を aria-controls に関連付けることができます。例えば aria-controls="myRegionID1 myRegionsID2"。

    + +
    ライブリージョンの aria-controls の側面が現在の AT に実装されているか、どの AT で実装されているかはわかりません。調査が必要です。
    +
    3. +
+ +

通常、aria-live="polite" のみが使われます。ユーザーにとって重要な更新を受け取るが、うるさくなるほど速くすべきでない領域にはこの属性を設定すべきです。スクリーンリーダーはユーザーがアイドル状態になったときに読み上げを行います。

+ +

重要ではない、もしくは迅速な更新や他の理由からうるさくなるような領域は、aria-live="off" で黙らせます。

+ + + +

ある惑星についての情報を提供することに特化したウェブサイトはドロップダウンボックスを提供します。ドロップダウンから惑星が選ばれたとき、選択された惑星の情報でページ上のリージョンは更新されます。

+ +

HTML

+ +
<fieldset>
+  <legend>Planet information</legend>
+  <label for="planetsSelect">Planet:</label>
+  <select id="planetsSelect" aria-controls="planetInfo">
+    <option value="">Select a planet&hellip;</option>
+    <option value="mercury">Mercury</option>
+    <option value="venus">Venus</option>
+    <option value="earth">Earth</option>
+    <option value="mars">Mars</option>
+  </select>
+  <button id="renderPlanetInfoButton">Go</button>
+</fieldset>
+
+<div role="region" id="planetInfo" aria-live="polite">
+  <h2 id="planetTitle">No planet selected</h2>
+  <p id="planetDescription">Select a planet to view its description</p>
+</div>
+
+<p><small>Information courtesy <a href="https://en.wikipedia.org/wiki/Solar_System#Inner_Solar_System">Wikipedia</a></small></p>
+
+ +

JavaScript

+ +
const PLANETS_INFO = {
+  mercury: {
+    title: 'Mercury',
+    description: 'Mercury is the smallest and innermost planet in the Solar System. It is named after the Roman deity Mercury, the messenger to the gods.'
+  },
+
+  venus: {
+    title: "Venus",
+    description: 'Venus is the second planet from the Sun. It is named after the Roman goddess of love and beauty.'
+  },
+
+  earth: {
+    title: "Earth",
+    description: 'Earth is the third planet from the Sun and the only object in the Universe known to harbor life.'
+  },
+
+  mars: {
+    title: "Mars",
+    description: 'Mars is the fourth planet from the Sun and the second-smallest planet in the Solar System after Mercury. In English, Mars carries a name of the Roman god of war, and is often referred to as the "Red Planet".'
+  }
+};
+
+function renderPlanetInfo(planet) {
+  const planetTitle = document.querySelector('#planetTitle');
+  const planetDescription = document.querySelector('#planetDescription');
+
+  if (planet in PLANETS_INFO) {
+    planetTitle.textContent = PLANETS_INFO[planet].title;
+    planetDescription.textContent = PLANETS_INFO[planet].description;
+  } else {
+    planetTitle.textContent = 'No planet selected';
+    planetDescription.textContent = 'Select a planet to view its description';
+  }
+}
+
+const renderPlanetInfoButton = document.querySelector('#renderPlanetInfoButton');
+
+renderPlanetInfoButton.addEventListener('click', event => {
+  const planetsSelect = document.querySelector('#planetsSelect');
+  const selectedPlanet = planetsSelect.options[planetsSelect.selectedIndex].value;
+
+  renderPlanetInfo(selectedPlanet);
+});
+
+ +

{{EmbedLiveSample('Dropdown_box_updates_useful_onscreen_information', '', 350)}}

+ +

ユーザーが新しい惑星を選択したとき、ライブリージョンの情報が通知されます。ライブリージョンは aria-live="polite" を持っているため、更新の通知が行われる前にユーザーが一時停止するまでスクリーンリーダーは待ちます。例えばリストを下りながら他の惑星を選択してもライブリージョンの更新は通知されないでしょう。最終的に選ばれた惑星のみライブリージョンの更新は通知されます。

+ +

ここにはライブリージョンへ (字幕を通して) 更新を通知している、Mac に内蔵している VoiceOver のスクリーンショットがあります:

+ +

A screenshot of VoiceOver on Mac announcing the update to a live region. Subtitles are shown in the picture.

+ +

優先する専門のライブリージョンロール

+ +

次のよく知られている事前に定義されているケースでは、専門的に用意された "ライブリージョンロール" を使ったほうが良いでしょう:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ロール説明互換性に関する注意事項
logチャット、エラー、ゲームもしくは別種のログ互換性を最大限にするために、このロールを使う際には冗長な aria-live="polite" を追加します。
statusある種の更新された状態を表すステータスバーもしくはスクリーン領域。スクリーンリーダーのユーザーは現在のステータスを読みとるための特別なコマンドを持っています。互換性を最大限にするために、このロールを使う際には冗長な aria-live="polite" を追加します。
alertスクリーン上で点滅するエラーもしくはアラートメッセージ。アラートは特に、クライアントサイドでユーザーへのバリデーションの通知で重要です。(TBD: ARIAフォームのチュートリアルへのリンク)互換性を最大限にするために、このロールを使う際に aria-live="assertive" を追加するよう勧める人もいます。しかし、aria-live と role=alert の両方を追加することは iOS の VoiceOver で二重に読み上げられてしまうという問題を引き起こします。
progressbarウィジェットとライブリージョンのハイブリッド。aria-valuemin や aria-valuenow、aria-valuemax と共に使います。
marquee株式相場表示機のようなスクロールするテキストのためのものです。
timerカウントダウンタイマーやストップウォッチなどの、ある種のタイマーや時計。
+ +

高度なライブリージョン

+ +

(TBD: OS/Browser/AT の組み合わせによる個々の属性についてのサポートに関するより詳しい情報)。

+ +

一般的なライブリージョンへのサポートはバージョン 10.0 の JAWS へ追加されました。Windows Eyes ではバージョン 8.0 以降から「Microsoft Internet Explorer と Mozilla Firefox でブラウザーモード外での使用で」ライブリージョンをサポートしています。 NVDA は 2008年 に Mozilla Firefox に対するいくつかの基本的なライブリージョンのサポートを追加し、2010 年から 2014 年までに改善されました。2015 年には Internet Explorer (MSHTML) 向けにも基本的なライブリージョンのサポートが追加されました。

+ +

The Paciello Group は、ライブリージョンのサポート状況についての情報 (2014) をいくつかもっています。Paul Jadam は特に aira-atomic と aria-relevant のサポートについてのリサーチをしました。

+ +
    +
  1. aria-atomic: aria-atomic=BOOLEAN は領域の一部だけが変更された場合でも、スクリーンリーダーが常にライブリージョン全体を読み上げるかどうかを設定します。可能な設定は false または true で、デフォルトは false です。
    2. +
  2. aria-relevant: aria-relevant=[LIST_OF_CHANGES] はどういったタイプの変更がライブリージョンに関連するかを設定します。可能な設定は additions、removals、text、all で、 additions text がデフォルトです。
    3. +
  3. aria-labelledby: aria-labelledby=[IDLIST] は領域とラベルを関連付けるために使われます。aria-controls と似ていますが、複数のラベルを領域へ関連付けられ、複数のラベル識別子は空白によって区切られます。
    4. +
  4. aria-describedby: aria-describedby=[IDLIST] は領域と説明の関連付けを行います。aria-controls と似ていますが、複数の説明を領域を関連付けられ、説明の識別子は空白によって区切られます。
    5. +
+ +

高度なユースケース: Clock

+ +

aria-atomic についての説明のために、時間と分を表するシンプルな時計を表示するサイトを考えます。時計は単に現在のコンテンツを上書きする、新しい残り時間により毎分更新されます。

+ +
<div id="clock" role="timer" aria-live="polite"></div>
+
+ +
/* basic JavaScript to update the clock */
+
+setInterval(function() {
+  var now = new Date();
+  document.getElementById('clock').innerHTML = "Time: " + now.getHours() + ":" + ("0"+now.getMinutes()).substr(-2);
+}, 60000);
+
+ +

最初の関数が実行されると、追加された文字列のすべてが通知されます。 その後の呼び出しでは、過去のコンテンツと比較して変更されたコンテンツの一部が通知されます。例えば、時計が "17:33" から "17:34" へ変更されたとき、支援技術は "4" のみを通知します。これはユーザーにとってほとんど役に立たないでしょう。

+ +

一つの回避策は最初にライブリージョンのコンテンツをクリアしてから、新しいコンテンツを挿入することです。しかしながら、この方法はこれら二更新の正確なタイミングに依存するため、しばしば信頼性にかけることがあります。

+ +

aria-atomic="true" はライブリージョンが更新されるたびに、コンテンツの更新がすべて (例 "Time: 17:34") 通知されることを保証します。

+ +
<div id="clock" role="timer" aria-live="polite" aria-atomic="true"></div>
+
+ +

高度なユースケース: Roster

+ +

チャットサイトでは、現在ログインしているユーザーを表示したいと思うでしょう。ページをリロードすることなく、ユーザーのログインおよびログアウトステータスが動的に反映されるユーザーの一覧を表示します。

+ +
<ul id="roster" aria-live="polite" aria-relevant="additions removals">
+	<!-- use JavaScript to add remove users here-->
+</ul>
+
+ +

ARIA ライブプロパティの内訳:

+ + + +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/aria_screen_reader_implementors_guide/index.html b/files/ja/web/accessibility/aria/aria_screen_reader_implementors_guide/index.html new file mode 100644 index 0000000000..2cd5772e94 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_screen_reader_implementors_guide/index.html @@ -0,0 +1,32 @@ +--- +title: ARIA Screen Reader Implementors Guide +slug: Web/Accessibility/ARIA/ARIA_Screen_Reader_Implementors_Guide +translation_of: Web/Accessibility/ARIA/ARIA_Screen_Reader_Implementors_Guide +--- +

Live Regions

+ +

This is just a guide. Live region markup is a complex area which is somewhat open to interpretation. The following is intended to provide implementation guidance that respects screen readers developers' need to try different things. The intention is to strike a balance between providing useful guidance on how to use the markup's intended meaning while supporting live regions as an area for screen readers to innovate and compete.

+ +

Interpreting WAI-ARIA live region markup

+ +
    +
  1. Live changes are hints: in general live region markup is provided by the author as hints, and the assistive technology may allow for global, site or even region-specific settings, as well as heuristics to help with live changes on pages that have no WAI-ARIA hints.
    2. +
  2. Optionally, create a second, additional queue if the user configures a second hardware channel: If there are two channels for presentation (e.g. text to speech and a Braille display), then two queues can be maintained to allow for parallel presentation. The channels could be user configured for presenting live regions based on role or politeness.
    3. +
  3. Busy regions: Any changes in a region marked with aria-busy="true" should not be added to the queue until that attribute is cleared.
    4. +
  4. Politeness (aria-live or from role) takes first precedence,: items should be added to the queue based on their politeness level from the aria-live property or inherited from the role (e.g. role="log" is polite by default). Assertive items are first then politeness level. Alternatively, implementations may choose to have a policy of clearing more polite items, e.g. assertive items clear any polite items from the queue.
    5. +
  5. Time takes second precedence: Prioritize items with the same politeness level according to when the event occurs (earlier events come first). Present items of the same politeness level in the order of what occurred first.
    6. +
  6. Atomic (aria-atomic="true") regions with multiple changes should not be presented twice with the same content. As a new event for an atomic region is added to the queue remove an earlier event for the same region. It is probably desirable to have at least a tiny timeout before presenting atomic region changes, in order to avoid presenting the region twice for two changes that occur quickly one after the other.
    7. +
  7. Include labels when presenting changes: if the change occurs in something with a semantic label of some kind, speak the label. This is particularly important for changes in data cells, where the column and row headers provide important contextual information.
    8. +
+ +

Ideas for Settings and Heuristics

+ +
    +
  1. Allow for a different voice (in text-to-speech) or other varying presentational characteristics to set live changes apart.
    2. +
  2. When no WAI-ARIA markup is present, automatically present some changes unless the user configures all live changes to off. For example, automatically speak changes that are caused by the user's own input, as part of the context of that input.
    3. +
  3. Allow global settings to turn off the presentation of live changes, present all live changes, use markup, or be "smart" (use heuristics)
    4. +
+ +

Details for Processing via Platform Accessibility APIs

+ +

We hope browser manufacturers will work to provide consistent implementations. The most complete implementation of live regions currently is in Firefox 3.  Here is how WAI-ARIA live regions are exposed in Firefox 3.

diff --git a/files/ja/web/accessibility/aria/aria_techniques/index.html b/files/ja/web/accessibility/aria/aria_techniques/index.html new file mode 100644 index 0000000000..b9a4af2949 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/index.html @@ -0,0 +1,216 @@ +--- +title: 'ARIA を使用する: ロール、ステート、プロパティ' +slug: Web/Accessibility/ARIA/ARIA_Techniques +tags: + - ARIA + - Accessibility + - Overview + - Reference + - TopicStub +translation_of: Web/Accessibility/ARIA/ARIA_Techniques +--- +

ロール

+ + + +

ウィジェットロール

+ +
+ +
+ +

複合ロール

+ +

以下のテクニックでは、それぞれの複合ロールとその必須および任意の子ロールについて説明します。

+ +
+ +
+ +

文書構造ロール

+ +
+ +
+ +

ランドマークロール

+ +
+ +
+ +

ライブリージョンロール

+ +
+ +
+ +

ウィンドウロール

+ +
+ +
+ +

ステートとプロパティ

+ +

ウィジェット属性

+ +
+ +
+ +

ライブリージョン属性

+ +
+ +
+ +

ドラッグ＆ドロップ属性

+ +
+ +
+ +

関係属性

+ +
+ +
+ +

MicrosoftEdge 固有のプロパティ

+ +
+ +
diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_alert_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_alert_role/index.html new file mode 100644 index 0000000000..4e3afbf773 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_alert_role/index.html @@ -0,0 +1,145 @@ +--- +title: alert ロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role +tags: + - ARIA + - Accessibility + - Advanced + - CSS + - Example + - HTML + - NeedsContent + - alert + - alert role + - alertrole + - alerts + - assitive technology + - role configuration + - wcag1.2.1 + - wcag3.3.1 +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role +--- +

説明

+ +
+

alert ロールの使用方法についての技術デモとブラウザおよび支援技術に及ぼす影響の説明。

+
+ +

alert ロールは重要かつ一般に時間的制約のあるメッセージをユーザーへ伝えるために使用されます。このロールが要素へ追加されたとき、ブラウザはアクセシブルなアラートイベントをユーザーに向けて通知可能な支援技術製品へ送信します。 アラートロールはユーザの注意を即座に必要とする場合において最も便利です、例えば:

+ + + +

その押し付けがましい性質から、アラートロールはユーザーの注意を直ちに引く必要があるときにだけかつ控えめに使用されるべきです。 緊急度の低い動的な変更は、aria-live="polite" や他のライブリージョンロールなどのあまり積極的ではない方法を使うべきです。

+ +

ユーザーエージェントと支援技術への影響

+ +

アラートロールが要素へ追加されたとき、もしくはそのような要素が可視になったときにユーザーエージェントは以下のことを実行する必要があります:

+ + + +

支援技術製品はそのようなイベントを監視し、それに応じてユーザへ通知すべきです:

+ + + +
注釈: 支援技術がこの技術をどのように処理すべきかについては意見が異なる場合があります。上記の情報は意見の一つで、したがって標準ではありません。
+ +

例

+ +

例1: HTMLコードへのロールの追加

+ +

下のスニペットは html ソースコードへどうのようにアラートロールが直接追加されるかを示しています。要素が読み込み完了した瞬間にスクリーンリーダーはアラートの通知をするはずです。ページが読み込み終わったとき、もし要素がすでにオリジナルのソースコードにあったら、スクリーンリーダーはページタイトルをアナウンスした後にすぐにエラーを知らせるでしょう。

+ +
<h2 role="alert">Your form could not be submitted because of 3 validation errors.</h2>
+ +

例2: 動的にアラートロールをもつ要素を追加

+ +

このスニペットはアラートロールを持つ要素を動的に生成し、ドキュメント構造へ追加します。

+ +
var myAlert = document.createElement("p");
+myAlert.setAttribute("role", "alert");
+var myAlertText = document.createTextNode("You must agree with our terms of service to create an account.");
+myAlert.appendChild(myAlertText);
+document.body.appendChild(myAlert);
+
+ +

注: jQuery のようなスクリプトライブラリを使ったときはより少ないコードで同じ結果を実現することができます:

+ +
$("<p role='alert'>You must agree with our terms of service to create an account.</p>").appendTo(document.body);
+
+ +

例3: 存在する要素へのアラートロールの追加

+ +

時々新しい要素を作るよりもすでにページに見えている要素にアラートロールを追加するほうが便利なことがあります。これにより開発者はユーザーへより関連度や緊急性の高い情報を繰り返し表示することができます。例えば、フォームコントロールは期待値についての指示を持っているかもしれません。違う値が入力されたら、スクリーンリーダーがそれを警告としてアナウンスするために role="alert を指示文へ追加される場合があります。以下の疑似スニペットコードはこのアプローチを示しています:

+ +
<p id="formInstruction">You must select at least 3 options</p>
+
+ +
// When the user tries to submit the form with less than 3 checkboxes selected:
+document.getElementById("formInstruction").setAttribute("role", "alert");
+ +

例4: アラートロールをもつ要素を表示する

+ +

要素が既に role="alert" を持ち、CSS を使用して最初に非表示になっている場合、それを表示することはページにちょうど追加されたかのようにアラートをが発せられます。存在するアラートを何回も "再利用" できるということを意味しています。

+ +

注: ほとんどのケースではこのアプローチは推奨されません、なぜなら現在適応できないエラーやアラート文を隠すことは理想的ではないからです。古い支援技術のユーザーは現在アラートが適応されてないときにもかかわらずアラート文を認識して、ユーザへ問題があると間違って信じこませてしまうかもしれません。

+ +
.hidden {
+  display:none;
+}
+
+ +
<p id="expirationWarning" role="alert" class="hidden">Your log in session will expire in 2 minutes</p>
+
+ +
// removing the 'hidden' class makes the element visible, which will make the screen reader announce the alert:
+document.getElementById("expirationWarning").className = "";
+ +

実施例:

+ + + +

注記 

+ + + +

使用される ARIA 属性

+ + + +

関連 ARIA 技術

+ + + +

互換性

+ +

TBD: Add support information for common UA and AT product combinations

+ +

その他のリソース

+ + + +

 

diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_alertdialog_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_alertdialog_role/index.html new file mode 100644 index 0000000000..97ecd72b2b --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_alertdialog_role/index.html @@ -0,0 +1,86 @@ +--- +title: alertdialog ロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alertdialog_role +--- +

説明

+ +
+

このテクニックは、alertdialog ロールの使用方法を示しています。

+
+ +

alertdialog ロールは、ユーザーの即時の注意を要する緊急情報をユーザーに通知するために使用されます。 その名前が示すように、alertdialog は一種のダイアログです。 これは、「ARIA: dialog ロール」で提供されているほとんどの指示が alertdialog ロールにも適用できることを意味します。

+ + + +

通常のダイアログとの違いは、alertdialog ロールはアラート、エラー、またはワーニングが発生した場合にのみ使用するべきであることです。 言い換えれば、ダイアログの情報とコントロールがユーザの即時の注意を必要とするとき、dialog の代わりに alertdialog が使用されるべきです。 この区別をするのは開発者次第です。

+ +

その緊急性のために、アラートダイアログは常にモーダルでなければなりません。

+ +
注: このロールは、インタラクティブなコントロールに関連付けられているアラートメッセージにのみ使用するべきです。 アラートダイアログに静的コンテンツしか含まれておらず、インタラクティブなコントロールがまったくない場合は、alertdialog がここで使用する適切なロールではない可能性があります。 その場合は、代わりに alert ロールを使用するべきです（ARIA: alert ロールの説明を参照）。
+ +

ユーザーエージェントと支援技術への影響

+ +

alertdialog ロールが使用されるとき、ユーザーエージェントは以下を行うべきです。

+ + + +

アラートダイアログが表示されたら、スクリーンリーダーはアラートをアナウンスするべきです。

+ +

アラートダイアログが正しくラベル付けされ、ダイアログ内のコントロールにフォーカスが移動したら、スクリーンリーダーは、フォーカスが当たっている要素をアナウンスする前に、ダイアログのアクセス可能なロール、名前、およびオプションの説明をアナウンスするべきです。

+ +
注: 支援技術がこの技術をどのように処理するかについては、意見が異なる場合があります。 上記の情報はそれらの意見の一つであり、したがって規範的なものではありません。
+ +

例

+ +

例 1: 基本的なアラートダイアログ

+ +

以下のコードスニペットは、メッセージと[OK]ボタンだけを提供するアラートダイアログをマークアップする方法を示しています。

+ +
<div role="alertdialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
+  <div role="document" tabindex="0">
+    <h2 id="dialog1Title">あなたのログインセッションは期限切れになりそうです</h2>
+    <p id="dialog1Desc">セッションを延長するには、[OK]ボタンをクリックしてください。</p>
+    <button>OK</button>
+  </div>
+</div>
+ +

動作する例

+ +

TBD

+ +

注

+ +

使用された ARIA 属性

+ + + + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ +

 

diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-activedescendant_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-activedescendant_attribute/index.html new file mode 100644 index 0000000000..dc7aa54366 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-activedescendant_attribute/index.html @@ -0,0 +1,46 @@ +--- +title: aria-activedescendant 属性の使用 +slug: >- + Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-activedescendant_attribute +tags: + - ARIA + - Accessibility +translation_of: >- + Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-activedescendant_attribute +--- +

この記事では、aria-activedescendant プロパティについて説明します。

+ +

説明

+ +

aria-activedescendant 属性には、ドキュメントオブジェクトモデル内の複合ウィジェットの一部である、現在アクティブな子オブジェクトの ID が含まれます。 これは、1つ以上の子にフォーカスを持たせるというオーバーヘッドを伴います。 名前が指定するように、複合ウィジェットの現在アクティブな子を管理するのに役立ちます。

+ +

ユーザーエージェントと支援技術への影響

+ +

ユーザーエージェントは、検索、レンダリング、およびエンドユーザーとウェブコンテンツとのやりとりを容易にするソフトウェアで、aria-activedescendant プロパティを使用して、フォーカスを持っているアクティブな子について支援技術に通知します。 aria-activedescendant プロパティを使用するこのアクティブな子は、常に画面上に表示され、ドキュメントオブジェクトモデルのコンテナの子孫でなければなりません。

+ +
注: 支援技術がどのようにこの技術を扱うべきかについての意見は異なる場合があります。 以下に示す情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

Example 1: 

+ +

 

+ +
Code
+ +

動作する例

+ + + +

注 

+ +

使用された ARIA 属性

+ + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.html new file mode 100644 index 0000000000..95da78a286 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.html @@ -0,0 +1,89 @@ +--- +title: aria-describedby 属性の使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute +tags: + - ARIA + - Accessibility + - Attribute +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute +--- +

説明

+ +

aria-describedby 属性は、オブジェクトを説明する要素の ID を示すために使用されます。 これは、ウィジェットまたはグループとそれらを記述するテキストの間の関係を確立するために使用されます。 これは、aria-labelledby と非常によく似ています。 ラベルはオブジェクトの本質を表し、説明はユーザーが必要とする可能性のある詳細を提供します。

+ +

aria-describedby 属性はフォーム要素にのみ使用されるものではありません。 静的テキストをウィジェット、要素のグループ、ペイン、見出しを持つ領域、定義等々に関連付けるためにも使用されます。 以下の{{ anch("Examples","例") }}のセクションでは、これらの場合に属性を使用する方法の詳細について説明します。

+ +

この属性は、一般的な HTML フォーム要素で使用できます。 ARIA の role が割り当てられている要素に限定されるものではありません。

+ +

値

+ +

スペースで区切られた要素の ID のリスト

+ +

ユーザーエージェントと支援技術への影響

+ +

 

+ +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1: アプリケーションのランドマークの説明

+ +

以下の例では、導入の段落でカレンダーアプリケーションについて説明します。 aria-describedby は、段落をアプリケーションのコンテナに関連付けるために使用されます。

+ +
<div role="application" aria-labelledby="calendar" aria-describedby="info">
+    <h1 id="calendar">カレンダー</h1>
+    <p id="info">
+        このカレンダーには、ボストンレッドソックスのゲームの予定が表示されます。
+    </p>
+    <div role="grid">
+        ...
+    </div>
+</div>
+
+ +

例 2: 閉じるボタン

+ +

以下の例では、ダイアログの [閉じる] ボタンとして機能するリンクが、ドキュメントの別の場所で説明されています。 aria-describedby 属性は、説明をリンクに関連付けるために使用されます。

+ +
<button aria-label="Close" aria-describedby="descriptionClose"
+    onclick="myDialog.close()">X</button>
+
+...
+
+<div id="descriptionClose">このウィンドウを閉じると、入力された情報は破棄され、
+メインページに戻ります</div>
+
+ +

動作する例

+ + + +

注

+ + + +

ARIA ロールによって使用される

+ +

ベースマークアップのすべての要素

+ + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-invalid_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-invalid_attribute/index.html new file mode 100644 index 0000000000..60313d5874 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-invalid_attribute/index.html @@ -0,0 +1,128 @@ +--- +title: aria-invalid 属性の使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-invalid_attribute +tags: + - ARIA + - Accessibility + - Attribute + - CodingScripting + - HTML + - JavaScript +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-invalid_attribute +--- +

説明

+ +
+

このテクニックは、aria-invalid 属性を使用する方法を示しています。

+
+ +

aria-invalid 属性は、入力フィールドに入力された値がアプリケーションが予期している形式に準拠していないことを示すために使用されます。 これには、電子メールアドレスや電話番号などの形式が含まれます。 aria-invalid は、必須フィールドが入力されていないことを示すためにも使用できます。 属性は、検証処理の結果としてプログラムで設定する必要があります。

+ +

この属性は、一般的な HTML フォーム要素で使用できます。 ARIA の role が割り当てられている要素に限定されるものではありません。

+ +

値

+ +

語彙:

+ +
+
false
+
（デフォルト）エラーは検出されませんでした。
+
grammar
+
文法上の誤りが検出されました。
+
spelling
+
スペルミスが検出されました。
+
true
+
値は検証に失敗しました。
+
+ +

この語彙に含まれていない値はすべて true として扱われるべきです。

+ +

ユーザーエージェントと支援技術への影響

+ +

ユーザーエージェントは、フィールドが無効であるときにユーザーに通知するべきです。 アプリケーション作成者は、可能であれば、問題を修正するための提案を提供するするべきです。 作成者は、フォームが送信されるのを防ぐことができます。

+ +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1: 簡単なフォーム検証

+ +

次のスニペットでは、2つのフォームフィールドの簡略化されたバージョンを示し、検証関数は blur イベントに関連付けられています。 aria-required のデフォルト値は false なので、input に属性を追加することは厳密には必要ではないことに注意してください。

+ +
 <input name="name" id="name" aria-required="true" aria-invalid="false"
+        onblur="checkValidity('name', ' ', '無効な名前が入力されました（名と姓が必要です）');"/>
+ <br />
+ <input name="email" id="email" aria-required="true" aria-invalid="false"
+         onblur="checkValidity('email', '@', '無効な電子メールアドレスです');"/>
+
+ +

blur ですぐにフィールドを検証する必要はありません。 アプリケーションはフォームが送信されるまで待つことができます（これは必ずしも推奨されません）。

+ +

以下のスニペットは、特定の文字の存在をチェックする非常に簡単な検証関数を示しています（現実世界では、検証はより複雑になるでしょう）。

+ +
function checkValidity(aID, aSearchTerm, aMsg){
+    var elem = document.getElementById(aID);
+    var invalid = (elem.value.indexOf(aSearchTerm) < 0);
+    if (invalid) {
+        elem.setAttribute("aria-invalid", "true");
+        updateAlert(aMsg);
+    } else {
+        elem.setAttribute("aria-invalid", "false");
+        updateAlert();
+    }
+}
+
+ +

以下のスニペットは、エラーメッセージを追加（または削除）するアラート関数を示しています。

+ +
function updateAlert(msg) {
+    var oldAlert = document.getElementById("alert");
+    if (oldAlert) {
+        document.body.removeChild(oldAlert);
+    }
+
+    if (msg) {
+       var newAlert = document.createElement("div");
+        newAlert.setAttribute("role", "alert");
+        newAlert.setAttribute("id", "alert");
+        var content = document.createTextNode(msg);
+        newAlert.appendChild(content);
+        document.body.appendChild(newAlert);
+    }
+}
+
+ +

アラートには、ARIAの role 属性が "alert" に設定されていることに注意してください。

+ +

動作する例

+ +

alert ロールの例（aria-invalid 属性を使用）

+ +

注

+ + + +

ARIA ロールで使用

+ +

ベースマークアップのすべての要素

+ + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html new file mode 100644 index 0000000000..241c58bf0c --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html @@ -0,0 +1,61 @@ +--- +title: aria-label 属性の使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute +tags: + - ARIA + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute +--- +

aria-label 属性は、現在の要素にラベル付けする文字列を定義するために使用されます。 これはテキストラベルが画面に表示されない場合に使用します。 要素にラベル付けする目に見えるテキストがある場合は、代わりに aria-labelledby を使用します。

+ +

この属性は、一般的な HTML 要素で使用できます。 ARIA の role が割り当てられている要素に限定されるものではありません。

+ +

値

+ +

文字列

+ +

ユーザーエージェントと支援技術への影響

+ +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +
+

例 1: 閉じるボタン

+ +

以下の例では、ボタンは典型的な [閉じる] ボタンのようにスタイルされており、中央に X があります。 ボタンの目的がダイアログを閉じることであることを示すものは何もないので、aria-label 属性は、支援技術によりラベル付けするために使用されます。

+
+ +
<button aria-label="閉じる" onclick="myDialog.close()">X</button>
+
+ +

動作する例

+ +

 

+ +

注

+ + + +

ARIA ロールによって使用される

+ +

ベースマークアップのすべての要素

+ + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-labelledby_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-labelledby_attribute/index.html new file mode 100644 index 0000000000..2751fbd56e --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-labelledby_attribute/index.html @@ -0,0 +1,143 @@ +--- +title: aria-labelledby 属性の使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute +tags: + - ARIA + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute +--- +

説明

+ +

aria-labelledby  属性には、入力要素、ウィジェット、グループなどのオブジェクトのラベルの要素の ID が含まれます。 属性は、オブジェクトとそのラベルの間の関係を確立します。 スクリーンリーダーなどの支援技術では、この属性を使用してドキュメント内のオブジェクトをカタログ化し、ユーザーがドキュメント間を移動できるようにします。 要素の ID がなければ、支援技術はオブジェクトをカタログ化できません。

+ +

aria-labelledby は aria-describedby と非常によく似ています。 ラベルはオブジェクトに関する重要な情報を提供し、説明はユーザーが必要とする幅広い情報を提供します。

+ +

フォーム要素に加えて、aria-labelledby 属性を使用して、静的テキストをウィジェット、要素のグループ、枠、見出し、定義、およびその他のタイプのオブジェクトを持つ領域に関連付けることができます。 以下の{{ anch("Examples","例") }}のセクションでは、この方法で属性を使用する方法の詳細について説明します。

+ +

ARIA をサポートしていないユーザーエージェントとの互換性を向上させるために、aria-labelledby を {{ HTMLElement("label") }} 要素とともに使用できます（for 属性を使用）。

+ +

この属性は、一般的な HTML フォーム要素で使用できます。 ARIA の role が割り当てられている要素に限定されるものではありません。

+ +

値

+ +

スペースで区切られた要素の ID のリスト

+ +

ユーザーエージェントと支援技術への影響

+ +

ユーザーエージェントが aria-labelledby 属性と aria-label 属性の両方を持つ要素のアクセス可能な名前プロパティを計算するとき、ユーザーエージェントは aria-labelledby を優先します。

+ +

例

+ +

例 1: 複数のラベル

+ +

以下の例では、各入力フィールドは、それぞれの個別のラベルとグループのラベルの両方でラベル付けされています。

+ +
<div id="billing">請求書</div>
+
+<div>
+    <div id="name">名前</div>
+    <input type="text" aria-labelledby="billing name"/>
+</div>
+<div>
+    <div id="address">住所</div>
+    <input type="text" aria-labelledby="billing address"/>
+</div>
+
+ +

例 2: 見出しを領域に関連付ける

+ +

以下の例では、見出し要素は、見出しの内容に関連付けられています。 参照される領域は、見出しを含む領域であることに注意してください。

+ +
<div role="main" aria-labelledby="foo">
+   <h1 id="foo">サンディエゴ・ヒルズに広がる野火</h1>
+   強風が高温の炎を広げます...
+</div>
+
+ +

例 3: ラジオグループ

+ +

以下の例では、radiogroup のコンテナは、aria-labelledby 属性を使用してそのラベルに関連付けられています。

+ +
<div id="radio_label">私のラジオラベル</div>
+<ul role="radiogroup" aria-labelledby="radio_label">
+    <li role="radio">項目 #1</li>
+    <li role="radio">項目 #2</li>
+    <li role="radio">項目 #3</li>
+</ul>
+
+ +

例 4: ダイアログラベル

+ +

以下の例では、ダイアログのラベルを付ける見出し要素は、aria-labelledby 属性によって参照されます。

+ +
<div role="dialog" aria-labelledby="dialogheader">
+    <h2 id="dialogheader">ファイルを選択</h2>
+    ... ダイアログの内容
+</div>
+
+ +

例 5: インライン定義

+ +

以下の例では、ナレーションの自然な流れに記述されている用語の定義は、aria-labelledby 属性を使用してその用語自体に関連付けられています。

+ +
<p>医師は、それが<dfn id="placebo">プラセボ</dfn>であり、<span role="definition" aria-labelledby="placebo">
+疾病に対する実際の効果よりも、患者の精神的救済のためにより多く処方される不活性製剤</span>であると説明しました。
+</p>
+
+ +

例 6: 定義リスト

+ +

以下の例では、正式な定義リストの定義は、aria-labelledby 属性を使用して定義する用語に関連付けられています。

+ +
<dl>
+    <dt id="anathema">anathema</dt>
+    <dd role="definition" aria-labelledby="anathema">教会の権威によって厳粛に発音され、
+                                                     破門を伴う禁止または呪い</dd>
+    <dd role="definition" aria-labelledby="anathema">激しい告発 : カーソル</dd>
+
+    <dt id="homily">homily</dt>
+    <dd role="definition" aria-labelledby="homily">通常は短い説教</dd>
+    <dd role="definition" aria-labelledby="homily">道徳的テーマに関する講義や談話</dd>
+</dl>
+
+ +

例 7: メニュー

+ +

次の例では、aria-labelledby 属性を使用してポップアップメニューをラベルに関連付けています。

+ +
<div role="menubar">
+    <div role="menuitem" aria-haspopup="true" id="fileMenu">ファイル</div>
+    <div role="menu" aria-labelledby="fileMenu">
+        <div role="menuitem">開く</div>
+        <div role="menuitem">保存</div>
+        <div role="menuitem">名前をつけて保存 ...</div>
+        ...
+    </div>
+    ...
+</div>
+
+ +

注 

+ +

ラベルの最も一般的なアクセシビリティ API のマッピングは、アクセス可能な名前プロパティです

+ +

ARIA ロールによって使用される

+ +

ベースマークアップのすべての要素

+ + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-orientation_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-orientation_attribute/index.html new file mode 100644 index 0000000000..5e8a0c4277 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-orientation_attribute/index.html @@ -0,0 +1,89 @@ +--- +title: aria-orientation 属性の使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-orientation_attribute +tags: + - ARIA + - Accessibility + - Attribute +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-orientation_attribute +--- +

aria-orientation 属性は、要素が水平方向か垂直方向かを示すために使用されます。

+ +

値

+ +

語彙

+ + + + + + + + + + + + + + + + +
vertical要素は垂直方向です。
horizontal要素は水平方向です。
undefined（デフォルト）要素の方向は不明または曖昧です。
+ +

ユーザーエージェントと支援技術への影響

+ +

 

+ +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1:

+ +

下のスニペットは、垂直方向に向けられた単純なスライダを示しています。

+ +
<a href="#" id="handle_zoomSlider"
+        role="slider"
+        aria-orientation="vertical"
+        aria-valuemin="0"
+        aria-valuemax="17"
+        aria-valuenow="14" >
+    <span>11</span>
+</a>
+
+ +

動作する例

+ + + +

注

+ +

ARIA ロールで使用

+ + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + + +

 

diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-relevant_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-relevant_attribute/index.html new file mode 100644 index 0000000000..f515cbb04b --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-relevant_attribute/index.html @@ -0,0 +1,31 @@ +--- +title: aria-relevant 属性の使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-relevant_attribute +tags: + - ARIA + - Accessibility + - ariaLive +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-relevant_attribute +--- +

aria-relevant 属性は、aria-live リージョンにどのような変更が生じたかを記述するために使用されるオプションの値で、関連性があり、アナウンスする必要があります。 関連性のない変更は、aria-live 属性が off に設定されている場合と同じように動作します。

+ +

aria-relevant は、ウェブページにページを表示中に更新される可能性のあるコンテンツが含まれている場合によく使用されます。

+ +

値

+ +

スペースで区切られた次の値の1つ以上のリスト。

+ + + +

aria-relevant="additions text" は、ライブリージョンのデフォルト値です。

+ +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-required_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-required_attribute/index.html new file mode 100644 index 0000000000..d042420e74 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-required_attribute/index.html @@ -0,0 +1,79 @@ +--- +title: aria-required 属性の使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-required_attribute +tags: + - ARIA + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-required_attribute +--- +

Description

+ +

aria-required 属性は、フォームが送信される前に要素にユーザー入力が必要であることを示すために使用されます。 この属性は、一般的な HTML フォーム要素で使用できます。 ARIA の role が割り当てられている要素に限定されるものではありません。

+ +

{{ HTMLVersionInline("5") }} には required 属性が追加されましたが、まだ HTML5 をサポートしていないユーザーエージェントには aria-required はまだ役立ちます。

+ +

値

+ +

true または false（デフォルトは false）

+ +

ユーザーエージェントと支援技術への影響

+ +

スクリーンリーダーはフィールドが必須であることをアナウンスするべきです。

+ +

この属性は、フィールドの表現を自動的に変更しないことに注意してください。

+ +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1: 単純なフォーム

+ +

 

+ +
 <form action="post">
+     <label for="firstName">名:</label>
+     <input id="firstName" type="text" aria-required="true" />
+     <br/>
+     <label for="lastName">姓:</label>
+     <input id="lastName" type="text" aria-required="true" />
+     <br/>
+     <label for="streetAddress">住所:</label>
+     <input id="streetAddress" type="text" />
+ </form>
+
+ +

動作する例

+ +

ツールチップの例（aria-required 属性の使用を含む）

+ +

注

+ +

ARIA ロールで使用

+ + + + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuemax_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuemax_attribute/index.html new file mode 100644 index 0000000000..3bd75a909c --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuemax_attribute/index.html @@ -0,0 +1,73 @@ +--- +title: aria-valuemax 属性の使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-valuemax_attribute +tags: + - ARIA + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-valuemax_attribute +--- +
+
+

説明

+ +

aria-valuemax 属性は、スライダー、スピンボタン、プログレスバーなどの範囲ウィジェットに許容される最大値を定義するために使用されます。 aria-valuenow が既知の最大値と最小値を持つ場合、作成者は aria-valuemax と aria-valuemin のプロパティを提供するべきです（SHOULD）。 aria-valuemax の値は、aria-valuemin の値以上でなければならない（MUST）。

+ +

aria-valuemax はスライダー、スクロールバー、スピンボタンのロールの必須属性です。

+ +

値

+ +

数値の文字列表現

+ +

ユーザーエージェントと支援技術への影響

+ +

aria-valuemax が不定である場合、または aria-valuemin が aria-valuemax の値以下でない場合、これは支援技術によって処理されるエラー条件を生成します。

+ +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1:

+ +

下のスニペットは、最大値が 10 の単純なスライダーを示しています。

+ +
<div role="slider" aria-valuenow="4" aria-valuemin="1" aria-valuemax="10">
+
+ +

動作する例

+ + + +

注 

+ +

ARIA ロールで使用

+ + + + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + +
+
diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuemin_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuemin_attribute/index.html new file mode 100644 index 0000000000..566d21a2bf --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuemin_attribute/index.html @@ -0,0 +1,67 @@ +--- +title: aria-valuemin 属性の使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-valuemin_attribute +tags: + - ARIA + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-valuemin_attribute +--- +

aria-valuemin 属性は、スライダー、スピンボタン、プログレスバーなどの範囲ウィジェットに許容される最小値を定義するために使用されます。 aria-valuenow が既知の最大値と最小値を持つ場合、作成者は aria-valuemax と aria-valuemin のプロパティを提供するべきです（SHOULD）。 aria-valuemin の値は aria-valuemax の値以下でなければならない（MUST）。

+ +

aria-valuemin は、スライダー、スクロールバー、スピンボタンのロールの必須属性です。

+ +

値

+ +

数値の文字列表現

+ +

ユーザーエージェントと支援技術への影響

+ +

aria-valuemin が aria-valuemax の値以下でない場合、これは支援技術によって処理されるエラー条件を生成します。

+ +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1:

+ +

下のスニペットは、最小値が 1 の単純なスライダーを示しています。

+ +
<div role="slider" aria-valuenow="4" aria-valuemin="1" aria-valuemax="10">
+
+ +

動作する例

+ + + +

注

+ +

ARIA ロールで使用

+ + + + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuenow_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuenow_attribute/index.html new file mode 100644 index 0000000000..a074c74c7a --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuenow_attribute/index.html @@ -0,0 +1,73 @@ +--- +title: aria-valuenow 属性の使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-valuenow_attribute +tags: + - ARIA + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-valuenow_attribute +--- +

aria-valuenow 属性は、スライダー、スピンボタン、プログレスバーなどの範囲ウィジェットの現在の値を定義するために使用されます。 現在の値がわからない場合は、aria-valuenow 属性を設定しないでください。 aria-valuenow に既知の最小値と最大値がある場合、作成者は aria-valuemin 属性と aria-valuemax 属性を設定するべきです。

+ +

レンダリングされた値を数値として正確に表現できない場合、作成者は aria-valuetext 属性を aria-valuenow と組み合わせて使用して、範囲の現在の値の使いやすい表現を提供するべきです（SHOULD）。 たとえば、スライダーのレンダリング値が小、中、大の場合があります。 この場合、aria-valuenow の値は 1 〜 3 の範囲で値空間内の各値の位置を示しますが、aria-valuetext は、小、中、大のいずれかの文字列になります。

+ +

aria-valuenow はスライダー、スクロールバー、スピンボタンのロールの必須属性です。

+ +

値

+ +

数値の文字列表現

+ +

ユーザーエージェントと支援技術への影響

+ +

プログレスバーとスクロールバーのロールを持つ要素の場合、支援技術は、aria-valuemin から aria-valuemax までの範囲の位置として計算された実際の値をパーセンテージとしてレンダリングするべきです（SHOULD）。

+ +

スライダーとスピンボタンのロールを持つ要素の場合、支援技術は実際の値をユーザーにレンダリングするべきです（SHOULD）。

+ +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1:

+ +

下のスニペットは、現在の値が 4 の単純なスライダーを示しています。

+ +
<div role="slider" aria-valuenow="4" aria-valuemin="1" aria-valuemax="10">
+
+ +

動作する例

+ + + +

注 

+ +

ARIA ロールで使用

+ + + + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + + +

 

diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuetext_attribute/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuetext_attribute/index.html new file mode 100644 index 0000000000..1563eecbc9 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_aria-valuetext_attribute/index.html @@ -0,0 +1,64 @@ +--- +title: aria-valuetext 属性の使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-valuetext_attribute +tags: + - ARIA + - Accessibility + - Attribute +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-valuetext_attribute +--- +

aria-valuetext 属性は、プログレスバー、スピンボタン、スライダーなどの範囲ウィジェットの aria-valuenow に対する人間が読める代替テキストを定義するために使用されます。

+ +

作成者は、レンダリングされた値を数値として正確に表現できない場合にのみ、aria-valuetext 属性を設定するべきです（SHOULD）。 たとえば、スライダーのレンダリング値が小、中、大の場合があります。 この場合、aria-valuenow の値は 1 〜 3 の範囲で値空間内の各値の位置を示しますが、aria-valuetext は、小、中、大のいずれかの文字列になります。

+ +

値

+ +

数値の文字列表現

+ +

ユーザーエージェントと支援技術への影響

+ +

aria-valuetext 属性がない場合、支援技術は現在の値の aria-valuenow 属性のみに依存します。 aria-valuetext が指定されている場合、支援技術は aria-valuenow の値の代わりにその値をレンダリングするべきです（SHOULD）。

+ +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1:

+ +

下のスニペットは、曜日を選択するための簡単なスライダーを示しています。 スライダーの値は数値で、aria-valuetext 属性を使用してその日の名前を指定します。 アプリケーションは、aria-valuenow に応じてプログラムで aria-valuetext を更新します。

+ +
<div role="slider" aria-valuenow="1"
+	aria-valuemin="1" aria-valuemax="7"
+	aria-valuetext="日曜日">
+
+ +

動作する例

+ +

注 

+ +

ARIA ロールで使用

+ + + + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + + +

 

diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_button_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_button_role/index.html new file mode 100644 index 0000000000..b17fe32b00 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_button_role/index.html @@ -0,0 +1,123 @@ +--- +title: ボタンロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role +tags: + - ARIA + - Accessibility + - NeedsContent +translation_of: Web/Accessibility/ARIA/Roles/button_role +--- +

ボタンロールはユーザーが操作した際にレスポンスをトリガーするクリック可能な要素に使用されなければなりません。role="button" だけで、どんな要素 (例えば {{HTMLElement("p")}}、{{HTMLElement("span")}} や {{HTMLElement("div")}}) でもボタンコントロールとしてスクリーンリーダーへ認識させることができます。さらにこのロールは、トグルボタンを作るために aria-pressed と組み合わせて使うことが出来ます。

+ +
注記: できれば、button ロールよりもネイティブ HTML ボタン (<button>、<input type="button" />、<input type="submit" />、<input type="reset" />や<input type="image" />) を使うことをおすすめします。ネイティブ HTML ボタンは古いユーザーエージェントや支援技術から広くサポートされています。ネイティブ HTML ボタンは追加のカスタマイズなしに、キーボードやフォーカスの要件をサポートしています。
+ +

キーボードとフォーカス

+ +

ボタンはインタラクティブなコントールでなのでフォーカス可能です。もし button ロールがそれ自身ではフォーカス可能でない要素 (<span>、<div> もしくは <p> のような) に追加されたら、tabindex 属性がフォーカス可能なボタンを作るために使用されなければなりません。

+ +

ボタンはマウスユーザーとキーボードユーザーの両方が操作できます。ネイティブ HTML <button> 要素では、ボタンの onclick イベントはマウスクリックとフォーカスされている間に Space もしくは Enter が押されたときに発火します。しかし他のタグがカスタムボタンを作成するために使用されていたら、role="button" が使われていたとしても onclick イベントはマウスカーソルにクリックされたときにだけに発火するでしょう。このため、開発者は Space もしくは Enter キーが押されたときにトリガーされるために別のキーイベントハンドラを要素に追加しなければなりません。

+ +

警告: リンクをボタンロールによりマークアップする際は注意してください。ボタンは Space もしくは Enter キーを使ってトリガーされることが期待されますが、リンクは Enter キーが期待されます。 言い換えれば、リンクがボタンのように振る舞うようときは、role="button" が追加されるだけでは不十分です。ネイティブのボタンと矛盾しないために、Space キーをリッスンするキーイベントハンドラを追加する必要があります。

+ +

トグルボタン

+ +

role="button" を使う利点は、トグルボタンの作成が許可されていることです。トグルボタンには、押された状態と押されていない状態の2つの状態があります。ボタンがトグルボタンであるかどうかは、 button ロールに加えて aria-pressed 属性で指定することができます。

+ + + +

ボタンのラベリング

+ +

ボタンには常にアクセシブルな名前があるべきです。多くのボタンでは、この名前はボタンの中にあるテキストと同じです。場合によっては、例えばアイコンボタンでは、アクセシブルな名前は aria-label または aria-labelledby 属性を通して提供することができます。

+ +

ユーザーエージェントと支援技術への影響

+ +

button ロールが使用されているとき、ユーザーエージェントはその要素をオペレーティングシステムのアクセシビリティAPIにおけるボタンコントロールとして公開すべきです。スクリーンリーダーはその要素をボタンとして通知し、そのアクセシブルな名前を言述すべきです。音声認識ソフトウェアは「クリック」に続けてボタンのアクセシブルな名前を発声することでボタンを有効にすべきです。

+ +
Note: 支援技術がどのようにこの手法を扱うべきかについての意見は異なる場合があります。上記の情報はこれらの意見のひとつであり、従って規範的ではありません。
+ +

例

+ +

ARIA ベーシックボタン

+ +

以下のスニペットでは、 span 要素に button ロールが与えられています。 <span> 要素が使用されているため、ボタンをフォーカス可能にし、タブナビゲーション順の一部にするために tabindex 属性が必要です。このスニペットは、 <span> 要素をボタンのように見せるための CSS スタイルが提供され、 handleBtnClick と handleBtnKeyPress は、クリックされたときや Space  もしくは Enter  キーが押されたときにボタンのアクションを実行するイベントハンドラであることを示しています。

+ +
<span role="button" tabindex="0" onclick="handleBtnClick()" onKeyPress="handleBtnKeyPress()">Save</span>
+
+ +

ARIA トグルボタン

+ +

このスニペットでは {{HTMLElement("span")}} 要素が button ロールと aria-pressed 属性によってトグルボタンに変更されています。ボタンが作動したとき、 aria-pressed の値を true と false で切り替え続けます。

+ +

HTML

+ +
<button type="button" aria-pressed="false" onclick="handleBtnClick(event)">
+  Native button toggle
+</button>
+
+<span role="button" tabindex="0"
+ aria-pressed="false" onclick="handleBtnClick(event)"
+ onKeyPress="handleBtnKeyPress(event)">
+  Span button toggle
+</span>
+ +

CSS

+ +
button,
+[role="button"] {
+    padding: 3px;
+    border: 1px solid #CCC;
+}
+
+button:active,
+button:focus,
+[role="button"][aria-pressed="true"] {
+    border: 2px solid #000;
+}
+
+ +

JavaScript

+ +
function handleBtnClick(event) {
+  toggleButton(event.target);
+}
+
+function handleBtnKeyPress(event) {
+  // スペースかエンターが押されているかを確認
+  if (event.key === " " || event.key === "Enter") {
+    // スペースが押されたときにスクロールさせないためにデフォルトの振る舞いをキャンセル
+    event.preventDefault();
+    toggleButton(event.target);
+  }
+}
+
+function toggleButton(element) {
+  // ボタンが押されているかを確認
+  var pressed = (element.getAttribute("aria-pressed") === "true");
+  // aria-pressed をの状態を反転
+  element.setAttribute("aria-pressed", !pressed);
+}
+ +

結果

+ +

{{EmbedLiveSample('ARIA_Toggle_Button')}}

+ +

注記

+ +

使用された ARIA 属性

+ + + +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_checkbox_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_checkbox_role/index.html new file mode 100644 index 0000000000..13f3fa4b10 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_checkbox_role/index.html @@ -0,0 +1,63 @@ +--- +title: チェックボックスロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_checkbox_role +tags: + - ARIA + - Accessibility + - NeedsContent + - Role(2) + - Rôle +translation_of: Web/Accessibility/ARIA/Roles/checkbox_role +--- +

チェックボックスロールはチェック可能なインタラクティブなコントロールに使用されます。もし要素が role="checkbox" を使っていたら 、支援技術へチェックボックスのステートを公開するためにaria-checked 属性も持つ必要があります。ネイティブHTMLのチェックボックスフォームコントロールが２つののみ（ "checked" もしくは "not checked" ）をもてる一方で、role=checkbox 要素は aria-checked を通して３つのステートを公開できます:

+ + + +

開発者はチェックボックスが作動した際に、 aria-checked 属性を動的に変更する必要があります。

+ +

チェックボックスはインタラクティブなコントロールなので、フォーカス可能かつキーボードからアクセス可能でなければなりません。 ロールがフォーカス可能ではない要素に適応されたとしたら、フォーカスを可能にするために tabindex 要素が使用されなければなりません。チェックボックスを動作させるために期待されるキーボードショートカットはスペースキーです。

+ +

ユーザーエージェントと支援技術への影響 

+ +

チェックボックスロールが要素に付与されたときに、ユーザーエージェントは次のように振る舞わなければなりません:

+ + + +

支援技術製品は次のように振る舞わなければなりません:

+ + + +
注記: 支援技術がこの技術をどう扱うべきかについて、意見は分かれています。上記の情報はこれらの意見の一つであり、標準的なものではありません。
+ +

例

+ +

例1: ARIA によるチェックボックスロールの追加

+ +
<span role="checkbox" aria-checked="false" tabindex="0" id="chk1"></span>
+<label for="chk1">Remember my preferences</label>
+ +

注記 

+ +

使用された ARIA 属性

+ + + +

関連する ARIA 技術

+ +

互換性

+ +

TBD: 一般的なUAとAT製品の組み合わせサポート情報の追加

+ +

その他のリソース

diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_group_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_group_role/index.html new file mode 100644 index 0000000000..9cd767047d --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_group_role/index.html @@ -0,0 +1,124 @@ +--- +title: group ロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_group_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_group_role +--- +

説明

+ +

このテクニックは、group ロールを使用する方法を示し、ブラウザーと支援技術に与える影響について説明します。

+ +

group ロールは、region とは対照的に、目次やページの要約に含まれないように意図された一連のユーザーインターフェイスオブジェクトを識別するために使用されます（スクリプトや支援技術によって動的に作成される構造のような）。 グループ（group）はページ上で主要な知覚可能なセクションと見なされるべきではありません。 このロールが要素に追加されると、ブラウザーは、アクセス可能なグループイベントを支援技術製品に送り、支援技術製品はそれをユーザーに通知することができます。

+ +

グループは、階層内の兄弟の集合を形成するツリーウィジェット内の子供や、ディレクトリ内に同じコンテナを持つ項目の集合のような、関連する機能を持つ項目の論理的集合を形成するために使用されるべきです。 ただし、グループがリストのコンテキストで使用される場合、作者はその子を listitem 要素に制限する必要があります。 グループ要素はネストすることができます。

+ +

支援技術によるグループの適切な取り扱いは、それが提供されるコンテキストによって決まります。

+ +

作者がページの目次に含まれることを保証するためにセクションが重要であると考える場合は、そのセクションに region ロールまたは標準的なランドマークロールを割り当てるべきです。

+ +

ユーザーエージェントと支援技術への影響

+ +

group ロールが要素に追加されるか、またはそのような要素が可視になると、ユーザーエージェントは以下を行うべきです。

+ + + +

支援技術製品は、そのようなイベントをリスンし、それに応じてユーザーに以下を通知するべきです。

+ + + +
注: 支援技術がどのようにこの技術を扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1: HTML ツリービューでの group ロールの使用

+ +

以下のスニペットは、HTML ソースコードに group ロールを直接追加する方法を示しています。

+ +
<div id="tree1" role="tree" tabindex="-1">
+  <div id="animals" class="groupHeader" role="presentation" aria-owns="animalGroup" aria-expanded="true">
+    <img role="presentation" tabindex="-1" src="images/treeExpanded.gif" />
+    <span role="treeitem" tabindex="0">動物</span>
+  </div>
+  <div id="animalGroup" role="group">
+    <div id="birds" role="treeitem">
+      <span tabindex="-1">鳥</span>
+    </div>
+    <div id="cats" class="groupHeader" role="presentation" aria-owns="catGroup" aria-expanded="false">
+      <img role="presentation" tabindex="-1" src="images/treeContracted.gif" />
+      <span role="treeitem" tabindex="0">猫</span>
+    </div>
+    <div id="catGroup" role="group">
+      <div id="siamese" role="treeitem">
+        <span tabindex="-1">シャム猫</span>
+      </div>
+      <div id="tabby" role="treeitem">
+        <span tabindex="-1">虎猫</span>
+      </div>
+    </div>
+  </div>
+</div>
+ +

例 2: HTML ドロップダウンメニューでの group ロールの使用

+ +

以下のスニペットは、HTML ソースコードに group ロールを直接追加する方法を示しています。

+ +
<div role="menu">
+  <ul role="group">
+    <li role="menuitem">受信トレイ</li>
+    <li role="menuitem">アーカイブ</li>
+    <li role="menuitem">ごみ箱</li>
+  </ul>
+  <ul role="group">
+    <li role="menuitem">カスタムフォルダ 1</li>
+    <li role="menuitem">カスタムフォルダ 2</li>
+    <li role="menuitem">カスタムフォルダ 3</li>
+  </ul>
+  <ul role="group">
+    <li role="menuitem">新規フォルダ</li>
+  </ul>
+</div>
+ +

動作する例

+ + + +

注

+ + + +

使用された ARIA 属性

+ + + + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_link_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_link_role/index.html new file mode 100644 index 0000000000..0cf9c79aba --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_link_role/index.html @@ -0,0 +1,97 @@ +--- +title: link ロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_link_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_link_role +--- +

説明

+ +

このテクニックは、link ロールを使用する方法を示し、ブラウザーと支援技術に与える影響について説明します。

+ +

link ロールは、アプリケーションまたは外部にあるリソースへのハイパーリンクを作成する要素を識別するために使用されます。 このロールが要素に追加されると、タブを使用してリンクへのフォーカスを変更したり、リンクの実行にスペースやエンターを使用することができます。

+ +
注: 可能であれば、ネイティブ要素は古いユーザーエージェントや支援技術によって広くサポートされているため、link ロールではなくネイティブの {{HTMLElement("a")}} 要素を使用することをお勧めします。 ネイティブ {{HTMLElement("a")}} 要素は、追加のカスタマイズを必要とせずに、デフォルトでキーボードとフォーカスの要件もサポートしています。
+ +

tabindex 属性は、タブの順序で要素の位置を直接指定するために、このロールで任意に使用できます。

+ +

ユーザーエージェントと支援技術への影響

+ +

要素に link ロールが追加された場合、またはそのような要素が可視になる場合、ユーザーエージェントは以下を行うべきです。

+ + + +

支援技術製品は、そのようなイベントをリスンし、それに応じてユーザーに以下を通知するべきです。

+ + + +

 

+ +

注: 支援技術がどのようにこの技術を扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。

+ +

例

+ +

例 1: HTML コードにロールを追加する

+ +

以下のスニペットは、link ロールが html ソースコードに直接どのように追加されるかを示しています。

+ +
<div role="link">リンク</div>
+ + + +
<script type="text/javascript">
+sap = {ui:{keycodes:{SPACE:32, ENTER:13 }}};
+//リンク上のクリックとキーダウンを処理する
+function navigateLink(evt) {
+    if (evt.type=="click" ||
+        evt.keyCode == sap.ui.keycodes.ENTER) {
+        var ref = evt.target != null ? evt.target : evt.srcElement;
+        if (ref) window.open(ref.getAttribute("href"),"_blank");
+    }
+}
+</script>
+
+<body role="application">
+
+    <h3>span を使った単純なリンクの構築</h3>
+    <span href="http://www.w3c.org" onkeydown="navigateLink(event)" onclick="navigateLink(event)" tabindex="0" id="link1" role="link" class="link">
+      スペースバーまたはエンターキーを使用してこのリンクをアクティブ化します。
+    </span>
+</body>
+
+ +

注

+ +

リンクを押すとアクションがトリガーされますが、ブラウザーのフォーカスは変更されず、新しいページに移動することもありません。 link ロールの代わりに button ロールを使用することを検討してください。

+ +

使用された ARIA 属性

+ + + + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_log_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_log_role/index.html new file mode 100644 index 0000000000..91e3298f55 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_log_role/index.html @@ -0,0 +1,90 @@ +--- +title: log ロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_log_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_log_role +--- +

説明

+ +

このテクニックは、log ロールを使用する方法を示し、ブラウザーと支援技術に与える影響について説明します。

+ +

log ロールは、新しい情報が意味のある順序で追加され、古い情報が消えるライブリージョンを作成する要素を識別するために使用されます。 たとえば、チャットログ、メッセージ履歴、エラーログなどです。 他のタイプのライブリージョンとは対照的に、このロールは順番に並べられ、新しい情報はログの末尾にのみ追加されます。 このロールが要素に追加されると、ブラウザーは支援技術製品にアクセス可能なログイベントを送信し、ユーザーにそれを通知することができます。

+ +

デフォルトでは、更新にはライブリージョンの変更のみが含まれ、ユーザーがアイドル状態のときにアナウンスされます。 変更の際にライブリージョン全体を聞く必要がある場合、 aria-atomic="true" を設定するべきです。 できるだけ早くアナウンスし、ユーザーが中断する可能性がある場合は、より積極的な更新のために aria-live="assertive" を設定することができます。

+ +

ユーザーエージェントと支援技術への影響

+ +

要素に log ロールが追加されたとき、またはそのような要素が可視になるとき、ユーザーエージェントは以下を行うべきです。

+ + + +

支援技術製品は、そのようなイベントをリスンし、それに応じてユーザーに以下を通知するべきです。

+ + + +
注: 支援技術がどのようにこの技術を扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1: HTML コードにロールを追加する

+ +

以下のスニペットは、log ロールを HTML ソースコードに直接追加する方法を示しています。

+ +
<div id="liveregion" class="region" role="log"></div>
+ +

例 2: サンプルアプリケーションからのスニペット

+ +

このスニペットは AJAX チャットアプリケーションにおいてチャットログを作成します。

+ +
<div id="chatArea" role="log">
+  <ul id="chatRegion" aria-live="polite" aria-atomic="false">
+    <li>AJAX チャットの使用を開始するには、ユーザー名を選択してください。</li>
+  </ul>
+  <ul id="userListRegion" aria-live="off" aria-relevant="additions removals text">
+  </ul>
+</div>
+
+ +

動作する例

+ + + +

注

+ + + +

使用された ARIA 属性

+ + + + + + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_presentation_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_presentation_role/index.html new file mode 100644 index 0000000000..c5b0f28f40 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_presentation_role/index.html @@ -0,0 +1,53 @@ +--- +title: presentation ロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_presentation_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_presentation_role +--- +

このテクニックは、presentation ロールの使い方を示し、ブラウザーや支援技術への影響について説明します。

+ +

presentation ロールは、要素とそれに関連する子要素の意味論的意味を取り除くために使用されます。 例えば、レイアウト目的で使用される表は、表要素に presentation ロールを適用して、表要素およびその表に関連する子要素（表のヘッダーや表のデータの要素など）から意味論的意味を取り除けます。 しかし、表に関係のない要素は、その意味論的意味を保持するべきです。

+ +

ユーザーエージェントと支援技術への影響

+ +

 

+ +
注: 支援技術がどのようにこの技術を扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

Example 1: 

+ +

 

+ +
Code
+ +

動作する例

+ + + +

注

+ +

 

+ +

使用された ARIA 属性

+ +

 

+ + + +

 

+ +

互換性

+ +

 

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ +

 

diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_progressbar_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_progressbar_role/index.html new file mode 100644 index 0000000000..5d69e27437 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_progressbar_role/index.html @@ -0,0 +1,74 @@ +--- +title: progressbar ロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_progressbar_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_progressbar_role +--- +

このテクニックは、progressbar ロールの使い方を示し、ブラウザーや支援技術への影響について説明します。

+ +

progressbar ロールは、長い時間がかかったり、いくつかの手順で構成されるタスクの進捗状況を表示する要素に使用するべきです。

+ +

プログレスバーは、ユーザーの要求を受けて、アプリケーションが要求された操作を完了に向かって進捗していることを示します。 プログレスバーの実際の値が決定できる場合、開発者は aria-valuenow、aria-valuemin、aria-valuemax 属性を使用してこの進捗状況を示す必要があります。 進捗値が不確定な場合、開発者は aria-valuenow 属性を省略するべきです。

+ +

タスクが進捗するにつれて、aria-valuenow 値は、この進捗を支援技術製品に示すために動的に更新されなければならない。

+ +

プログレスバーがページの特定の領域のロード進捗状況を説明している場合、作者は、aria-describedby を使用してステータスを指し示すべきであり、ロードが完了するまで領域の aria-busy 属性を true に設定するべきです（SHOULD）。 これは常に読み取り専用なので、ユーザーはプログレスバーの値を変更することはできません。

+ +
注: 支援技術は、aria-valuetext が指定されていない限り、aria-valuemin の値と aria-valuemax の値の間の範囲のパーセントとして、aria-valuenow の値を一般にレンダリングします。 この計算に適した方法で、aria-valuemin、aria-valuemax、aria-valuenow の値を設定することをお勧めします。
+ +
注: progressbar ロールを持つ要素の暗黙の aria-readonly の値は true です。
+ +

ユーザーエージェントと支援技術への影響

+ +

スクリーンリーダーは進捗状況の更新が発生したときにアナウンスするべきです。 プログレスバーにラベルが付いている場合は、ラベルテキストも同様に述べるべきです。

+ +
注: 支援技術がどのようにこの技術を扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1: パーセンテージ値を持つ基本的なプログレスバー

+ +
<div role="progressbar" aria-valuenow="20" aria-valuemin="0" aria-valuemax="100">20 %</div>
+
+ +

 

+ +

例 2: aria-valuetext の使用

+ +
<div role="progressbar" aria-valuenow="20" aria-valuemin="0" aria-valuetext="ステップ 2: ファイルをコピーしています... " aria-valuemax="100">
+  ステップ 2: ファイルをコピーしています...
+</div>
+
+ +

 

+ +

動作する例

+ +

 

+ +

注

+ +

 

+ +

使用された ARIA 属性

+ + + + + +

 

+ +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_radio_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_radio_role/index.html new file mode 100644 index 0000000000..6b2b7dda4a --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_radio_role/index.html @@ -0,0 +1,53 @@ +--- +title: radio ロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_radio_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_radio_role +--- +

説明

+ +

このテクニックは、radio ロールをどのように使用するかを示し、ブラウザーと支援技術に及ぼす影響について説明します。

+ +

ユーザーエージェントと支援技術への影響

+ +
注: 支援技術がどのようにこの技術を扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1:

+ +

MDN ページの基本的なフォームのヒントからの例

+ +
<h3 id="rg1_label">ランチオプション</h3>
+
+<ul class="radiogroup" id="rg1" role="radiogroup" aria-labelledby="rg1_label">
+  <li id="r1" tabindex="-1" role="radio" aria-checked="false">
+    <img role="presentation" src="radio-unchecked.gif" /> タイ
+  </li>
+  <li id="r2" tabindex="-1" role="radio" aria-checked="false">
+    <img role="presentation" src="radio-unchecked.gif" /> サブウェイ
+  </li>
+  <li id="r3" tabindex="0" role="radio" aria-checked="true">
+    <img role="presentation" src="radio-checked.gif" /> ラジオマリア
+  </li>
+</ul>
+ +

動作する例

+ + + +

注

+ +

使用された ARIA 属性

+ + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_slider_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_slider_role/index.html new file mode 100644 index 0000000000..f8b1001d8e --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_slider_role/index.html @@ -0,0 +1,135 @@ +--- +title: slider ロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_slider_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_slider_role +--- +

 

+ +

このテクニックは、slider ロールの使い方を示し、ブラウザーと支援技術に及ぼす影響について説明します。

+ +

slider ロールは、ユーザーが所定の範囲内から値を選択できるマークアップに使用されます。 slider ロールは、値を変更するために調節するコントロールである「つまみ」に割り当てられます。 ユーザーがつまみとやり取りするとき、アプリケーションはスライダーの aria-valuenow（および可能なら aria-valuetext）属性をプログラムで調整して現在の値を反映する必要があります。 詳細については、下記の{{ anch("Examples","例") }}のセクションを参照してください。

+ +

キーボードとフォーカス

+ +

スライダーはキーボードでフォーカス可能で操作可能であるべきです。 ユーザーがタブキーでスライダーにフォーカスを合わせると、フォーカスはつまみに当たるべきです。 つまみはマウスのユーザーがドラッグするコントロールです。 矢印キーは、次のように操作する必要があります（右から左の言語のローカライゼーションは矢印の方向を逆にする必要があります）。

+ + + + + + + + + + + + + + + + + + + + + + +
キー動作
右矢印と上矢印選択した値を増やす
左矢印と下矢印選択した値を減らす
ページアップとページダウンオプションで、設定した量だけ値を増減します（例えば、0 ～ 100 の範囲で 10 ずつ）
+ +

ユーザーエージェントと支援技術への影響

+ +

 

+ +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1: 単純な数値範囲

+ +

次の例では、単純なスライダーを使用して 1 ～ 100 の値を選択しています。 現在のボリュームは 50 です。 アプリケーションは、ユーザーの入力に応じてプログラムで aria-valuenow の値を更新します。

+ +
<label for="fader">ボリューム</label>
+<input type="range"
+  id="fader"
+  min="1"
+  max="100"
+  value="50"
+  step="1"
+  aria-valuemin="1"
+  aria-valuemax="100"
+  aria-valuenow="50"
+  oninput="outputUpdate(value)">
+<output for="fader" id="volume">50</output>
+
+ +

次のコードスニペットを使用すると、ユーザー入力によって更新された出力を返すことができます。

+ +
function outputUpdate(vol) {
+  document.querySelector('#volume').value = vol;
+}
+
+ +

例 2: テキスト値

+ +

時には、意味的には数字ではない値を選択するためにスライダーが使用されることがあります。 このような場合、aria-valuetext 属性を使用して、現在選択されている値に対して適切なテキスト名を指定します。 次の例では、スライダーを使用して曜日を選択しています。

+ +
<label id="day-label">曜日</label>
+<div class="day-slider">
+  <div id="day-handle" class="day-slider-handle" role="slider" aria-labelledby="day-label"
+     aria-valuemin="1"
+     aria-valuemax="7"
+     aria-valuenow="2
+     aria-valuetext="月曜日">
+ </div>
+</div>
+
+ +

以下のコードスニペットは、ユーザーの入力に応答して aria-valuenow および aria-valuetext 属性を更新する関数を示しています。

+ +
var dayNames = ["日曜日", "月曜日", "火曜日", "水曜日", "木曜日", "金曜日", "土曜日"];
+var updateSlider = function (newValue) {
+    var handle = document.getElementById("day-handle");
+    handle.setAttribute("aria-valuenow", newValue.toString());
+    handle.setAttribute("aria-valuetext", dayNames[newValue]);
+};
+
+ +

動作する例

+ + + +

注

+ +

 

+ +

 

+ +

使用された ARIA 属性

+ + + + + +

 

+ +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_status_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_status_role/index.html new file mode 100644 index 0000000000..dfed2dab7a --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_status_role/index.html @@ -0,0 +1,82 @@ +--- +title: status ロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_status_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_status_role +--- +

説明

+ +

このテクニックは、status ロールを使用する方法を示し、ブラウザーと支援技術に及ぼす影響について説明します。

+ +

status ロールは、ライブリージョンの一種であり、内容は alert を正当化するほど重要ではないユーザーのためのアドバイザリ情報であり、多くの場合ステータスバーとして表示されます。 ロールが要素に追加されると、ブラウザーは、支援技術製品にアクセス可能なステータスイベントを送信し、ユーザーに通知することができます。

+ +

ステータス情報のコンテンツは、ステータスオブジェクト内に提供されなければならず、このオブジェクトがフォーカスを受け取らないようにするべきです。 ページの別の部分がステータスに表示されるものを制御する場合、関係は aria-controls 属性を介して明示的に指定するべきです。

+ +

支援技術は、ステータスをレンダリングするために点字ディスプレイのいくつかのセルを予約することができます。

+ +

ユーザーエージェントと支援技術への影響

+ +

status ロールが要素に追加されるか、またはそのような要素が可視になると、ユーザーエージェントは以下を行うべきです。

+ + + +

支援技術製品は、そのようなイベントをリスンし、それに応じてユーザーに以下を通知するべきです。

+ + + +
注: 支援技術がどのようにこの技術を扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1: HTMLで status ロールを追加する

+ +

以下のスニペットは、status ロールが html ソースコードに直接追加される仕組みを示しています。

+ +
<p role="status">変更は自動的に保存されました。</p>
+ +

動作する例

+ + + +

注

+ +

使用された ARIA 属性

+ + + + + + + +

互換性

+ + + +

その他のリソース

+ + diff --git a/files/ja/web/accessibility/aria/aria_techniques/using_the_toolbar_role/index.html b/files/ja/web/accessibility/aria/aria_techniques/using_the_toolbar_role/index.html new file mode 100644 index 0000000000..fec2cec021 --- /dev/null +++ b/files/ja/web/accessibility/aria/aria_techniques/using_the_toolbar_role/index.html @@ -0,0 +1,45 @@ +--- +title: toolbar ロールの使用 +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_toolbar_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_toolbar_role +--- +

説明

+ +

このテクニックは、toolbar ロールを使用する方法を示し、ブラウザーと支援技術に与える影響について説明します。

+ +

ユーザーエージェントと支援技術への影響

+ +

 

+ +
注: 支援技術がどのようにこの技術を扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

Example 1: 

+ +

 

+ +
Code
+ +

動作する例

+ +

W3C toolbar example

+ + + +

注

+ +

使用された ARIA 属性

+ + + +

互換性

+ +

TBD: 一般的な UA と AT 製品の組み合わせに関するサポート情報を追加する

+ +

その他のリソース

diff --git a/files/ja/web/accessibility/aria/forms/alerts/index.html b/files/ja/web/accessibility/aria/forms/alerts/index.html new file mode 100644 index 0000000000..3bce447f64 --- /dev/null +++ b/files/ja/web/accessibility/aria/forms/alerts/index.html @@ -0,0 +1,153 @@ +--- +title: alerts +slug: Web/Accessibility/ARIA/forms/alerts +tags: + - ARIA + - Accessibility + - Forms + - Web +translation_of: Web/Accessibility/ARIA/forms/alerts +--- +

問題点

+ +

アクセシブルなエラーチェックを組み入れたいフォーム、例えば問い合わせフォームがあります。よくある問題点は電子メールアドレスが有効ではない、あるいは名前欄に姓も名も含まれていないことです。

+ +

フォーム

+ +

始めに、aria-required の手法に関する記事を読んでいないのでしたら、まずはそちらをお読みください。ここでは、その手法を拡張します。

+ +

こちらがシンプルなフォームです:

+ +
 <form method="post" action="post.php">
+   <fieldset>
+     <legend>Please enter your contact details</legend>
+     <label for="name">Your name (required):</label>
+     <input name="name" id="name" aria-required="true"/>
+     <br />
+     <label for="email">E-Mail address (required):</label>
+     <input name="email" id="email" aria-required="true"/>
+     <br />
+     <label for="website">Website (optional):</label>
+     <input name="website" id="website"/>
+   </fieldset>
+   <label for="message">Please enter your message (required):</label>
+   <br />
+   <textarea name="message" id="message" rows="5" cols="80"
+             aria-required="true"></textarea>
+   <br />
+   <input type="submit" name="submit" value="Send message"/>
+   <input type="reset" name="reset" value="Reset form"/>
+ </form>
+
+ +

ストレートでシンプルですが、この時点では美しさの賞は与えられないでしょう。:-)

+ +

有効性の確認とユーザへの通知

+ +

有効性の確認とユーザへの通知は、いくつかのステップで構成されます:

+ +
    +
  1. 電子メールアドレスや入力された名前が有効かを確認します。シンプルにするため、電子メールアドレスは “@” 記号を含んでいるか、名前は空白 ” “ を少なくとも 1 文字含んでいるかを確認します。
    2. +
  2. フィールドの aria-invalid 属性を設定して、値を “true” にします。
    3. +
  3. alert を通して、入力した値が間違っていることをユーザに通知します。それには JavaScript の ‘alert’ 関数を使用した押しつけがましいダイアログボックスではなく、シンプルな WAI-ARIA のウィジェットを使用します。これはユーザに通知を行いますが、ユーザは割り込まれることなくフォームとの対話を続けられます。
    4. +
+ +

これらのすべては input がフォーカスを失ったとき、つまり “onblur” ハンドラの状況で発生します。

+ +

私が作成した JavaScript コードは以下のとおりであり、“head” の終了タグの前に挿入しました:

+ +
 <script type="application/javascript">
+ function removeOldAlert()
+ {
+   var oldAlert = document.getElementById("alert");
+   if (oldAlert)
+     document.body.removeChild(oldAlert);
+ }
+
+ function addAlert(aMsg)
+ {
+   removeOldAlert();
+   var newAlert = document.createElement("div");
+   newAlert.setAttribute("role", "alert");
+   newAlert.setAttribute("id", "alert");
+   var msg = document.createTextNode(aMsg);
+   newAlert.appendChild(msg);
+   document.body.appendChild(newAlert);
+ }
+
+ function checkValidity(aID, aSearchTerm, aMsg)
+ {
+   var elem = document.getElementById(aID);
+   var invalid = (elem.value.indexOf(aSearchTerm) < 0);
+   if (invalid) {
+     elem.setAttribute("aria-invalid", "true");
+     addAlert(aMsg);
+   } else {
+     elem.setAttribute("aria-invalid", "false");
+     removeOldAlert();
+   }
+ }
+ </script>
+
+ +

checkValidity 関数

+ +

中核をなすのが checkValidity 関数です。これは 3 つの引数をとります: 検証を行う input の ID、有効性を確かめるために検索する語句、alert に挿入するエラーメッセージです。

+ +

値が有効かを調べるため、この関数は input の値 indexOf が -1 より大きいかを確認します。検索語句が値の中で見つからないときに、-1 以下の値が返ります。

+ +

値が無効であるとき、この関数は 2 つのことを行います:

+ +
    +
  1. 要素の aria-invalid 属性を “true” に設定します。これは、そこに無効な内容物があることをスクリーンリーダーに示します。
    2. +
  2. 示されたエラーメッセージを持つ alert を追加するため、addAlert 関数を呼び出します。
    3. +
+ +

検索語句が見つかった場合は aria-invalid 属性を “false” にリセットします。加えて、まだ残っているかもしれない alert を削除します。

+ +

addAlert 関数

+ +

この関数は始めに、古い alert を削除します。この機能はシンプルです: id が “alert” である要素を探して、発見した場合はその要素を Document Object Model から削除します。

+ +

次にこの関数は、alert のテキストを保持する div 要素を作成します。これは “alert” という ID を持ちます。また、“alert” が設定された role を持ちます。これは属性名に “aria” がついていませんが、実は ARIA から生まれたものです。その理由は role が、簡素化のため単純に HTML へ移植された、XHTML Role Attribute Module に基づいているためです。

+ +

テキストは div 要素に追加され、また div 要素はドキュメントに追加されます。

+ +

これが発生したとき、その div が現れるとすぐに Firefox は支援技術に対して “alert”イベントを発生させます。ほとんどのスクリーンリーダーは自動的にその div 要素を拾い上げて、読み上げるでしょう。これはパスワードを保存したいかを尋ねる、Firefox の通知バーに似ています。ここで作成した alert はボタンを持たず、何が誤っているかを伝えるのみです。

+ +

“onblur” イベントのマジックを加える

+ +

あとはイベントハンドラの追加が残っています。以下のように電子メールアドレスと名前の入力欄の変更が必要です:

+ +
 <input name="name" id="name" aria-required="true"
+        onblur="checkValidity('name', ' ', 'Invalid name entered!');"/>
+ <br />
+ <input name="email" id="email" aria-required="true"
+        onblur="checkValidity('email', '@', 'Invalid e-mail address');"/>
+
+ +

サンプルのテスト

+ +

Firefox 3 およびサポート済みのスクリーンリーダーを使用している場合は、以下を試してみましょう:

+ +
    +
  1. 名前欄に (姓を除く) 名だけを入力してください。Tab キーを押すと、無効な名前を入力したことを伝える警告が聞こえるでしょう。Shift-Tab を押して戻り、エラーを修正できます。
    2. +
  2. “@” 記号がない電子メールアドレスを入力してください。Tab を押してフィールドを離れると、有効な電子メールアドレスを入力していないことを伝える警告が聞こえるでしょう。
    3. +
+ +

どちらのケースでも問題のフィールドへフォーカスを戻すと、スクリーンリーダーはそのフィールドのデータが無効であることを伝えるでしょう。JAWS 9 はこれをサポートしていますが JAWS 8 は未サポートであり、サポートしているスクリーンリーダーの前バージョンで動作するわけではありません。

+ +

よくある質問

+ +
+
Q. いくつかの input で、ラベルテキストの “(required)” と aria-required 属性の両方を置いている理由は?
+
A. これが実際のフォームで、またサイトを ARIA 未サポートのブラウザでアクセスされた場合でも、入力必須のフィールドであることを示したいと考えているためです。
+
Q. 無効なデータのフィールドへ自動的にフォーカスを戻さない理由は?
+
A. これは少なくとも Windows API の仕様で許可されていないなどの理由があります。また、実際のユーザとの対話なしにフォーカスを飛ばせるようにすることは、一般的によいことではありません。
+
+ +
TBD: これは再考しましょう -- 個人的には、キーボードトラップを発生させずに行えるのであれば、フォーカスの設定はよいであろうと考えます。
+ +

おわりに

+ +

Web サイトのアクセシビリティは、クライアントサイドの検証向けにアクセシブルな alert を提供することで大きく向上します。ユーザにとっては、20 個ほどのフィールドを埋めて送信するとフィールド 3 のデータが無効であるとわかるだけで、すべてのフィールドで値が残っているかを見直さなければならなかったりいくつかの情報を余計に入力したりすることより失望させられることはありません。

diff --git a/files/ja/web/accessibility/aria/forms/basic_form_hints/index.html b/files/ja/web/accessibility/aria/forms/basic_form_hints/index.html new file mode 100644 index 0000000000..f8fc0aea2c --- /dev/null +++ b/files/ja/web/accessibility/aria/forms/basic_form_hints/index.html @@ -0,0 +1,121 @@ +--- +title: 基本的なフォームのヒント +slug: Web/Accessibility/ARIA/forms/Basic_form_hints +tags: + - ARIA + - Accessibility + - Forms +translation_of: Web/Accessibility/ARIA/forms/Basic_form_hints +--- +

フォームラベル

+ +

伝統的な HTML のフォーム関連要素を使用してフォームを実装する際は、コントロール向けのラベルを提供することと、ラベルとコントロールとを明示的に結びつけることが重要です。スクリーンリーダーのユーザがページをナビゲートするときにスクリーンリーダーはフォームコントロールについて述べますが、コントロールトラベルとの間に直接的な結びつきがないと、どのラベルが適切かをスクリーンリーダーが知る方法がなくなります。

+ +

以下の例では、ラベルを持つシンプルなフォームを示しています。各 {{HTMLElement("input")}} 要素は id を持ち、また各 {{HTMLElement("label")}} 要素は結びつけられる {{HTMLElement("input")}} の id を示す、for 属性を持つことに注目してください。

+ +

例 1. ラベルを持つシンプルなフォーム

+ +
<form>
+  <ul>
+    <li>
+      <input id="wine-1" type="checkbox" value="riesling"/>
+      <label for="wine-1">Berg Rottland Riesling</label>
+    </li>
+    <li>
+      <input id="wine-2" type="checkbox" value="weissbergunder"/>
+      <label for="wine-2">Weissbergunder</label>
+    </li>
+    <li>
+      <input id="wine-3" type="checkbox" value="pinot-grigio"/>
+      <label for="wine-3">Pinot Grigio</label>
+    </li>
+    <li>
+      <input id="wine-4" type="checkbox" value="gewurztraminer"/>
+      <label for="wine-4">Berg Rottland Riesling</label>
+    </li>
+  </ul>
+</form>
+
+ +

ARIA でラベルをつける

+ +

HTML の {{HTMLElement("label")}} 要素はフォーム関連の要素にふさわしいのですが、多くのフォームコントロールは {{HTMLElement("div")}} や {{HTMLElement("span")}} を使用した、動的な JavaScript ウィジェットとして実装されています。W3C の Web Accessibility Initiative から生まれた WAI-ARIA こと Accessible Rich Internet Applications 仕様は、このような場合のために aria-labelledby 属性を用意しています。

+ +

以下の例では、順不同リストを使用して実装したラジオボタングループを示しています。3 行目で {{HTMLElement("li")}} 要素の aria-labelledby 属性に、1 行目の {{HTMLElement("h3")}} 要素の id である "rg1_label" を設定しており、h3 要素がラジオボタングループのラベルです。

+ +

例 2. 順不同リストを使用して実装したラジオボタングループ (http://www.oaa-accessibility.org/examplep/radio1/ をもとに改作)

+ +
<h3 id="rg1_label">Lunch Options</h3>
+
+<ul class="radiogroup" id="rg1"  role="radiogroup" aria-labelledby="rg1_label">
+  <li id="r1"  tabindex="-1" role="radio" aria-checked="false">
+    <img role="presentation" src="radio-unchecked.gif" /> Thai
+  </li>
+  <li id="r2"  tabindex="-1" role="radio"  aria-checked="false">
+    <img role="presentation" src="radio-unchecked.gif" /> Subway
+  </li>
+  <li id="r3"   tabindex="0" role="radio" aria-checked="true">
+    <img role="presentation" src="radio-checked.gif" /> Radio Maria
+  </li>
+</ul>
+
+ +

ARIA で説明する

+ +

フォームコントロールはラベルに加えて、説明文が結びつけられることがあります。ARIA には、説明文とコントロールを直接結びつけるための aria-describedby 属性があります。

+ +

以下の例では別の {{HTMLElement("div")}} 要素内の文で説明されている、{{HTMLElement("button")}} 要素を示しています。{{HTMLElement("button")}} 要素の aria-describedby 属性は {{HTMLElement("div")}} 要素の id を参照しています。

+ +

例 3. 別の要素で説明されているボタン

+ +
<button aria-describedby="descriptionRevert">Revert</button>
+<div id="descriptionRevert">Reverting will undo any changes that have been made
+                            since the last save.</div>
+ +

(aria-describedby 属性はフォームコントロールに加えて、他の用途にも使用されることに注意してください。)

+ +

必須のフィールドと正しくないフィールド

+ +

一般的に Web 開発者は、必須のフィールドや正しくないフィールドを示すために視覚的な方法を使用します。しかし、支援技術 (AT) は必ずしもその表示から情報を推測できるわけではありません。ARIA は、コントロールが必須あるいは正しくないことを示すための属性を用意しています:

+ + + +

以下の例では、3 つのフィールドを持つシンプルなフォームを示しています。4 行目から 12 行目で、name および email フィールドは入力必須であることを示すために (ラベルの隣にアスタリスクを置くのに加えて) aria-required 属性を true に設定しています。2 番目の例は電子メールの形式を検証して、その結果に応じて email フィールド (HTML の 12 行目) の (要素を視覚的に変化させるのに加えて) aria-invalid 属性を設定する JavaScript コードスニペットです。

+ +

例 4a. 必須のフィールドを持つフォーム

+ +
<form>
+  <div>
+    <label for="name">* Name:</label>
+    <input type="text" value="name" id="name" aria-required="true"/>
+  </div>
+  <div>
+    <label for="phone">Phone:</label>
+    <input type="text" value="phone" id="phone" aria-required="false"/>
+  </div>
+  <div>
+    <label for="email">* E-mail:</label>
+    <input type="text" value="email" id="email" aria-required="true"/>
+  </div>
+</form>
+ +

例 4b. フォームの入力内容を検証するスクリプトの一部

+ +
var validate = function () {
+  var emailElement = document.getElementById(emailFieldId);
+  var valid = emailValid(formData.email); // 正しい場合に true、そうでない場合に false を返す
+
+  emailElement.setAttribute("aria-invalid", !valid);
+  setElementBorderColour(emailElement, valid); // 第 2 引数が false である場合はボーダーを赤色に設定
+};
+ +

役に立つエラーメッセージの提供

+ +

フォームを強化するための ARIA alerts の使い方をご覧ください。

+ +
TBD: ひとつの記事にまとめるか、テクニックを分けるか、あるいはその両方を行うとよいでしょう。また ARIA のマークアップは、サーバサイドの検証の後に読み込まれたページ内のエラーメッセージにふさわしいのでしょうか?
+ +

フォームのアクセシビリティのために ARIA を使用する際のさらなるガイドラインについては、WAI-ARIA Authoring Practices のドキュメントをご覧ください。

diff --git a/files/ja/web/accessibility/aria/forms/index.html b/files/ja/web/accessibility/aria/forms/index.html new file mode 100644 index 0000000000..06d28f5f8d --- /dev/null +++ b/files/ja/web/accessibility/aria/forms/index.html @@ -0,0 +1,17 @@ +--- +title: フォーム +slug: Web/Accessibility/ARIA/forms +tags: + - ARIA + - Accessibility +translation_of: Web/Accessibility/ARIA/forms +--- +

以下のページでは、Web フォームのアクセシビリティを向上させるさまざまなテクニックを紹介します:

+ + + +

同様のコンテンツを多く扱っている、フォーム検証や ARIA に関する Yahoo! の記事もご覧ください。

diff --git a/files/ja/web/accessibility/aria/forms/multipart_labels/index.html b/files/ja/web/accessibility/aria/forms/multipart_labels/index.html new file mode 100644 index 0000000000..d2e3c6d4de --- /dev/null +++ b/files/ja/web/accessibility/aria/forms/multipart_labels/index.html @@ -0,0 +1,41 @@ +--- +title: マルチパートのラベル +slug: Web/Accessibility/ARIA/forms/Multipart_labels +tags: + - ARIA + - Accessibility + - Guide + - NeedsContent + - label +translation_of: Web/Accessibility/ARIA/forms/Multipart_labels +--- +
+

問題点

+ +

ユーザに質問をするフォームがありますが、その回答が質問文で触れられています。ブラウザの設定項目から皆が知っている伝統的な例を挙げると、“履歴を x 日後に削除する” 設定です。“履歴を” はテキストボックスの左側にあり、また x は例えば 21 といった数値であり、そして “日後に削除する” という文言はテキストボックスの後ろにあって、理解しやすい文を構成します。

+ +

スクリーンリーダーを使用している場合、Firefox でこの設定項目に達すると “履歴を 21 日後に削除する” と伝えられ、その後にあなたはテキストボックス内にいて、数値 21 が入っているとと知らされることに気づきます。すばらしいでしょう? 単位を見つけるために行き来する必要はありません。“日” は容易に “月” や “年” に変えることができ、また多くの通常のダイアログではこれを見つけるための方法が、スクリーンの再調査コマンドで行き来する以外にありません。

+ +

解決策は、ARIA の aria-labelledby という属性にあります。このパラメータは、ひとつのアクセシブルな名称になるように連結したい HTML 要素の ID で構成される文字列です。

+ +

aria-labelledby および aria-describedby はどちらもラベル付けされる要素、例えば <input> で指定します。どちらの場合もラベルとコントロールの紐付けがあってもかまいませんが、aria-labelledby によって上書きされます。aria-labelledby を提供する HTML ページでは、ARIA を未サポートとの古いブラウザもサポートするように構成したラベルも提供してください。Firefox 3 では新しい属性により、目の不自由なユーザが自動的によりよいアクセシビリティを得られますが、古いブラウザのユーザはこの方法でアクセシビリティがない状態を抜けられません。

+ +

例:

+Shut down computer after minutes + +
<input aria-labelledby="labelShutdown shutdownTime shutdownUnit" type="checkbox" />
+<span id="labelShutdown">Shut down computer after</span>
+<input aria-labelledby="labelShutdown shutdownTime shutdownUnit" id="shutdownTime" type="text" value="10" />
+<span id="shutdownUnit"> minutes</span>
+
+ +

JAWS 8 ユーザへの注意

+ +

JAWS 8.0 はラベルを発見する独自のロジックを持っており、常に HTML ドキュメントで見つけたテキストボックスの accessibleName より優先します。JAWS 8 で、上記の例からラベルを受け入れるようにする方法は見つかっていません。しかし NVDA や Window-Eyes の動作は良好であり、また Linux での Orca も問題がありません。

+ +
TBD: さらに互換性情報を追加する
+ +

ARIA を使用せずに実現できますか?

+ +

コミュニティーのメンバーである Ben Millard はブログへの投稿で、単に input を label 内に埋め込むことにより HTML 4 を使用して前出の例のようにコントロールをラベル内埋め込むことが可能であることを指摘しました。この情報をありがとう、Ben! これはとても役に立ち、また長年使用されてきたテクニックには時に権威から逃れるものもあることを示します。このテクニックは Firefox で動作しますが、現時点で IE を含む他の多くのブラウザは動作しません。従ってフォームコントロールを埋め込んだラベルについては、aria-labelledby を使用することがやはり最善の方法です。

+
diff --git a/files/ja/web/accessibility/aria/index.html b/files/ja/web/accessibility/aria/index.html new file mode 100644 index 0000000000..a262674af4 --- /dev/null +++ b/files/ja/web/accessibility/aria/index.html @@ -0,0 +1,126 @@ +--- +title: ARIA +slug: Web/Accessibility/ARIA +tags: + - ARIA + - Accessibility + - HTML +translation_of: Web/Accessibility/ARIA +--- +

Accessible Rich Internet Applications (ARIA) は Web コンテンツや Web アプリケーション (特に Ajax や JavaScript や Bootstrap のようなより最新のウェブ技術を伴って開発するもの) を、ハンディキャップを持つ人々にとってよりアクセシブルにする方法を定義します。例えば、ARIA はナビゲーションの目印、JavaScript ウィジェット、フォームのヒントやエラーメッセージ、動的なコンテンツ更新などをアクセシブルにします。

+ +

ARIA は任意のマークアップに追加できる特別なアクセシビリティの属性のセットですが、とりわけ HTML に適応しています。role 属性は、オブジェクトの一般的な型が何か (article、alert、slider など) を定義します。付加的な ARIA の属性は他の役に立つ特性、例えばフォームの説明やプログレスバーの現在の値を提供します。ARIA の属性はオブジェクト(特にボタン)のアクティブ/無効化の状態を指定するのにも使われます。

+ +

スクリーンリーダーにその要素が無視できるのを教える aria-hidden 属性は、ブラウザーに表示しないよう教える HTML5 の hidden 属性と混用されるべきではありません。

+ +

ARIA は、ほとんどの一般的なブラウザーやスクリーンリーダーに実装されています。ただし実装状況はまちまちであり、また古い技術では (どうあっても) それを十分にサポートしていません。上手に退行する "安全な" ARIA を使用するか、新しい技術へのアップグレードをユーザーに求めましょう。

+ +
+

注記: ぜひ貢献して、後進のために ARIA をよりよくしてください! 十分な時間がありませんか? でしたら、Mozilla のアクセシビリティメーリングリストや IRC の #accessibility チャンネルで提案してください。

+
+ +
+
+

ARIA 入門

+ +
+
ARIA の紹介
+
ARIA で動的コンテンツをアクセシブルにする方法の簡単な紹介です。2008 年に作成された、定評のある Gez Lemon 氏による ARIA の紹介もご覧ください。
+
Web アプリケーションと ARIA の FAQ
+
WAI-ARIA に関する一般的な質問や、なぜ Web アプリケーションをアクセシブルにすることが必要かに対する回答です。
+
Videos of Screen Readers Using ARIA
+
ARIA の導入 "前" および "後" を含む、Web の方々から集めた簡単な実例のビデオをご覧ください。
+
Using ARIA
+
+

開発者向けの実践的なガイドです。HTML 要素で使用する ARIA 属性は何かについて提案しています。提案内容は、実際の実装状況に基づいています。

+
+
+ +

簡単な ARIA の強化

+ +
+
Enhancing Page Navigation with ARIA Landmarks
+
スクリーンリーダーの利用者向けに Web ページのナビゲーションを向上させるための、ARIA landmark の使用法を紹介します。ARIA landmark の実装状況の覚え書きや実際のサイトでの例もご覧ください (2011 年 7 月更新)。
+
フォームのアクセシビリティ向上
+
ARIA は動的コンテンツのためだけのものではありません! 付加的な ARIA の属性を使用して HTML フォームのアクセシビリティを向上させる方法を学びましょう。
+
Live regions (作成中)
+
Live region は、ページのコンテンツの変化をどのように制御するかに関する提案を、スクリーンリーダーに与えます。
+
Using ARIA Live Regions to Announce Content Changes
+
スクリーンリーダーソフトウェア JAWS の作者による、Live region の簡単な概説です。なお、live region は Firefox での NVDA や、Safari での VoiceOver (OS X Lion および iOS 5) でもサポートされています。
+
+ +

スクリプトウィジェット向け ARIA

+ +
+
JavaScript ウィジェット向けのキーボードナビゲーションとフォーカス
+
アクセシブルな JavaScript ウィジェットを作成する最初のステップは、キーボードでナビゲーション可能にすることです。この記事では、そのプロセスを見ていきます。Yahoo! のフォーカス制御に関する記事もすばらしい情報源です。
+
Style Guide for Keyboard Navigation
+
ARIA は、開発者に一貫性のある動作を実装させることに挑戦します。それは明らかにユーザーにとってもっともよいことです。このスタイルガイドは、一般的なウィジェット向けのキーボードインターフェイスを説明します。
+
+ +

リファレンス

+ +
+
ウィジェット技術、チュートリアル、サンプル
+
スライダー、メニュー、あるいは他のウィジェットが必要ですか? こちらで情報を見つけましょう。
+
ARIA が有効な JavaScript UI ライブラリ
+
新たなプロジェクトを始める場合は、ARIA サポートが組み込まれた UI ウィジェットライブラリを選択しましょう。注意: これは 2009 年から存在する記事です。更新することが可能な MDN のページへコンテンツを移行すべきでしょう。
+
+ +
+
Role attribute-ARIA
+
role 属性の提案。
+
+

例

+
+
ARIA サンプルライブラリ
+
学びやすくなっている、要点のサンプルファイルを集めています。
+
アクセシブルな JS ウィジェットライブラリのデモ
+
jQuery, YUI
+
+ +

標準化の取り組み

+ +
+
W3C の WAI-ARIA 活動の概要
+
Web Accessibility Initiative (WAI) による、WAI-ARIA の標準化の取り組みに関する権威ある概要です。
+
+WAI-ARIA 仕様 + +
+
W3C の仕様そのものであり、リファレンスとして有用です。まだ実装に不一致がみられるため、現時点では互換性のテストが重要であることに注意してください。
+
WAI-ARIA Authoring Practices
+
W3C の WAI-ARIA 仕様と同様に、将来の理想 (さまざまなブラウザーやスクリーンリーダーで一貫性のある ARIA サポートに作成者が頼れるとき) を表した公式のベストプラクティスです。W3C のドキュメントは ARIA の深い視点をもたらします。
+
+ 今のところ、ARIA を実装する Web 開発者は互換性を最大化するべきです。現在の実装状況に基づいて、ベストプラクティスのドキュメントやサンプルを使用しましょう。
+
Open AJAX Accessibility Task Force
+
Open AJAX は、ARIA の開発ツール、サンプルファイル、自動テストを中心に取り組んでいます。
+
作成中: WCAG 2.0 ARIA Techniques
+
+

コミュニティは WAI-ARIA + HTML 向けの WCAG 技術の完全なセットを求めており、それにより組織は自身の ARIA が有効なコンテンツが WCAG に準拠するという要求を満たすことができます。これは主として、規則や方針が WCAG に基づいている場合に重要です。

+
+
+
+ +
+

ブログ

+ +

ブログ上の ARIA に関する情報は、早々に古くなってしまう傾向があります。それでも、現在 ARIA に取り組んでいる他の開発者が提供したすばらしい情報があります。

+ +

Paciello Group

+ +

動画

+ +

Following talks are a great way to understand ARIA:

+ +

ARIA, Accessibility APIs and coding like you give a damn! – Léonie Watson

+ +

バグ報告

+ +

ブラウザー、スクリーンリーダー、JavaScript ライブラリの ARIA に関するバグを報告してください。

+
+
+ + + +

Accessibility, AJAX, JavaScript

diff --git a/files/ja/web/accessibility/aria/roles/alert_role/index.html b/files/ja/web/accessibility/aria/roles/alert_role/index.html new file mode 100644 index 0000000000..89b0251538 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/alert_role/index.html @@ -0,0 +1,70 @@ +--- +title: 'ARIA: alert ロール' +slug: Web/Accessibility/ARIA/Roles/Alert_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Alert_Role +--- +

\{{ariaref}}alert ロールは、要素が動的に更新されたことをユーザーに通知するために使用できます。 ロールが追加されると、スクリーンリーダーは更新されたコンテンツの読み上げを即座に開始します。 ユーザーがアラートを閉じることを期待する場合は、代わりに alertdialog ロールを使用するべきです。

+ +

説明

+ +

5つのライブリージョンロールの1つである alert ロールは、重要な、通常は時間依存の情報をユーザーに提供するために使用され、要素が動的に更新されたことをユーザーに伝えることがよくあります。

+ +

alert ロールは、アラート（alert）メッセージを含むノードに追加し、アラートをトリガーする要素には追加しません。 アラートは主張的なライブリージョンです。 role="alert" の設定は、aria-live="assertive" と aria-atomic="true" の設定と同じです。 それらはフォーカスを受け取らないので、フォーカスを管理する必要はなく、ユーザーインタラクションを必要とするべきではありません。

+ +

alert ロールについて最も重要なことは、動的コンテンツ用であることです。 ユーザーがフォームに記入し、JavaScript を使用してエラーメッセージを追加すると、アラートがすぐにメッセージを読み上げるなどの状況に最適です。 ユーザーが HTML と対話していない HTML 上では使用するべきではありません。 例えば、ページ上に複数の可視のアラートが散在して読み込まれたページは、動的にトリガーされないため読み上げられません。

+ +

例

+ +

アラートをトリガーする最も基本的な方法は、デフォルトで display: none; を持つ要素に role="alert" を追加することです。 CSS や JavaScript で display の値を変更すると、自動的にスクリーンリーダーがコンテンツを読み上げるようになります。

+ +
<p role="alert" style="display: none;">要素が表示されるとアラートがトリガーされます。</p>
+ +

CSS だけでアラートをトリガーすることは可能ですが、ブラウザやスクリーンリーダーのサポートが増え、イベントハンドラやフォームの検証などのより大きなユーザーインタラクションの一部として、より適切な場合が多いため、JavaScript を使用する方がよいでしょう。 JavaScript を使用すると、開発者はアラートの追加と削除を適切に制御できます。

+ +
<button type="button" onclick="triggerAlert">アラートをトリガー</button>
+<p class="alert">ボタンを押すとアラートがトリガーされます。</p>
+
+ +
function triggerAlert() {
+  var alertEl = document.querySelector('.alert');
+  alertEl.addAttribute("role", "alert");
+}
+
+ +

（訳注：ARIA ライブリージョンによると、alert ロールを動的に追加してもトリガーされないそうです。）

+ +

アクセシビリティに関する懸念

+ +

alert ロールは、変更されたコンテンツを読み上げるべきで、直ちにユーザーの注意を引く必要があるため、静的コンテンツに使用したり、定期的に使用したりするべきではありません。 アラートは、定義上、破壊的です。 一度にたくさんのアラートがある場合や、不必要なアラートがある場合、悪いユーザーエクスペリエンスをもたらします。

+ +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#alert","Alert")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#alert","Alert")}}{{Spec2('ARIA Authoring Practices')}}
+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/application_role/index.html b/files/ja/web/accessibility/aria/roles/application_role/index.html new file mode 100644 index 0000000000..151333eb49 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/application_role/index.html @@ -0,0 +1,108 @@ +--- +title: 'ARIA: application ロール' +slug: Web/Accessibility/ARIA/Roles/Application_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Application_Role +--- +

\{{ariaref}}application ロールは、要素とその全ての子要素をデスクトップアプリケーションと同様に扱うべきであり、伝統的な HTML 解釈テクニックを使用するべきでないと支援技術に指示します。 このロールは、とても動的でデスクトップ的なウェブアプリケーションを定義するためにのみ使用するべきです。

+ +
<div role="application">...</div>
+
+ +

これは、デスクトップアプリケーションの一部であるように、この <div> 要素とその全ての子孫を処理することを定義します。

+ +

説明

+ +

application ロールは、支援技術に対して、ウェブコンテンツのこの部分に、他の既知の HTML 要素や WAI-ARIA ウィジェットに適合しない要素が含まれていることを示します。 HTML 構造やウィジェットの特別な解釈は一切中止し、マウスやキーボード、タッチのインタラクションを扱うためには、コントロールをブラウザーやウェブアプリケーション（web application）に完全に渡すべきです。

+ +

このモードでは、ウェブ作成者は、キーボード入力、フォーカス管理、その他のインタラクションを全て処理する責任があり、支援技術が最終的に何らかの処理を行うとは想定できません。

+ +

application ロールに包まれるウェブアプリケーションに、通常のウェブコンテンツと同様に扱われるべき部分が含まれている場合は、document ロールや article ロールを使用するべきです。

+ +

背景

+ +

歴史的な理由で、特に Windows 上では、スクリーンリーダーやその他の支援技術（AT）は、従来、読み込みが完了した後に、ブラウザーからウェブコンテンツ全体を一度に取得していました。 AT は、視覚障害者がコンテンツを消費するのに最も合理的な表現を独自に構築します。 これは、仮想ドキュメント、ブラウズモード、または類似の用語で呼ばれることがよくあります。 ドキュメントは単一列のビューに合理化されます。 キーボードインタラクションモデルが生成され、これはワードプロセッサにとても似ていて、このモデルでは、行単位、文単位、段落単位で読むことができます。 AT は、リンク、見出し、フォームコントロール、テーブル、リスト、画像のような任意の意味論を読みます。

+ +

さらに、長年にわたり、いわゆるクイックナビゲーションキーのセットが確立されているため、視覚障害者は特定の要素タイプを介してページを見ることができます。 このような要素には、通常、見出し、フォームフィールド、リスト、テーブル、リンク、グラフィック、ランドマークリージョンが含まれます。

+ +

この全てがうまくいくためには、AT はほぼ全てのキーボード入力を遮り、それを消費し、ブラウザーや他のユーザエージェントに何も送られないようにします。 ウェブページとインタラクションできるように、特定のキー（通常は Enter キー）を押すと、このモードはオフになり、標準的なウィジェットのセットが認識されます。 フォームモードやフォーカスモードとも呼ばれるスクリーンリーダーモードでは、全てのキーボード入力がブラウザーに再び送られます。 Esc キーはブラウズモードに切り替える最も一般的な方法です。

+ +

application ロールは、ウェブコンテンツとインタラクションするためにブラウズモードとフォーカスモードの両方を使用する AT において、直接的なインタラクションでアクセス可能な標準的なセットの一部ではないウィジェットのための手段を提供するように設計されています。

+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +
+
document, article
+
通常のウェブコンテンツとして扱われるべきアプリケーションの部分を示すために使用します。
+
aria-activedescendant
+
アプリケーション内でのフォーカスの管理に使用します。
+
aria-label
+
公開されているアプリケーションの名前やウィジェットの目的を提供するために使用します。
+
aria-describedby
+
この要素をナビゲートまたは操作するための追加の説明書を含む要素の id 参照を示すのに使用します。
+
aria-roledescription
+
スクリーンリーダーが話すために、アプリケーションにもっと説明的なロールのテキストを与えるために使用します。 これはローカライズするべきです。
+
+ +

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

+ +

キーボードインタラクションは、完全にウェブ制作者のコントロール下にあり、実装されている特定のウィジェットに関連するものでもかまいません。 例えば、スライドアプリケーションでは、矢印キーを使用してスライド上の要素を配置し、ARIA のライブリージョンを介して音声によるフィードバックを使用して位置や他のオブジェクトとのオーバーラップの状態を伝えるウィジェットを作成できます。 フォーカスは、aria-activedescendant によって管理します。

+ +

Tab キー、スペースキー、Enter キー、および Esc キーは、アプリケーションで処理する必要があります。 1つの例外は、フォーカスが、ブラウザーからのキーボードナビゲーションをサポートするアプリケーション内の標準ウィジェット（例えば {{htmlelement("input")}} 要素）に設定されている場合です。

+ +

必要な JavaScript 機能

+ +
+
keyPress
+
キーボード入力の処理とフォーカスの制御に使用する。
+
Click, Touch
+
あなたのウィジェットにも適切に対処してください。
+
Changing attribute values
+
aria-activedescendant は、アプリケーションコンテナ内のフォーカスを管理するために使用されます。 フォーカスやインタラクションのポイントを変更するキーボードやその他のアプリケーションのイベントに応じて設定します。
+
+ +
+

application ロールには、関連する HTML ウィジェットがないため、完全に自由形式です。 アプリケーションの作成者は、ユーザーがフォーカスのリンボに拘束されたり、ユーザーが抜け出せないものの中にフォーカスを閉じ込められたりしないようにするために全面的な責任を負う必要があります。 ページの他の部分で通常のウェブコンテンツに戻ることを含む、インタラクションの全ての側面を処理する必要があります。 賢明に、そして慎重に使用してください！

+
+ +

例

+ +

application ロールを適切に使用するいくつかの有名なウェブアプリケーションは次のとおりです。

+ + + +

アクセシビリティに関する懸念

+ +

application ロールを不適切に使用すると、意図せずにウェブページの情報からのアクセスを奪う可能性があるので、使用には十分注意してください。 あなたが実際にそれを必要とし、他の既知のウィジェットのセットを使うことができない場合に、真剣に考えます。 使用する場合は、application ロールは、例えば <body> 要素ではなく、可能な最も低い共通コンテナに追加するべきです。

+ +

仕様

+ + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#application","application")}}{{Spec2('ARIA')}}
+ +

優先順位

+ +

application ロールを適用すると、この要素の全ての子孫要素がウェブコンテンツではなくアプリケーションコンテンツのように扱われます。 支援技術がウェブコンテンツに与えるであろう読み上げメカニズムは適用されません。

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/article_role/index.html b/files/ja/web/accessibility/aria/roles/article_role/index.html new file mode 100644 index 0000000000..9381ee3b24 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/article_role/index.html @@ -0,0 +1,114 @@ +--- +title: 'ARIA: article ロール' +slug: Web/Accessibility/ARIA/Roles/Article_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Article_Role +--- +

\{{ariaref}}article ロールは、ページ、ドキュメント、またはウェブサイト上で容易に自立することができるページのセクションを示します。 これは、通常、コメント、フォーラム投稿、新聞記事、または1ページにまとめられたその他項目などの関連コンテンツの項目に設定します。

+ +
<div role="article">
+<h2>この断片の見出し</h2>
+<p>この断片の段落。</p>
+<p>別の段落。</p>
+... 記事とインタラクションしたり、共有したり等するためのコントロール ...
+</div>
+<div role="article"> ... </div>
+
+ +

この例では、1ページに2つの記事を並べて表示しています。 これらは同じように構成でき、関連しています。

+ +
+

article ロールを持つ <div> ではなく、<article> 要素を使用します。 利用可能な場合は、いつでもネイティブの要素を使用します。

+
+ +

role="article" を使用する代わりに、{{htmlelement("article")}} 要素を使用することができます。

+ +
<article>
+<h2>この断片の見出し</h2>
+<p>この断片の段落。</p>
+<p>別の段落。</p>
+... 記事とインタラクションしたり、共有したり等するためのコントロール ...
+</article>
+<article> ... </article>
+
+ +

説明

+ +

article ロールは、ドキュメント、ページ、サイトのセクションを表し、それが単独で存在する場合は、完全なドキュメント、ページ、サイトとして見ることができます。 一連の記事（article）セクションの目的は、互いの関係を示すことです。

+ +

記事は、ナビゲーションに関するランドマークとは見なされませんが、ランドマークをサポートする多くの支援技術は、記事間をナビゲートする手段をサポートします。 また、記事内のネスト関係の表示をサポートすることもあります。

+ +

記事をネストすることができ、ネストされた記事は、それをネストしているものと直接関係しますが、必ずしもネスト階層の外側にあるものとは限りません。 具体的な使用事例については、例を参照してください。

+ +

記事がフィード（feed）の一部である場合、aria-posinset 属性および aria-setsize 属性を設定して、この特定の記事が表すフィード内の位置を示すことができます。

+ +

スクリーンリーダーやその他の支援技術がパススルーモードになるような application やその他のウィジェット内では、記事を使用して、囲んだコンテンツを通常のウェブコンテンツとして扱うように切り替えるべきであることを示すことができます。

+ +

意味論のない要素に article ロールを含める代わりに、{{htmlelement("article")}} 要素を使用するべきです。 ユーザーエージェントは、これを article ロールのような適切なアクセシビリティ情報に変換します。 <article> 要素を使用すると、検索エンジンがページの構造をよりよく検出できるようになります。 role="article"、または好ましくは <article> の適切な使用例には、ブログ投稿、フォーラム投稿、フォーラムまたはブログ投稿へのコメント、フォーラムまたはブログ投稿へのコメントへのコメント、ソーシャルメディアフィード内の項目等が含まれます。

+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +
+
aria-posinset
+
フィードのコンテキストでは、1から始まるカウントに基づいて、そのフィード内のこの特定の記事の位置を示します。
+
aria-setsize
+
フィードのコンテキストでは、そのフィード内にいくつの記事の項目があるかを示します。
+
+ +

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

+ +

このロールは、具体的なキーボードインタラクションをサポートしていません。

+ +

必要な JavaScript 機能

+ +
+
イベントハンドラ
+
このロールでは、イベントハンドラは必要ありません。
+
属性値の変更
+
フィードを作成するときは、各 article ロールの aria-posinset 属性と aria-setsize 属性を適切な値に設定します。 aria-posinset は、1ベースであることに注意してください。
+
+ +
+

常にネイティブの要素を使用してください。 article ロールを持つ <div> ではなく、{{htmlelement("article")}} 要素を使用するべきです。

+
+ +

例

+ + + +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#article","article")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#feed","feed")}}{{Spec2('ARIA Authoring Practices')}}
+ +

優先順位

+ +

このロールは、HTML の {{htmlelement("article")}} 要素に対応し、可能な場合はその要素を代わりに使用するべきでます。 このロールは、その子の間に具体的なロールが存在する必要はありません。 これは、feed ロールを持つ要素の直接の子として許可される唯一のロールです。

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/banner_role/index.html b/files/ja/web/accessibility/aria/roles/banner_role/index.html new file mode 100644 index 0000000000..156371cecc --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/banner_role/index.html @@ -0,0 +1,97 @@ +--- +title: 'ARIA: banner ロール' +slug: Web/Accessibility/ARIA/Roles/Banner_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Banner_role +--- +

\{{ariaref}} banner ロールは、ページの先頭に頻繁に配置される一般的で有益なコンテンツを表します。 これには、通常、ロゴ、会社名、検索アイコン、ページに関連する写真、またはスローガンが含まれます。

+ +
<div role="banner">
+  <img src="companylogo.svg" alt="会社名">
+  <h1>タイトル<h1>
+  <h2>サブタイトル</h2>
+</div>
+ +

HTML5 の {{htmlelement("header")}} 要素は、{{htmlelement("aside")}}、{{htmlelement("article")}}、{{htmlelement("main")}}、{{htmlelement("nav")}}、または {{htmlelement("section")}} の子孫でない限り、banner ランドマークと同じ意味を持ちます。

+ + + +

説明

+ +

banner ランドマークロールは、それが適用されたコンテナ要素をヘッダーに変換します。 これは、一般的に全ページ上部にあるサイト全体共通のサイトヘッダーのコンテンツ用に予約されているべきです。

+ +

バナー（banner）には、通常ロゴやコーポレートアイデンティティ、おそらくサイト固有の検索ツールが含まれており、一般的にマーケティングチームがサイトのヘッダーやトップバナーと呼ぶものです。 {{htmlelement("header")}} 要素技術がそのバナーで使用されていない場合は、支援技術に対して banner ランドマーク（landmark）を定義するために、role="banner" の宣言を使用するべきです。

+ +

支援技術は、{{htmlelement("body")}} 要素の子孫であり、<article>、<aside>、<main>、<nav> または <section> サブセクション内にネストされていない場合、バナーとしてページのメイン <header> 要素を識別できます。

+ +

各ページに banner ランドマークを持っていてもかまいませんが、各ページは banner ロールを持つ1つの <header> に限定するべきです。 ネストされた document ロールおよび/または application ロールを含むページの場合、ネストされたそれぞれの document ロールや application ロールは、1つの banner ランドマークを持っていてもかまいません。 ページに複数の banner ランドマークが含まれている場合は、それぞれに固有のラベルを付けるべきです。

+ +

関連する ARIA のロール、ステート、プロパティ

+ +

無し

+ +

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

+ +

無し

+ +

必要な JavaScript 機能

+ +

無し

+ +

例

+ +

ここでは、ナビゲーションへ飛ぶリンク、ロゴ、タイトル、サブタイトルを含む簡単なバナーがあります。 これがサイトのメインヘッダーであるため、banner ランドマークロールをコンテナ要素に追加しました。

+ +
<div role="banner">
+  <a href="#nav" id="skipToMenu" class="skiptocontent">キーボードナビゲーションへ飛ぶ</a>
+  <img src="images/w3c.png" alt="W3C ロゴ">
+  <h1>ARIA ランドマーク</h1>
+  <p>容易なナビゲーションのためのページのサブセクションの特定</p>
+</div>
+ +

また、上記の HTML の <header> 要素で記述することもできます。

+ +
<header>
+  <a href="#nav" id="skipToMenu" class="skiptocontent">キーボードナビゲーションへ飛ぶ</a>
+  <img src="images/w3c.png" alt="W3C ロゴ">
+  <h1>ARIA ランドマーク</h1>
+  <p>容易なナビゲーションのためのページのサブセクションの特定</p>
+</header>
+ +

ベストプラクティス

+ +

<header> 要素を使用して、ページの任意のサブセクションの子孫でないことを保証するのが最善ですが、場合によっては基になる HTML にアクセスできません。 この場合、JavaScript を使用してページのメインヘッダーに banner ロールを追加できます。 この方法でページのバナーを特定すると、サイトのアクセシビリティが向上します。

+ +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#banner","ARIA: banner role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#aria_lh_banner","Banner landmark role")}}{{Spec2('ARIA Authoring Practices')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/cell_role/index.html b/files/ja/web/accessibility/aria/roles/cell_role/index.html new file mode 100644 index 0000000000..05813316b2 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/cell_role/index.html @@ -0,0 +1,199 @@ +--- +title: 'ARIA: cell ロール' +slug: Web/Accessibility/ARIA/Roles/Cell_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Cell_Role +--- +
\{{ariaref}}
+ +

ARIA の role 属性の cell 値は、要素を列ヘッダーや行ヘッダーの情報を含まない表形式コンテナ内のセルとして識別します。 サポートされるには、セルが row ロールを持つ要素内にネストされている必要があります。

+ +
<div role="row">
+  <span role="cell">フランス</span>
+  <span role="cell">6700 万</span>
+</div>
+
+ +

上のセルの書き方より良い、より意味のある方法は、意味論的な <td> 要素を使うことでしょう。

+ +
<tr role="row">
+  <td role="cell">フランス</td>
+  <td role="cell">6700 万</td>
+</tr>
+
+ +

説明

+ +

role="cell" を持つ要素は、grid、table、treegrid 内の、row 内のセル（オプションで rowgroup 内のセル）であり、静的な表形式の構造内にあります。 可能であれば、ネイティブな HTML <td> 要素を使用することを強く推奨します。

+ +

role="row" を持つコンテナ要素内に、role="cell" を持つ各要素をネストしなければなりません（MUST）。 この行（row）は、role="rowgroup" を持つ要素内にネストすることができ、grid、table、treegrid 内にネストするべきです。 セルに列ヘッダーまたは行ヘッダーの情報が含まれている場合は、それぞれ colheader ロールや rowheader ロールを使用します。 セルにヘッダー情報が含まれておらず、grid や treegrid にネストされている場合、gridcell ロールがより適切な場合があります。

+ +

セルには、aria-colindex、aria-colspan、aria-rowindex、aria-rowspan など、表形式データ構造内のセルの位置を明確にする多数のプロパティ属性を含めることができます。

+ +
+

可能であれば、ネイティブな HTML 表要素（<table>）を、表の行要素（<tr>）および表のセル要素（<td>）と共に使用することを強く推奨します。

+
+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +

コンテキストロール

+ +
+
role="row"
+
role="row" の要素は、表形式の構造内のセルの行です。 行には、grid、table、treegrid 内において1つ以上のセル、グリッドセル、列ヘッダー、行ヘッダーが含まれます。 オプションで rowgroup 内にも含まれます。
+
role="rowgroup"
+
行はセルの親として必須です。 行グループ（rowgroup）は、オプションのコンテキスト上の行の親で、子孫となる行との間に関係を確立します。 これは、HTML 表要素の thead、tfoot、tbody 要素と構造的に同等です。
+
role="table"
+
grid と treegrid と共に3つの可能なコンテキストのうちの1つで、セルを含む行が見つかります。 表（table）は、セルを、ネイティブな <table> HTML 要素と同様に、行と列に配置されたデータを含む非対話型の表構造の一部として識別します。
+
role="grid"
+
table と treegrid と共に3つの可能なコンテキストのうちの1つで、セルとグリッドセル（gridcell）を含む行が見つかります。 グリッド（grid）は、セルを、ネイティブな <table> HTML 要素と同様に、行と列に配置されたデータを含む対話型の可能性のある表構造の一部として識別します。
+
role="treegrid"
+
grid に似ていますが、tree と同じ方法で展開や折りたたみができる行があります。
+
+ +

サブクラスロール

+ +
+
role="gridcell"
+
grid や treegrid 内の行内のセル。
+
role="columnheader"
+
列スコープを持つ HTML <th> 要素と構造的に同等なヘッダーセル。 プレーンなセルとは異なり、columnheader ロールは、対応する列の全てのセルとの関係を確立します。
+
role="rowheader"
+
行スコープを持つ HTML <th> 要素と構造的に同等なヘッダーセル。 プレーンなセルとは異なり、rowheader ロールは、対応する行の全てのセルとの関係を確立します。
+
+ +

ステートとプロパティ

+ +
+
aria-colspan 属性
+
HTML の <th> と <td> 要素の colspan 属性と同様に、セルにまたがる列数を定義します。
+
aria-rowspan 属性
+
HTML の <th> と <td> 要素の rowspan 属性と同様に、セルにまたがる行数を定義します。
+
aria-colindex 属性
+
+

aria-colindex 属性は、列が DOM から隠されている場合にのみ必要です。 この属性は、値として 1 と table、grid、treegrid 内の全列数の間の整数をとります。 aria-colindex は、行内の全列数に対する要素の列インデックスまたは位置を定義します。 全ての列が DOM 内にある場合、この属性は必要ありません。

+
+
aria-rowindex 属性
+
+

aria-rowindex 属性は、行が DOM から隠されている場合にのみ必要です。 現在のセルが入っている全行のリストの行を示します。 この属性は、値として 1 と table、grid、treegrid 内の全行数の間の整数をとり、セルの位置またはインデックスを示します。 たとえば、最初のヘッダーの最初の行のセルは aria-rowindex="1" と設定され、47 行目のセルは、DOM 内に全ての行が存在しないために aria-rowindex が必要な場合は、aria-rowindex="47" となるでしょう。 表示されている行が連続していて、colspan や rowspan が 1 より大きいセルがない場合、このプロパティは行の全てのセルの代わりに親の行に追加できます。

+ +

 

+
+
+ +

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

+ +

無し

+ +

必要な JavaScript 機能

+ +
+
+ +

ARIA の最初のルールは、要素を再定義し、ARIA のロール、ステート、プロパティを追加してアクセス可能にするのではなく、すでに組み込まれている意味論と挙動を持つネイティブな機能を使用できることです。 可能であれば、ARIA の cell ロールの代わりに HTML の <td> 要素を使用してください。

+ +

例

+ +
<div role="table" aria-label="意味論的な要素" aria-describedby="semantic_elements_table_desc" aria-rowcount="81">
+  <div id="semantic_elements_table_desc">ARIA のロールの代わりに使用する意味論的な要素</div>
+  <div role="rowgroup">
+     <div role="row">
+       <span role="columnheader" aria-sort="none" aria-rowindex="1">ARIA のロール</span>
+       <span role="columnheader" aria-sort="none" aria-rowindex="1">意味論的な要素</span>
+     </div>
+   </div>
+   <div role="rowgroup">
+    <div role="row">
+       <span role="cell" aria-rowindex="11">header</span>
+       <span role="cell" aria-rowindex="11">h1</span>
+    </div>
+    <div role="row">
+      <span role="cell" aria-rowindex="16">header</span>
+      <span role="cell" aria-rowindex="16">h6</span>
+    </div>
+    <div role="row">
+      <span role="cell" aria-rowindex="18">rowgroup</span>
+      <span role="cell" aria-rowindex="18">thead</span>
+    </div>
+    <div role="row">
+      <span role="cell" aria-rowindex="24">term</span>
+      <span role="cell" aria-rowindex="24">dt</span>
+    </div>
+  </div>
+</div>
+
+ +

上記は、DOM 内に 81 行のうち 5 行が存在する意味論的でない ARIA の表です。 表のヘッダー内に 1 行、表の本体内に 4 行あります。 全ての行が DOM 内にあるわけではないので、全てのセルに aria-rowindex プロパティを追加しました。 複数の行や列にまたがるセルがない場合、aria-rowindex は行の個々のセルではなく行に配置されている可能性があります。

+ +

ベストプラクティス

+ +

データ表構造には、table、tbody、thead、tr、th、td などのみを使用します。 アクセシビリティを確保するために ARIA のロールを追加し、例えば CSS で表のネイティブな意味論を削除するべきです。 ARIA の table ロールの関連するユースケースは、display: grid など、CSS の display プロパティによって表のネイティブな意味論がオーバーライドされる場合です。 この場合、ARIA の table ロールを使用して意味論を戻すことができます。

+ +
<table role="table" aria-label="意味論的な要素" aria-describedby="semantic_elements_table_desc" aria-rowcount="81">
+  <caption id="semantic_elements_table_desc">ARIA のロールの代わりに使用する意味論的な要素</caption>
+  <thead role="rowgroup">
+     <tr role="row">
+       <th role="columnheader" aria-sort="none" aria-rowindex="1">ARIA のロール</th>
+       <th role="columnheader" aria-sort="none" aria-rowindex="1">意味論的な要素</th>
+     </tr>
+  </thead>
+  <tbody role="rowgroup">
+     <tr role="row">
+       <td role="cell" aria-rowindex="11">header</td>
+       <td role="cell" aria-rowindex="11">h1</td>
+     </tr>
+     <tr role="row">
+       <td role="cell" aria-rowindex="16">header</td>
+       <td role="cell" aria-rowindex="16">h6</td>
+     </tr>
+     <tr role="row">
+       <td role="cell" aria-rowindex="18">rowgroup</td>
+       <td role="cell" aria-rowindex="18">thead</td>
+     </tr>
+     <tr role="row">
+       <td role="cell" aria-rowindex="24">term</td>
+       <td role="cell" aria-rowindex="24">dt</td>
+     </tr>
+   </tbody>
+ </table>
+ +

上記は表を書く意味論的な方法です。 表のネイティブな意味論の場合、ARIA のロールは必要ありません。 したがって、display プロパティなどで表の行は変更されていません。

+ +

追加された利点

+ +

無し

+ +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#cell","ARIA Cell Role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#cell","ARIA Cell Role")}}{{Spec2('ARIA Authoring Practices')}}
+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/complementary_role/index.html b/files/ja/web/accessibility/aria/roles/complementary_role/index.html new file mode 100644 index 0000000000..ff7fe74363 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/complementary_role/index.html @@ -0,0 +1,114 @@ +--- +title: 'ARIA: complementary ロール' +slug: Web/Accessibility/ARIA/Roles/Complementary_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Complementary_role +--- +

\{{ariaref}}complementary ランドマークロールは、メインコンテンツに関連する補助セクションを指定するために使用され、しかも分離しても単独で成り立つことができます。 これらのセクションは、サイドバーやコールアウトボックスとして表示されることがよくあります。 可能であれば、代わりに HTML の {{htmlelement("aside")}} 要素を使用してください。

+ +
<div role="complementary">
+  <h2>私たちのパートナー</h2>
+  <!-- 補完的なセクションのコンテンツ -->
+</div>
+
+ +

これはイベントのスポンサーへのリンクを含むサイドバーです。

+ +

説明

+ +

complementary ロールはランドマークロールです。 ランドマーク（landmark）は、支援技術によって使用され、文書の大きなセクションを迅速に識別してナビゲートすることができます。 complementary ランドマークロールを持つコンテナ内にリストされたコンテンツは、文書のメインのコンテンツから分離されている場合でも意味をなすべきです。

+ +
+

{{htmlelement("aside")}} 要素を使用すると、自動的にセクションが complementary ロールを持つことを伝えます。 開発者は、ARIA を使用するよりも正しい意味論の HTML 要素を常に使用するべきです。

+
+ +

例

+ +
<div role="complementary">
+  <h2>トレンド記事</h2>
+  <ul>
+     <li><a href="#">あなたがすべての気分を感じさせる18のツイート</a></li>
+     <li><a href="#">私は完璧な昼食用の容器を見つけたので、それを探すのを停止する</a></li>
+     <li><a href="#">最終的に私たちがこれらの食品と呼ぶべきものを決定する時が来た</a></li>
+     <li><a href="#">Tumblr で今週見た17の本当に良い投稿</a></li>
+     <li><a href="#">10の親のハック、私たちはそれらを試したので、働くことを知っている</a></li>
+   </ul>
+ </div>
+
+ +

アクセシビリティに関する懸念

+ +

ランドマークロールは、文書のより大きな全体的なセクションを識別するために、控えめに使用することを意図しています。 あまりにも多くのランドマークロールを使用すると、スクリーンリーダーで「ノイズ」が発生し、ページ全体のレイアウトを理解することが難しくなります。

+ +

ベストプラクティス

+ +

好ましい HTML

+ +

{{htmlelement("aside")}} 要素を使用すると、自動的にセクションが complementary ロールを持つことを伝えます。 可能であれば、それを代わりに使用することをお勧めします。

+ +

ランドマークのラベル付け

+ +

複数のランドマーク

+ +

文書に複数の complementary ランドマークロールや {{htmlelement("aside")}} 要素がある場合は、各ランドマークに aria-label 属性を使用してラベルを付けるか、それらに適切な説明的なタイトルがある場合は、aria-labelledby 属性を使用してそれを指してください。 このラベルで、支援技術のユーザーがそれぞれのランドマークの目的をすばやく理解できるようになります。

+ +
<aside aria-label="使用上の注意">
+  <!-- コンテンツ -->
+</aside>
+
+...
+
+<aside id="sidebar" aria-label="スポンサー">
+  <!-- コンテンツ -->
+</aside>
+
+ +

冗長な説明

+ +

スクリーンリーダーは、ランドマークロールの種類をアナウンスします。 このため、ラベルでランドマークが何であるかを説明する必要はありません。 例えば、 aria-label="サイドバー" の role="complementary" の宣言は、"complementary サイドバー" として重複してアナウンスすることができます。

+ +

追加された利点

+ +

ブラウザー拡張などの特定の技術は、ページ上に存在する全てのランドマークロールのリストを生成することができ、非スクリーンリーダーユーザーはドキュメントの大きなセクションを素早く識別してナビゲートできます。

+ + + +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#complementary","ARIA: Complementary role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#aria_lh_complementary","Complementary landmark role")}}{{Spec2('ARIA Authoring Practices')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/contentinfo_role/index.html b/files/ja/web/accessibility/aria/roles/contentinfo_role/index.html new file mode 100644 index 0000000000..3f61014940 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/contentinfo_role/index.html @@ -0,0 +1,147 @@ +--- +title: 'ARIA: contentinfo ロール' +slug: Web/Accessibility/ARIA/Roles/Contentinfo_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Contentinfo_role +--- +
\{{ariaref}}
+ +

contentinfo ランドマークロールは、著作権情報、ナビゲーションリンク、プライバシーステートメントなど、ウェブサイトの各ページの最後に繰り返される情報を識別するために使用されます。 このセクションは一般的にフッターと呼ばれます。

+ +
<div role="contentinfo">
+  <h2>フッター</h2>
+  <!-- フッターのコンテンツ -->
+</div>
+
+ +

これはウェブサイトのフッターです。 代わりに {{htmlelement("footer")}} 要素を使用することをお勧めします。

+ +
<footer>
+  <h2>フッター</h2>
+  <!-- フッターのコンテンツ -->
+</footer>
+
+ +

説明

+ +

contentinfo ロールは、ページフッターを識別するためのランドマークです。 ランドマークは、支援技術によって使用され、文書の大きなセクションを迅速に識別してナビゲートすることができます。 ページには、1ページあたり1つのトップレベルの contentinfo ランドマークロールのみが含まれているべきです。

+ +

各ページには、{{htmlelement("footer")}} 要素を使用するか、または role="contentinfo" を宣言することによって作成された contentinfo ランドマークが1つだけ含まれているべきです。 {{htmlelement("iframe")}} 要素を介して埋め込まれたコンテンツに存在する contentinfo ランドマークは、この制限に含まれません。

+ +
+

{{htmlelement("footer")}} 要素を使用すると、自動的にセクションに contentinfo ロールを持つことを伝えます。 開発者は、ARIA を使用するよりも正しい意味論の HTML 要素を常に使用するべきで、確実に VoiceOver の既知の問題をテストしてください。

+
+ +

例

+ +
<body>
+
+  <!-- 他のページのコンテンツ -->
+
+  <div role="contentinfo">
+    <h2>MDN Web Docs</h2>
+    <ul>
+      <li><a href="#">ウェブ技術</a></li>
+      <li><a href="#">ウェブ開発について学ぶ</a></li>
+      <li><a href="#">MDN について</a></li>
+      <li><a href="#">フィードバック</a></li>
+    </ul>
+    <p>© 2005-2018 Mozilla および各貢献者 コンテンツは <a href="#">これらのライセンス</a> の下で公開されています。</p>
+  </div>
+</body>
+
+ +

アクセシビリティに関する懸念

+ +

控えめに使用する

+ +

ランドマークロールは、文書のより大きな全体的なセクションを識別することを意図しています。 あまりにも多くのランドマークロールを使用すると、スクリーンリーダーで「ノイズ」が発生し、ページ全体のレイアウトを理解することが難しくなります。

+ +

ページあたり1つの contentinfo ランドマーク

+ +

<body> 要素

+ +

{{htmlelement("body")}} 要素の直接の子孫として使用される文書ごとに1つの contentinfo ランドマークが存在するべきです。

+ +

メガフッター

+ +

文書のフッターの中に追加の {{htmlelement("footer")}} 要素や contentinfo ランドマークを入れ子にしないでください。 代わりに、他のコンテンツセクショニング要素を使用してください。

+ +

ランドマークのラベル付け

+ +

複数のランドマーク

+ +

文書に複数の contentinfo ランドマークロールや {{htmlelement("footer")}} 要素がある場合は、各ランドマークの aria-label 属性でラベルを指定します。 このラベルで、支援技術のユーザーがそれぞれのランドマークの目的をすばやく理解することができます。

+ +
<body>
+
+  ...
+
+  <article>
+    <h2>毎日パッタイ</h2>
+    <!-- 記事のコンテンツ -->
+    <footer aria-label="毎日パッタイのメタデータ">
+      <p><a href="#">リサ</a>によって<time datetime="2018-09-23 12:17">5月16日</time>に投稿されました。</p>
+    </footer>
+  </article>
+
+  ...
+
+  <footer aria-label="フッター">
+    <!-- フッターのコンテンツ -->
+  </footer>
+</body>
+ +

冗長な説明

+ +

スクリーンリーダーは、ランドマークロールの種類をアナウンスします。 このため、ラベルでランドマークが何であるかを説明する必要はありません。 例えば、aria-label="フッター" の role="contentinfo" の宣言は、"contentinfo フッター" として重複してアナウンスすることができます。

+ +

ベストプラクティス

+ +

好ましい HTML

+ +

{{htmlelement("body")}} 要素の直接の子孫である場合、{{htmlelement("footer")}} 要素を使用すると、自動的にセクションが contentinfo ロールを持つことを伝えます（VoiceOver の既知の問題は別として）。 可能であれば、代わりに <footer> を使用することをお勧めします。 <article>、<aside>、<main>、<nav>、<section> 内にネストされた <footer> 要素は、contentinfo とはみなされないことに注意してください。

+ +

追加された利点

+ +

ブラウザー拡張などの特定の技術は、ページ上に存在する全てのランドマークロールのリストを生成することができ、非スクリーンリーダーユーザーは文書の大きなセクションを素早く識別してナビゲートできます。

+ + + +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#contentinfo","contentinfo landmark role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#aria_lh_contentinfo","contentinfo landmark role")}}{{Spec2('ARIA Authoring Practices')}}
+ +

スクリーンリーダーのサポート

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/dialog_role/index.html b/files/ja/web/accessibility/aria/roles/dialog_role/index.html new file mode 100644 index 0000000000..283e1d5042 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/dialog_role/index.html @@ -0,0 +1,166 @@ +--- +title: 'ARIA: dialog ロール' +slug: Web/Accessibility/ARIA/Roles/dialog_role +tags: + - ARIA + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/dialog_role +--- +

\{{ariaref}}

+ +

dialog ロールは、ウェブアプリケーションまたはウェブページの他の部分からコンテンツまたは UI を分離する HTML ベースのアプリケーションのダイアログまたはウィンドウをマークアップするために使用されます。 ダイアログは、通常、オーバーレイを使用してページコンテンツの残りの部分の上に配置されます。 ダイアログは非モーダル（ダイアログの外のコンテンツとやりとりすることは可能です）またはモーダル（ダイアログ内のコンテンツのみがやり取りできる）のいずれかになります。

+ +
<div role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
+  <h2 id="dialog1Title">あなたの個人情報が更新されました</h2>
+  <p id="dialog1Desc">詳細は、ユーザーアカウントのセクションでいつでも変更できます。</p>
+  <button>閉じる</button>
+</div>
+ +

説明

+ +

ダイアログの要素を dialog ロールと共にマークアップすると、支援技術がダイアログのコンテンツをグループ化し、ページのコンテンツの他の部分から分離されたものとして識別するのに役立ちます。 ただし、role="dialog" だけを追加するだけでは、ダイアログをアクセス可能にするには不十分です。 さらに、次のことを行う必要があります。

+ + + +

以下のセクションでは、これら2つの要件がどのように満たされるかについて説明します。

+ +

ラベリング

+ +

ダイアログ自体がフォーカスを受け取れる必要はありませんが、それでもラベルを付ける必要があります。 ダイアログに与えられたラベルは、ダイアログ内のインタラクティブコントロールのコンテキスト情報を提供します。 つまり、ダイアログのラベルは、その内部のコントロールのグループラベルのように動作します（<legend> 要素が <fieldset> 要素内のコントロールのグループラベルを提供する方法と同様です）。

+ +

ダイアログにすでに表示されているタイトルバーがある場合、そのバーの中のテキストを使用してダイアログ自体にラベルを付けることができます。 これを達成する最善の方法は、role="dialog" 要素に aria-labelledby 属性を使用することです。 さらに、ダイアログにダイアログタイトルの他に説明的なテキストが含まれている場合、このテキストは aria-describedby 属性を使用してダイアログに関連付けることができます。 このアプローチは、次のコードスニペットに示されています。

+ +
<div role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
+  <h2 id="dialog1Title">あなたの個人情報が更新されました</h2>
+  <p id="dialog1Desc">詳細は、ユーザーアカウントのセクションでいつでも変更できます。</p>
+  <button>閉じる</button>
+</div>
+ +

 

+ +
非仮想モードで動作するスクリーンリーダーが知覚するためには、ダイアログのタイトルと説明のテキストにフォーカスを合わせる必要はありません。 ARIA の dialog ロールとラベリング手法を組み合わせることで、スクリーンリーダーは、フォーカスがダイアログへ移動したときにダイアログの情報をアナウンスするべきです。
+ +

 

+ +

必要な JavaScript 機能

+ +

 

+ +

フォーカス管理 

+ +

ダイアログには、キーボードフォーカスをどのように管理するべきかについての特定の要件があります。

+ + + +

関連する ARIA のロール、ステート、プロパティ

+ +
+
aria-labelledby
+
ダイアログにラベルを付けるには、この属性を使用します。 多くの場合、aria-labelledby 属性の値は、ダイアログのタイトルに使用される要素の ID になります。
+
aria-describedby
+
この属性を使用して、ダイアログの内容を記述します。
+
+ +

ユーザーエージェントと支援技術への影響

+ +

dialog ロールが使用されるとき、ユーザーエージェントは以下を行うべきです。

+ + + +

ダイアログが正しくラベル付けされ、フォーカスがダイアログ内のコントロールに移動されると、スクリーンリーダーは、フォーカスされた要素をアナウンスする前にダイアログのアクセシブルロール、名前、および任意で説明をアナウンスするべきです。

+ +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1: フォームを含むダイアログ

+ +
 <div role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
+   <h2 id="dialog1Title">加入申込書</h2>
+   <p id="dialog1Desc">私たちは、この情報を第三者と共有することはありません。</p>
+   <form>
+     <p>
+       <label for="firstName">名</label>
+       <input id="firstName" type="text" />
+     </p>
+     <p>
+       <label for="lastName">姓</label>
+       <input id="lastName" type="text"/>
+     </p>
+     <p>
+       <label for="interests">興味</label>
+       <textarea id="interests"></textarea>
+     </p>
+     <p>
+       <input type="checkbox" id="autoLogin"/>
+       <label for="autoLogin">自動ログイン</label>
+     </p>
+     <p>
+         <input type="submit" value="情報を保存する"/>
+     </p>
+   </form>
+ </div>
+ +

例 2: フォールバックコンテンツとしての fieldset に基づくダイアログ

+ +

ARIA マークアップをサポートしていないブラウザーや AT 製品をサポートするには、フォールバックコンテンツとして fieldset 要素にダイアログマークアップを適用することもできます。 このようにして、ダイアログのタイトルは正しくアナウンスされます。

+ +
<fieldset role="dialog" aria-labelledby="dialog1Title" aria-describedby="dialog1Desc">
+  <legend>
+    <span id="dialog1Title">あなたの個人情報が更新されました。</span>
+    <span id="dialog1Desc">詳細は、ユーザーアカウントのセクションでいつでも変更できます。</span>
+  </legend>
+
+  <button>閉じる</button>
+</fieldset>
+ +

動作する例

+ + + +

注

+ +
注: キーボードユーザーがダイアログの外の要素にフォーカスを移動するのを防ぐことは可能ですが、スクリーンリーダーの仮想カーソルを使用するためにスクリーンリーダーのユーザーは仮想的にそのコンテンツをナビゲートすることができます。 このため、ダイアログは application ロールの特別なケースとみなされます。 非仮想ナビゲーションモードでは、スクリーンリーダーのユーザーがナビゲートすることが予想されます。
+ + + +

仕様

+ + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#dialog","dialog")}}{{Spec2('ARIA')}}
+ +

スクリーンリーダーのサポート

+ +

近日公開

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/document_role/index.html b/files/ja/web/accessibility/aria/roles/document_role/index.html new file mode 100644 index 0000000000..eb69ada642 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/document_role/index.html @@ -0,0 +1,94 @@ +--- +title: 'ARIA: document ロール' +slug: Web/Accessibility/ARIA/Roles/Document_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Document_Role +--- +

\{{ariaref}}複雑な複合ウィジェットやアプリケーションで一般的に使用される document ロールは、コンテキストを読み取りモードに切り替えることを支援技術を知らせることができます。 document ロールは、ドキュメントモードを使用して、この要素に含まれるコンテンツを読み取るための読み取りモードまたはブラウズモードを支援技術に指示します。

+ +
<div role="dialog">
+ ...
+ <div id="InfoText" role="document" tabindex="0">
+  <p>いくつかの情報テキストがここに入ります。</p>
+ </div>
+ ...
+ <button>閉じる</button>
+</div>
+
+ +

この例は、いくつかのコントロールと、支援技術のユーザーがタブを当てて（Tab キーによる移動で）読むことができる情報テキストを含むセクションを含むダイアログウィジェットを示しています。

+ +

説明

+ +

デフォルトでは、ウェブページはドキュメント（document）として扱われ、支援技術（AT）は、新しいウェブページに入るときブラウズモードまたは読み取りモードにします。 このモードは、ウィジェットロールや application ロールなど、さまざまなロールを通じて変更できます。 document ロールは、AT をブラウズモードまたは読み取りモードに戻します。

+ +

一般に、application ロールまたは他のインタラクティブなウィジェットロール内に配置される document ロールは、利用可能な場合、支援技術のユーザがブラウズモードまたは仮想読み取りモードを使用して読むべきである複雑な複合ウィジェットのセクションを示すために使用します。

+ +

読み取りモードの AT は、ウィジェットロールまたは application ロールのセットを持つ要素を除くすべての要素に対してそのモードをデフォルトとしているため、document ロールは、静的リッチテキストとして読むべきであるウィジェットまたはアプリケーション内のフォーカス可能な要素に対してのみ役に立ちます。 ウィジェット内のテキストを含む要素に role="document" と tabindex="0" を追加すると、スクリーンリーダーのユーザーは Tab キーを押してドキュメント要素にフォーカスを合わせ、スクリーンリーダーの読み取りカーソルでテキストを読み取ることができます。

+ +

支援技術は、親の動的コンテキストのために再配線されたコントロールを遮り、上矢印または下矢印キーボードイベントなどの標準入力イベントを再度有効にして、読み取りカーソルを制御するために、コンテキストをドキュメントモードに戻すべきです。

+ +

article ロールとは対照的に、document ロールは、document ロールを持つ他の要素との関係はなく、単にそれ含む複合ウィジェットとの関係を持っています。 記事（article）は関連記事を持つことができます。

+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +
+
aria-expanded
+
ドキュメント要素が折りたたみ可能である場合は、true または false の値を含み、ドキュメントが現在展開されているか折りたたまれているかを示します。 他の値には、ドキュメントが折りたたまれないことを意味するデフォルトの undefined が含まれます。
+
+ +
+
tabindex="0"
+
支援技術のユーザーがそれにタブを当ててすぐに読むことができるように、それをフォーカス可能にするために使用します。
+
+ +

 

+ +

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

+ +

tabindex="0" 属性/値のペアを設定することで、要素をフォーカス可能にするべきです。 これにより、ユーザーはタブを当てることができ、読み取りモードが自動的に呼び出され、コンテンツをすぐに読むことができます。

+ +

必要な JavaScript 機能

+ +

なし（任意の属性が必要とする場合を除く。 例えば、document が折りたたみ可能である場合、aria-expanded のステートと値を維持する必要があります。）

+ +

例

+ +

例えば、Gmail と1つの会話ビューがあります。 GMail はウェブアプリケーションです。 Gmail の場合、ほとんどのユーザーエージェントのインタラクションは、ほとんどの場合、アプリケーションによって奪われます。 ただし、会話の件名を含む1つの会話の開始見出しにキーボードフォーカスが設定されている場合、スクリーンリーダーのユーザーは読み取りモードのコマンドを使用してメッセージを読んだり、展開したり、折りたたんだり、彼らがどんなやり方でも操作できるようにします。 Back ボタンをアクティブにするか、関連するキーを押すことによって、フォーカスがメッセージリストに戻ると、直接アプリケーションのインタラクションモードが再度呼び出され、矢印キーを使用してリスト内の別の会話に移動できます。

+ +

ベストプラクティス

+ +

tabindex 属性に値 0 を設定することにより、document ロールを持つ項目がフォーカス可能であることを常に確認します。 これはタブ順にも含まれます。

+ +

追加の利点

+ +

document ロールは、ユーザーが標準のスクリーンリーダーのコマンドで読むべき内容であることを明白に明示することによって、支援技術の動作を間接的に制御する簡単な方法です。

+ +

仕様

+ + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#document","document")}}{{Spec2('ARIA')}}
+ +

スクリーンリーダーのサポート

+ +

 

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/feed_role/index.html b/files/ja/web/accessibility/aria/roles/feed_role/index.html new file mode 100644 index 0000000000..ca699a87dc --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/feed_role/index.html @@ -0,0 +1,124 @@ +--- +title: 'ARIA: feed ロール' +slug: Web/Accessibility/ARIA/Roles/Feed_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Feed_Role +--- +

\{{ariaref}}

+ +

フィード（feed）は動的にスクロール可能な記事（article）のリスト（list）で、ユーザーがスクロールすると記事がリストの両端から追加または削除されます。 feed を使用すると、スクリーンリーダーはブラウズモードの読み取りカーソルを使用して、ユーザーが読むにつれてより多くのコンテンツをロードすることで無限にスクロールし続けることができるリッチコンテンツのストリームを読み、スクロールすることができます。

+ +
<section role="feed" aria-busy="false">
+  ...
+  <tweet role="article" aria-posinset="427" aria-setsize="-1">...</tweet>
+  <tweet role="article" aria-posinset="428" aria-setsize="-1">...</tweet>
+  <tweet role="article" aria-posinset="429" aria-setsize="-1">...</tweet>
+  ...
+</section>
+ +

Description

+ +
+

フィード（feed）は、スクロール可能な記事（article）のリスト（list）のためのページ構造であり、スクロールすることで、リストの先頭または末尾に記事が追加され、ウェブページと、スクロールインタラクションを制御する支援技術との間の相互運用契約が確立され、ユーザーが記事を読み、記事を前後にジャンプし、読み取りモードで新しい記事を確実にロードするようにします。 例としては、RSS フィード、ニュースフィード、Facebook（フェイスブック）、Instagram（インスタグラム）、Twitter（ツイッター）などのソーシャルメディアフィード、さらには電子商取引ページ上の関連商品のリストなどがあります。 これらのストリームは有限か無限であり、ユーザーがスクロールするにつれてより多くのコンテンツをロードします。 フィードパターンを実装することで、スクリーンリーダーは読み取りモードを維持しながら、確実に読み取り、フィードコンテンツのロードをトリガーすることができます。

+ +

 

+ +

feed は、コンテナ要素であり、その子は {{htmlelement("article")}} であるか、article ロールを持ちます。 フィード内の各記事は、tabindex が 0 または -1 でフォーカス可能であるべきです。 記事またはその子孫要素にフォーカスが移ったときに、記事をスクロールして表示するべきです。 記事の追加がメインのブラウザースレッドを占有している場合は、フィード自体に aria-busy="true" を設定し、処理が終了したりユーザーに更新が表示されない場合は false に設定し直してください。

+ +

優れたユーザーエクスペリエンスを確保するため、フィードの途中で記事を挿入または削除しないようにし、ユーザーがフィードの終わりに達する前に新しい記事をロードし、記事間でフォーカスを移動するためのキーボードコマンドを提供して、キーボードユーザーがフィード内をナビゲートできるようにします。 下記のキーボードインタラクションを参照してください。
+ 記事の数がわかっている場合は、記事自体に aria-setsize を設定してください。 ただし、総数が非常に大きい場合、不明確な場合、または頻繁に変わる場合は、aria-setsize="-1" を設定してフィードのサイズがわからないことを示します。

+ +

フィードパターンのもう1つの特徴は、斜め読みです。 フィード内の記事には、aria-label によるアクセス可能な名前と aria-describeby による説明の両方を含めることで、記事をナビゲートするときに、ラベルの後にどの要素を話すべきかをスクリーンリーダーに提案することができます。 タイトルと主要コンテンツを提供する記事内の要素を識別することによって、支援技術は、ユーザが記事から記事へとジャンプし、どの記事がより注目に値するかを効率的に見分けることを可能にする機能を提供できます。

+ +

フィードパターンは、ウェブページと支援技術の間に次の相互運用性に関する合意を確立することによって、信頼できる支援技術の読み取りモードでのインタラクションを可能にします。

+ +
    +
  1. フィードのコンテキストでは、ウェブページのコードは次の責任を負います。 +
      +
    • どの記事に DOM フォーカスが含まれているかに基づいて、コンテンツを適切に視覚的にスクロールします。
      • +
    • どの記事に DOM フォーカスが含まれているかに基づいて、フィード記事をロードまたは削除する。
      • +
    +
    2. +
  2. フィードのコンテキストでは、読み取りモードを持つ支援技術は次の責任を負います。 +
      +
    • 記事要素またはその子孫の1つに DOM フォーカスがあることを確認して、どの記事に読み取りカーソルがあるかを示します。
      • +
    • DOM フォーカスを次の記事および前の記事に移動するための読み取りモードキーを提供します。
      • +
    • 読み取りカーソルと DOM フォーカスをフィードの終わりを超えてフィードの開始前に移動するための読み取りモードキーを提供します。
      • +
    +
    3. +
+ +
+

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

+ +

フォーカスがフィード内にある場合は、次のような、または同様のインターフェースをサポートすることをお勧めします。

+ +
    +
  • Page Down: 次の記事にフォーカスを移動します。
    • +
  • Page Up: 前の記事にフォーカスを移動します。
    • +
  • Control + End: フィードの後方で最初にフォーカス可能な要素にフォーカスを移動します。
    • +
  • Control + Home: フィードの前方で最初にフォーカス可能な要素にフォーカスを移動します。
    • +
+ +

ブログ投稿のフィード内のコメントフィードなど、フィード内にネストしたフィードがある場合の慣例は、Tab キーでネストしたフィードにタブで移動し、「外側の」記事からその記事内にネストしたフィードの最初の項目に移動するための Alt + Page Down などの別のキーを提供することです。 メインフィードとネストしたフィードの間をナビゲートするには、Control + End で内側のフィードから外側のフィードの次の記事にフォーカスを移動します。

+
+ +
+

関連する WAI-ARIA のロール、ステート、プロパティ

+ +
+
aria-label
+
フィードに目に見えるタイトルがない場合、feed 要素には aria-label で指定されたラベルがあります。 もしそうなら、aria-labelledby を見てください。
+
aria-labelledby
+
フィードに目に見えるタイトルがある場合、feed 要素はタイトルを含む要素を参照する aria-labelledby を持ちます。 そうでない場合は、aria-label を追加してください。
+
aria-busy
+
記事をフィードに追加または削除しているときなど、忙しい場合は、更新操作中に aria-busy="true" を設定します。 操作が完了するか、変更が見えなくなる可能性がある場合は、必ず false にリセットしてください。
+
article
+
フィード内のコンテンツの各セクションは、{{htmlelement("article")}} または article ロールを持つ要素に含めるべきです。 各記事（article）は、その記事のタイトルまたは識別ラベルとして役立つその他の子を参照する aria-labelledby を持つべきです。 各記事は、好ましくは、その記事の主要なコンテンツとして役立つ記事内の１つまたは複数の要素を参照する aria-describedby を持つべきです。 各記事要素は、フィード内の位置を表す値に設定された aria-posinset と、ロードされた記事の総数またはフィード内の総数を表す値のどちらかに設定された aria-setsize を持ちます。 それは、どちらの値がユーザーにとってより役立つかによって異なります。 フィード内の総数がわからない場合は、aria-setsize="-1" を設定してください。
+
+
+ +

 

+
+ +

 

+ +

必要な JavaScript 機能

+ +

なし（任意の属性が必要とする場合を除く。 例えば、必要に応じて更新操作中に aria-busy を true に設定し、完了したら false に設定します。）

+ +

例

+ +

フィードパターンの実装例（英語）

+ +

仕様

+ + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#feed","feed")}}{{Spec2('ARIA')}}
+ +

スクリーンリーダーのサポート

+ +

Coming soon

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/figure_role/index.html b/files/ja/web/accessibility/aria/roles/figure_role/index.html new file mode 100644 index 0000000000..f878ae0eaa --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/figure_role/index.html @@ -0,0 +1,148 @@ +--- +title: 'ARIA: figure ロール' +slug: Web/Accessibility/ARIA/Roles/Figure_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Figure_Role +--- +
\{{ariaref}}
+ +

ARIA の figure ロールは、適切な意味論が存在しないページコンテンツ内の図表を識別するために使用できます。 図表は、通常、1つまたは複数の画像、コードスニペット、または情報を通常のテキストの流れとは異なる方法で配置するその他のコンテンツとみなされます。

+ +
<div role="figure" aria-labelledby="caption">
+  <img src="image.png"
+      alt="画像の完全な代替説明">
+  <p id="caption">図表 1: キャプション</p>
+</div>
+
+ +

上記の例では、画像とキャプションの2つの別々のコンテンツ項目で構成される図表があります。 これは、コンテンツを role="figure" を使用して図表として識別する {{htmlelement("div")}} 要素で囲まれます。

+ +

図表を作成するために ARIA を使用する代わりに、{{htmlelement("figcaption")}} 要素と共に、ネイティブな意味論の HTML {{htmlelement("figure")}} 要素の使用を検討してください。 以下の{{anch("Best practices","ベストプラクティス")}}をご覧ください。

+ +

説明

+ +

一緒にグループ化され、図表（画像、動画、音声、コードスニペット、または他のコンテンツを含む）として消費されるべきコンテンツは、 role="figure" を使用して図表として識別できます。

+ +

図表のコンテンツをどのように書くべきかについての鉄則はありません。 他のコンテンツと同様にアクセス可能であることを確認するべきです。 例えば、支援技術のユーザーがキーボードやマウスなどで操作できることを確認してください。

+ +

図表にキャプションやラベルを追加する場合は、さまざまな方法でキャプションやラベルを追加できます。 図表を説明するコンテンツを含む要素に ID を追加し、図表上の適切な属性でその ID を参照して、次のように図表をラベルに関連付けることができます。

+ +
<div role="figure" aria-labelledby="figure-1">
+  ...
+  <p id="figure-1">図表を説明するテキスト。</p>
+</div>
+ + + +

ここでも、ARIA 無しで、HTML の {{htmlelement("figure")}} 要素と {{htmlelement("figcaption")}} 要素を使用して、意味論的に行うことができます。

+ +
<figure>
+  ...
+  <figcaption>図表を説明するテキスト。</figcaption>
+</figure>
+ + + +

ラベルを画面に表示したくないが、支援技術のユーザーにわかりやすいラベルを提供したい場合は、図表コンテナの aria-label 属性を使用できます。

+ +
<div role="figure" aria-label="図表を説明するテキスト。">
+  ...
+</div>
+ +

aria-label は <figure> と一緒に使うことができます。

+ +
<figure aria-label="図表を説明するテキスト。">
+  ...
+</figure>
+ +

一般的には、メインテキストから図表を参照するべきですが、図表は参照元の要素と同じ場所に表示する必要はありません。

+ +
+

注: 可能な限り、意味論的 HTML 要素を使用して図表とそのキャプション（{{htmlelement("figure")}} と {{htmlelement("figcaption")}}）をマークアップするべきです。 詳しくは、{{anch("Best practices","ベストプラクティス")}}を参照してください。

+
+ +

 

+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +
+
aria-describedby
+
キャプションとしての参照テキストを含む要素の ID。
+
aria-labelledby
+
ラベルとしてのテキストを含む要素の ID。
+
aria-label
+
ラベルとして機能することができるテキストを含む要素がない場合は、figure ロールを持つ要素や <figure> 要素の aria-label の値として直接ラベルを追加できます。
+
+ +

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

+ +

ロールに固有のキーボードインタラクションはありません。

+ +

必要な JavaScript 機能

+ +

ロール固有の JavaScript 要件はありません。 HTML の意味論を制御できない場合は、JavaScript でこれらのロールとプロパティを追加することで、HTML のアクセシビリティを向上させることができます。

+ +

例

+ +

aria-labelledby でその ID を参照することによって、図表の説明的なラベルを提供する段落を識別するために、このページの最初の例を拡張することもできます。

+ +
<div role="figure" aria-labelledby="figure-1">
+  <img src="diagram.png"
+       alt="素晴らしい4つの層と相対的な優先順位を示すダイヤグラム —
+            音楽、猫、自然、そしてアイスクリーム">
+  <pre><code>
+    let awesome = ['音楽', '猫', '自然', 'アイスクリーム'];
+  </code></pre>
+  <p id="figure-1">図表 1: 素晴らしい4つの層。</p>
+</div>
+ +

ベストプラクティス

+ +

たとえば、HTML を制御できないが、JavaScript を使用した後でアクセシビリティを動的に向上させる必要がある場合など、role="figure" のみを使用する必要があります。

+ +

可能であれば、図表とそのキャプション（{{htmlelement("figure")}} と {{htmlelement("figcaption")}}）をマークアップするために、適切な意味論の HTML 要素を使用する必要があります。 たとえば、上記の例は次のように書き直されます。

+ +
<figure>
+  <img src="diagram.png"
+       alt="素晴らしい4つの層と相対的な優先順位を示すダイヤグラム —
+       音楽、猫、自然、そしてアイスクリーム">
+  <pre><code>
+    let awesome = ['音楽', '猫', '自然', 'アイスクリーム'];
+  </code></pre>
+  <figcaption>図表 1: 素晴らしい4つの層。</figcaption>
+</figure>
+ +

仕様

+ + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#figure","figure")}}{{Spec2('ARIA')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/form_role/index.html b/files/ja/web/accessibility/aria/roles/form_role/index.html new file mode 100644 index 0000000000..b181d1ff15 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/form_role/index.html @@ -0,0 +1,171 @@ +--- +title: 'ARIA: form ロール' +slug: Web/Accessibility/ARIA/Roles/Form_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Form_Role +--- +
\{{ariaref}}
+ +

form ランドマークロールは、HTML のフォームと同等の機能を提供するページ上の要素のグループを識別するために使用できます。

+ +
<div role="form" id="contact-info" aria-label="連絡先">
+  <!-- フォームのコンテンツ -->
+</div>
+
+ +

これは、ユーザーの連絡先を収集して保存するフォームです。

+ +
+

重要: 本当に正当な理由がない限り、HTML の {{htmlelement("form")}} 要素を使用してフォームのコントロールを格納するべきです。

+
+ +

説明

+ +

form ロールは、フォーム（form）を識別するためのランドマークです。 ランドマークは、支援技術によって使用され、文書の大きなセクションを迅速に識別してナビゲートすることができます。 form ランドマークは、他の指名されたランドマークが適切でない場合（例えば、main や search）に、全体としてフォームを作成するために組み合わせるアイテムとオブジェクトのコレクションを含む領域を識別します。

+ +
+
+
+

{{htmlelement("form")}} 要素を使用すると、アクセス可能な名前がある場合、自動的にセクションに contentinfo ロールと form ランドマークを持つことを伝えます。 開発者は、ARIA を使用するよりも正しい意味論の HTML 要素を常に使用するべきです。

+
+
+
+ +

可能であれば、HTML の {{htmlelement("form")}} 要素を使用してください。 <form> 要素は、アクセス可能な名前（例えば、aria-labelledby、aria-label、または title）がある場合、form ランドマークを定義します。 ユーザーがフォームの目的を理解できるように、文書内の各フォームに固有のラベルを付けるようにしてください。 このラベルは、支援技術のユーザーだけでなく、すべてのユーザーに表示するべきです。 検索機能にフォームが使用されている場合は、form ランドマークの代わりに search ランドマークを使用します。

+ +

ページの領域を特定するには、role="form" を使用します。 すべてのフォームのフィールドを識別するためにそれを使用しないでください。 <form> の代わりに form ランドマークを使用している場合でも、<button>、<input>、<select>、<textarea> などのネイティブな HTML フォームのコントロールを使用することをお勧めします。

+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +

ロールに固有のステートやプロパティはありません。

+ +

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

+ +

ロールに固有のキーボードインタラクションはありません。

+ +

必要な JavaScript 機能

+ +
+
onsubmit
+
onSubmit イベントハンドラは、フォームの送信時に発生するイベントを処理します。 <form> 以外のものは送信できませんので、{{domxref("XMLHTTPRequest")}} などの代替データ送信メカニズムを構築するには、JavaScript を使用する必要があります。
+
+ +

例

+ +
<div role="form" id="send-comment" aria-label="コメントを追加">
+  <label for="username">ユーザー名</label>
+  <input id="username" name="username" autocomplete="nickname" autocorrect="off" type="text">
+
+  <label for="email">電子メール</label>
+  <input id="email" name="email" autocomplete="email" autocapitalize="off" autocorrect="off" spellcheck="false" type="text">
+
+  <label for="comment">コメント</label>
+  <textarea id="comment" name="comment"></textarea>
+
+  <input value="コメント" type="submit">
+</div>
+
+ +

代わりに <form> を使用することをお勧めします。

+ +
<form id="send-comment" aria-label="コメントを追加">
+  ....
+</form>
+
+ +

アクセシビリティに関する懸念

+ +

控えめに使用する

+ +

ランドマークロールは、文書のより大きな全体的なセクションを識別することを意図しています。 あまりにも多くのランドマークロールを使用すると、スクリーンリーダーで「ノイズ」が発生し、ページ全体のレイアウトを理解することが難しくなります。

+ +

入力はフォームではない

+ +

すべてのフォーム要素（入力、テキスト領域、選択など）で role="form" を宣言する必要はありません。 フォーム要素をラップする HTML 要素で宣言するべきです。 理想的には、{{htmlelement("form")}} 要素をラップ要素として使用し、role="form" を宣言しないでください。

+ + + +

フォームを使用して検索する場合は、より専門化した role="search" 値を使用する必要があります。

+ +

ランドマークのラベル付け

+ +

それそれの {{htmlelement("form")}} 要素と form ランドマークロールには、ラベルが必要です。 このラベルで、支援技術のユーザーがフォームの目的をすばやく理解することができます。

+ +

フォームにラベルを付けるには、2つの方法があります。 {{htmlelement("legend")}} 要素は、<form> 要素の直接の子孫として使用します。role="form" の宣言を使用している場合、role="form" が宣言されている要素に適用される aria-label を使用します。 理想的には、フォームにラベルを付けるには、<form> と <legend> のテクニックを使用します。
+ （訳注：<legend> は <fieldset> の最初の子でなければならないとある。）

+ +

<form> 要素の使用

+ +
<form id="address">
+  <legend>あなたの住所を更新してください</legend>
+  <!-- フォームのコンテンツ -->
+</form>
+
+ +

role="form" の使用

+ +
<div role="form" id="gift-cards" aria-label="ギフトカードを購入する">
+  <!-- フォームのコンテンツ -->
+</div>
+ +

冗長な説明

+ +

スクリーンリーダーは、ランドマークロールの種類をアナウンスします。 このため、ラベルでランドマークが何であるかを説明する必要はありません。 例えば、aria-label="お問い合わせフォーム" の role="form" の宣言は、"form お問い合わせフォーム" として重複してアナウンスすることができます。

+ +

ベストプラクティス

+ +

好ましい HTML

+ +

{{htmlelement("form")}} 要素を使用すると、自動的にセクションが form ロールを持つことを伝えます。 可能であれば、<form> を代わりに使用することをお勧めします。

+ +

追加された利点

+ +

ブラウザー拡張などの特定の技術は、ページ上に存在する全てのランドマークロールのリストを生成することができ、非スクリーンリーダーユーザーは文書の大きなセクションを素早く識別してナビゲートできます。

+ + + +
+
+ +
+
+ +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#form","ARIA Form Role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#aria_lh_form","Role Form")}}{{Spec2('ARIA Authoring Practices')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/grid_role/index.html b/files/ja/web/accessibility/aria/roles/grid_role/index.html new file mode 100644 index 0000000000..666819b2b4 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/grid_role/index.html @@ -0,0 +1,715 @@ +--- +title: 'ARIA: grid ロール' +slug: Web/Accessibility/ARIA/Roles/Grid_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Grid_Role +--- +

\{{ariaref}}

+ +

grid ロールは、1つ以上のセルの行を含むウィジェット用です。 各セルの位置は重要であり、キーボード入力を使用してフォーカスすることができます。

+ +
<table role="grid" aria-labelledby="select-your-seat">
+  <caption>座席を選んでください</caption>
+  <tbody role="presentation">
+    <tr role="presentation">
+      <td></td>
+      <th>列 A</th>
+      <th>列 B</th>
+    </tr>
+    <tr>
+      <th scope="row">島 1</th>
+      <td tabindex="0">
+        <button id="1a" tabindex="-1">1A</button>
+      </td>
+      <td tabindex="-1">
+        <button id="1b" tabindex="-1">1B</button>
+      </td>
+      <!-- More Columns -->
+    </tr>
+    <tr>
+      <th scope="row">島 2</th>
+      <td tabindex="-1">
+        <button id="2a" tabindex="-1">2A</button>
+      </td>
+      <td tabindex="-1">
+        <button id="2b" tabindex="-1">2B</button>
+      </td>
+      <!-- More Columns -->
+    </tr>
+  </tbody>
+</table>
+
+ +

（オプション）上記の例の簡単な説明を含めます。

+ +

説明

+ +

グリッドウィジェットには、テーマに関連するインタラクティブなコンテンツの1つ以上のセルを持つ1つ以上の行が含まれています。 それは特定の視覚的プレゼンテーションを意味するわけではありませんが、要素間の関係を意味します。 これは、チェックボックスやナビゲーションリンクなどのような単純なグループ化に使用します。 複雑なスプレッドシートアプリケーションにも使用できます。

+ +

セル要素には、行ヘッダーや列ヘッダーでない限り、gridcell ロールがあります。 ヘッダー要素ではそれぞれ rowheader ロールと columnheader ロールです。 セル要素は、row ロールを持つ要素によって所有される必要があります。 行は rowgroup を使用してグループ化できます。

+ +

グリッドをインタラクティブなウィジェットとして使用する場合は、{{anch("Keyboard interactions","キーボードインタラクション")}}を実装する必要があります。

+ +

 

+ +

関連する ARIA のロール、ステート、プロパティ

+ +
+
+

ロール

+
+
treegrid（サブクラス）
+
展開や折りたたみができる列を持つグリッドには、ツリーグリッドを使用できます。
+
row
+
グリッド内の行。
+
rowgroup
+
1つ以上の row を含むグループ。
+
+ +

ステートとプロパティ

+ +
+
aria-level
+
他の構造内のグリッドの階層レベルを示します。
+
aria-multiselectable
+
aria-multiselectable が true に設定されている場合、グリッド内の複数の項目を選択できます。 デフォルト値は false です。
+
aria-readonly
+
ユーザーがグリッドをナビゲートできるが、グリッドの値を変更できない場合は、aria-readonly を true に設定するべきです。 デフォルト値は false です。
+
+ +
+

多くのユースケースでは、HTML の table 要素で十分であり、その要素にはすでに多くの ARIA ロールが含まれています。

+
+ +

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

+ +

キーボードユーザーはグリッドに出会うと、左、右、上、下のキーを使用して行と列をナビゲートします。 インタラクティブなコンポーネントをアクティブにするには、リターンキーとスペースキーを使用します。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
キー動作
→1セル右にフォーカスを移動します。 フォーカスが行の右端のセルにある場合、フォーカスは移動しません。
←1セル左にフォーカスを移動します。 フォーカスが行の左端のセルにある場合、フォーカスは移動しません。
↓1セル下にフォーカスを移動します。 フォーカスが列の最下部のセルにある場合、フォーカスは移動しません。
↑1セル上にフォーカスを移動します。 フォーカスが列の最上部のセルにある場合、フォーカスは移動しません。
Page Down作成者が決定した行数だけ下にフォーカスを移動します。 通常、現在表示されている行セットの一番下の行が最初に表示される行の1つになるようにスクロールします。 フォーカスがグリッドの最後の行にある場合、フォーカスは移動しません。
Page Up作成者が決定した行数だけ上にフォーカスを移動します。通常、現在表示されている行セットの一番上の行が最後に表示される行の1つになるようにスクロールします。 フォーカスがグリッドの最初の行にある場合、フォーカスは移動しません。
Homeフォーカスを含む行の最初のセルにフォーカスを移動します。
Endフォーカスを含む行の最後のセルにフォーカスを移動します。
ctrl + Home最初の行の最初のセルにフォーカスを移動します。
ctrl + End最後の行の最後のセルにフォーカスを移動します。
+ +

セル、行、列を複数選択できる場合は、次のキーの組み合わせが一般的に使用されます。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
キーの組み合わせ動作
ctrl + Spaceフォーカスを含む列を選択します。
shift + Spaceフォーカスを含む行を選択します。 グリッドに行を選択するためのチェックボックス付きの列が含まれている場合、このキーの組み合わせを使用して、フォーカスがチェックボックスにない場合でもそのボックスをチェックできます。
ctrl + Aすべてのセルを選択します。
shift + →選択範囲を1セル右側に拡張します。
shift + ←選択範囲を1セル左側に拡張します。
shift + ↓選択範囲を1セル下側に拡張します。
shift + ↑選択範囲を1セル上側に拡張します。
+ +

例

+ +

カレンダーの例

+ + + +

{{EmbedLiveSample("Calendar_example", "100%", "300")}}

+ +

 

+ +

HTML

+ +
<table role="grid" aria-labelledby="calendarheader">
+  <caption id="calendarheader">September 2018</caption>
+  <thead role="rowgroup">
+    <tr role="row">
+      <td></td>
+      <th role="columnheader" aria-label="Sunday">S</th>
+      <th role="columnheader" aria-label="Monday">M</th>
+      <th role="columnheader" aria-label="Tuesday">T</th>
+      <th role="columnheader" aria-label="Wednesday">W</th>
+      <th role="columnheader" aria-label="Thursday">T</th>
+      <th role="columnheader" aria-label="Friday">F</th>
+      <th role="columnheader" aria-label="Saturday">T</th>
+    </tr>
+  </thead>
+  <tbody role="rowgroup">
+    <tr role="row">
+      <th scope="row" role="rowheader">Week 35</th>
+      <td>26</td>
+      <td>27</td>
+      <td>28</td>
+      <td>29</td>
+      <td>30</td>
+      <td>31</td>
+      <td role="gridcell" tabindex="-1">1</td>
+    </tr>
+    <tr role="row">
+      <th scope="row" role="rowheader">Week 36</th>
+      <td role="gridcell" tabindex="-1">
+        2
+      </td>
+      <td role="gridcell" tabindex="-1">
+        3
+      </td>
+      <td role="gridcell" tabindex="-1">
+        4
+      </td>
+      <td role="gridcell" tabindex="-1">
+        5
+      </td>
+      <td role="gridcell" tabindex="-1">
+        6
+      </td>
+      <td role="gridcell" tabindex="-1">
+        7
+      </td>
+      <td role="gridcell" tabindex="-1">
+        8
+      </td>
+    </tr>
+    <!-- … Additional Rows … -->
+  </tbody>
+</table>
+ +

CSS

+ +
table {
+  margin: 0;
+  border-collapse: collapse;
+  font-variant-numeric: tabular-nums;
+}
+
+tbody th, tbody td {
+  padding: 5px;
+}
+
+tbody td {
+  border: 1px solid #000;
+  text-align: right;
+  color: #767676;
+}
+
+tbody td[role="gridcell"] {
+  color: #000;
+}
+
+tbody td[role="gridcell"]:hover, tbody td[role="gridcell"]:focus {
+  background-color: #f6f6f6; outline: 3px solid blue;
+}
+
+ +

JavaScript

+ +
var selectables = document.querySelectorAll('table td[role="gridcell"]');
+
+selectables[0].setAttribute('tabindex', 0);
+
+var trs = document.querySelectorAll('table tbody tr'),
+    row = 0,
+    col = 0,
+    maxrow = trs.length - 1,
+    maxcol = 0;
+
+Array.prototype.forEach.call(trs, function(gridrow, i){
+  Array.prototype.forEach.call(gridrow.querySelectorAll('td'), function(el, i){
+    el.dataset.row = row;
+    el.dataset.col = col;
+    col = col + 1;
+  });
+  if (col>maxcol) { maxcol = col - 1; }
+  col = 0;
+  row = row + 1;
+});
+
+function moveto(newrow, newcol) {
+  var tgt = document.querySelector('[data-row="' + newrow + '"][data-col="' + newcol + '"]');
+  if (tgt && (tgt.getAttribute('role')==='gridcell') ) {
+    Array.prototype.forEach.call(document.querySelectorAll('[role=gridcell]'), function(el, i){
+      el.setAttribute('tabindex', '-1');
+    });
+    tgt.setAttribute('tabindex', '0');
+    tgt.focus();
+    return true;
+  } else {
+    return false;
+  }
+}
+
+document.querySelector('table').addEventListener("keydown", function(event) {
+  switch (event.key) {
+    case "ArrowRight":
+      moveto(parseInt(event.target.dataset.row, 10), parseInt(event.target.dataset.col, 10) + 1);
+      break;
+    case "ArrowLeft":
+      moveto(parseInt(event.target.dataset.row, 10), parseInt(event.target.dataset.col, 10) - 1);
+      break;
+    case "ArrowDown":
+      moveto(parseInt(event.target.dataset.row, 10) + 1, parseInt(event.target.dataset.col, 10));
+      break;
+    case "ArrowUp":
+      moveto(parseInt(event.target.dataset.row, 10) - 1, parseInt(event.target.dataset.col, 10));
+      break;
+    case "Home":
+      if (event.ctrlKey) {
+        var i = 0;
+        var result;
+        do {
+          var j = 0;
+          var result;
+          do {
+            result = moveto(i, j);
+            j++;
+          } while (result == false);
+          i++;
+        } while (result == false);
+      } else {
+        moveto(parseInt(event.target.dataset.row, 10), 0);
+      }
+      break;
+    case "End":
+      if (event.ctrlKey) {
+        var i = maxrow;
+        var result;
+        do {
+          var j = maxcol;
+          do {
+            result = moveto(i, j);
+            j--;
+          } while (result == false);
+          i--;
+        } while (result == false);
+      } else {
+        moveto(parseInt(event.target.dataset.row, 10), document.querySelector('[data-row="' + event.target.dataset.row + '"]:last-of-type').dataset.col);
+      }
+      break;
+    case "PageUp":
+      var i = 0;
+      var result;
+      do {
+        result = moveto(i, event.target.dataset.col);
+        i++;
+      } while (result == false);
+      break;
+    case "PageDown":
+      var i = maxrow;
+      var result;
+      do {
+        result = moveto(i, event.target.dataset.col);
+        i--;
+      } while (result == false);
+      break;
+    case "Enter":
+      alert(event.target.textContent);
+      break;
+  }
+  event.preventDefault();
+});
+ +

 

+ +

より多くの例

+ +

他の例を以下で見つけることができます。

+ + + +

アクセシビリティに関する懸念

+ +

{{anch("Keyboard interactions","キーボードインタラクション")}}が適切に実装されていても、矢印キーを使用する必要があることに気づかないユーザーもいます。 grid ロールを使用して、必要な機能とインタラクションが最善にアーカイブできることを確認してください。

+ +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#grid","Role Grid")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#grid","Role Grid")}}{{Spec2('ARIA Authoring Practices')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/heading_role/index.html b/files/ja/web/accessibility/aria/roles/heading_role/index.html new file mode 100644 index 0000000000..b8fb52a347 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/heading_role/index.html @@ -0,0 +1,114 @@ +--- +title: 'ARIA: heading ロール' +slug: Web/Accessibility/ARIA/Roles/heading_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/heading_role +--- +
 {{MDNSidebar}}\{{ariaref}}
+ +

heading ロールは、この要素をページやセクションの見出しとして定義します。 ページに構造を与えるために、セクション間の関係を示すレベルも提供するべきです。

+ +
<div role="heading" aria-level="1">これはメインページの見出しです</div>
+
+ +

これは div のテキストをページのメインの見出しとして定義します。 それは aria-level 属性を介してレベル 1 で示します。

+ +

説明

+ +

heading ロールは、この要素を見出しのように扱うべきであることを支援技術に示します。 スクリーンリーダーは、たとえば、テキストを読み、このテキストが見出しのように書式設定されていることを示します。 さらに、レベルは、この見出しが表すページ構造のどの部分を支援技術に伝えるべきかを示すべきです。 レベル 1 見出しは、通常、ページのメインの見出しを示し、レベル 2 は、最初のサブセクションを示し、レベル 3 は、そのサブセクションなどとなります。

+ +

関連する ARIA のロール、ステート、プロパティ

+ +
+
aria-level
+
aria-level 属性は、この見出しが文書構造内にあるレベルを指定します。 レベルが存在しない場合、デフォルト値は 2 です。
+
+ +

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

+ +

このロールは特別なキーボードナビゲーションを必要としません。 どんな見出しもそうであるように、ID を与えることで、アンカーリンクから参照できるようになり、キーボードを介してアクセス可能となります。

+ +

必要な JavaScript 機能

+ +
+
必要なイベントハンドラ
+
無し
+
属性値の変更
+
コンテンツを動的に挿入する場合を除き、通常は必須ではありませんが、この場合、新しく追加された見出しには、文書構造の残りの部分と値が整合する aria-level 属性が必要です。
+
+ +
+

heading ロールと aria-level で <div> または <span> を使用する代わりに、このテキストが見出しであり、それが表す構造の部分を示すために、代わりに <h1> から <h6> の要素を使用することを検討してください 。

+
+ +

例

+ +

以下は典型的なページ構造を示しています。

+ +
<div id="container">
+<div role="heading" aria-level="1">メインページ見出し</div>
+<p>この記事では、ページ構造の表示について説明します。</p>
+<div role="heading" aria-level="2">前書き</div>
+<p>導入テキスト。</p>
+<div role="heading" aria-level="2">第 1 章</div>
+<p>テキスト</p>
+<div role="heading" aria-level="3">第 1.1 章</div>
+<p>サブセクション内の複数のテキスト。</p>
+...</div>
+ +

ただし、代わりに次のようにするべきです。

+ +
<div id="container">
+<h1>メインページ見出し</h1>
+<p>この記事では、ページ構造の表示について説明します。</p>
+<h2>前書き</h2>
+<p>導入テキスト。</p>
+<h2>第 1 章</h2>
+<p>テキスト</p>
+<h3>第 1.1 章</h3>
+<p>サブセクション内の複数のテキスト。</p>
+...</div>
+ +

アクセシビリティに関する懸念

+ +

heading ロールと aria-level 属性を使用する必要がある場合は、HTML との整合性を保つために、レベルでレベル 6 を超えないようにしてください。 理論的にはそれより大きくすることができますが、一部のスクリーンリーダーでサポートする場合もありますが、他のブラウザーやスクリーンリーダーの組み合わせでは結果が予測できない場合があります。

+ +

ベストプラクティス

+ +

このロールを使用する最良の方法は、まったく使用しないで、代わりに上記の例に示すようにネイティブの見出しタグ <h1> ～ <h6> を使用することです。 heading ロールと aria-level 属性は、実際には、大きな変更を加えることができないレガシーコードにアクセシビリティを取り入れる場合にのみ使用するべきです。

+ +

追加の利点

+ +

無し

+ +

仕様

+ + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#heading","heading")}}{{Spec2('ARIA')}}
+ +

優先順位

+ +

heading ロールは、それが使用されている要素のネイティブな意味論的意味をオーバーライドします。 また、aria-level 属性は、どのレベルの見出しが公開されているかに関する情報を提供します。

+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/index.html b/files/ja/web/accessibility/aria/roles/index.html new file mode 100644 index 0000000000..c3fc70ecab --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/index.html @@ -0,0 +1,72 @@ +--- +title: WAI-ARIA ロール +slug: Web/Accessibility/ARIA/Roles +translation_of: Web/Accessibility/ARIA/Roles +--- +

このページは、MDN で説明されているすべての WAI-ARIA ロールをカバーするリファレンスページを一覧にしています。ロールの完全なリストについては、ARIA を使用する: ロール、ステート、プロパティをご覧ください。

+ +

{{SubpagesWithSummaries}}

+ + diff --git a/files/ja/web/accessibility/aria/roles/list_role/index.html b/files/ja/web/accessibility/aria/roles/list_role/index.html new file mode 100644 index 0000000000..d3dfaa48f3 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/list_role/index.html @@ -0,0 +1,115 @@ +--- +title: 'ARIA: list ロール' +slug: Web/Accessibility/ARIA/Roles/List_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/List_role +--- +

\{{ariaref}}ARIA の list ロールは、項目のリスト（list）を識別するために使用できます。 これは、通常、リスト内に含まれるリスト項目（list item）を識別するために使用される listitem ロールと組み合わせて使用されます。

+ +
<section role="list">
+  <div role="listitem">リスト項目 1</div>
+  <div role="listitem">リスト項目 2</div>
+  <div role="listitem">リスト項目 3</div>
+</section>
+
+ +

説明

+ +

外側のコンテナとその内側の要素のリストで構成されるコンテンツは、それぞれ list と listitem のコンテナを使用して支援技術で識別できます。 list には1つ以上の listitem の子が含まれているか、1つ以上の group が子として存在し、各 group には1つ以上の listitem が子として格納されている必要があります。

+ +

リストとリスト項目をマークアップするためにどの要素を使用すべきかについて、鉄則はありませんが、リスト項目がリストのコンテキストで意味をなすようにするべきです。 例えば、買い物リスト、料理の手順、運転の指示。

+ +
+

警告: 可能な限り、適切な意味論の HTML 要素を使用して、list とその listitem（{{htmlelement("ul")}} や {{htmlelement("ol")}} と {{htmlelement("li")}}）をマークアップする必要があります。 詳しくは、{{anch("Best practices","ベストプラクティス")}}を参照してください。

+
+ +

 

+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +
+
listitem
+
+

リストやディレクトリ内の単一項目。 listitem ロールを持つ要素は、list ロールや group ロールを持つ要素内にのみ存在します。

+
+
group
+
+

リストにネストされたときにリスト項目に限定される関連オブジェクトのコレクションです。 ページの目次に独自の場所を持つほど重要ではありません。

+
+
+ +

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

+ +

無し

+ +

必要な JavaScript 機能

+ +

無し

+ +

例

+ +

 ARIA Lists — Scott O'Hara によるいくつかの有用な例と考え（英語）

+ +

ベストプラクティス

+ +

例えば、HTML を制御できないが、JavaScript を使用した後でアクセシビリティを動的に向上させる必要がある場合など、role="list" と role="listitem" のみを使用する必要があります。

+ +

HTML の {{htmlelement("ol")}} と {{htmlelement("ul")}} とは異なり、ARIA の list ロールは順序付きリストと順序無しリストを区別しません。 可能な場合は、リスト（{{htmlelement("ol")}} と {{htmlelement("ul")}}）とリスト項目（{{htmlelement("li")}}）をマークアップするのに適切な意味論の HTML 要素を使用するべきです。 例えば、上記の例は次のように書き直すべきです。

+ +
<ul>
+  <li>リスト項目 1</li>
+  <li>リスト項目 2</li>
+  <li>リスト項目 3</li>
+</ul>
+ +

リスト項目の順序が重要な場合は、順序付きリストを使用します。

+ +
<ol>
+  <li>リスト項目 1</li>
+  <li>リスト項目 2</li>
+  <li>リスト項目 3</li>
+</ol>
+ +
+

注: ARIA の list ロールと listitem ロールでは、順序付きリストと順序無しリストを区別しません。

+
+ +

仮に、ol または ul という意味論の HTML 要素を使用して presentation ロールを適用する場合、ARIA では listitem 要素に親 list 要素が必要であるため、各子 li 要素は presentation ロールを継承します。 したがって、li 要素は支援技術には見えませんが、これらの要素の内部に含まれる要素（ネストされたリストを含む）は、支援技術に見えます。

+ +
+

注: タブ付きインターフェースとして機能する項目のリストをマークアップする場合は、代わりに tab、tabpanel、tablist ロールを使用するべきです。

+
+ +

仕様

+ + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#list","list")}}{{Spec2('ARIA')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/listbox_role/index.html b/files/ja/web/accessibility/aria/roles/listbox_role/index.html new file mode 100644 index 0000000000..58106a9e75 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/listbox_role/index.html @@ -0,0 +1,211 @@ +--- +title: 'ARIA: listbox ロール' +slug: Web/Accessibility/ARIA/Roles/listbox_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/listbox_role +--- +

\{{ariaref}}

+ + + + + +

listbox ロールは、ユーザーが静的な1つ以上の項目を選択するリストに使用され、HTML の <select> 要素とは異なり、画像を含むことがあります。

+ +

説明

+ +

listbox ロールは、HTML の {{htmlelement("select")}} 要素と同様に、ユーザーが1つまたは複数の静的項目を選択できるリストを作成する要素を識別するために使用されます。 <select> とは異なり、リストボックス（listbox）は画像を含むことができます。 リストボックスのそれぞれの子は、option ロールを持つべきです。

+ +

HTML の <select> 要素または、1項目のみを選択する場合はラジオボタンのグループ、複数項目を選択する場合はチェックボックスのグループを使用することを強くお勧めします。 なぜなら、全ての子孫のフォーカスを管理するためのキーボードのインタラクティビティがたくさんあり、ネイティブな HTML 要素がこの機能を無料で提供するためです。

+ +

listbox ロールを持つ要素は、暗黙の aria-orientation の値に vertical を持ちます。

+ +

リストにタブで移動した場合、他に何も選択されていない場合はリスト内の最初の項目が選択されます。 上/下矢印はリストをナビゲートし、Shift + 上/下矢印を押すと選択範囲が移動して拡張されます。 1つ以上の文字を入力すると、リスト項目をナビゲートします（同じ文字はその文字から始まる各項目に移動し、異なる文字はその文字列全体で始まる最初の項目に移動します）。 現在の項目に関連するコンテキストメニューがある場合、Shift + F10 でそのメニューが起動します。 リスト項目がチェック可能である場合、スペースを使用してチェックボックスをトグルできます。 選択可能なリスト項目の場合、スペースは選択をトグルし、Shift + スペースを使用して連続項目を選択し、Ctrl + 矢印で選択せず​​に移動し、Ctrl + スペースを使用して不連続項目を選択できます。 全ての項目を選択するには、チェックボックス、リンクまたは他の方法を使用することをお勧めします。 Ctrl + A は、このためのショートカットキーとして使用できます。

+ +

listbox ロールが要素に追加されるか、そのような要素が可視になると、スクリーンリーダーは、フォーカスを得たときにリストボックスのラベルとロールをアナウンスします。 オプションや項目がリスト内でフォーカスされている場合は、次にそれがアナウンスされ、その後、スクリーンリーダーがサポートしている場合は、リストでの項目の位置が示されます。 リスト内でフォーカスが移動すると、スクリーンリーダーは関連する項目をアナウンスします。

+ +

関連する ARIA のロール、ステート、プロパティ

+ +

関連するロール

+ +
+
option
+
1つ以上のネストされたオプションが必要です。 選択された全てのオプションは、aria-selected が true に設定されています。 選択されていない全てのオプションは、aria-selected が false に設定されています。 オプションを選択できない場合は、aria-selected を省略します。
+
list
+
listitem 要素を含むセクション。
+
+ +

ステートとプロパティ

+ +
+
aria-multiselectable
+
ユーザーが複数のオプションを選択できるようにするには、これを含めて true を設定します。 true に設定するならば、全てのオプションに aria-selected 属性を含めるべきです。 false または省略すると、現在選択されているオプションのみが選択され、いずれかのオプションが選択されている場合は、aria-selected 属性が必要で、true に設定する必要があります。
+
aria-activedescendant
+
そのオプションの aria-selected の値が true や false を持っているかどうかに関わらず、最も最近にオプションと対話したことを意味する、現在アクティブなオプションの id を値として取ります。 複数選択であっても、1つの id の値をとります。
+
aria-required
+
選択が必要であることを示します。
+
aria-readonly
+
リストボックスは編集可能ではありません。 ユーザーはオプションの選択や非選択を変更することはできませんが、それ以外の操作は可能です。
+
+ +

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

+ + + +

必要な JavaScript 機能

+ +

単一選択リストボックスでオプションを選択する

+ +

ユーザーがオプションを選択すると、以下が起こる必要があります。

+ +
    +
  1. 前に選択したオプションを非選択にし、aria-selected を false に設定するか、属性を完全に削除して、新しく選択されなくなったオプションの外観を選択されていないように変更する。
    2. +
  2. 新しく選択したオプションを選択し、オプションで aria-selected="true" と設定し、新しく選択されたオプションの外観を選択されているように変更する。
    3. +
  3. リストボックスの aria-activedescendant の値を、新しく選択したオプションの id に更新する。
    4. +
  4. オプションのぼかし、フォーカス、選択状態を視覚的に処理する。
    5. +
+ +

複数選択リストボックスでオプションの状態をトグルする

+ +

ユーザーがオプションをクリックするか、オプションにフォーカスを当てたときにスペースを押すか、その他でオプションの状態をトグルすると、以下が起こる必要があります。

+ +
    +
  1. 現在選択されているオプションの aria-selected ステート（状態）をトグルし、選択されている aria-selected の状態を false なら true に、true なら false に変更する。
    2. +
  2. 選択状態を反映するようにオプションの外観を変更する。
    3. +
  3. リストボックスの aria-activedescendant の値を、オプションが非選択へトグルされている場合でも、ユーザーが直前に対話したオプションの id に更新します。
    4. +
+ +
+

 ARIA の最初のルールは、要素を再定義し、ARIA のロール、ステート、プロパティを追加してアクセス可能にするのではなく、すでに組み込まれている意味論と挙動を持つネイティブな機能を使用できることです。 <option> 要素を子孫に持つ <select> 要素は、必要な全てのインタラクションをネイティブに処理します。

+
+ +

例

+ +

例 1: aria-activedescendant を使用する単一選択リストボックス

+ +

以下のスニペットは、listbox ロールが HTML ソースコードに直接どのように追加されるかを示しています。

+ +
<p id="listbox1label" role="label">色を選択:</p>
+<div role="listbox" tabindex="0" id="listbox1" aria-labelledby="listbox1label"
+  onclick="return listItemClick(event);"
+  onkeydown="return listItemKeyEvent(event);"
+  onkeypress="return listItemKeyEvent(event);"
+  aria-activedescendant="listbox1-1">
+    <div role="option" id="listbox1-1" class="selected" aria-selected="true">緑</div>
+    <div role="option" id="listbox1-2">オレンジ</div>
+    <div role="option" id="listbox1-3">赤</div>
+    <div role="option" id="listbox1-4">青</div>
+    <div role="option" id="listbox1-5">紫</div>
+    <div role="option" id="listbox1-6">ペリウィンクル</div>
+</div>
+
+ +

これは、ネイティブの HTML の {{htmlelement("select")}} 要素と {{htmlelement("label")}} 要素でより簡単に処理できます。

+ +
<label for="listbox1">色を選択:</label>
+<select id="listbox1">
+   <option selected>緑</option>
+   <option>オレンジ</option>
+   <option>赤</option>
+   <option>青</option>
+   <option>紫</option>
+   <option>ペリウィンクル</option>
+</select>
+ +

より多くの例

+ + + +

ベストプラクティス

+ + + +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#listbox","ARIA listbox role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#Listbox","Listbox Role")}}{{Spec2('ARIA Authoring Practices')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/listitem_role/index.html b/files/ja/web/accessibility/aria/roles/listitem_role/index.html new file mode 100644 index 0000000000..02c85295f2 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/listitem_role/index.html @@ -0,0 +1,113 @@ +--- +title: 'ARIA: listitem ロール' +slug: Web/Accessibility/ARIA/Roles/Listitem_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Listitem_role +--- +
\{{ariaref}}
+ +

ARIAの listitem ロールは、項目のリスト内の項目を識別するために使用できます。 これは、通常、リストコンテナを識別するために使用される list ロールとともに使用されます。

+ +
<section role="list">
+  <div role="listitem">リスト項目 1</div>
+  <div role="listitem">リスト項目 2</div>
+  <div role="listitem">リスト項目 3</div>
+</section>
+
+ +

説明

+ +

外側のコンテナとその内側の要素のリストで構成されるコンテンツは、それぞれ list と listitem のコンテナを使用して支援技術で識別できます。

+ +

リストとリスト項目をマークアップするためにどの要素を使用すべきかについて、鉄則はありませんが、リスト項目がリストのコンテキストで意味をなすようにするべきです。 例えば、買い物リスト、料理の手順、運転の指示。

+ +
+

警告: 可能な限り、適切な意味論の HTML 要素を使用して、list とその listitem（{{htmlelement("ul")}} や {{htmlelement("ol")}} と {{htmlelement("li")}}）をマークアップする必要があります。 詳しくは、{{anch("Best practices","ベストプラクティス")}}を参照してください。

+
+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +
+
list
+
+

項目のリスト。 list ロールを持つ要素には、子として listitem ロールを持つ1つ以上の要素、group ロールを持つ1つ以上の要素が必要です。 group ロールを持つ要素は、子として listitem ロールを持つ1つ以上の要素を持ちます。

+
+
group
+
+

リストにネストされたときにリスト項目に限定される関連オブジェクトのコレクションです。 ページの目次に独自の場所を持つほど重要ではありません。

+
+
+ +

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

+ +

無し

+ +

必要な JavaScript 機能

+ +

無し

+ +

例

+ +

 ARIA Lists — Scott O'Hara によるいくつかの有用な例と考え（英語）

+ +

ベストプラクティス

+ +

例えば、HTML を制御できないが、JavaScript を使用した後でアクセシビリティを動的に向上させる必要がある場合など、role="list" と role="listitem" のみを使用する必要があります。

+ +

可能な限り、適切な意味論の HTML 要素を使用して、list と listitem（{{htmlelement("ol")}} や {{htmlelement("ul")}} と {{htmlelement("li")}}）をマークアップする必要があります。 例えば、上記の例は次のように書き直すべきです。

+ +
<ul>
+  <li>リスト項目 1</li>
+  <li>リスト項目 2</li>
+  <li>リスト項目 3</li>
+</ul>
+ +

リスト項目の順序が重要な場合は、順序付きリストを使用します。

+ +
<ol>
+  <li>リスト項目 1</li>
+  <li>リスト項目 2</li>
+  <li>リスト項目 3</li>
+</ol>
+ +
+

注: ARIA の list ロールと listitem ロールでは、順序付きリストと順序無しリストを区別しません。

+
+ +
+

注: タブ付きインターフェースとして機能する項目のリストをマークアップする場合は、代わりに tab、tabpanel、tablist ロールを使用するべきです。

+
+ +

仕様

+ + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#listitem","listitem")}}{{Spec2('ARIA')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/main_role/index.html b/files/ja/web/accessibility/aria/roles/main_role/index.html new file mode 100644 index 0000000000..28d6448238 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/main_role/index.html @@ -0,0 +1,131 @@ +--- +title: 'ARIA: main ロール' +slug: Web/Accessibility/ARIA/Roles/Main_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Main_role +--- +

{{draft}}\{{ariaref}}

+ +

main ランドマークロールは、文書の主要なコンテンツを示すために使用されます。 メインコンテンツ領域は、文書の中心的な話題と直接に関連したり発展させるコンテンツや、アプリケーションの中心的な機能のコンテンツで構成されます。

+ +
<div id="main" role="main">
+  <h1>アボカド</h1>
+  <!-- メインセクションのコンテンツ -->
+</div>
+
+ +

これは、アボカドについて議論する文書のメインセクションです。 この文書のサブセクションでは、その歴史、品種の違い、栽培地域などを議論することができます。

+ +

説明

+ +

main ロールは、文書のメイン（main）コンテンツを識別するナビゲーションに関するランドマークロールです。 ランドマークは、支援技術によって使用され、文書の大きなセクションを迅速に識別してナビゲートすることができます。 ページのセクションを分類およびラベル付けすることにより、レイアウトを通じて視覚的に伝達される構造情報をプログラムで表現することができます。 スクリーンリーダーは、ランドマークロールを使用して、ページの重要なセクションにキーボードナビゲーションを提供します。 ランドマークロールを介してナビゲートする場合、main ロールは「メインコンテンツへスキップする」リンクの代わりです。 文書ごとに1つの main ランドマークロールがあるべきです。

+ +

{{htmlelement("main")}} 要素は main ロールを持ちます。 開発者は、ARIA を使用するよりも正しい意味論の HTML 要素を常に使用するべきです。

+ +

文書とアプリケーションは DOM にネストすることができます。 これにより、DOM の子孫として複数のメイン要素が存在する可能性があります。 このような場合は、aria-owns を組み込んで、文書やアプリケーションの祖先に対するメインの関係を識別します。

+ +

例

+ +
<body>
+  <!-- 主要なナビゲーション -->
+
+  <div role="main">
+    <h1>第一次インドシナ戦争</h1>
+    <!-- 記事のコンテンツ -->
+  </div>
+
+ <!-- サイドバーとフッター -->
+</body>
+
+ +

アクセシビリティに関する懸念

+ +

文書ごとに1つの main ロールのみを使用する

+ +

main ランドマークロールは、文書ごとに1回のみ使用するべきです。

+ +

文書に2つの main ロールが含まれている場合、JavaScript でトリガされたときにページコンテンツを更新するなどで、hidden 属性を切り替えるなどのテクニックによって、非アクティブな main ロールの存在を支援技術から取り除くべきです。

+ +
<main>
+  <h1>アクティブな <code>main</code> 要素</h1>
+  <!-- コンテンツ -->
+</main
+
+<main hidden>
+  <h1>隠された <code>main</code> 要素</h1>
+  <!-- コンテンツ -->
+</main>
+
+ +

ベストプラクティス

+ +

好ましい HTML

+ +

{{htmlelement("main")}} 要素を使用すると自動的にセクションが main ロールを持つことを伝えます。 可能であれば、<main> を代わりに使用することをお勧めします。

+ +

スキップナビゲーション

+ +

スキップナビゲーション（"skipnav" とも呼ばれる）は、支援技術のユーザーが繰返したコンテンツ（メインナビゲーション、情報バナーなど）の大きなセクションをすばやくバイパスすることを可能にするテクニックです。 これにより、ユーザーはページのメインコンテンツにすばやくアクセスできます。

+ +

role="main" という宣言を持つ要素に id 属性を追加すると、それをスキップナビゲーションリンクのターゲットにすることができます。

+ +
<body>
+  <a href="#main-content">メインコンテンツへスキップする</a>
+
+  <!-- ナビゲーションとヘッダーのコンテンツ -->
+
+  <div id="main-content" role="main">
+    <!-- メインページのコンテンツ -->
+  </div>
+</body>
+
+ + + +

追加された利点

+ +

ブラウザー拡張などの特定の技術は、ページ上に存在する全てのランドマークロールのリストを生成することができ、非スクリーンリーダーユーザーは文書の大きなセクションを素早く識別してナビゲートできます。

+ + + +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#main","ARIA Main Role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#aria_lh_main","Main Landmark Role")}}{{Spec2('ARIA Authoring Practices')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/navigation_role/index.html b/files/ja/web/accessibility/aria/roles/navigation_role/index.html new file mode 100644 index 0000000000..80bdc3d70a --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/navigation_role/index.html @@ -0,0 +1,151 @@ +--- +title: 'ARIA: navigation ロール' +slug: Web/Accessibility/ARIA/Roles/Navigation_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Navigation_Role +--- +

\{{ariaref}}

+ +

navigation ランドマークロールは、ウェブサイトまたはページコンテンツをナビゲートするために使用される主要なリンクのグループを識別するために使用されます。

+ +
<div role="navigation" aria-label="メインナビゲーション">
+  <!-- 主要なウェブサイトの場所へのリンクのリスト -->
+</div>
+
+ +

これはウェブサイトのメインナビゲーションです。

+ +

説明

+ +

navigation ロールはランドマークロールです。 ランドマークロールは、ウェブページの構成と構造を識別する方法を提供します。 ページのセクションを分類およびラベル付けすることにより、レイアウトを通じて視覚的に伝達される構造情報がプログラム的に表されます。 スクリーンリーダーは、ランドマークロールを使用して、ページの重要なセクションにキーボードナビゲーションを提供します。 HTML の <nav> 要素と同様に、navigation ランドマークは、ウェブサイトまたはページコンテンツのナビゲーション（navigation）に使用するリンクのグループ（例えば、リスト）を識別する手段を提供します。 ページに複数の navigation ランドマークが含まれている場合は、それぞれが固有のラベルを持つべきです。 ページ上の2つ以上のナビゲーションに関するランドマークが同じリンクのセットを持つ場合は、それぞれに同じラベルを使用します。

+ +

navigation ランドマークを定義するには、HTML5 の {{htmlelement("nav")}} 要素を使用することをお勧めします。 HTML5 の <nav> 要素のテクニックが使用されていない場合は、role="navigation" 属性を使用して navigation ランドマークを定義します。

+ +
+

{{htmlelement("nav")}} 要素を使用すると、自動的にセクションが navigation ロールを持つことを伝えます。 開発者は、ARIA を使用するよりも正しい意味論の HTML 要素を常に使用するべきです。

+
+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +
+
aria-label
+
ナビゲーションの目的を簡単に説明します。 スクリーンリーダーはロールとラベルの内容の両方を読むので、"navigation" という用語を省略します。
+
+ +

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

+ +

無し

+ +

必要な JavaScript 機能

+ +

無し

+ +

例

+ +
<div role="navigation" aria-label="顧客サービス">
+  <ul>
+    <li><a href="#">ヘルプ</a></li>
+    <li><a href="#">注文追跡</a></li>
+    <li><a href="#">出荷と配達</a></li>
+    <li><a href="#">返品</a></li>
+    <li><a href="#">お問い合わせ</a></li>
+    <li><a href="#">お店を探す</a></li>
+  </ul>
+</div>
+
+ +

アクセシビリティに関する懸念

+ +

ランドマークロールは、文書のより大きな全体的なセクションを識別するために、控えめに使用することを意図しています。 あまりにも多くのランドマークロールを使用すると、スクリーンリーダーで「ノイズ」が発生し、ページ全体のレイアウトを理解することが難しくなります。

+ +

ベストプラクティス

+ +

好ましい HTML

+ +

{{htmlelement("nav")}} 要素を使用すると、自動的にセクションが navigation ロールを持つことを伝えます。 可能であれば、<nav> を代わりに使用することをお勧めします。

+ +

ランドマークのラベル付け

+ +

複数のランドマーク

+ +

文書に複数の navigation ランドマークロールや {{htmlelement("nav")}} 要素がある場合は、各ランドマークに対してラベルを指定します。 このラベルで、支援技術のユーザーがそれぞれのランドマークの目的をすばやく理解することができます。

+ +
<div id="main-nav" role="navigation" aria-label="メイン">
+  <!-- コンテンツ -->
+</div>
+
+...
+
+<nav id="footer-nav" aria-label="フッター">
+  <!-- コンテンツ -->
+</nav>
+
+ +

繰り返されるランドマーク

+ +

文書内の navigation ランドマークロールまたは {{htmlelement("nav")}} 要素が文書内で繰り返され、両方のランドマークのコンテンツが同じ場合は、各ランドマークに同じラベルを使用します。 この例では、ページの上部と下部でメインナビゲーションが繰り返されています。

+ +
<header>
+  <nav id="main-nav" aria-label="メイン">
+    <!-- 主要なウェブサイトの場所へのリンクのリスト -->
+  </div>
+</header>
+
+...
+
+<footer>
+  <nav id="footer-nav" aria-label="メイン">
+    <!-- 主要なウェブサイトの場所へのリンクのリスト -->
+  </nav>
+</footer>
+
+ +

冗長な説明

+ +

スクリーンリーダーは、ランドマークロールの種類をアナウンスします。 このため、ラベルでランドマークが何であるかを説明する必要はありません。 例えば、aria-label="主要なナビゲーション" の role="navigation" の宣言は、"navigation 主要なナビゲーション" として重複してアナウンスすることができます。

+ +

追加された利点

+ +

ブラウザー拡張などの特定の技術は、ページ上に存在する全てのランドマークロールのリストを生成することができ、非スクリーンリーダーユーザーは文書の大きなセクションを素早く識別してナビゲートできます。

+ + + +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#navigation","ARIA Navigtion Role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#aria_lh_navigation","Navigation Landmark Role")}}{{Spec2('ARIA Authoring Practices')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/region_role/index.html b/files/ja/web/accessibility/aria/roles/region_role/index.html new file mode 100644 index 0000000000..d986fecb65 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/region_role/index.html @@ -0,0 +1,138 @@ +--- +title: 'ARIA: region ロール' +slug: Web/Accessibility/ARIA/Roles/Region_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Region_role +--- +

\{{ariaref}}

+ +

region ランドマークロールは、文書内で、著者が重要であると識別した領域を識別するために使用されます。 これは、他のランドマークロールのどれも適切でないときでも、汎用のランドマークを提供することで、人々が容易にナビゲートできるようにするために使用されます。

+ +
<div role="region" aria-label="例">
+  <!-- リージョンのコンテンツ -->
+</div>
+
+ +

説明

+ +

region ロールは、ARIA のランドマークロールです。 ランドマークロールは、ウェブページの構成と構造を識別する方法を提供します。 ページのセクションを分類およびラベル付けすることにより、レイアウトを通じて視覚的に伝達される構造情報がプログラム的に表されます。 スクリーンリーダーは、ランドマークロールを使用して、ページの重要なセクションにキーボードナビゲーションを提供します。

+ +

region ロールは、ユーザーがそのセクションに簡単にナビゲートし、ページの要約にリストされることを望むほど重要なコンテンツのセクションのために予約するべきです。 region ロールはより汎用の用語であり、識別が必要なセクションが、banner、main、contentinfo、complementary、navigation などの他のランドマークロールのいずれかによって正確に説明できない場合に使用するべきです。

+ +

region ロールを持つすべての要素には、リージョン（region）内のコンテンツの目的を説明するラベルを含めるべきで、目に見えるヘッダーを参照する aria-labelledby を伴うのが好ましいです。 目に見える適切なヘッダーがない場合は、aria-label を使用するべきです。

+ +

region ランドマークロールのコンテンツは、文書のメインコンテンツから分離されている場合にも意味をなすべきです。

+ +

{{htmlelement("section")}} 要素を使用すると、アクセス可能な名前が与えられている場合、自動的にセクションが region ロールを持つことを伝えます。 開発者は、ARIA を使用するよりも正しい意味論の HTML 要素（この場合は <section>）を常に使用するべきです。

+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +
+
aria-labeledby
+
リージョンにラベルを付けるには、この属性を使用します。 多くの場合、aria-labeledby 属性の値は、セクションのタイトルに使用される要素の ID になります。
+
+ +

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

+ +

無し

+ +

必要な JavaScript 機能

+ +

無し

+ +

例

+ +
<div role="region" aria-labeledby="region-heading">
+  <h2 id="region-heading">この見出しの <code>id</code> 属性は、このリージョンがアクセス可能な名前を持つのに役立ちます</h2>
+  <!-- リージョンのコンテンツ -->
+</div>
+
+ +

アクセシビリティに関する懸念

+ +

控えめに使用してください！ ランドマークロールは、文書のより大きな全体的なセクションを識別するために、控えめに使用することを意図しています。 あまりにも多くのランドマークロールを使用すると、スクリーンリーダーで「ノイズ」が発生し、ページ全体のレイアウトを理解することが難しくなります。

+ +

他の関連コンテンツセクショニング要素またはランドマークロールが当てはまらない場合にのみ、region ロールを使用してください。 ページ上に複数のリージョンが存在する場合は、そのページの全体構造を再検討する価値があります。

+ +

ベストプラクティス

+ +

好ましい HTML

+ +

{{htmlelement("section")}} 要素を使用すると、アクセス可能な名前が与えられている場合、自動的にセクションが region ロールを持つことを伝えます。 可能であれば、<section> を代わりに使用することをお勧めします。

+ +

ランドマークのラベル付け

+ +

文書に複数の region ランドマークロールがある場合は、それぞれにラベルを付けます。 このラベルで、支援技術のユーザーがそれぞれのランドマークの目的をすばやく理解することができます。

+ +
<div role="region" aria-labeledby="heading">
+  <h3 id="use-discretion">慎重に <code>region</code> ロールを使用してください</h3>
+  <!-- コンテンツ -->
+</div>
+
+...
+
+<div role="region" aria-labeledby="please-reconsider">
+  <h3 id="please-reconsider">文書構造を再検討してください</h3>
+  <!-- コンテンツ -->
+</div>
+
+ +

この例では、リージョンのラベルは aria-labeledby 属性によって作成されています。

+ +

オーバーフローテキストを含むコンテンツ領域のスクロール

+ +

tabindex="0" のコンテンツ領域がある場合は、role="region" を追加して、汎用のリージョンであるとスクリーンリーダーのユーザーに伝えます。 これは、キーボードのみのユーザーがオーバーフローテキストを含むリージョンをスクロールできるようにするためです。

+ +

SVG

+ +

SVG の個々のセクションを説明できるようにするために、SVG の領域上に role="region" を aria-label とともに宣言することができます。

+ +

追加された利点

+ +

ブラウザー拡張などの特定の技術は、ページ上に存在する全てのランドマークロールのリストを生成することができ、非スクリーンリーダーユーザーは文書の大きなセクションを素早く識別してナビゲートできます。

+ + + +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#region","ARIA Region Role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#aria_lh_region","Region landmark role")}}{{Spec2('ARIA Authoring Practices')}}
+ +

 

+ +

スクリーンリーダーのサポート

+ +

 

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/role_img/index.html b/files/ja/web/accessibility/aria/roles/role_img/index.html new file mode 100644 index 0000000000..748b3e3f47 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/role_img/index.html @@ -0,0 +1,125 @@ +--- +title: 'ARIA: img ロール' +slug: Web/Accessibility/ARIA/Roles/Role_Img +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Role_Img +--- +
\{{ariaref}}
+ +

ARIA の img ロールは、単一の画像とみなすべきページコンテンツ内の複数の要素を識別するために使用できます。 これらの要素は、画像、コードスニペット、テキスト、絵文字、または視覚的に情報を伝達するために組み合わせることができる他のコンテンツであってもよい。

+ +
<div role="img" aria-label="全体的な画像の説明">
+  <img src="graphic1.png" alt="">
+  <img src="graphic2.png">
+</div>
+
+ +

説明

+ +

role="img" を使用すると、単一の画像（画像、動画、音声、コードスニペット、絵文字、その他のコンテンツを含む）として消費されるべきコンテンツの集合を識別できます。

+ +

支援技術へのコンテキストを伝えるために個々の画像要素の代替テキストを数えるべきではありません。 ほとんどのスクリーンリーダーは、role="img" を持つ要素をブラックボックスのように見て、内部の個々の要素にはアクセスしません。 したがって、周囲のテキストのいずれか、または aria-label 属性を使用して画像の包括的な全体説明的な代替テキストを提供します。 画像が欠ける場合は、検索エンジンまたはサイトユーザーのためのオプションの alt 属性を使用してページに書きます。

+ +
<div role="img" aria-label="全体的な画像の説明">
+  <img src="graphic1.png" alt="">
+  <img src="graphic2.png">
+</div>
+ +

ページに表示される画像にキャプションまたはラベルを追加する場合は、次の方法を使用できます。

+ + + +

例えば、

+ +
<div role="img" aria-labelledby="image-1">
+  ...
+  <p id="image-1">画像のグループを説明するテキスト。</p>
+</div>
+ +

SVG と role="img"

+ +

ページに埋め込み SVG 画像を使用している場合は、外側の <svg> 要素で role="img" を設定し、ラベルを付けることをお勧めします。 これにより、スクリーンリーダーは全ての子ノードを読み出すのではなく、単一の実体とみなし、ラベルを使用して説明します。

+ +
<svg role="img" aria-label="SVG 画像の説明">
+  <!-- SVG 画像の内容 -->
+</svg>
+ +

role="img" を使用して、不明瞭や暗黙なものに意味を付与する

+ +

場合によっては、支援技術ユーザーは、特定の方法で、特定のメディアを通して、または特定の方法で暗示された内容の意味を得ることができません。 これは画像の場合では直すのは明らかです（alt 属性を使うことができます）が、混在したコンテンツや他の特定の種類のコンテンツの場合はそれほど明白ではないので、role="img" が有効になります。

+ +

例えば、テキストに絵文字を使用した場合、その意味は目の見えるユーザーにとっては明白かもしれませんが、スクリーンリーダーを使用している人は、絵文字はテキスト表現を全く持たないか、代替テキストが紛らわしく、使用されているコンテキストと一致しない可能性があります。 例えば、次のコードです。

+ +
<div role="img" aria-label="その猫はとても面白い">
+  <p>
+    &#x1F408; &#x1F602;
+  </p>
+</div>
+ +

&#x1F408; &#x1F602; の絵文字の実体参照は「猫」と「涙が出るほど嬉しい顔」で読み上げられますが、これは必ずしも意味をなしません — 暗黙の意味はおそらく「その猫はとても面白い」で、それを aria-label で role="img" と一緒に指定します。

+ +

これはブラウザーやスクリーンリーダーの組み合わせによっては正常に動作するように見えますが、その中にはラベルを2度読んでしまうものもあります。 慎重に使用し、十分にテストしてください。

+ +

これが適している別の例は、伝説的な「ちゃぶ台返し」のような ASCII 絵文字の組み合わせを使用する場合です。

+ +
<div role="img" aria-label="ちゃぶ台返し">
+  <p>
+    (╯°□°）╯︵ ┻━┻
+  </p>
+</div>
+ +

 

+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +
+
aria-label
+
アクセス可能な名前が必要です。 aria-label 属性
+
 
+
+ +

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

+ +

 

+ +

 

+ +

必要な JavaScript 機能

+ +

例

+ + + +

仕様

+ + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#img","img")}}{{Spec2('ARIA')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/row_role/index.html b/files/ja/web/accessibility/aria/roles/row_role/index.html new file mode 100644 index 0000000000..8cb4b15f96 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/row_role/index.html @@ -0,0 +1,231 @@ +--- +title: 'ARIA: row ロール' +slug: Web/Accessibility/ARIA/Roles/Row_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Row_Role +--- +
\{{ariaref}}
+ +

role="row" の要素は、表形式の構造内のセルの行（row）です。 行には、grid、table、treegrid 内の1つ以上のセル、グリッドセル、列ヘッダー、場合によっては行ヘッダーが含まれます。 オプションで rowgroup 内にも含まれます。

+ +
<div role="table" aria-label="人口" aria-describedby="country_population_desc">
+   <div id="country_population_desc">国別世界人口</div>
+   <div role="rowgroup">
+      <div role="row">
+         <span role="columnheader" aria-sort="descending">国</span>
+         <span role="columnheader"aria-sort="none">人口</span>
+      </div>
+   </div>
+   <div role="rowgroup">
+     <div role="row">
+        <span role="cell">フィンランド</span>
+        <span role="cell">550 万</span>
+     </div>
+     <div role="row">
+        <span role="cell">フランス</span>
+        <span role="cell">6700 万</span>
+     </div>
+  </div>
+</div>
+
+ +

説明

+ +

role="row" を持つ要素は、grid、table、treegrid 内の行で、オプションで rowgroup 内の行です。 行は、静的な表構造内の1つ以上の cell、gridcell、columnheader、rowheader のコンテナです。 可能であれば、ネイティブな HTML <tr> 要素を使用することを強く推奨します。

+ +

ARIA の行を作成するには、コンテナ要素に role="row" を追加します。 その行は、grid、table、treegrid 内にネストするべきです。 行のグループは、grid、table、treegrid 内に直接ネストすることができますし、これらのコンテナ内の rowgroup 内に配置することもできます。 それぞれの行には子のセルが含まれています。 これらのセルは、列ヘッダーや行ヘッダーやグリッドセルや普通のセルの異なるタイプのセルにすることができます。

+ +

行には、aria-colindex、aria-level、aria-rowindex、aria-selected など、行のロールを明確にする属性だけでなく、多くの属性を含めることができます。

+ +

行が treegrid 内にある場合、現在の状態を示す属性を使用して行を展開可能にするため、行に aria-expanded 属性を含めることができます。 これは、aria-expanded 属性が存在しない通常の table や grid の場合には当てはまりません。

+ +

表形式の構造を持つ対話型のウィジェットを作成するには、代わりに grid のパターンを使用します。 インタラクションが個々のセルの選択状態を提供する場合や、上下左右のナビゲーションが提供されている場合や、ユーザインタフェースがセル順序の再配置を許可する場合や、ドラッグアンドドロップなどで個々のセル順序の変更が可能な場合は、代わりに grid や treegrid を使用します。

+ +
+

注: 可能であれば、表の行要素（<tr>）と共にネイティブな HTML 表要素（<table>）を使用することを強く推奨します。

+
+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +

コンテキストロール

+ +
+
role="rowgroup"
+
オプションのコンテキスト上の行の親で、子孫となる行との間に関係を確立します。 これは、HTML 表要素の thead、tfoot、tbody 要素と構造的に同等です。
+
role="table"
+
grid と treegrid と共に行が見つかる3つの可能なコンテキストの1つで、行がネイティブな <table> HTML 要素と同様に、行と列に配置されたデータを含む非対話型の表構造の一部であることを識別します。
+
role="grid"
+
table と treegrid と共に行が見つかる3つの可能なコンテキストの1つで、行がネイティブな <table> HTML 要素と同様に、行と列に配置されたデータを含む非対話型の表構造の一部であることを識別します。
+
role="treegrid"
+
grid に似ていますが、tree と同じ方法で展開や折りたたみができる行があります。
+
+ +

子孫のロール

+ +
+
role="cell"
+
表形式のコンテナ内の行内のセル。
+
role="gridcell"
+
grid 内または treegrid 内の行内のセル。
+
role="columnheader"
+
列スコープを持つ HTML <th> 要素と構造的に同等なヘッダーセル。 プレーンなセルとは異なり、columnheader ロールは、対応する列の全てのセルとの関係を確立します。
+
role="rowheader"
+
行スコープを持つ HTML <th> 要素と構造的に同等なヘッダーセル。 プレーンなセルとは異なり、rowheader ロールは、対応する行の全てのセルとの関係を確立します。
+
+ +

ステートとプロパティ

+ +
+
aria-expanded ステート
+
+

行の状態を定義する aria-expanded 属性は、次の3つの値のいずれかを取るか省略することができます。

+ +
    +
  • aria-expanded="true: 行は現在展開されています。
    • +
  • aria-expanded="false": 行は現在折りたたまれています。
    • +
  • aria-expended="undefined"、または属性がない: 行は展開も折りたたみもできません。
    • +
+ +

aria-expanded 属性を持つ要素が、要素が '所有していない' 別のグループ化コンテナの展開を制御する場合、aria-controls 属性を使用してコンテナを参照するべきです（SHOULD）。

+
+
aria-selected ステート
+
grid や treegrid などの対話型のコンテナ内に行がある場合のみ関連し、行が table の行の場合は関連しません。 aria-selected 属性は、次の3つの値のいずれかを取るか省略することができます。 +
    +
  • aria-selected="true: 行は現在選択されています。
    • +
  • aria-selected="false": 行は現在選択されていません。
    • +
  • aria-selected="undefined"、または属性がない: 行は選択できません。
    • +
+
+
aria-colindex 属性
+
+

aria-colindex 属性は、列が DOM から隠されている場合にのみ必要であり、一般的に行に置くことができるときに表示される列が連続していない限り、行自体ではなく行の子に配置されます。
+
+ この属性は、値として、1 と table、grid、treegrid 内の全列数の間の整数をとります。 aria-colindex は、行に配置されると、行内の全列数に対する要素の列インデックスまたは位置を定義します。 たとえば、表内に 15 列あり、4、5、6 列のみが DOM にある場合、全ての行に aria-colindex="4" を設定できます。
+
+ DOM に存在する列のセットが連続していない場合や、複数の行や列にまたがるセルがある場合は、行自体ではなく各行の全ての子に aria-colindex を配置します。

+ +

全ての列が DOM 内にある場合、この属性は必要ありません。

+
+
aria-rowindex 属性
+
+

aria-rowindex 属性は、行が DOM から隠されている場合にのみ必要で、全行のリスト内のどの行が読み込まれているかを示します。 属性は、それぞれの行に一意の値が設定され、値として、1 と table、grid、treegrid 内の全行数の間の整数をとり、各行の位置またはインデックスを示します。 たとえば、テーブル内に 1,500 行があり、47 行目と 52 行目とヘッダーのみが DOM にある場合は、ヘッダー行に aria-rowindex="1" が設定され、47 行目と 52 行目にそれぞれ aria-rowindex="47" と aria-rowindex="52" が設定されます。

+ +

全ての行が DOM に存在する場合、この属性は必要ありません。

+
+
+ +

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

+ +

無し

+ +

必要な JavaScript 機能

+ +
+
+ +

無し。 ソート可能な列については、columnheader ロールを参照してください。

+ +
+

ARIA の最初のルールは、要素を再定義し、ARIA のロール、ステート、プロパティを追加してアクセス可能にするのではなく、すでに組み込まれている意味論と挙動を持つネイティブな機能を使用できることです。 可能であれば、ARIA の table ロールの代わりに HTML の <table> 要素を使用してください。

+
+ +

例

+ +
<div role="table" aria-label="意味論的な要素" aria-describedby="semantic_elements_table_desc" aria-rowcount="81">
+  <div id="semantic_elements_table_desc">ARIA のロールの代わりに使用する意味論的な要素</div>
+  <div role="rowgroup">
+     <div role="row">
+       <span role="columnheader" aria-sort="none">ARIA のロール</span>
+       <span role="columnheader" aria-sort="none">意味論的な要素</span>
+     </div>
+   </div>
+   <div role="rowgroup">
+    <div role="row" aria-rowindex="11">
+       <span role="cell">header</span>
+       <span role="cell">h1</span>
+    </div>
+    <div role="row"  aria-rowindex="16">
+      <span role="cell">header</span>
+      <span role="cell">h6</span>
+    </div>
+    <div role="row"  aria-rowindex="18">
+      <span role="cell">rowgroup</span>
+      <span role="cell">thead</span>
+    </div>
+    <div role="row"  aria-rowindex="24">
+      <span role="cell">term</span>
+      <span role="cell">dt</span>
+    </div>
+  </div>
+</div>
+
+ +

上記は、DOM 内に 81 行のうち 5 行が存在する意味論的でない ARIA の表です。 表のヘッダー内に 1 行、表の本体内に 4 行あります。 ヘッダー行は、ヘッダーの rowgroup 内に単独であり、2 つの列ヘッダーを持ちます。 列はソート可能ですが、aria-sort プロパティで示されているように、現在はソートされていません。 表の本体は別の rowgroup にあり、現在 DOM 内に 4 行あります。 全ての行が DOM 内にあるわけではないため、全ての行に aria-rowindex プロパティを追加しました。

+ +

 

+ +

ベストプラクティス

+ +

データ表構造には、table、tbody、thead、tr、th、td などのみを使用します。 アクセシビリティを確保するために ARIA のロールを追加し、例えば CSS で表のネイティブな意味論を削除するべきです。 ARIA の table ロールの関連するユースケースは、display: grid など、CSS の display プロパティによって表のネイティブな意味論がオーバーライドされる場合です。 この場合、ARIA の table ロールを使用して意味論を戻すことができます。

+ +
<table role="table" aria-label="意味論的な要素" aria-describedby="semantic_elements_table_desc" aria-rowcount="81">
+  <caption id="semantic_elements_table_desc">ARIA のロールの代わりに使用する意味論的な要素</caption>
+  <thead role="rowgroup">
+     <tr role="row">
+       <th role="columnheader" aria-sort="none">ARIA のロール</th>
+       <th role="columnheader" aria-sort="none">意味論的な要素</th>
+     </tr>
+  </thead>
+  <tbody role="rowgroup">
+     <tr role="row" aria-rowindex="11">
+       <td role="cell">header</td>
+       <td role="cell">h1</td>
+     </tr>
+     <tr role="row" aria-rowindex="16">
+       <td role="cell">header</td>
+       <td role="cell">h6</td>
+     </tr>
+     <tr role="row" aria-rowindex="18">
+       <td role="cell">rowgroup</td>
+       <td role="cell">thead</td>
+     </tr>
+     <tr role="row" aria-rowindex="24">
+       <td role="cell">term</td>
+       <td role="cell">dt</td>
+     </tr>
+   </tbody>
+ </table>
+ +

上記は表を書く意味論的な方法です。 ARIA のロールは、表のネイティブな意味論の場合にのみ必要です。 したがって、display プロパティを flex または grid に設定すると表の行が消されます。

+ +

追加された利点

+ +

無し

+ +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#row","ARIA row role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#row","ARIA row role")}}{{Spec2('ARIA Authoring Practices')}}
+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/rowgroup_role/index.html b/files/ja/web/accessibility/aria/roles/rowgroup_role/index.html new file mode 100644 index 0000000000..56fdbe4014 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/rowgroup_role/index.html @@ -0,0 +1,163 @@ +--- +title: 'ARIA: rowgroup ロール' +slug: Web/Accessibility/ARIA/Roles/Rowgroup_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Rowgroup_Role +--- +
\{{ariaref}}
+ +

role="rowgroup" を持つ要素は、表構造内の行（row）のグループです。 行グループ（rowgroup）には、グリッド(grid)、表（table）、またはツリーグリッド（treegrid）内のセル（cell）、グリッドセル（gridcell）、列ヘッダー（columnheader）、または行ヘッダー（rowheader）の1つ以上の行が含まれます。

+ +
<div role="table" aria-label="人口" aria-describedby="country_population_desc">
+   <div id="country_population_desc">国別世界人口</div>
+   <div role="rowgroup">
+      <div role="row">
+         <span role="columnheader" aria-sort="descending">国</span>
+         <span role="columnheader" aria-sort="none">人口</span>
+      </div>
+   </div>
+   <div role="rowgroup">
+     <div role="row">
+        <span role="cell">フィンランド</span>
+        <span role="cell">550 万</span>
+     </div>
+     <div role="row">
+        <span role="cell">フランス</span>
+        <span role="cell">6700 万</span>
+     </div>
+  </div>
+</div>
+
+ +

説明

+ +

行グループ（rowgroup）は、所有する行（row）の要素間の関係を確立し、HTML の表ヘッダー（{{htmlelement("thead")}}）、表フッター（{{htmlelement("tfoot")}}） 、および表本体（{{htmlelement("tbody")}}）の要素と構造的に同等です。 ただし、異なる種類の行グループを区別することはできません。 それらの要素は、表（table）またはグリッド（grid）のロールを持つ要素に含まれているか、またはそれらの要素によって所有されている必要があります。 可能な限り、ネイティブの {{htmlelement("thead")}}、{{htmlelement("tfoot")}} 、および {{htmlelement("tbody")}} HTML 要素を使用することを強くお勧めします。

+ +

ARIA の表ヘッダー、表フッター、または表本体を作成するには、role="rowgroup" を要素に追加します。 その行グループは、1つ以上の行のグループを含むグリッド、表、またはツリーグリッド内にネストする必要があります。 各行には子セルが含まれています。 これらのセルは、列ヘッダーか行ヘッダーか、プレーンなセルかグリッドセルかによって、さまざまなタイプにすることができます。

+ +
+

注: 可能であれば、ネイティブの HTML 表要素（<table>）を表ヘッダー（<thead>）、表フッター（<tfoot>）、および表本体（<tbody>）の要素と共に使用することを強くお勧めします。

+
+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +

コンテキストロール

+ +
+
role="table"
+
行を見つけることができる3つのコンテキスト（グリッドとツリーグリッドを含む）の1つで、ネイティブの <table> HTML 要素と同様に、行と列に配列されたデータを含む非インタラクティブな表構造の一部として行を識別します。
+
role="grid"
+
行を見つけることができる3つのコンテキスト（表とツリーグリッドを含む）の1つで、ネイティブの <table> HTML 要素と同様に、行と列に配列されたデータを含む非インタラクティブな表構造の一部として行を識別します。
+
role="treegrid"
+
グリッドと似ていますが、ツリーの場合と同じ方法で行を展開したり折りたたんだりすることができます。
+
+ +

子孫のロール

+ +
+
role="row"
+
表構造内のセルの行。 行には、1つ以上のセル（cell）、グリッドセル（gridcell）、または列ヘッダー（columnheader）が含まれ、場合によっては行ヘッダー（rowheader）も含まれます。
+
+ +

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

+ +

無し

+ +

必要な JavaScript 機能

+ +

無し。

+ +
+

ARIA の最初のルールは、要素を再定義し、ARIA のロール、ステート、プロパティを追加してアクセス可能にするのではなく、すでに組み込まれている意味論と挙動を持つネイティブな機能を使用できることです。 可能な限り、ARIA の table ロールの代わりに HTML の {{htmlelement("table")}} 要素を使用してください。

+
+ +

例

+ +
<div role="table" aria-label="意味論的な要素" aria-describedby="semantic_elements_table_desc" aria-rowcount="81">
+  <div id="semantic_elements_table_desc">ARIA のロールの代わりに使用する意味論的な要素</div>
+  <div role="rowgroup">
+     <div role="row">
+       <span role="columnheader" aria-sort="none">ARIA のロール</span>
+       <span role="columnheader" aria-sort="none">意味論的な要素</span>
+     </div>
+   </div>
+   <div role="rowgroup">
+    <div role="row" aria-rowindex="11">
+       <span role="cell">header</span>
+       <span role="cell">h1</span>
+    </div>
+    <div role="row"  aria-rowindex="16">
+      <span role="cell">header</span>
+      <span role="cell">h6</span>
+    </div>
+    <div role="row"  aria-rowindex="18">
+      <span role="cell">rowgroup</span>
+      <span role="cell">thead</span>
+    </div>
+    <div role="row"  aria-rowindex="24">
+      <span role="cell">term</span>
+      <span role="cell">dt</span>
+    </div>
+  </div>
+</div>
+
+ +

上記は、表ヘッダーと表本体を持つ非意味論的な ARIA の表で、DOM には81行のうち5行が含まれています。 表ヘッダー内に1行、表本体内に4行あります。 ヘッダー行は、ヘッダーの行グループに単独であり、2つの列ヘッダーを持ちます。 aria-sort プロパティで示されるように、列はソート可能ですが、現在はソートされていません。 表本体は独立した行グループで、現在 DOM には4行あります。 すべての行が DOM 内にあるわけではないので、すべての行に aria-rowindex プロパティを含めました。

+ +

ベストプラクティス

+ +

データ表構造には、{{htmlelement("table")}}、{{htmlelement("tbody")}}、{{htmlelement("thead")}}、{{htmlelement("tr")}}、{{htmlelement("th")}}、{{htmlelement("td")}} などのみを使用します。 アクセシビリティを確保するために ARIA のロールを追加し、例えば CSS で表のネイティブな意味論を削除するべきです。 ARIA の table ロールの関連するユースケースは、display: grid など、CSS の {{cssxref("display")}} プロパティによって表のネイティブな意味論がオーバーライドされる場合です。 この場合、ARIA の table ロールを使用して意味論を戻すことができます。

+ +
<table role="table" aria-label="意味論的な要素" aria-describedby="semantic_elements_table_desc" aria-rowcount="81">
+  <caption id="semantic_elements_table_desc">ARIA のロールの代わりに使用する意味論的な要素</caption>
+  <thead role="rowgroup">
+     <tr role="row">
+       <th role="columnheader" aria-sort="none">ARIA のロール</th>
+       <th role="columnheader" aria-sort="none">意味論的な要素</th>
+     </tr>
+  </thead>
+  <tbody role="rowgroup">
+     <tr role="row" aria-rowindex="11">
+       <td role="cell">header</td>
+       <td role="cell">h1</td>
+     </tr>
+     <tr role="row" aria-rowindex="16">
+       <td role="cell">header</td>
+       <td role="cell">h6</td>
+     </tr>
+   </tbody>
+ </table>
+ +

上記は表を書く意味論的な方法です。 ARIA のロールは、表のネイティブな意味論の場合にのみ必要です。 したがって、display プロパティを flex または grid に設定すると表の行が消されます。
+  

+ +

追加された利点

+ +

無し

+ +

仕様

+ + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#rowgroup","ARIA rowgroup role")}}{{Spec2('ARIA')}}
+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/search_role/index.html b/files/ja/web/accessibility/aria/roles/search_role/index.html new file mode 100644 index 0000000000..df6ac80cd3 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/search_role/index.html @@ -0,0 +1,122 @@ +--- +title: 'ARIA: search ロール' +slug: Web/Accessibility/ARIA/Roles/Search_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Search_role +--- +

\{{ariaref}}

+ +

search ランドマークロールは、ページ、サイト、またはサイトのコレクションを検索するために使用されるページのセクションを識別するために使用されます。

+ +
<form role="search">
+  <!-- 検索入力 -->
+</form>
+
+ +

説明

+ +

search ロールはランドマークです。 ランドマークは、支援技術によって使用され、文書の大きなセクションを迅速に識別してナビゲートすることができます。 search ロールは、全体として結合して検索（search）機能を作成するアイテムおよびオブジェクトを包含するコンテナ要素に追加します。 <form> が検索フォームの場合、form ロールの代わりに search ロールを使用します。 文書に複数の検索が含まれている場合、それぞれに固有のラベルを持つべきです。 search 型の <input> 要素があるなら、search ランドマークを定義する HTML 要素があります。

+ +

例

+ +
<form id="search" role="search">
+  <label for="search-input">このサイトを検索</label>
+  <input type="search" id="search-input" name="search" spellcheck="false">
+  <input value="検索する" type="submit">
+</form>
+
+ +

アクセシビリティに関する懸念

+ +

ランドマークロールは、文書のより大きな全体的なセクションを識別するために、控えめに使用することを意図しています。 あまりにも多くのランドマークロールを使用すると、スクリーンリーダーで「ノイズ」が発生し、ページ全体のレイアウトを理解することが難しくなります。

+ +

ベストプラクティス

+ +

好ましい HTML

+ +

{{htmlelement("form")}} 要素を role="search" の宣言とともに使用すると、最大限のサポートが得られます。

+ +

ランドマークのラベル付け

+ +

複数のランドマーク

+ +

文書に複数の search ランドマークロールがある場合は、各ランドマークに対してラベルを指定します。 このラベルで、支援技術のユーザーがそれぞれのランドマークの目的をすばやく理解することができます。

+ +
<form id="site-search" role="search" aria-label="サイト全体">
+  <!-- 検索入力 -->
+</form>
+
+...
+
+<form id="page-search" role="search" aria-label="このページ">
+  <!-- 検索入力 -->
+</form>
+
+ +

繰り返されるランドマーク

+ +

文書内の search ランドマークロールが文書内で繰り返され、両方のランドマークのコンテンツが同じ場合は、各ランドマークに同じラベルを使用します。 この例では、ページの上部と下部でサイト全体の検索が繰り返されています。

+ +
<header>
+  <form id="site-search" role="search" aria-label="サイト全体">
+    <!-- 検索入力 -->
+  </form>
+</header>
+
+...
+
+<footer>
+  <form id="site-search" role="search" aria-label="サイト全体">
+    <!-- 検索入力 -->
+  </form>
+</footer>
+
+ +

冗長な説明

+ +

スクリーンリーダーは、ランドマークロールの種類をアナウンスします。 このため、ラベルでランドマークが何であるかを説明する必要はありません。 例えば、aria-label="サイト全体の検索" の role="search" の宣言は、"search サイト全体の検索" として重複してアナウンスすることができます。

+ +

追加された利点

+ +

ブラウザー拡張などの特定の技術は、ページ上に存在する全てのランドマークロールのリストを生成することができ、非スクリーンリーダーユーザーは文書の大きなセクションを素早く識別してナビゲートできます。

+ + + +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#search","ARIA search role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#aria_lh_search","ARIA search role")}}{{Spec2('ARIA Authoring Practices')}}
+ +

スクリーンリーダーのサポート

+ +

TBD

+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/switch_role/index.html b/files/ja/web/accessibility/aria/roles/switch_role/index.html new file mode 100644 index 0000000000..ea926c66ec --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/switch_role/index.html @@ -0,0 +1,187 @@ +--- +title: 'ARIA: switch ロール' +slug: Web/Accessibility/ARIA/Roles/Switch_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Switch_role +--- +

\{{ariaref}}

+ +

ARIA の switch ロールは、checkbox ロールと機能的に同じですが、"checked" と "unchecked" の状態を表す代わりに、その意味ではかなり一般的なもので、switch ロールは、「オン」と「オフ」の状態を表します。

+ +

この例では、ウィジェットを作成し、ARIA の switch ロールを割り当てます。

+ +
<button role="switch" aria-checked="true"
+       id="speakerPower" class="switch">
+   <span>オフ</span>
+   <span>オン</span>
+ </button>
+ <label for="speakerPower" class="switch">スピーカー電源</label>
+ +

説明

+ +

ARIA の switch ロールは、checkbox ロールと同じですが、"checked" や "unchecked" ではなく、「オン」と「オフ」のどちらかです。 checkbox ロールと同様に、aria-checked 属性が必要です。 可能な2つの値は true と false です。 <checkbox> や role="checkbox" とは異なり、不確定な状態（indeterminate）や混在した状態（mixed）はありません。 switch ロールは、aria-checked 属性に mixed の値をサポートしていません。 switch に mixed の値を割り当てると、代わりに値を false に設定します。

+ +

支援技術は、オン/オフスイッチの概念を反映するために、スイッチウィジェットを専門化したプレゼンテーションで表現することを選択することができます。

+ +

スイッチはインタラクティブなコントロールなので、フォーカス可能でキーボードによりアクセス可能でなければなりません。 ロールがフォーカス可能でない要素に適用されている場合は、tabindex 属性を使用してこれを変更します。 スイッチの値を切り替えるために必要なキーボードショートカットはスペースキーです。 開発者は、スイッチがトグルされたときに、aria-checked 属性の値を動的に変更する必要があります。

+ +

関連する ARIA のロール、ステート、プロパティ

+ +
+
aria-checked 属性
+
aria-checked 属性は、switch ロールを使用する場合に必要です。 これは、switch ロールが適用されているウィジェットの現在の状態を表すためです。 true の値は「オン」状態を表します。 false の値は「オフ」状態を表します。 mixed の値は switch ロールでサポートされておらず、false として扱われます。 デフォルト値は false です。
+
aria-readonly 属性
+
aria-readonly 属性は、switch ロールでサポートされています。 ウィジェットの状態がユーザーによって編集可能かどうかを示します。 false の値は、ユーザーがウィジェットの状態を変更できることを意味します。 true の値は、ユーザーがウィジェットの状態を変更できないことを意味します。 デフォルト値は false です。
+
+ +

必要な JavaScript 機能

+ +
+
click イベントのハンドラ
+
ユーザーがスイッチウィジェットをクリックすると、click イベントが発生します。 これは、ウィジェットの状態を変更するために処理する必要があります。
+
aria-checked 属性の変更
+
スイッチウィジェットで click イベントが発生した場合、ハンドラは aria-checked 属性の値を true から false やその逆に変更する必要があります。
+
+ +

ユーザーエージェントと支援技術への影響

+ +

switch ロールが要素に追加されると、{{Glossary("user agent","ユーザーエージェント")}}は次のようにそれを処理します。

+ + + +

支援技術は、switch ロールをサポートしている場合は、次のように応えます。

+ + + +
+

支援技術がこのロールをどのように処理すべきかについて、さまざまな意見があります。 上記は推奨される方法であり、他の情報源とは異なる場合があります。

+
+ +

例

+ +

次の例は、switch ロールを適用して使用する方法を理解するのに役立ちます。

+ +

ARIA で switch ロールを追加する

+ +

この単純な例では、ウィジェットを作成して ARIA の switch ロールを割り当てます。 このボタンは、オン/オフの電源スイッチを連想させるような外観になっています。

+ +

HTML

+ +

HTML はここではかなり簡単です。 スイッチは {{HTMLElement("button")}} 要素として実装され、最初に aria-checked 属性が "true" に設定されているかどうかチェックされます。 スイッチには、"off" と "on" のラベルを含む2つの子要素があり、スイッチを識別する {{HTMLElement("label")}} が続きます。

+ +
<button role="switch" aria-checked="true"
+      id="speakerPower" class="switch">
+  <span>off</span>
+  <span>on</span>
+</button>
+<label for="speakerPower" class="switch">Speaker power</label>
+
+ +

JavaScript

+ +

この JavaScript コードは、スイッチウィジェットの click イベントを処理する関数を定義して適用します。 この関数は、aria-checked 属性を true から false やその逆に変更します。

+ +
document.querySelectorAll(".switch").forEach(function(theSwitch) {
+  theSwitch.addEventListener("click", handleClickEvent, false);
+});
+
+function handleClickEvent(evt) {
+  let el = evt.target;
+
+  if (el.getAttribute("aria-checked") == "true") {
+      el.setAttribute("aria-checked", "false");
+  } else {
+      el.setAttribute("aria-checked", "true");
+  }
+}
+ +

CSS

+ +

CSS の目的は、電源スイッチのパラダイムを思い起こさせるスイッチのルックアンドフィールを確立することです。

+ +
button.switch {
+  margin: 0;
+  padding: 0;
+  width: 60px;
+  height: 26px;
+  border: 2px solid black;
+  display: inline-block;
+  margin-right: 0.25em;
+  line-height: 20px;
+  vertical-align: middle;
+  text-align: center;
+  font: 12px "Open Sans", "Arial", serif;
+}
+
+button.switch span {
+  padding: 0 4px;}
+
+[role="switch"][aria-checked="false"] :first-child,
+[role="switch"][aria-checked="true"] :last-child {
+  background: #262;
+  color: #eef;
+}
+
+[role="switch"][aria-checked="false"] :last-child,
+[role="switch"][aria-checked="true"] :first-child {
+  color: #bbd;
+}
+
+label.switch {
+  font: 16px "Open Sans", "Arial", sans-serif;
+  line-height: 20px;
+  user-select: none;
+  vertical-align: middle;
+  -moz-user-select: none;
+  -ms-user-select: none;
+  -webkit-user-select: none;
+  -o-user-select: none;
+}
+ +

最も興味深いのは、おそらく属性セレクタと {{cssxref(":first-child")}} と {{cssxref(":last-child")}} の擬似クラスを使用して、スイッチのオン/オフに応じてスイッチの外観を変えるということです。

+ +

結果

+ +

結果は次のようになります。

+ +

{{EmbedLiveSample("Adding_the_switch_role_in_ARIA", 600, 40)}}

+ +

仕様

+ + + + + + + + + + + + + + + + + + + + + +
仕様状態コメント
{{SpecName('ARIA', '#switch')}}{{Spec2('ARIA')}}一般的に ARIA をすべてのロール、プロパティなどとともに定義します。
{{SpecName('ARIA in HTML', '#index-aria-switch')}}{{Spec2('ARIA in HTML')}}ARIA の機能を HTML に統合する方法について説明します。
+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/table_role/index.html b/files/ja/web/accessibility/aria/roles/table_role/index.html new file mode 100644 index 0000000000..4d98392f80 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/table_role/index.html @@ -0,0 +1,154 @@ +--- +title: 'ARIA: table ロール' +slug: Web/Accessibility/ARIA/Roles/Table_Role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/Table_Role +--- +
\{{ariaref}}
+ +

ARIA の role 属性の table 値は、このロールを含む要素を、ネイティブの {{htmlelement("table")}} HTML 要素と同様に、行と列に配置されたデータを含む非インタラクティブな表構造を持つものとして識別します。

+ +
<div role="table" aria-label="意味論的な表の要素" aria-describedby="semantic_table_desc">
+  <div id="semantic_table_desc">ARIA の table ロールの代わりに使用する意味論的な要素</div>
+  <div role="rowgroup">
+     <div role="row">
+       <span role="columnheader">ARIA の table ロール</span>
+       <span role="columnheader">意味論的な要素</span>
+     </div>
+   </div>
+   <div role="rowgroup">
+    <div role="row">
+       <span role="cell">table</span>
+       <span role="cell">table</span>
+    </div>
+    <div role="row">
+      <span role="cell">rowgroup</span>
+      <span role="cell">thead, tbody, or tfoot </span>
+    </div>
+  </div>
+</div>
+
+ +

説明

+ +

role="table" を持つ要素はセルを含む行を持つ静的な表構造です。 表の個々のセル内のウィジェットはインタラクティブになることがありますが、セルはフォーカス可能または選択可能ではありません。 可能な限りネイティブの HTML {{htmlelement("table")}} 要素を使用することを強くお勧めします。

+ +
+

表が選択状態を維持している場合、2次元ナビゲーションを使用している場合、またはユーザーがセルの順序を並べ替えることができる場合は、代わりにグリッド（grid）またはツリーグリッド（treegrid）を使用します。

+
+ +

ARIA の表を作成するには、role="table" をコンテナ要素に追加します。 そのコンテナ内では、各行に role="row" を設定し、子セルを含ませます。 各セルには、列ヘッダー（columnheader）、行ヘッダー（rowheader）、または単なるセル（cell）のいずれかのロールがあります。 行は、表の子になることも、行グループ（rowgroup）内になることもあります。

+ +

表のキャプションは、aria-labelledby、aria-label、または aria-describeby によって定義できます。 {{htmlelement("tbody")}}、{{htmlelement("thead")}}、{{htmlelement("tr")}}、{{htmlelement("th")}}、{{htmlelement("td")}} など、他のすべての意味論的な表の要素は、rowgroup、row、columnheader、cell などの関連するロールを介して追加する必要があります。

+ +

表にソート可能な列または行が含まれる場合は、aria-sort 属性をヘッダーのセル要素に追加する必要があります（表自体ではありません）。 ある行または列が隠されている場合は、それぞれのセルの aria-colindex または aria-rowindex とともに、それぞれ列または行の総数を示す aria-colcount または aria-rowcount を含める必要があります。 aria-colindex または aria-rowindex は、それぞれ行または列内のセルの位置に設定します。 表に複数行または複数列にわたるセルが含まれる場合は、aria-rowspan または aria-colspan も含める必要があります。 すべての支援技術でサポートされているすべての関連する意味論的な要素および属性と共に、{{htmlelement("table")}} 要素を単純に使用する方がはるかに簡単です。

+ +

表構造を持つインタラクティブなウィジェットを作成するには、代わりにグリッドパターンを使用してください。 インタラクションが個々のセルの選択状態を提供する場合、左から右へ、上から下へのナビゲーションを提供する場合、またはユーザーインターフェイスでセルの順序の並べ替えやドラッグアンドドロップなどの個々のセルの順序の変更を許可する場合、代わりに grid または treegrid を使用してください。

+ +
+

注: 可能な限りネイティブの HTML の表要素を使用することを強くお勧めします。

+
+ +

関連する WAI-ARIA のロール、ステート、プロパティ

+ +
+
role="rowgroup"
+
表のオプションの子である行グループは、{{htmlelement("thead")}}、{{htmlelement("tbody")}}、および {{htmlelement("tfoot")}} と同様に、行のグループをカプセル化します。
+
role="row"
+
表内の行、およびオプションで行グループ（rowgroup）内の行、つまり1つ以上のセル（cell）、列ヘッダー（columnheader）、または行ヘッダー（rowheader）のコンテナです。
+
aria-describedby 属性
+
値として、表のキャプションとして機能する要素の id を取ります。
+
aria-label 属性
+
aria-label は、表にアクセス可能な名前を提供します。
+
aria-colcount 属性
+
+

この属性は、ある列が常に DOM に存在しない場合にのみ必要です。 全表の列数を明示的に示します。 値を全表の列の総数に設定します。 不明な場合は、aria-colcount="-1" を設定してください。

+
+
aria-rowcount 属性
+
この属性は、DOM ノードの数を最小限に抑えるために行を再利用するスクロール可能な表など、ある行が常に DOM に存在しない場合にのみ必要です。 全表の行数を明示的に示します。 値を全表の行の総数に設定します。 不明な場合は、aria-rowcount="-1" を設定してください。
+
+ +

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

+ +

無し

+ +

必要な JavaScript 機能

+ +
+
+ +

無し。 ソート可能な列については、 columnheader ロールを参照してください。

+ +
+

ARIA の最初のルールは、要素を再定義し、ARIA のロール、ステート、プロパティを追加してアクセス可能にするのではなく、すでに組み込まれている意味論と挙動を持つネイティブな機能を使用できることです。 可能な限り、ARIA の table ロールの代わりに HTML の {{htmlelement("table")}} 要素を使用してください。

+
+ +

例

+ +
<div role="table" aria-label="意味論的な要素" aria-describedby="semantic_elements_table_desc" aria-rowcount="81">
+  <div id="semantic_elements_table_desc">ARIA のロールの代わりに使用する意味論的な要素</div>
+  <div role="rowgroup">
+     <div role="row">
+       <span role="columnheader" aria-sort="none">ARIA のロール</span>
+       <span role="columnheader" aria-sort="none">意味論的な要素</span>
+     </div>
+   </div>
+   <div role="rowgroup">
+    <div role="row" aria-rowindex="11">
+       <span role="cell">header</span>
+       <span role="cell">h1</span>
+    </div>
+    <div role="row"  aria-rowindex="16">
+      <span role="cell">header</span>
+      <span role="cell">h6</span>
+    </div>
+    <div role="row"  aria-rowindex="18">
+      <span role="cell">rowgroup</span>
+      <span role="cell">thead</span>
+    </div>
+    <div role="row"  aria-rowindex="24">
+      <span role="cell">term</span>
+      <span role="cell">dt</span>
+    </div>
+  </div>
+</div>
+
+ +

上記は表の一部です。 aria-rowcount プロパティで示されるように、全表には81のエントリがありますが、現在表示されているのは4つだけです。 列ヘッダーの aria-sort プロパティで示されるように、列はソート可能ですが、現在はソートされていません。

+ +

ベストプラクティス

+ +

データ表構造には、{{htmlelement("table")}}、{{htmlelement("tbody")}}、{{htmlelement("thead")}}、{{htmlelement("tr")}}、{{htmlelement("th")}}、{{htmlelement("td")}} などのみを使用します。 アクセシビリティを確保するために ARIA のロールを追加し、例えば CSS で表のネイティブな意味論を削除するべきです。 ARIA の table ロールの関連するユースケースは、display: grid など、CSS の {{cssxref("display")}} プロパティによって表のネイティブな意味論がオーバーライドされる場合です。 この場合、ARIA の table ロールを使用して意味論を戻すことができます。

+ +

追加された利点

+ +

無し

+ +

仕様

+ + + + + + + + + + + + + + + + +
仕様状態
{{SpecName("ARIA","#table","ARIA Table Role")}}{{Spec2('ARIA')}}
{{SpecName("ARIA Authoring Practices","#table","ARIA Table Role")}}{{Spec2('ARIA Authoring Practices')}}
+ +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/roles/textbox_role/index.html b/files/ja/web/accessibility/aria/roles/textbox_role/index.html new file mode 100644 index 0000000000..6597033574 --- /dev/null +++ b/files/ja/web/accessibility/aria/roles/textbox_role/index.html @@ -0,0 +1,130 @@ +--- +title: 'ARIA: textbox ロール' +slug: Web/Accessibility/ARIA/Roles/textbox_role +tags: + - ARIA + - ARIA Role + - Accessibility +translation_of: Web/Accessibility/ARIA/Roles/textbox_role +--- +

\{{ariaref}}textbox ロールは、自由形式テキストの入力を可能にする要素を識別するために使用されます。 可能であれば、このロールを使用するのではなく、単一行入力の場合は type="text" の {{HTMLElement("input")}} 要素を使用し、複数行入力の場合は {{HTMLElement("textarea")}} 要素を使用してください。

+ +

説明

+ +

要素に textbox ロールがある場合、ブラウザーはアクセス可能なテキストボックスイベントを支援技術に送信し、ユーザーにそのことを通知できます。

+ +

デフォルトは単一行入力で、Return や Enter はフォームを送信します。 この場合、 type="text" の HTML の {{HTMLElement("input")}} を使用することをお勧めします。 HTML の {{HTMLElement("textarea")}} のように改行をサポートする複数行のテキストボックスを作成するには、aria-multiline="true" を設定します。 HTML の contenteditable 属性を含めると、テキストノードが確実に編集可能になります。

+ +
<!-- 単純なテキスト入力フィールド -->
+<div id="txtboxLabel">5桁の郵便番号を入力してください</div>
+<div role="textbox" contenteditable="true" aria-placholder="5-digit zipcode" aria-labeledby="txtboxLabel"></div>
+
+<!-- 複数行のテキスト領域 -->
+<div id="txtboxMultilineLabel">記事のタグを入力してください</div>
+<div role="textbox" contenteditable="true" aria-multiline="true"
+   aria-labeledby="txtboxMultilineLabel" aria-required="true"></div>
+ +

意味論的な要素はより簡潔であり、テキストボックス機能をサポートするために JavaScript を必要としません。

+ +

 

+ +
<label for="txtbox">5桁の郵便番号を入力してください</label>
+<input type="text" placholder="5-digit zipcode" id="txtbox"/>
+
+<!-- 複数行のテキスト領域 -->
+<label for="txtboxMultiline">記事のタグを入力してください</lable>
+<textarea id="txtboxMultiline" required></textarea>
+ +

 

+ +

テキストフィールドが読み取り専用の場合、要素に対して aria-readonly="true" と設定することでこれを示します。

+ +
+
+ +

関連する ARIA のプロパティ

+ +
+
aria-activedescendent 属性
+
その値として、ID は DOM のフォーカスを持つ要素の子孫であるか、または aria-owns 属性で指定された論理的子孫であり、combobox などの複合ウィジェットの一部であるときに、その要素にフォーカスがあるときを示します。 たとえば、コンボボックスでは、テキストボックスにフォーカスが残ることがありますが、textbox 要素の aria-activedescendant の値は、テキストボックスによって制御されるポップアップリストボックスの子孫を参照します。 この属性は、フォーカスが変更されるとプログラムで更新する必要があります。
+
aria-autocomplete 属性
+
フィールドへのユーザーの入力が、意図した値の予測の表示をトリガーできるかどうか、およびその方法を示します。 これは以下の値をサポートしています。 +
    +
  • inline: 予測されたテキストがキャレットの後に挿入されます。
    • +
  • list: 予測されたテキストは、値の集まりとして提示されます。
    • +
  • both: 予測されたテキストは、値の集まりとして提示され、補完に必要なテキストの1つの値がキャレットの後に挿入されます。
    • +
  • none（デフォルト）: 予測されたテキストは提供されません。
    • +
+ +

list または both が設定されている場合は、aria-controls 属性と aria-haspopup 属性も含める必要があります。 aria-controls の値は、提案値のリストを含む要素の ID です。 さらに、テキストボックスまたは combobox ロールを含む包含要素のいずれかに、提案値のリストを含む要素のロールに一致する aria-haspopup の値を持ちます。

+
+
aria-multiline 属性
+
aria-multiline="true" が設定されている場合、支援技術は、テキストボックスが複数行入力をサポートしていることをユーザーに知らせます。 Enter や Return はフォームを送信するのではなく改行を作成します。 ARIA は要素の動作を変更しません。 むしろ、この機能は開発者によって制御されなければなりません。 false が設定されている場合、または属性が省略されていて false がデフォルトの場合、ユーザーはコントロールが単一行のテキストボックスであり、Enter や Return がフォームを送信することを期待しています。
+
aria-placeholder 属性
+
テキストフィールドに何を入力するかについてのヒント（単語またはフレーズ）をユーザーに示します。 ヒントは、サンプル値または期待されるフォーマットの簡単な説明であるべきです。 この情報は、ラベルの代用として使用するべきではありません。 ラベルはフォーカス可能で永続的で、どのような情報が期待されているかを示し、プレースホルダーのテキストは期待値を一時的に示唆しているだけで、誤って実装するとアクセシビリティが低下する可能性があります。 プレースホルダーは、コントロールが最初にフォーカスを受け取ったときやユーザーが以前に入力した値を削除したときなど、コントロールの値が空の文字列のときに表示するべきです。 aria-placeholder を使用する代わりに、意味論的な <input type="text"> や <textarea> に placeholder 属性を使用します。
+
aria-readonly 属性
+
ユーザーがテキストフィールドの値を変更できないことを示します。 aria-readonly を使用する代わりに、意味論的な <input type="text"> や <textarea> に readonly 属性を使用します。
+
aria-required 属性
+
フィールドが送信される前にフィールドに値を指定する必要があることを示します。 aria-required を使用する代わりに、意味論的な <input type="text"> や <textarea> に required 属性を使用します。
+
+ +

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

+ +

単一行での使用（aria-multiline が false または使用されていない場合）では、Return キーや Enter キーがフォームを送信します。 複数行での使用（aria-multiline が true の場合）では、Return キーや Enter キーを押すと改行が挿入されます。

+ +

必要な JavaScript 機能

+ +

すべてのプロパティとステートに関連するすべての機能を維持する必要があります。 また、単一行のテキストボックスにおいて Enter や Return でフォームを送信する必要があります。

+ +
+
フォーカスイベントハンドラと aria-activedescendent 属性
+
テキストボックスとリストボックスで構成されるコンボボックスなどの複合ウィジェットを実装する場合は、ハンドラを使用して aria-activedescendent 属性を管理する必要があります。 この手法を使用する前に、ターゲットとするブラウザーが現在サポートしていることを確認してください。 詳細については、aria-descendent の仕様（英語）を参照してください。
+
+ +
+

ARIA の textbox ロールの代わりに type="text" の {{HTMLElement("input")}} 要素、または {{HTMLElement("textarea")}} 要素を使用する方が良い方法です。 どちらの意味論的な要素を使用する場合でも、ARIA の textbox ロールは必要ありません。 HTML で ARIA を使用する場合の注意（英語）を参照してください。

+
+ +

ユーザーエージェントと支援技術への影響

+ +

textbox ロールが要素に追加されるか、そのような要素が可視になると、ユーザーエージェントは以下を行うべきです。

+ + + +

支援技術製品は、そのようなイベントをリスンし、それに応じてユーザーに以下を通知するするべきです。

+ + + +
注: 支援技術がこの手法をどのように扱うべきかについての意見は異なる場合があります。 上記の情報は、これらの意見の1つで、したがって規範的ではありません。
+ +

例

+ +

例 1: 単一行入力の HTML コードにロールを追加する

+ +

以下のスニペットは、textbox ロールが HTML ソースコードにどのように直接追加されるかを示しています。

+ +
<div role="textbox" contenteditable="true"></div>
+ +

例 2: 複数行入力の HTML コードにロールを追加する

+ +

以下のスニペットは、textbox ロールが HTML ソースコードにどのように直接追加されるかを示しています。

+ +
<div role="textbox" contenteditable="true" aria-multiline="true"></div>
+ +

ベストプラクティス

+ + + +

関連情報

+ + diff --git a/files/ja/web/accessibility/aria/web_applications_and_aria_faq/index.html b/files/ja/web/accessibility/aria/web_applications_and_aria_faq/index.html new file mode 100644 index 0000000000..bc71bf3ba0 --- /dev/null +++ b/files/ja/web/accessibility/aria/web_applications_and_aria_faq/index.html @@ -0,0 +1,302 @@ +--- +title: Web アプリケーションと ARIA の FAQ +slug: Web/Accessibility/ARIA/Web_applications_and_ARIA_FAQ +tags: + - ARIA + - Accessibility + - Guide +translation_of: Web/Accessibility/ARIA/Web_applications_and_ARIA_FAQ +--- +

ARIA とは何か?

+ +

WAI-ARIA は、W3C の Web Accessibility Initiative による、{{原語併記("アクセシブルなリッチインターネットアプリケーション", "Accessible Rich Internet Applications")}} の仕様です。ARIA は Web アプリケーションやウィジェットを、スクリーンリーダーや拡大鏡といった支援技術を使用するユーザを含む幅広いユーザに対してアクセシブルにする手段を提供します。

+ +

ARIA はメニュー、スライダー、ツリー、ダイアログといった多くの一般的なユーザインターフェイスの役割、状態、機能性を示す付加的な意味を与えます。また作者がページ上の目印、部分、グリッドを設定することを支援する、付加的な構造情報も与えます。ARIA は動的で JavaScript 駆動のアプリケーションやウィジェットを、さまざまなデスクトップベースの支援技術と対話可能にします。

+ +

ARIA でアクセシブルなウィジェットを作成する方法について詳しくは、アクセシブルな Web アプリケーションやウィジェットの概要をご覧ください。

+ +

ARIA はどこでサポートされていますか?

+ +

ARIA は比較的新しい仕様ですが、サポートは進んでいます。多種多様なよく使用されるブラウザ、支援技術、JavaScript ツールキットやアプリケーションが ARIAをサポートしています。しかし、多くのユーザはいまだにこれらの古いバージョンを使用しているでしょう。古いブラウザや支援技術を良好にサポートするために、先進的な拡張方法 (例えばマークアップに直接ではなく JavaScript を使用して ARIA を追加する) を使用して ARIA を実装したいと考えるでしょう。

+ +

ブラウザ

+ +

ARIA は以下のブラウザでサポートされています:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ブラウザ最低バージョン備考
Firefox3.0 以降NVDA、JAWS 10 以降、Orca で動作
Chrome最新Chrome 15 現在、スクリーンリーダーは試験にサポート
Safari4 以降Safari 5 のサポートはとても向上しています。
+ Live region のサポートは、iOS5 または OS X Lion の VoiceOver と Safari 5 が必要です。
Opera9.5 以降OS X では VoiceOver が必要です。TBD: 現在の状況はどうでしょうか?
Internet Explorer8 以降JAWS 10 以降や NVDA で動作します。NVDA では live region をサポートしません。
+ IE9 のサポートはとても向上しています。
+ +

以前のバージョンでは ARIA の一部の機能しかサポートしない場合があります。より詳しいブラウザ実装状況の表を、複数の情報源から得られます:

+ + + +

支援技術

+ +

支援技術は ARIA を順次採用しています。それらが搭載しているものは:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
支援技術基本的な ARIA の最低バージョンlive region および alert サポートの最低バージョン
NVDA2010.2
+ (NVDA のアップグレードは常に無償です)		Firefox 向けは 2011.1 でサポートしました。2011.2 の時点で IE の live region サポートはありません。
Orca? (TBD)? (TBD)
VoiceOverOSX 10.5,
+ iOS 4		OS X 10.7
+ iOS 5
JAWS810
Window-Eyes7現在 live region はサポートしていません。
ZoomText?現在 live region はサポートしていません。
+ +

注記: これらツールの過去のバージョンは、ARIA の実装が部分的あるいはバグがある場合があります。

+ +

JAWS 10 時点の、JAWS の ARIA サポートに関する注記については、Paciello Group による記事をご覧ください: JAWS Support for ARIA。

+ +

JavaScript ツールキット

+ +

ARIA のロール、ステート、プロパティは、以下のような多くのポピュラーな JavaScript ユーザインターフェイスツールキットに追加されています:

+ + + +

JavaScript ツールキットのアクセシビリティに関する詳細情報:

+ + + +

ARIA の実例を見せていただけますか?

+ +

はい。こちらがプログレスバーのウィジェットのマークアップです:

+ +
<div id="percent-loaded" role="progressbar" aria-valuenow="75" aria-valuemin="0" aria-valuemax="100" />
+ +

このプログレスバーは <div> を使用して作られており、あまり説明的ではありません。残念ながら HTML 4 で開発者が使用できる、より意味があるタグはありませんので、ARIA のロールやプロパティを含めることが必要です。これらは、要素に属性を追加することによって指定します。この例では role="progressbar" 属性で、要素が実際は JavaScript で動作するプログレスバーウィジェットであることをブラウザに伝えます。aria-valuemin 属性や aria-valuemax 属性はプログレスバーの最小値と最大値を、aria-valuenow 属性は現在の状態を示します。

+ +

ARIA の属性はマークアップ内に直接置くほかに、以下のような JavaScript コードを使用して要素へ追加および動的な更新を行うこともできます:

+ +
// DOM でプログレスバーである <div> を探します。
+var progressBar = document.getElementById("percent-loaded");
+
+// どのようなウィジェットであるかを支援技術がわかるように、ARIA のロールやステートを設定します。
+progressBar.setAttribute("role", "progressbar");
+progressBar.setAttribute("aria-valuemin", 0);
+progressBar.setAttribute("aria-valuemax", 100);
+
+// プログレスバーの値を更新するたびに呼び出すことが可能な関数を作成します。
+function updateProgress(percentComplete) {
+  progressBar.setAttribute("aria-valuenow", percentComplete);
+}
+
+ +

ARIA を追加するとページのスタイルや動作が変わりますか?

+ +

いいえ。ARIA は支援技術の API を使用可能にするだけであり、DOM やスタイルに関するブラウザのネイティブ機能には影響を与えません。ブラウザから見ると、ネイティブな HTML は要素のセマンティックな意味や動作を定義するものであり、ARIA の属性は AT API のサポートを支援するレイヤーとして機能します。ARIA の属性は他の HTML 属性と同様にスタイルを変更しませんが、CSS は要素のセレクタとして ARIA の属性を活用できます。これは、ARIA が有効なウィジェットにスタイルを設定するうえで便利な仕組みです。

+ +
.tab-panel[aria-hidden="true"] {
+  display: none;
+  }
+
+.tab-panel[aria-hidden="false"] {
+  display: block;
+  }
+
+ +

検証はどうなりますか?

+ +

role 属性や aria- 接頭辞がついた属性のような、ARIA で導入された新たな属性は、HTML 4 や XHTML 4 の正式な一部分ではありません。その結果、ARIA を含むページは W3C の Markup Validator のようなツールで検証してはいけません。

+ +

第一にこの問題の解決策になり得ることは、ARIA のロールやステートをマークアップ内に直接置くのを避けることです。代わりに、前出の ARIA の実例を見せていただけますか? への回答で示したように、JavaScript を使用してページへ動的に ARIA を追加してください。それでも理論上、ページは妥当ではありませんが、すべての静的な検証は正しく合格するでしょう。

+ +

別の代案は HTML5 の doctype を使用することで、これは ARIA のサポートが組み込まれています。W3C の HTML5 validator は、あなたの HTML5 ページにおける ARIA の誤った使い方も発見するでしょう。

+ +

HTML5 と ARIA との関係は?

+ +

HTML5 では、役に立つ多くのセマンティックなタグを HTML に導入しました。新たな <progress> 要素のようにいくつかのタグは、ARIA で使用可能なロールと正に重複します。ARIA にも存在する HTML5 タグをブラウザがサポートする場合は、通常その要素に ARIA のロールやステートも追加する必要はありません。ARIA には HTML5 で使用できない多くのロール、ステート、プロパティが含まれており、それらは HTML5 を使用する開発者にとって引き続き有用でしょう。詳細情報として、Steve Faulkner 氏が HTML5 と ARIA の関係について良い概説を記述しました。

+ +

HTML5 から ARIA への円滑な退行

+ +

HTML5 を理解しないブラウザにコンテンツを提供するときに、必要なところで ARIA の使用へ円滑に退行したいと考えるでしょう。よってプログレスバーの例で言うと、<progressbar> タグがサポートされていない場合は role="progressbar" へ円滑に退行できます。

+ +

こちらが、HTML5 のプログレスバーを使用するマークアップの例です:

+ +
<!DOCTYPE html>
+<html>
+  <head><title>Gracefully degrading progress bar</title></head>
+  <body>
+    <progress id="progress-bar" value="0" max="100">0% complete</progress>
+    <button id="update-button">Update</button>
+ </body>
+</html>
+
+ +

そして、こちらが古いブラウザでもプログレスバーが動作するようにする JavaScript コードです:

+ +
var progressBar = document.getElementById("progress-bar");
+
+// ブラウザが HTML5 の <progress> タグをサポートするかを確認します。
+var supportsHTML5Progress = (typeof (HTMLProgressElement) !== "undefined");
+
+function setupProgress() {
+  if (!supportsHTML5Progress) {
+    // HTML5 の <progress> がブラウザでサポートされていないので、
+    // ARIA のロールやステートを要素に追加します。
+    progressBar.setAttribute("role", "progressbar");
+    progressBar.setAttribute("aria-valuemin", 0);
+    progressBar.setAttribute("aria-valuemax", 100);
+  }
+}
+
+function updateProgress(percentComplete) {
+  if (!supportsHTML5Progress) {
+    // HTML5 の <progress> がブラウザでサポートされていないので、
+    // aria-valuenow 属性の更新が必要です。
+    progressBar.setAttribute("aria-valuenow", percentComplete);
+  } else {
+    // HTML5 の <progress> がサポートされているので、代わりに value 属性を更新します。
+    progressBar.setAttribute("value", percentComplete);
+  }
+
+  progressBar.textContent = percentComplete + "% complete";
+}
+
+function initDemo() {
+  setupProgress(); // プログレスバーの設定。
+
+  // click ハンドラをボタンに割り当てます。これはプログレスバーを 75% に更新します。
+  document.getElementById("update-button").addEventListener("click", function (e) {
+    updateProgress(75);
+    e.preventDefault();
+  }, false);
+}
+initDemo();
+
+ +

支援技術はどのように動作しますか?

+ +

支援技術は、アプリケーションのユーザインターフェイスのロール、ステート、構造を表すよう特に設計された、各オペレーティングシステムに組み込まれた API を使用します。例えば、スクリーンリーダーはテキスト読み上げエンジンでユーザインターフェイスを読むために、拡大鏡はスクリーンで重要またはアクティブな領域を強調するために、オンスクリーンキーボードはそのときの状況や UI コントロールに対してもっとも効率的なキーボードレイアウトを提供するために、この API を使用します。さらに支援技術はたいてい、ページのセマンティクスや属性を理解するために、この API を通してページの DOM にアクセスします。

+ +

ARIA は DOM の世界とデスクトップの世界との間を橋渡しします。ブラウザは ARIA が有効な要素を、ネイティブなウィジェットであるかのように支援技術の API に公開します。その結果ユーザは潜在的により一貫したユーザ体験を得て、そこでは Web の動的な JavaScript で動作するウィジェットが、デスクトップで同等のウィジェットに匹敵します。

+ +

私の ARIA の使い方の確認方法は? 自由に使用できるツールはありますか?

+ +

動作中の ARIA のテストを支援する、調査ツールやデバッグツールがいくつかあります:

+ + + +

ARIA の実践的なテストに使用できる、フリーまたはオープンソースのスクリーンリーダーもいくつかあります。以下のようなものです:

+ + + +

スクリーンリーダーでテストを行うときは、2 つのポイントを覚えておいてください:

+ +
    +
  1. スクリーンリーダーのユーザとの軽いテストでは、実際のユーザのフィードバック、テスト、および支援の代替にはなりません。
    2. +
  2. スクリーンリーダーのサポートだけがアクセシビリティではありません。さまざまなユーザビリティやアクセシビリティの手法を試しましょう。
    3. +
+ +

ARIA が有効なアプリケーションやウィジェット向けの、その他の有用なテストツールや手法です:

+ + + +

ARIA の議論はどこで行われていますか?

+ + + +

ARIA についてより詳しく学ぶには?

+ + diff --git a/files/ja/web/accessibility/aria/widgets/index.html b/files/ja/web/accessibility/aria/widgets/index.html new file mode 100644 index 0000000000..136aecae2e --- /dev/null +++ b/files/ja/web/accessibility/aria/widgets/index.html @@ -0,0 +1,10 @@ +--- +title: widgets +slug: Web/Accessibility/ARIA/widgets +tags: + - Accessibility + - NeedsTranslation + - TopicStub +translation_of: Web/Accessibility/ARIA/widgets +--- +

This page was auto-generated because a user created a sub-page to this page.

diff --git a/files/ja/web/accessibility/aria/widgets/overview/index.html b/files/ja/web/accessibility/aria/widgets/overview/index.html new file mode 100644 index 0000000000..c49401a24b --- /dev/null +++ b/files/ja/web/accessibility/aria/widgets/overview/index.html @@ -0,0 +1,72 @@ +--- +title: 概観 +slug: Web/Accessibility/ARIA/widgets/overview +tags: + - Accessibility + - JavaScript + - Landing + - NeedsUpdate +translation_of: Web/Accessibility/ARIA/widgets/overview +--- +
Warning: needs updating
+ +

入門

+ +

ここでは、動作する例とアクセシブルなJavaScript ウィジェットを作るベストプラクティスを見ていきます。

+ +

一般リソース

+ + + +

チェックボックス

+ + + + + + + +

スライダー

+ + + +

タブ

+ + + + + + + +

フォーム検証

+ + + +

表

+ + diff --git a/files/ja/web/accessibility/at_development/index.html b/files/ja/web/accessibility/at_development/index.html new file mode 100644 index 0000000000..f811a5ddab --- /dev/null +++ b/files/ja/web/accessibility/at_development/index.html @@ -0,0 +1,55 @@ +--- +title: AT Development +slug: Web/Accessibility/AT_Development +tags: + - AT_APIs + - Accessibility +translation_of: Mozilla/Tech/Accessibility/AT_Development +--- +
+
+

入門

+ +
+
ソフトウェアアクセシビリティ: 我々は今どこにいるのか？
+
コンピューターソフトウェアのアクセシビリティはこの20年で劇的に改良されました。この記事 (2007年から) では、進歩とテクノロジーが開発されてくるにあわせて振り返っています。
+
+ +

Guidelines

+ +
+
Gecko での AT API 実装
+
FirefoxやThunderbirdなどのようなGeckoベースのアプリケーションのAT ベンダーのサポートガイド
+
アクセシビリティアーキテクチャ
+
アクセシビリティ階層が Mozilla でどう実装されているか (いくつかの問題は前のガイドで記されていません)。
+
+ +
+
Python でXULRunner をビルドする
+
WindowsのPythonでXULRunner をビルドする方法。次に comtypes gives access to MSAA and IAccessible2.
+
+
+ +
+

リファレンス

+ +
+
AT API の実装リファレンス
+
Gecko がどのように ATK, IAccessible2, MSAA, Universal Access APIを扱うかを示します。
+
+ +
+
アクセシブルな Web 仕様のリファレンス
+
Provides the map of reflecting web specification to AT APIs. This page includes: +
    +
  • ARIA References - W3C specification reflecting ARIA mapping into AT APIs.
    • +
  • XForms References - Gecko documentation showing how XForms controls are mapped to AT APIs.
    • +
+
+
+
+
+ +

 

+ +

 

diff --git a/files/ja/web/accessibility/community/index.html b/files/ja/web/accessibility/community/index.html new file mode 100644 index 0000000000..ee8bc00fb7 --- /dev/null +++ b/files/ja/web/accessibility/community/index.html @@ -0,0 +1,19 @@ +--- +title: Community +slug: Web/Accessibility/Community +tags: + - Accessibility +--- +

+

アクセシビリティに関する、役立つメーリングリストやニュースグループ、フォーラム、その他のコミュニティをご存知の方は、ここにリンクを追加してください。 +

+ +

以下、日本語の情報: +

+ diff --git a/files/ja/web/accessibility/index.html b/files/ja/web/accessibility/index.html new file mode 100644 index 0000000000..958a539a10 --- /dev/null +++ b/files/ja/web/accessibility/index.html @@ -0,0 +1,57 @@ +--- +title: アクセシビリティ +slug: Web/Accessibility +tags: + - Accessibility + - Advanced + - Landing + - Web Development +translation_of: Web/Accessibility +--- +

ウェブ開発におけるアクセシビリティとは、何らかの理由により能力に制約がある場合でも、可能な限り多くの人々がウェブサイトを使用できるようにすることを意味します。この記事では、アクセシビリティを考慮したコンテンツを開発するための情報を提供します。

+ +

"アクセシビリティは "車椅子対応" のように障害を持つ人々を支援する設備や施設を説明するためによく利用されます。これが指し示すものは、点字表示、車椅子用傾斜路、横断歩行者用音声信号、歩道標識、ウェブサイトのデザインなどにも広げられます。" Wikipedia

+ +

"ハードウェア、ソフトウェア、言語、文化、所在地、物理的/精神的能力にかかわらず、ウェブは基本的にすべての人に向けて設計されています。ウェブがこの目的を達成できると、さまざまな聴力、視力、認知能力をもつ人々がウェブにアクセスできるようになります。" W3C - Accessibility

+ +
+
+

主なチュートリアル

+ +

MDN のアクセシビリティ学習エリアには、アクセシビリティの基本事項を含むモダンな最新のチュートリアルが含まれています:

+ +
+
アクセシビリティとは何か？
+
この記事では、アクセシビリティが実際にどのようなものであるかをよく見てモジュールを開始します。これには、どのグループを考慮する必要があるのかとそのグループの理由、さまざまな人々がウェブとやりとりするために使用するツール、アクセシビリティをウェブ開発ワークフローの一部にする方法を含みます。
+
HTML: アクセシビリティのための良い基礎
+
適切な HTML 要素が常に正しい目的で使用されていることを確認するだけで、大量のウェブコンテンツをアクセシブルにすることができます。この記事では、最大限のアクセシビリティを確保するために HTML をどのように使用できるかについて詳しく説明します。
+
CSS と JavaScript のアクセシビリティベストプラクティス
+
CSS と JavaScript を適切に使用すると、アクセシブルなウェブ体験を可能にするポテンシャルがあります。また、悪用されるとアクセシビリティに大きな悪影響を与える可能性があります。この記事では、複雑なコンテンツでさえも可能な限りアクセシブルであることを保証するために考慮する必要がある CSS と JavaScript のベストプラクティスの概要を説明します。
+
WAI-ARIA の基礎
+
前の記事に従って、セマンティックでない HTML や動的に JavaScript で更新されたコンテンツを含む複雑なUIコントロールを作成することは理解しづらい場合があります。WAI-ARIA は、ブラウザーや支援技術が認識して使用できるセマンティクスを追加することで、このような問題の解決に役立つ技術です。ここでは、アクセシビリティを向上させるために基本レベルで使用する方法を示します。
+
アクセシブルなマルチメディア
+
アクセシビリティの問題を引き起こす可能性のある別のカテゴリーのコンテンツは、マルチメディアです。映像、音声、および画像のコンテンツには、補助的なテクノロジーとそのユーザーが理解できるように適切なテキストの代替が必要です。この記事では、その方法を示します。
+
モバイルアクセシビリティ
+
モバイル端末でのウェブアクセスが普及しており、iOS や Android などの普及しているプラットフォームではアクセシビリティツールが完全に提供されているため、これらのプラットフォームでのウェブコンテンツのアクセシビリティを考慮する必要があります。この記事では、モバイル固有のアクセシビリティの考慮事項について説明します。
+
+
+ +
+

他の文書

+ +
+
ウェブコンテンツ・アクセシビリティガイドラインを理解する
+
この一連の記事では、W3C ウェブコンテンツ・アクセシビリティガイドライン 2.0 または 2.1（WCAG、Web Content Accessibility Guidelines）で概説されている推奨事項に準拠するために必要な手順を理解するのに役立つ簡単な説明を提供します。
+
キーボードでナビゲート可能な JavaScript ウィジェット
+
今まで、スタイル付きの <div> や <span> ベースのウィジェットを作りたいというウェブ開発者は、適切な技術を欠いていました。 キーボード・アクセシビリティは、開発者が知っておくべき最低限のアクセシビリティ要件の一部です。
+
空気
+
ARIAを使用してHTML文書をより使いやすくする方法を学ぶための記事のコレクション。
+
支援技術 (AT) 開発
+
支援技術の開発者向け記事のコレクション
+
モバイルアクセシビリティのチェックリスト
+
このドキュメントは、モバイルアプリ開発者向けのアクセシビリティ要求事項の簡潔なチェックリストを提供します。
+
+ +

アクセシビリティについてのすべての記事を見る...

+
+
diff --git a/files/ja/web/accessibility/index/index.html b/files/ja/web/accessibility/index/index.html new file mode 100644 index 0000000000..3e2035d320 --- /dev/null +++ b/files/ja/web/accessibility/index/index.html @@ -0,0 +1,11 @@ +--- +title: アクセシビリティ関連ドキュメントの索引 +slug: Web/Accessibility/Index +tags: + - Accessibility + - Index +translation_of: Web/Accessibility/Index +--- +

このドキュメントは、Mozilla Developer Network サイト上の、すべてのアクセシビリティの記事へのリンクの一覧を提供します。

+ +

{{Index("/ja/docs/Web/Accessibility")}}

diff --git a/files/ja/web/accessibility/keyboard-navigable_javascript_widgets/index.html b/files/ja/web/accessibility/keyboard-navigable_javascript_widgets/index.html new file mode 100644 index 0000000000..72a23044f3 --- /dev/null +++ b/files/ja/web/accessibility/keyboard-navigable_javascript_widgets/index.html @@ -0,0 +1,171 @@ +--- +title: キーボードでナビゲート可能な JavaScript ウィジェット +slug: Web/Accessibility/Keyboard-navigable_JavaScript_widgets +tags: + - Accessibility + - DOM + - JavaScript +translation_of: Web/Accessibility/Keyboard-navigable_JavaScript_widgets +--- +

概要

+ +

ウェブアプリケーションは、メニュー、ツリービュー、リッチテキストフィールド、タブパネルなどのデスクトップウィジェットを模倣するために JavaScript を使用することがよくあります。 これらのウィジェットは通常、{{htmlelement("div")}} 要素と {{htmlelement("span")}} 要素で構成されています。これらの要素は本来、デスクトップのものと同じキーボード機能を提供しません。 このドキュメントは JavaScript ウィジェットをキーボードでアクセス可能にするためのテクニックを説明します。

+ +

tabindex を使う

+ +

デフォルトでは、人々がウェブページを閲覧するために Tab キーを使うとき、（リンクやフォームコントロールのような）インタラクティブ要素だけがフォーカスされます。 {{htmlattrxref("tabindex")}} グローバル属性を使うと、作成者は他の要素もフォーカス可能にできます。 0 に設定すると、要素はキーボードとスクリプトによってフォーカス可能になります。 -1 に設定すると、要素はスクリプトによってフォーカス可能になりますが、キーボードによるフォーカスの順序の一部にはなりません。

+ +

キーボードを使用したときに要素がフォーカスを得る順序は、デフォルトではソースの順序です。 例外的な状況では、作成者は順序を再定義したいと思うかもしれません。 これを行うために、作成者は tabindex を任意の正数に設定することができます。

+ +
+

警告: tabindex に正の値を使わないでください。 tabindex に正の値を持つ要素は、ページ上のデフォルトのインタラクティブ要素の前に配置されます。 つまり、ページ作成者は、tabindex に 1 以上の正の値を使用する時は必ず、ページ上の全てのフォーカス可能要素に対して tabindex の値を設定（および維持）する必要があります。

+
+ +

次の表は、最新のブラウザーにおける tabindex の動作を説明しています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
tabindex 属性element.focus() を介してマウスや JavaScript でフォーカス可能タブでナビゲート可能
存在しない要素のプラットフォーム規約に従います（フォームコントロール、リンクなどでは、可）。要素のプラットフォーム規約に従います。
負（つまり、tabindex="-1"）可不可。 作成者は、矢印キーなどの押下に応答して、focus() で要素をフォーカスしなければなりません。
ゼロ（つまり、tabindex="0"）可ドキュメント内の要素の位置を基準としたタブ順序（{{htmlelement("a")}} のようなインタラクティブ要素は、デフォルトでこの振る舞いをすることに注意してください。 それらにこの属性は不要です）。
正（例えば、tabindex="33"）可tabindex の値は、この要素がタブ順序のどこに配置されるかを決定します。 小さい値は、大きい値よりもタブ順序の早い位置に要素を配置します（例えば、tabindex="7" は tabindex="11" の前に配置されます）。
+ +

ネイティブでないコントロール

+ +

{{htmlelement("a")}}、{{htmlelement("input")}}、{{htmlelement("select")}} のようなインタラクティブなネイティブ HTML 要素はすでにキーボードによりアクセス可能であるため、これらのいずれかを使用することが、コンポーネントをキーボードで使えるようにするための最速の方法です。

+ +

作成者は、0 の tabindex を追加することによって、{{htmlelement("div")}} や {{htmlelement("span")}} をキーボードでアクセス可能にすることもできます。 これは、HTML には存在しないインタラクティブ要素を使用するコンポーネントに特に役立ちます。

+ +

コントロールのグループ化

+ +

メニュー、タブリスト、グリッド、ツリービューなどのウィジェットをグループ化するには、親要素をタブ順序に入れて（tabindex="0"）、各子孫の選択項目/タブ/セル/行をタブ順序から除く（tabindex="-1"）必要があります。 ユーザーは矢印キーを使って子孫要素をナビゲートできるべきです。 （典型的なウィジェットに通常期待されるキーボードサポートの詳細な説明については、WAI-ARIA のオーサリングプラクティス（英語）を参照してください。）

+ +

以下の例は、入れ子になったメニューコントロールで使用されるこのテクニックを示しています。 キーボードフォーカスが含まれている {{htmlelement("ul")}} 要素に到達したら、JavaScript 開発者はプログラム的にフォーカスを管理し、矢印キーに応答する必要があります。 ウィジェット内でフォーカスを管理するためのテクニックについては、以下の「グループ内のフォーカス管理」を参照してください。

+ +

例 2: tabindex を使用してキーボードアクセスを制御するメニューコントロール

+ +
<ul id="mb1" tabindex="0">
+  <li id="mb1_menu1" tabindex="-1"> フォント
+    <ul id="fontMenu" title="フォント" tabindex="-1">
+      <li id="sans-serif" tabindex="-1">サンセリフ</li>
+      <li id="serif" tabindex="-1">セリフ</li>
+      <li id="monospace" tabindex="-1">モノスペース</li>
+      <li id="fantasy" tabindex="-1">ファンタジー</li>
+    </ul>
+  </li>
+  <li id="mb1_menu2" tabindex="-1"> スタイル
+    <ul id="styleMenu" title="スタイル" tabindex="-1">
+      <li id="italic" tabindex="-1">斜体</li>
+      <li id="bold" tabindex="-1">太字</li>
+      <li id="underline" tabindex="-1">下線</li>
+    </ul>
+  </li>
+  <li id="mb1_menu3" tabindex="-1"> 位置揃え
+    <ul id="justificationMenu" title="位置揃え" tabindex="-1">
+      <li id="left" tabindex="-1">左</li>
+      <li id="center" tabindex="-1">中央</li>
+      <li id="right" tabindex="-1">右</li>
+      <li id="justify" tabindex="-1">両端</li>
+    </ul>
+  </li>
+</ul>
+ +

無効なコントロール

+ +

カスタムコントロールが無効になったら、tabindex="-1" を設定して、タブ順序から除きます。 グループ化されたウィジェット内の無効な項目（メニュー内のメニュー項目など）は、矢印キーを使用してナビゲート可能なままにするべきであることに注意してください。

+ +

グループ内のフォーカス管理

+ +

ユーザーがウィジェットからタブで離れてから戻ると、フォーカスはフォーカスを持っていた特定の要素、例えば、ツリーアイテムやグリッドセルに戻るべきです。 これを実現するには次の2つのテクニックがあります。

+ +
    +
  1. 動き回る tabindex: プログラム的にフォーカスを移動
    2. +
  2. aria-activedescendant: 「仮想」フォーカスの管理
    3. +
+ +

テクニック 1: 動き回る tabindex

+ +

フォーカスされた要素の tabindex を "0" に設定すると、ユーザーがウィジェットからタブで離れてから戻ってきた場合でも、グループ内の選択された項目にフォーカスが保持されます。 tabindex を "0" に更新したら、以前に選択した項目を tabindex="-1" に更新する必要もあることに注意してください。 このテクニックでは、キーイベントに応答してプログラムでフォーカスを移動し、現在フォーカスされた項目を反映するように tabindex を更新します。 次を行います。

+ +

キーダウンハンドラをグループ内の各要素にバインドし、矢印キーを使用して別の要素に移動した場合、

+ +
    +
  1. プログラム的に新しい要素にフォーカスを適用します。
    2. +
  2. フォーカスされた要素の tabindex を "0" に更新します。
    3. +
  3. 以前にフォーカスされた要素の tabindex を "-1" に更新します。
    4. +
+ +

これはこのテクニックを使った WAI-ARIA ツリービューの例です。

+ +
ヒント
+ +
element.focus() を使ってフォーカスを設定する
+ +

要素にフォーカスを移すために createEvent()、initEvent()、および dispatchEvent() を使用しないでください。 DOM フォーカスイベントは情報提供のみを目的としています。 何かがフォーカスされた後にシステムによって生成されますが、実際にはフォーカスの設定には使用されません。 代わりに element.focus() を使用してください。

+ +
onfocus を使って現在のフォーカスを追跡する
+ +

全てのフォーカスの変更がキーイベントやマウスイベントを介して行われるとは限りません。 スクリーンリーダーなどの支援技術では、フォーカスを任意のフォーカス可能な要素に設定できます。 代わりに onfocus と onblur を使ってフォーカスを追跡します。

+ +

onfocus と onblur は全ての要素で使用できるようになりました。 現在のドキュメントのフォーカスを取得するための標準的な DOM インターフェースはありません。 フォーカスの状態を追跡したい場合は、document.activeElement を使ってアクティブな要素を取得できます。 document.hasFocus を使って、現在のドキュメントのフォーカスかどうかを確認することもできます。

+ +

テクニック 2: aria-activedescendant

+ +

このテクニックでは、単一のイベントハンドラをコンテナウィジェットにバインドし、aria-activedescendant を使用して「仮想」フォーカスを追跡します。 （ARIA に関する詳細は、アクセス可能なウェブアプリケーションとウィジェットの概要を参照してください。）

+ +

aria-activedescendant プロパティは、現在仮想フォーカスを持っている子孫要素の ID を識別します。 コンテナのイベントハンドラーは、aria-activedescendant の値を更新し、（例えば、境界線や背景色で）現在の項目が適切にスタイル設定されていることを確実にすることで、キーイベントおよびマウスイベントに応答する必要があります。 これがどのように機能するかの直接的な説明については、この ARIA ラジオグループの例のソースコードを参照してください。

+ +

一般的なガイドライン

+ +

onkeypress ではなく onkeydown を使ってキーイベントをトラップする

+ +

IE は、英数字以外のキーに対する keypress イベントを発生させません。 代わりに onkeydown を使用してください。

+ +

キーボードとマウスが同じエクスペリエンスを生み出すことを確実にする

+ +

ユーザーエクスペリエンスが入力デバイスに関係なく一貫していることを保証するために、キーボードとマウスのイベントハンドラは適切な場所でコードを共有するべきです。 例えば、ユーザーが矢印キーを使用して移動したときに tabindex やスタイルを更新するコードは、マウスクリックハンドラでも同じ変化を生み出すために使用するべきです。

+ +

キーボードを使用して要素をアクティブにできることを確実にする

+ +

キーボードを使用して要素をアクティブにできることを確実にするには、マウスイベントにバインドされているハンドラもキーボードイベントにバインドするべきです。 例えば、onclick="doSomething()" がある場合、Enter キーで要素がアクティブにできることを確実にするには、onkeydown="return event.keyCode != 13 || doSomething();" で doSomething() をキーダウンイベントにもバインドするべきです。

+ +

tabindex="-1" 項目およびプログラムでフォーカスを受け取る要素に常にフォーカスを描画する

+ +

プログラム的にフォーカスを受け取る項目には、IE は自動的にフォーカスの輪郭を描画しません。 背景色を this.style.backgroundColor = "gray"; のようなもので変更するか、または this.style.border = "1px dotted invert" で点線の境界線を追加することの中から選らんでください。 点線の境界線の場合は、最初から見えない 1px の境界線があるようにして、境界線スタイルを適用しても要素が大きくならないようにする必要があります（境界線はスペースを取り、IE は CSS アウトラインを実装しません）。

+ +

使用したキーイベントがブラウザー機能を実行しないようにする

+ +

ウィジェットがキーイベントを処理する場合は、イベントハンドラのリターンコードを使用して、ブラウザーもそれを処理しないようにします（例えば、矢印キーに応答してスクロールするなど）。 イベントハンドラが false を返した場合、そのイベントはハンドラを超えて伝播しません。

+ +

例えば、次で、

+ +
<span tabindex="-1" onkeydown="return handleKeyDown();">
+ +

handleKeyDown() が false を返すと、イベントは消費され、ブラウザーはキーストロークに基づいたアクションを実行できなくなります。

+ +

現時点では、キーリピートに一貫した動作を当てにしないこと

+ +

残念ながら onkeydown は、使用しているブラウザーや OS によってはリピートするかもしれないし、しないかもしれません。

diff --git a/files/ja/web/accessibility/mobile_accessibility_checklist/index.html b/files/ja/web/accessibility/mobile_accessibility_checklist/index.html new file mode 100644 index 0000000000..8871da882b --- /dev/null +++ b/files/ja/web/accessibility/mobile_accessibility_checklist/index.html @@ -0,0 +1,92 @@ +--- +title: モバイルアクセシビリティのチェックリスト +slug: Web/Accessibility/Mobile_accessibility_checklist +tags: + - Accessibility + - Guidelines + - Mobile + - checklist +translation_of: Web/Accessibility/Mobile_accessibility_checklist +--- +
+

このドキュメントは、モバイルアプリ開発者向けのアクセシビリティ要件の簡潔なチェックリストを提供します。 それはより多くのパターンが生じるにつれて絶えず進化することを意図しています。

+
+ +

色

+ + + +

可視性

+ + + +

フォーカス

+ + + +

同等のテキスト

+ + + +

ステートの取り扱い

+ + + +

一般的なガイドライン

+ + + +
+

メモ: この文書のオリジナル版（英語）は、Yura Zenevich によって書かれました。

+
+ +

 

diff --git a/files/ja/web/accessibility/understanding_wcag/index.html b/files/ja/web/accessibility/understanding_wcag/index.html new file mode 100644 index 0000000000..67d1dcfbe8 --- /dev/null +++ b/files/ja/web/accessibility/understanding_wcag/index.html @@ -0,0 +1,58 @@ +--- +title: ウェブコンテンツ・アクセシビリティガイドラインを理解する +slug: Web/Accessibility/Understanding_WCAG +tags: + - Accessibility + - WCAG + - Web Content Accessibility Guidelines +translation_of: Web/Accessibility/Understanding_WCAG +--- +

この一連の記事では、W3C {{glossary("WCAG","ウェブコンテンツ・アクセシビリティガイドライン")}} 2.0 または 2.1（WCAG、Web Content Accessibility Guidelines）で概説されている推奨事項に準拠するために必要な手順を理解するのに役立つ簡単な説明を提供します。

+ +

WCAG 2.0 と 2.1 は、さまざまな障碍を持つ人々にとってウェブコンテンツをよりアクセスしやすくするための詳細なガイドラインを提供しています。 それは包括的ですが信じられないほど詳細であり、そして迅速な理解を得ることは非常に困難です。 このため、さまざまな推奨事項を満たすために必要な実際的な手順をまとめ、必要に応じて詳細へのリンクを追加しました。

+ +

4つの原則

+ +

WCAG は大きく4つの原則に分割されます —  ウェブコンテンツがアクセス可能であるように熟慮しなければならない主要な事柄（WCAG 定義のためのアクセシビリティの4つの原則の理解（英語）を参照してください）。

+ +

以下の各リンクはこれらの分野をさらに拡大するページにあなたを連れて行くでしょう。 それらは、WCAG 2.0 および 2.1 の各ガイドラインで概説されている達成基準に準拠するように、ウェブコンテンツの書き方について実際的なアドバイスを与え、各原則をさらに細分化します。

+ + + +

WCAG 2.0 と 2.1 のどちらを使うべきか？

+ +

WCAG 2.1 は最新かつ関連性のあるアクセシビリティ標準です。 WCAG 2.1 を使用して、より多くの障碍者を支援し、ウェブサイト所有者に対する将来の法的リスクを軽減します。 リソースを割り当てるときは、最初に WCAG 2.0 を目標にしてください。 それから WCAG 2.1 にステップアップしてください。

+ +

WCAG 2.1 とは何か？

+ +

WCAG 2.1 は、2018年6月5日に公式勧告として発行されました。 欧州連合（EU）は、2018年9月にデジタルアクセシビリティ標準として WCAG 2.1 を採用しました。 W3C は、プレスリリース ヨーロッパにおける WCAG 2.1 の採用（英語）を発表しました。

+ +

WCAG 2.1 には以下が含まれます。

+ + + + + +

このガイドは、より良く、よりアクセスしやすいウェブサイトを構築するのに役立つ実用的な情報を提供することを目的としています。 しかし、私たちは弁護士ではありません、そしてこれのどれも法的助言を構成しません。 ウェブのアクセシビリティが法的にどのような意味を持つのかを心配している場合は、あなたの国や地域のウェブや公共のリソースに対するアクセシビリティを規定する特定の法律を調べ、有資格の弁護士に相談することをお勧めします。

+ +

アクセシビリティとは？と、その中のアクセシビリティのガイドラインと法律のセクションには、より関連性の高い情報が記載されています。

diff --git a/files/ja/web/accessibility/understanding_wcag/operable/index.html b/files/ja/web/accessibility/understanding_wcag/operable/index.html new file mode 100644 index 0000000000..52d258a1a8 --- /dev/null +++ b/files/ja/web/accessibility/understanding_wcag/operable/index.html @@ -0,0 +1,319 @@ +--- +title: 操作可能 +slug: Web/Accessibility/Understanding_WCAG/Operable +tags: + - Accessibility + - Focus + - Navigation + - Principle 2 + - Timing + - WCAG + - Web Content Accessibility Guidelines + - headings + - keyboard + - keyboard trap + - labels + - operable + - seizures +translation_of: Web/Accessibility/Understanding_WCAG/Operable +--- +

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の操作可能原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法についての実用的なアドバイスを提供します。 操作可能とは、ユーザーインターフェイス・コンポーネントとナビゲーションが操作可能でなければならないということです。

+ +
+

注: 操作可能の W3C の定義とそのガイドラインおよび達成基準を読むには、原則 2: 操作可能 — ユーザーインターフェース・コンポーネントとナビゲーションが操作可能でなければならない（英語）を参照してください。

+
+ +

ガイドライン 2.1 — キーボードアクセス可能: キーボードから全ての機能を利用可能にする

+ +

このガイドラインは、キーボード制御に頼るユーザーがコアウェブサイト機能にアクセスできるように、他の手段（例えば、マウス）に加えてキーボードを介してそれらを利用可能にする必要性をカバーする。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
2.1.1 キーボード (A)キーボードを使用して行えない場合（例えば、フリーハンド描画）を除き、全ての機能はキーボード制御を使用してアクセス可能であるべきです。 可能な場合は組み込みのコントロールを使用するべきで（例えば、フォームコントロール間のタブ移動）、必要な場合にのみカスタム機能を組み込むべきです。UI コントロールとキーボード・アクセシビリティを取り戻すを参照してください。
2.1.2 キーボードを閉じ込めない (A) +

キーボードを使用してある機能のセクションに入るときは、キーボードのみを使用してそのセクションから再び出ることができるべきです。 例えば、フォーカスのあるボタンの上で Enter / Return を押してオプションウィンドウを開いたら、キーボードを使ってそのウィンドウを再び閉じてメインコンテンツに戻ることができるべきです。

+ +

キーボードユーザーをアプリの特定のセクションに閉じ込めないようにするために、これは非常に重要です。

+ 		 
2.1.3 キーボード — 全機能 (AAA)これは、基準 2.1.1 を超えるさらなるステップです。 AAA 準拠を達成するために、全ての機能はキーボードコントロールを使用してアクセス可能であるべきです — 例外なく。UI コントロールとキーボード・アクセシビリティを取り戻すを参照してください。
2.1.4 文字キーショートカット (A) 2.1 で追加（英語）単一文字キーショートカットが存在する場合は、少なくとも次の1つが当てはまります。 単一文字キーショートカットは、オフにする、再マップする、または関連するユーザーインターフェース・コンポーネントにフォーカスがあるときにのみアクティブにすることができます。文字キーショートカットを理解する（英語）
+ +
+

注: ガイドライン 2.1: キーボードアクセス可能: キーボードから全ての機能を利用可能にする（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 2.2 — 十分な時間: コンテンツを読んで使用するのに十分な時間をユーザーに提供する

+ +

このガイドラインでは、機能に制限時間があるかもしれない状況について説明します。 例えば、セキュリティ上の理由から、購入を制限時間内に完了する必要がある場合があります。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
2.2.1 タイミングは調整可能 (A) +

制限時間付きの機能の場合（例えば、ホテルやフライトの予約を完了するには制限時間があることが多い）、ユーザーには、制限時間の調整、延長、または無効化を許可するコントロールを与えるべきです。

+ +

これに対する例外は、20時間を超える制限時間のある活動、リアルタイムイベント（例えば、ライブマルチプレイヤーゲーム）、および制限時間が必要で、無効にされた場合に無効になるその他の活動です。

+ 		 
2.2.2 一時停止、停止、非表示 (A) +

自動的に開始され、5秒以上続き、他のコンテンツと一緒に表示されるコンテンツを移動や点滅させるには、一時停止、停止、または非表示にするためのコントロールを提供するべきです。 これは、体験に不可欠なコンテンツの移動や点滅には適用されません。 例としては、テキストのスクロールと動画があります。

+ +

自動的に開始され、他のコンテンツと一緒に表示される自動更新情報の場合は、一時停止、停止、または非表示にするため、あるいは更新頻度を制御するためのコントロールを提供するべきです。 これは、体験に不可欠なコンテンツの自動更新には当てはまりません。 例としては、回転木馬や回転アナウンスがあります。

+ 		 
2.2.3 制限時間なし (AAA)これは基準 2.2.1 に基づいており、AAA 適合に合格したいコンテンツには制限時間がないことを述べています。 
2.2.4 中断を抑止する (AAA)アラートやインタースティシャル広告などによる中断には、緊急アラートでない限り、それらを抑制または延期するための機能を用意するべきです。 
2.2.5 再認証 (AAA)ウェブアプリの使用中に認証セッションが期限切れになった場合、ユーザーはデータを失うことなく再認証して使用を続けることができます。 
2.2.6 タイムアウト (AAA) 2.1 で追加（英語） +

タイムアウトした場合（ユーザーの非活動状態が原因で）、プロセスの開始時にユーザーに警告するので、タイムアウトが存在していても驚くことはありません（または、20時間の非活動状態の後にのみタイムアウトするようにします）。

+ 		タイムアウトを理解する（英語）
+ +
+

注: ガイドライン 2.2: 十分な時間: コンテンツを読んで使用するのに十分な時間をユーザーに提供する（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン2.3 — 発作と身体的反応: 発作や身体的反応を引き起こすことが知られている方法でコンテンツをデザインしないでください

+ +

これは、変更しないとてんかんなどの症状のあるユーザーに発作を起こす可能性がある、または前庭障碍などの症状のあるユーザーに身体的反応（めまいなど）を引き起こす可能性があるコンテンツを意味します。

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
2.3.1 3回の閃光、またはしきい値を下回る (A)コンテンツに1秒間に3回以上の閃光を放つアスペクトが含まれていない、または閃光を放つコンテンツが許容できる閃光および赤色閃光のしきい値（英語）を下回っている。 
2.3.2 3回の閃光 (AAA)コンテンツには、1秒間に3回以上の閃光を放つアスペクトは含まれていません。 
2.3.3 インタラクションによるアニメーション (AAA) 2.1 で追加（英語）ユーザーがインタラクションによるアニメーションを無効にできるようにする（アニメーションが必須でない限り）。インタラクションによるアニメーションを理解する（英語）
+ +
+

注: ガイドライン 2.3: 発作と身体的反応: 発作や身体的反応を引き起こすことが知られている方法でコンテンツをデザインしないでください（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 2.4 — ナビゲート可能: ユーザーがナビゲートし、コンテンツを見つけ、どこにいるのかを判断するのに役立つ方法を提供する

+ +

このガイドラインの下での適合基準は、ユーザーが自分自身を指向し、サイトの現在のページや他のページで探しているコンテンツと機能を見つけることが期待できる方法に関連しています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
2.4.1 ブロックのバイパス (A) +

繰り返される機能（会社のロゴやナビゲーションなど）を通り過ぎて、ユーザーがページにあるメインコンテンツや機能に直接スキップできるようにするメカニズムを提供するべきです。 これはしばしば、スキップリンク（"skip links"）を使用して達成されます — メインコンテンツにリンクする CSS によって隠されたリンクはページのソースのトップに置かれます。

+ +

見出しと意味論のコンテナの適切な構造（例えば、{{htmlelement("section")}}、{{htmlelement("aside")}} など）がナビゲートするために提供されている場合は、追加のスキップリンクは必要ありません。

+ 		スキップリンクのセクションを追加する必要があります。
2.4.2 ページタイトルを含める (A)各ウェブページには有益な {{htmlelement("title")}} を含めるべきです。 そのコンテンツは、ページのコンテンツや目的を説明しています。タイトルの追加を参照してください。
2.4.3 論理的なフォーカスの順序 (A)フォーカス可能なページ機能（例えば、リンク、ボタン、フォーム入力）の「タブ順序」は論理的に意味があり、そのページはまだ非晴眼者でもキーボードのユーザーでも使用可能であることを意味します。コントロールへのタブ移動に関する一般的なアドバイスについては、UI コントロールを参照してください。 要素を独特なレイアウトに配置する必要がある場合は、ソースの順序が適切であることを確認してから、配置などの CSS 機能を使用してレイアウトを扱うことをお勧めします。
2.4.4 リンクの目的（コンテキストにそった）（A）リンクの目的や行き先は、リンクテキストから、またはその周囲（例えば、周囲のテキスト）から決定することができます。 例外は、リンクの目的が全てのユーザーにとってあいまいな場合です（これに関する有用な説明については、一般的にユーザーにとってあいまい（英語）を参照してください）。わかりやすいテキストラベルを参照してください。 また、同じテキストの複数のコピーが異なる場所にリンクされている場合は最小限に抑えるべきです。 これはスクリーンリーダーのユーザーにとって問題となる可能性があり、リンクの一覧がコンテキストから外れて表示されることがよくあります — 全てが「ここをクリック」、「ここをクリック」、「ここをクリック」とラベル付けされたいくつかのリンクは混乱を招くでしょう。
2.4.5 複数のナビゲーションメカニズム (AA) +

ウェブサイト上のページを見つけるために少なくとも二つの一般的なナビゲーションメカニズム、例えば、ナビゲーションメニュー、パンくずリスト、サイト検索、サイトマップ、関連リンクのリストなどを提供するべきです。

+ +

これに対する唯一の例外は、ページがプロセスの1ステップである場合で、論理的には前後のステップへのリンクのみを持つべきです。

+ 		これらのメカニズムのほとんどは、単純な HTML 機能を使用して作成できます。 例えば、検索フィールド、ナビゲーションメニューの作成、ボタンとしてのリンクのスタイリングを参照してください。
2.4.6 見出しとラベル (AA)見出し（例えば、{{htmlelement("h2")}}）および {{htmlelement("label")}} 要素は、それらが説明していると思われるコンテンツおよびフォーム要素の目的を明確に説明しています。 +

UI コントロール、わかりやすいテキストラベル、見出しと段落の基本、<label> 要素を参照してください。

+ +

構造上、それらを簡単に区別できない場合を除き、見出しやラベルの重複は避けるべきです（例えば、「詳細情報」が複数ある場合）。

+
2.4.7 フォーカス可能な要素に対する可視フォーカス (AA)リンクやフォーム入力などのフォーカス可能な要素間をタブ移動するときは、どの要素に現在フォーカスがあるかを示す視覚的なインジケーターがあるはずです。 これは通常、デフォルトでは点線や青のアウトラインです（ブラウザ、プラットフォームなどによって異なります）が、CSS によって上書きすることができます。ネイティブなキーボード・アクセシビリティの使用を参照してください。
2.4.8 サイト内の場所 (AAA)複雑なサイトまたは一連のステップ内のページにいる場合は、パンくずリスト、サイトマップ、「Form page 2 of 10」といったテキストなど、サイト内の場所を示すインジケーターをユーザーに提示するべきです。 
2.4.9 リンクの目的（リンクのみ） (AAA)この基準は 2.4.4 に基づいており、AAA に準拠するためには、コンテキストから外れていてもリンクの目的やリンク先はリンクテキストのみから決定可能であるべきであると述べています。わかりやすいテキストラベルを参照してください。 また、同じテキストの複数のコピーが異なる場所にリンクされている場合は最小限に抑えるべきです。 これはスクリーンリーダーのユーザーにとって問題となる可能性があり、リンクの一覧がコンテキストから外れて表示されることがよくあります — 全てが「ここをクリック」、「ここをクリック」、「ここをクリック」とラベル付けされたいくつかのリンクは混乱を招くでしょう。
2.4.10 セクション見出し (AAA) +

便利な文書構造を作成するだけでなく、見出しも正確に記述し、コンテンツ領域を論理的なセクションに分割するべきです。

+ +

この基準は、一般的なウェブコンテンツの見出しとタイトルを指すことに注意してください（例えば、テキストコンテンツ内の見出し）。 ユーザーインターフェースの見出しとタイトルは、基準 4.1.2 で扱われる特別なケースです。

+ 		+

見出しと段落の基本を参照してください。

+
+ +
+

注: ガイドライン 2.4: ナビゲート可能：ユーザーがナビゲートし、コンテンツを見つけ、どこにいるのかを判断するのに役立つ方法を提供する（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 2.5 — 入力様式: キーボードを超えた様々な入力を通して機能をユーザーが操作しやすくする

+ +

このガイドラインの適合基準は、ユーザーがキーボードやマウス以外のさまざまな入力方法（タッチスクリーン、音声、デバイスの動き、その他の入力デバイスを含む）を使用してデジタルテクノロジーと対話できることを保証します。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
2.5.1 ポインタジェスチャー (A) 2.1 で追加（英語）ポインタで操作できる全ての機能は、シングルポイントのアクションで操作できます。 パスベースやマルチポイントのジェスチャーは、機能を操作するために必要ではありません。 例外があります。ポインタジェスチャーを理解する（英語）
2.5.2 ポインタキャンセル (A) 2.1 で追加（英語）シングルポインタを使用して操作できる機能については、次のうち少なくとも1つが当てはまります。 ダウンイベントなし、中止や元に戻す、アップリバーサル、必要不可欠。ポインタキャンセルを理解する（英語）
2.5.3 名前のラベル (A) 2.1 で追加（英語）表示可能なテキストラベルを含む各ユーザーインターフェイス・コンポーネントについて、アクセス可能な名前がラベルの表示可能なテキストと一致する（または含まれる）ことを確認します。名前のラベルを理解する（英語）
2.5.4 動きによる作動 (A) 2.1 で追加（英語）a）デバイスの動き（揺れ、傾きのような）、または b）デバイスのセンサー（カメラを含む）によって検出されたユーザーのジェスチャーによって引き起こされる可能性のある機能について、次の両方が当てはまることを確認します。 1) 動きによる作動を無効にすることができ、2) 機能をデバイスの動きやユーザーのジェスチャーを使用せずに動作させることができる。 例外があります。動きによる作動を理解する（英語）
2.5.5 ターゲットサイズ (AAA) 2.1 で追加（英語）アクション可能アイテムのタッチターゲットのサイズは、幅と高さの両方で少なくとも 44 CSS ピクセルにする必要があります。 例外があります。ターゲットサイズを理解する（英語）
2.5.6 同時入力メカニズム (AAA) 2.1 で追加（英語）タッチスクリーン、キーボード、マウス、音声コマンド、その他の入力デバイスを含むデジタルコンテンツと対話するときに、さまざまな入力モードを使用したり切り替えたりできることを確認します。 本質的な例外があります。同時入力メカニズムを理解する（英語）
+ +
+

注: ガイドライン2.5: 入力様式: キーボードを超えた様々な入力を通して機能をユーザーが操作しやすくする（英語）に関する WCAG の説明も参照してください。

+
+ +

 

+ +

関連情報

+ + + +

 

diff --git a/files/ja/web/accessibility/understanding_wcag/perceivable/index.html b/files/ja/web/accessibility/understanding_wcag/perceivable/index.html new file mode 100644 index 0000000000..ff6eae9cac --- /dev/null +++ b/files/ja/web/accessibility/understanding_wcag/perceivable/index.html @@ -0,0 +1,357 @@ +--- +title: 知覚可能 +slug: Web/Accessibility/Understanding_WCAG/Perceivable +tags: + - Accessibility + - Principle 1 + - WCAG + - Web Content Accessibility Guidelines + - contrast + - different presentation + - text alternatives + - time-based media +translation_of: Web/Accessibility/Understanding_WCAG/Perceivable +--- +

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の知覚可能原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法についての実用的なアドバイスを提供します。 知覚可能とは、ユーザーが自分の感覚の1つ以上を使用して何らかの方法でそれを知覚できなければならないということです。

+ +
+

注: 知覚可能の W3C 定義とそのガイドラインおよび達成基準を読むには、原則 1: 知覚可能 — 情報とユーザーインターフェイス・コンポーネントが、ユーザーが認識できる方法で提示可能である必要があります（英語）を参照してください。

+
+ +

ガイドライン 1.1 — 非テキストコンテンツのための代替テキストの提供

+ +

ここで重要なのは、テキストならば障碍のある人が使用できる他の形式に変換できることです。 例えば、スクリーンリーダーで話させたり、ズームインしたり、点字ディスプレイに表示したりできます。 非テキストコンテンツとは、画像、音声、動画などのマルチメディアを指します。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
1.1.1 同等のテキストを提供する (A)意味のある内容を伝える全ての画像は、適切な代替テキストを与えられるべきです。代替テキスト。
複雑な画像や図表には、同じページ上またはリンク先のいずれかにアクセス可能な代替手段を用意するべきです。 {{htmlattrxref("longdesc","img")}} 属性ではなく通常のリンクを使用してください。 +

テキストの説明や、アクセス可能なデータ表がうまくいくかもしれません（HTML 表の高度な機能とアクセシビリティを参照）。 longdesc 反対論については、その他の代替テキストの仕組みも参照してください。

+
マルチメディアコンテンツ（例えば、音声や動画）は、少なくともわかりやすい識別が利用できるべきです（例えば、キャプションまたは同様のもの）。 +

静的キャプションの選択肢については代替テキストを、その他の選択肢についてはオーディオトランスクリプト、 ビデオテキストトラック、その他のマルチメディアコンテンツを参照してください。

+
フォーム要素やボタンのような UI コントロールには、その目的を説明するテキストラベルを付けるべきです。ボタンは簡単です — ボタンのテキストがボタンの機能を説明していることを確認してください（例えば、<button>画像のアップロード</button>）。 他の UI コントロールの詳細については、UI コントロールを参照してください。
支援技術には見えない方法で、装飾的な（コンテンツではない）画像、動画などを実装すると、ユーザーを混乱させません。 +

装飾画像は CSS 背景画像を使用して実装する必要があります（背景を参照）。 {{htmlelement("img")}} 要素を介して画像を含める必要がある場合は、空白の alt（alt=""）を付けます。 そうしないと、スクリーンリーダーがファイルパスなどを読み上げようとする可能性があります。

+ +

自動再生する背景の動画や音声を含める場合は、できるだけ目立たないようにします。 コンテンツのように見せたり鳴らさないでください。 また、無効にするコントロールを提供してください。 理想的には、それをまったく含めないでください。

+
+ +
+

注: ガイドライン1.1: 代替テキスト（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 1.2 — タイムベースト・メディアのための代替テキストの提供

+ +

タイムベースト・メディアは、持続期間を有するマルチメディア、すなわち音声および動画を指します。 また、それらの音声や動画が既存のテキストコンテンツの代替を兼ねる場合は、別の代替テキストを提供する必要はありません。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
1.2.1 記録済みの音声のみおよび動画のみのコンテンツに代わるものを提供する (A)トランスクリプトは、録音済みの音声のみのメディアに提供するべきで、トランスクリプトまたは音声解説は、録画済みの動画のみのメディア（すなわち、サイレントビデオ）に提供するべきです。トランスクリプト情報については、オーディオトランスクリプトを参照してください。 音声解説のチュートリアルはまだありません。
1.2.2  ウェブベースの動画にキャプションを付ける (A)ウェブ上に表示される動画（例えば、HTML5 動画）には、キャプションを付けるべきです。 これは、動画の音声部分が聞こえない人々のためのものです。HTML5 動画のキャプションについてはビデオテキストトラックを、その他のテクノロジについてはその他のマルチメディアコンテンツを参照してください。 独自の字幕とクローズドキャプションを追加する（YouTube、英語）も参照してください。
1.2.3 ウェブベースの動画にテキストトランスクリプトまたは音声解説を提供する (A)ウェブ上に提示される動画（例えば、HTML5 動画）のためのテキストトランスクリプトまたは音声解説を提供するべきです。 これは、動画の視覚的な部分を見ることができず、音声だけではコンテンツ全体を取得できない人々のためのものです。トランスクリプト情報については、オーディオトランスクリプトを参照してください。 音声解説のチュートリアルはまだありません。
1.2.4 生音声にキャプションを付ける (AA)音声を含んだ全ての生のマルチメディア（ビデオ会議、生音声放送など）には、同期したキャプションを付けるべきです。 
1.2.5 録画済み動画の音声解説を提供する (AA)音声解説は、録画済み動画に対して提供するべきですが、既存の音声が動画によって表現された完全な意味を伝えない場合に限ります。 
1.2.6 録音済み音声と同等の手話を提供する (AAA)音声を含んだ記録済みコンテンツには、同等の手話動画を提供するべきです。 
1.2.7 音声解説付きの拡張動画を提供する (AAA)動画のタイミングの問題で音声解説を提供できない場合（例えば、音声解説を挿入するコンテンツに適切な間がない場合）（1.2.5 を参照）、挿入された間（と音声解説）を含んだ動画の代替バージョンを提供するべきです。 
1.2.8 記録済みメディアの代替を提供する (AAA)動画を特徴とする全てのコンテンツには、わかりやすいテキストトランスクリプトを提供する必要があります。 例えば、あなたが見ている映画のスクリプトなどです。 これは、コンテンツを聴くことができない聴覚障碍者のためのものです。トランスクリプト情報については、オーディオトランスクリプトを参照してください。
1.2.9 生音声用のトランスクリプトを提供する (AAA)放送されている生音声のコンテンツのために、例えば、あなたが聞いている演劇やミュージカルのスクリプトのような説明文を提供するべきです。 これは、コンテンツを聴くことができない聴覚障碍者のためのものです。トランスクリプト情報については、オーディオトランスクリプトを参照してください。
+ +
+

注: ガイドライン 1.2: タイムベースト・メディア: タイムベースト・メディアに代わるものを提供する（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 1.3 — さまざまな方法で提示できるコンテンツの作成

+ +

このガイドラインは、異なるニーズに柔軟に対応して、コンテンツがユーザーによってさまざまな方法で消費される能力について言及しています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
1.3.1 情報と関係 (A) +

いかなるコンテンツ構造 — またはコンテンツ間に作られた視覚的関係 — もまた、プログラム的に決定されるか、またはテキストの説明から推論され得ます。 これが関連する主な状況は次のとおりです。

+ +
    +
  • テキストラベルとそれが説明するフォーム要素は、{{htmlelement("label")}} 要素を使用して明確に関連付けられて、スクリーンリーダーなどが拾うことができます。
    • +
  • 画像の代替テキスト — コンテンツ画像には、その画像の内容を明確に説明するテキストが含まれているべきです。 これは、プログラム的に関連付けることができます（例えば、{{htmlattrxref("alt","img")}} テキスト）。 そうでない場合は、関連付けるのは簡単です（例えば、それを説明し、そのすぐ隣に置きます）。 これは、たとえあなたが画像を見ることができなくても、完全な意味がまだ推測できることを意味するはずです。
    • +
  • リスト — リスト項目の順序が重要で、順序付きリストを使用するべき場合（{{htmlelement("ol")}}）。
    • +
+ 		+

HTML: アクセシビリティの基礎全体には、これに関する情報が満載されていますが、特に優れた意味論、UI コントロール、代替テキストを参照するべきです。

+
1.3.2 重要なコンテンツの順序 (A)賢明で論理的な読み上げ順序は、たとえそれが独特な方法で視覚的に提示されていても、どんな内容に対しても決定しやすいはずです。 マークアップに関係なく、CSS を使用して独特なレイアウトスタイルを作成することで、正しい意味論的要素（見出し、段落など）を使用して順序を明確にするべきです。繰り返しますが、HTML: アクセシビリティの基礎を参照してください。
1.3.3 感覚的性質 (A) +

コントロールを操作したり、コンテンツを理解したりするための指示は、単一の感覚には依存しません — これは、その感覚に関連する障碍を持つ人々、またはその感覚をサポートしていないデバイスにとってアクセスできないことを証明するかもしれません。 だから、例えば、

+ +
    +
  • 「続けるために丸いボタンをクリックしてください」 — それがあなたが押す必要があるボタンであることは明らかであるように、ボタンは明確にラベル付けされるべきです。 複数のボタンがある場合は、それらの機能を区別するために全てが明確にラベル付けされていることを確認してください。
    • +
  • 「ガイダンスに関する音声の説明を聞く」 — これは明らかに問題があります — 音声は聴覚障碍のある人にはアクセスできないのに対して、テキストは読むことができるだけでなく、必要に応じてスクリーンリーダーによって話させることもできます。
    • +
  • 「メニューを表示するには、画面の右側からスワイプ」 — 一部のユーザーは、障碍のためや、デバイスがタッチをサポートしていないために、画面をスワイプできない可能性があります。 キーボードショートカットや、キーボードなどの手段でアクティブにできるボタンなどの代替手段を提供する必要があります。
    • +
+ +
+

注: 色だけで指示を伝えることは関連していますが、異なるガイドラインでカバーされています — 1.4.1。

+
+ 		 
1.3.4 オリエンテーション (AA) 2.1 で追加（英語）特定のディスプレイの向きが重要でない限り、コンテンツの表示と操作はポートレートやランドスケープなどの単一のディスプレイの向きに制限されません。 +

オリエンテーションを理解する（英語）

+
1.3.5 入力の目的の識別 (AA) 2.1 で追加（英語） +

 

+ +

53個の入力フィールド（英語）のリストに従って、プログラム的にフィールドの目的を識別してください。

+ 		入力の目的の識別を理解する（英語）
1.3.6 目的の識別 (AAA) 2.1 で追加（英語）マークアップ言語を使用して実装されたコンテンツでは、ユーザーインターフェイス・コンポーネント、アイコン、およびリージョンの目的はプログラム的に決定できます。目的の識別を理解する（英語）
+ +
+

注: ガイドライン 1.3: 適応可能: 情報や構造を失うことなくさまざまな方法で提示できるコンテンツを作成する（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 1.4: 前景と背景の分離を含め、ユーザーがコンテンツを見たり聞いたりしやすくする

+ +

このガイドラインは、コアコンテンツが背景や他の装飾から識別しやすいことを確認することに関するものです。 典型的な例は、色で（色のコントラストと指示を伝えるための色の使い方の両方が）、他の状況でも適用されます。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
1.4.1 色の使い方 (A) +

色だけを頼りにして情報を伝えるべきではありません — 例えば、フォームでは、必須フィールドに純粋に色（赤など）で印を付けることは絶対にしないでください。 代わりに（または同様に）、「必須」というラベルの付いたアスタリスクのようなものがより適切です。

+ 		色とそのコントラストおよび複数のラベルを参照してください。
1.4.2 音声コントロール (A)3 秒以上再生される音声の場合は、音声や動画の再生と一時停止、および音量のミュートや調整を行うためのアクセス可能なコントロールを用意する必要があります。ビデオプレーヤーのスタイリングの基本に示すように、ネイティブの <button> を使用してアクセス可能なキーボードコントロールを提供します。
1.4.3 最低限のコントラスト (AA) +

背景と前景のコンテンツの間の色のコントラストは、読みやすさを確実なものとするための最低限のレベルであるべきです。

+ +
    +
  • テキストとその背景のコントラスト比は少なくとも 4.5:1 であるべきです。
    • +
  • 見出し（またはそれよりも大きい）テキストの比は、少なくとも 3:1 であるべきです。 大きいテキストは、少なくとも 18 ポイント、または 14 ポイントの太字として定義されます。
    • +
+ 		色とそのコントラストを参照してください。
1.4.4 テキストのサイズ変更 (AA)テキストサイズが2倍になったときに、ページは読みやすく使えるべきです。 つまり、デザインはレスポンシブであるべきで、テキストサイズを大きくしてもコンテンツにアクセス可能であることを意味します。 
1.4.5 テキストの画像 (AA)テキストが仕事をするようなコンテンツを提示するために画像を使用してはいけません。 例えば、画像がほとんどテキスト形式の場合、画像だけでなくテキストも使用して表現できます。 
1.4.6 強化されたコントラスト (AAA) +

これは、基準 1.4.3 に従い、その上に構築されます。

+ +
    +
  • テキストとその背景のコントラスト比は少なくとも 7:1 であるべきです。
    • +
  • 見出し（またはそれよりも大きい）テキストの比は少なくとも 4.5:1 であるべきです。 大きいテキストは、少なくとも 18 ポイント、または 14 ポイントの太字として定義されます。
    • +
+ 		 
1.4.7 背景音声は小さいか無い (AAA)話し言葉を主な特徴とする録音済みの音声記録は、背景雑音を最小限に抑えるべきため、コンテンツを簡単に理解できます。 
1.4.8 視覚的表現 (AAA) +

テキストコンテンツの表現では、次のことが当てはまります。

+ +
    +
  • 前景色と背景色は、ユーザーが選択できるようにするべきです。
    • +
  • テキストブロックは、読みやすくするために、80 文字（またはグリフ）以下の幅にしてください。
    • +
  • テキストは、両端揃えにするべきではありません（例えば、{{cssxref("text-align","text-align: justify;")}}）。
    • +
  • 行の高さは、段落内ではテキストサイズの 1.5 倍以上（例えば、{{cssxref("line-height","line-height: 1.5;")}}）、段落間ではテキストサイズの 2.25 倍以上（例えば、{{cssxref("padding","padding: 2.25rem;")}}）にするするべきです。
    • +
  • テキストサイズが2倍になったときに、コンテンツのスクロールが必要になるべきではありません。
    • +
+ 		 
1.4.9 テキストの画像（例外なし） (AAA)テキストは、純粋に装飾である（すなわち、それがいかなる内容も伝えない）か、または他の方法で提示することができない限り、画像の一部として提示するべきではありません。 
1.4.10 リフロー (AA) 2.1 で追加（英語） +
    +
  • 右から左への言語（英語など）や、左から右への言語（アラビア語など）の水平スクロール無し。
    • +
  • 上から下への言語（日本語など）の垂直スクロール無し。
    • +
  • 使用法や意味のために2次元レイアウトを必要とするコンテンツの部分を除く（大きなデータ表のように）。
    • +
+ 		リフローを理解する（英語）
1.4.11 テキスト以外のコントラスト (AA) 2.1 で追加（英語）ユーザーインターフェイス・コンポーネントとグラフィックオブジェクトの最低限のカラーコントラスト比は 3:1 です。テキスト以外のコントラストを理解する（英語）
1.4.12 テキストの間隔 (AA) 2.1 で追加（英語） +

次のスタイルを適用しても、コンテンツや機能が失われることはありません。

+ +
    +
  • 行の高さ（行間）をフォントサイズの 1.5 倍以上にします。
    • +
  • 後続の段落との間隔をフォントサイズの 2 倍以上にします。
    • +
  • 文字間隔（トラッキング）をフォントサイズの 0.12 倍以上にします。
    • +
  • 単語間隔をフォントサイズの 0.16 倍以上にします。
    • +
+ 		テキストの間隔を理解する（英語）
1.4.13 ホバーまたはフォーカスにおけるコンテンツ (AA) 2.1 で追加（英語） +

追加のコンテンツがホバーやキーボードフォーカスに連動して現れたり消えたりします。 この達成基準では、満たす必要がある次の3つの条件を指定します。

+ +
    +
  • 却下可能（閉じたり取り除くことが可能）。
    • +
  • ホバリング可能（追加のコンテンツは、ポインタが上にあるときは消えません）。
    • +
  • 永続的（追加のコンテンツは、ユーザーの操作なしでは消えません）。
    • +
+ 		ホバーまたはフォーカスにおけるコンテンツを理解する（英語）
+ +
+

注: ガイドライン 1.4: 識別可能: 背景から前景を分離するなど、ユーザーがコンテンツを見やすく、聞き取りやすくする（英語）に関する WCAG の説明も参照してください。

+
+ +

 

+ +

関連情報

+ + + +

 

diff --git a/files/ja/web/accessibility/understanding_wcag/robust/index.html b/files/ja/web/accessibility/understanding_wcag/robust/index.html new file mode 100644 index 0000000000..18f492e218 --- /dev/null +++ b/files/ja/web/accessibility/understanding_wcag/robust/index.html @@ -0,0 +1,85 @@ +--- +title: 堅牢 +slug: Web/Accessibility/Understanding_WCAG/Robust +tags: + - Accessibility + - HTML + - Parsing + - Principle 4 + - Robust + - Role(2) + - Validation + - WAI-ARIA + - WCAG + - Web Content Accessibility Guidelines + - value +translation_of: Web/Accessibility/Understanding_WCAG/Robust +--- +

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の堅牢原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法についての実用的なアドバイスを提供します。 堅牢とは、支援技術を含む多種多様なユーザーエージェントによって確実に解釈されることができるほど十分に堅牢でなければならないと述べています。 これは通常、ウェブ標準に準拠し、厳密にテストすることによって実現できます。

+ +
+

.注: W3C の堅牢の定義とそのガイドラインおよび達成基準を読むには、原則 4: 堅牢 — コンテンツは、支援技術を含むさまざまなユーザーエージェントによって確実に解釈されるよう十分に堅牢である必要があります（英語）を参照してください。

+
+ +

ガイドライン 4.1 — 互換性: 支援技術を含む現在および将来のユーザーエージェントとの互換性を最大化する

+ +

このガイドラインは、現在のユーザーエージェント（例えば、ブラウザ）だけでなく将来のものともコンテンツをできる限り互換性を持たせることに焦点を当てています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
4.1.1 解析 (A) +

コンテンツは、ブラウザやスクリーンリーダーのような他のユーザーエージェントによって正常に解析されるように、整形式（well-formed）にするべきです。

+ +

この基準に合格するには、HTML ができるだけ妥当（valid）であることを確認してください。 マークアップを検証するために W3C の検証ツール（英語）を使用してください。

+ 		実用的なガイドについては、HTML のデバッグを参照してください。
4.1.2 名前、役割、値 (A) +

ユーザインターフェース・コンポーネント（例えば、フォーム入力、ボタン、リンクなど）の名前と役割（role、ロール）はプログラム的に決定可能であるべきです。

+ +

意図された目的のために意味論の要素を正しく使用するとき、この基準に自動的に合格するはずです。 カスタムコンポーネントをスクリプト化するときは、例えば、晴眼でマウスのユーザーだけでなく、スクリーンリーダーのユーザー、キーボードのみのユーザーなども、コントロールが解釈されて意図したとおりに使用できるようにするために、WAI-ARIA のロールおよびその他の機能を使用する必要があります。

+ 		HTML: アクセシビリティの基礎と WAI-ARIA の基本を参照してください。
4.1.3 ステータスメッセージ (AA) 2.1 で追加（英語） +

支援技術のユーザーは、ページに追加された新しいステータスメッセージを認識します。

+ 		ステータスメッセージを理解する（英語）
+ +
+

注: ガイドライン 4.1: 互換性: 支援技術を含む現在および将来のユーザーエージェントとの互換性を最大化する（英語）に関する WCAG の説明も参照してください。

+
+ +

 

+ +

関連情報

+ + + +

 

diff --git a/files/ja/web/accessibility/understanding_wcag/understandable/index.html b/files/ja/web/accessibility/understanding_wcag/understandable/index.html new file mode 100644 index 0000000000..43a97f8b90 --- /dev/null +++ b/files/ja/web/accessibility/understanding_wcag/understandable/index.html @@ -0,0 +1,259 @@ +--- +title: 理解可能 +slug: Web/Accessibility/Understanding_WCAG/Understandable +tags: + - Accessibility + - HELP + - Language + - Navigation + - Principle 3 + - Text + - Understandable + - WCAG + - Web Content Accessibility Guidelines + - abbreviations + - consistency + - error messages + - form validation + - labels + - slang +translation_of: Web/Accessibility/Understanding_WCAG/Understandable +--- +

この記事では、ウェブコンテンツ・アクセシビリティガイドライン（WCAG）2.0 および 2.1 の理解可能原則に概説されている達成基準に準拠するようにウェブコンテンツを作成する方法について実用的なアドバイスを提供します。 理解可能とは、情報とユーザーインターフェースの操作が理解可能でなければならないと述べています。

+ +
+

注: 理解可能の W3C の定義とそのガイドラインおよび達成基準を読むには、原則 3: 理解可能 — 情報とユーザーインターフェイスの操作が理解可能でなければならない（英語）を参照してください。

+
+ +

ガイドライン 3.1 — 読みやすさ: テキストコンテンツを読みやすく理解しやすいものにする

+ +

このガイドラインは、テキストコンテンツをできるだけわかりやすくすることに焦点を当てています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
3.1.1 ページの言語 (A)各ウェブページのデフォルトの人間の言語はコードで検出できるべきです。 これは、読者が自分に合った言語で書かれたページにアクセスしたことを確認するなどの目的に不可欠です。 これを実現する最も簡単な方法は、ページの {{htmlelement("html")}} 要素に {{htmlattrxref("lang")}} 属性を設定して、ページが書かれている言語を最もよく表す言語コードをそれに与えることです。文書の第一言語の設定を参照してください。
3.1.2 パーツの言語 (AA) +

ページのコンテンツに第一言語とは異なる言語の単語や語句が含まれている場合は、問題の用語を囲む要素（例えば、意味論の要素が利用できない場合は {{htmlelement("span")}}）に {{htmlattrxref("lang")}} 属性を使用して適切な言語を設定します。

+ +

言語に関係なく同じである単語や語句に異なる言語を設定する必要はありません（例えば、固有名詞、特定の言語の一部ではない専門用語など）。

+ 		 
3.1.3 珍しい単語 (AAA)専門用語、業界用語、または慣用句やスラングが使用されている場合は、そのような語句や単語に対して定義を提供するべきです。 サイトでは、そのような言葉や用語の定義を含む用語集を、それらが現れたときにリンクできるように提供するか、少なくとも周囲のテキストやページ下部の説明リストのどこかに定義を提供するべきです。 
3.1.4 略語 (AAA) +

略語が使用されている場合は、それらの展開や、必要に応じて定義を提供するべきです。

+ +

{{htmlelement("abbr")}} 要素は、略語の展開を提供するための推奨される方法と考えられています — 展開を含む {{htmlattrxref("title")}} 属性を取り、略語をマウスオーバーしたとき、これが表示されます。 ただし、title の内容はキーボードからはアクセスできず、スクリーンリーダーによって確実に読み上げられるわけでもありません。 これを扱うためのより良い方法は、この場合も先と同様に略語の展開と説明を含む用語集のページへのリンクを提供するか、少なくともコンテキスト内の周囲のテキストにそれらを含めることです。

+ 		略語を参照してください。
3.1.5 読解力 (AAA) +

前期中等教育レベル（通常11〜14歳前後の子供）より高い読解力を必要とするテキストが提供される場合は、それを読むことができない人々を支援する補足説明資料を提供するか、あるいは前期中等教育レベルで書かれた代替バージョンを提供します。

+ +

これは、全ての主題が全ての人に理解されるべきであるという意味ではありませんが、書くスタイルは全ての人にアクセス可能であるべきです。 そうしない正当な理由や（例えば、詩的効果のための代替的なスタイル）、厳密なスタイルで記述する必要（例えば、W3C の仕様）がない限り、プログラミングチュートリアルのような技術文書でさえも、全てのコンテンツを前期中等教育レベルで書くことをお勧めします。

+ 		 
3.1.6 発音 (AAA) +

コンテンツを完全に理解するために必要な単語の発音へのアクセスをユーザーに与えるためのメカニズムを提供するべきです。

+ +

HTML5 の {{htmlelement("audio")}} 要素を使用して、正しい発音を含む音声ファイルを読者が再生できるようにするコントロールを作成できます。 そして、辞書のエントリーと同じように難しい言葉の後にテキストの発音ガイドを含めるのも理にかなっています。

+ 		+

動画と音声のコンテンツ、および英語辞書の発音ガイド（英語）を参照してください。

+
+ +
+

注: ガイドライン 3.1: 読みやすさ: テキストコンテンツを読みやすく理解しやすいものにする（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 3.2 — 予測可能: ウェブページを予測可能な方法で表示して操作させる

+ +

このガイドラインは、ユーザーインターフェースを直感的でわかりやすくすることに焦点を当てています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
3.2.1 フォーカス時 (A) +

コントロールや他のページ機能がフォーカスを受けたときに、ユーザーが混乱したり迷ったりするような方法でコンテキストを変更するべきではありません。

+ +

これは賢明なデザインの問題です — 人々はインターフェースによって驚かされることを望みません。 彼らは物事が直感的で期待通りに振る舞うことを望みます。 例えば、ナビゲーションメニューのオプションにフォーカスを置いても、表示されたページは変わりません — 表示が変わる前にアクティブにする必要があります。

+ 		{{domxref("GlobalEventHandlers.onfocus")}} には、役に立つ情報がいくつか含まれています。 役に立つ実装のアイデアについては、キーボード・アクセシビリティを取り戻すを参照してください。
3.2.2 入力時 (A) +

データがコントロールに入力されたとき、または設定が変更されたときに、コンテキストが予期せずに変更されるべきではありません。 差し迫った変更が発生する前に、ユーザーに警告や通知をする必要があります。

+ +

繰り返しますが、賢明なデザインを実装するべきです。 例えば、ボタンを押してアプリケーションが現在のビューを終了すると、ユーザーは必要に応じて作業内容を保存するかなど、この操作の確認を求められるべきです。

+ 		{{domxref("GlobalEventHandlers.oninput")}} はここで役に立ちます。
3.2.3 一貫したナビゲーション (AA) +

ナビゲーションのメニューやコントロールのスタイルと配置は、ウェブページの異なるページやビューの間で一貫しているべきで、例えば、新しい項目が追加されたとしても、既存の項目は同じ順序で現れるべきです。 ユーザーが変更を始めた場合、例えば、ナビゲーションのために異なる配色や位置を選択すると、それらの選択は全てのページにわたって尊重されるべきです。

+ +

繰り返しますが、賢明なデザイン — 全てのページやビューでナビゲーションコントロールを同じにします。

+ 		モダンなレイアウトのマークアップについては、ページレイアウトを参照してください。 便利なアクセス可能なナビゲーションメニューの例については、ボタンとしてのリンクのスタイリングも参照してください。
3.2.4 一貫した識別 (AA) +

同じ機能を持つコントロールやコンポーネントは、異なるページやビューでも同じように識別されるべきです。 例えば、世界旅行サイトの全てのページに表示される通貨換算機は、意味論的にもラベルの観点からもまったく同じであるべきです。

+ +

繰り返しますが、賢明なデザイン！

+ 		「ラベル」とは、テキストコンテンツ内の説明的な情報、または HTML フォームのラベルのことです。 詳細については、わかりやすいテキストラベルを参照してください。
3.2.5 要求に応じた変更 (AAA) +

ユーザーを混乱させたり、迷わせたりする可能性があるコンテキストの変更は、ユーザーから要求された場合にのみ行われるべきか、あるいは、ユーザーはそれらをオフにできるべきです。

+ +

現在のビュー（例えば、コンテンツやコントロール）を大幅に変更するものが必要な場合は、変更をいつ実行するかをユーザーに制御させます（例えば、どのページを表示するか、いつギャラリーの次の写真に進むか...）。

+ +

ページに回転木馬のようなものが必要な場合は、自動的に進まないようにするオプションを提供します。 可能であれば、そのような機能を避ける方が良いでしょう。

+ 		 
+ +
+

注: ガイドライン 3.2: 予測可能: ウェブページを予測可能な方法で表示して操作させる（英語）に関する WCAG の説明も参照してください。

+
+ +

ガイドライン 3.3 — 入力支援: ユーザーが間違いを避けて修正できるようにする

+ +

このガイドラインは、必要なときにユーザーが正しい情報を間違いを最小限にとどめて入力できるように手助けすることを中心にしています。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
達成基準基準への準拠方法実用的なリソース
3.3.1 エラーの識別 (A) +

ユーザーがフォームに入力したりオプションを選択したりするときに検出したエラーは、エラーに関連するフォームコントロールと共に、ユーザーに明確に報告するべきです。

+ +

状況に最適なものであれば、HTML5 フォームの検証機能や JavaScript を使用して、クライアント側のエラー検出と処理を実装することをお勧めします。 エラーを検出したら、ユーザーが入力を修正するのを助けるために、直観的なエラーメッセージをフォーム入力の横に表示するべきです。 スクリーンリーダーのユーザーの場合は、ARIA のライブリージョンを使用して、ページ上の変更についてユーザーに警告することができます。

+ +
+

注: サーバー側の検証は、クライアント側の検証と同時に常に使用するべきです。 クライアント側の検証は、無効にしたり回避したりするのが簡単すぎるため、単独では信頼できません。

+
+ 		包括的な検証情報についてはフォームデータの検証を、ライブリージョンに関する情報については WAI-ARIA: 動的コンテンツの更新を参照してください。
3.3.2 ラベルや指示 (A) +

データ入力が必要な場合は、明確な指示を提供するべきです。 単純な指示やプロンプトが必要な場合は、名前や年齢のような単一入力には {{htmlelement("label")}} 要素を使用したり、（生年月日や住所の要素のような）複数を一緒にした入力には {{htmlelement("label")}} と {{htmlelement("fieldset")}} / {{htmlelement("legend")}} を組み合わせて使用できます。

+ +

より複雑な説明が必要な場合は、常に説明段落を含めることも、フォームをより直感的にすることを試みる必要があるかもしれません。

+ 		わかりやすいテキストラベルと便利な例については HTML フォームの作成方法を参照してください。
3.3.3 エラーに対する提案 (AA) +

エラーが検出され、修正の提案が判明したら、セキュリティ上の問題（例えば、パスワード入力時）やコンテキスト上の問題（例えば、クイズアプリでの回答時）が発生しない限り、ユーザーにこれらの情報を提供してください（例えば、ユーザーが既に選らんだことがあるユーザー名についての選択肢の提案）。

+ +

このような場合、これが適切であれば、おそらく JavaScript とサーバー側の機能の組み合わせを使用して、エントリが正しいかどうかを確認し、正しくない場合は、ユーザーに実行可能な提案を提示できます。 そのような提案は、エラーメッセージのようなコンテキストの中で有用に表示されるべきです（3.3.1 を参照）。

+ 		まだチュートリアルの提案はありません。
3.3.4 エラー防止（法務、財務、データ） (AA) +

機密データの入力に関わるフォーム（法的契約、電子商取引、個人データなど）の場合は、少なくとも次のいずれかに該当するべきです。

+ +
    +
  • 提出は可逆的です。
    • +
  • データにエラーがないかチェックされ、ユーザーにはエラーを修正する機会が与えられます。
    • +
  • 最終提出の前に情報を確認し修正するためのメカニズムが利用可能です。
    • +
+ 		+

可逆的 — データを入力できるビューには、必要に応じてエントリを編集または削除することもできる同等のビューを提供します（例えば、Django ウェブフレームワークを参照）。

+ +

データのチェック — 3.3.1 で説明したように、クライアント側とサーバー側の検証を組み合わせてエラーを検出し、入力を修正できるようにユーザーに役立つメッセージを表示するべきです。

+ +

確認と修正 — 必要に応じて、（製品の購入のような）一連のフォームフィールドに入力するタスクを実行した後、ユーザーに確認画面を表示して入力内容を見直し、正しくないものは修正できるようにするべきです。 このパターンは、Amazon のような電子商取引サイトで一般的に使用されています。

+
3.3.5 状況依存ヘルプが利用可能 (AAA)フォームの完成と提出を助けるために、コンテキストの中で指示と他の適切な合図を提供してください。これは実際には単に 3.3.1 や他の同様の基準に基づいていますが、もっと徹底的なコンテキスト上のヘルプ情報とサービスを必要とします。 例えば、各ページのヘルプページまたはサービスへの専用リンクを提供し、正常に完了したらどのように見えるか示す例を提供します。
3.3.6 エラー防止（全て） (AAA)この原則は 3.3.4 に基づいており、機密データを含むものだけでなく、全てのユーザ入力状況に要件を拡張しています。繰り返しますが、3.3.4 を参照してください。
+ +
+

注: ガイドライン 3.3: 入力支援: ユーザーが間違いを避けて修正できるようにする（英語）に関する WCAG の説明も参照してください。

+
+ +

 

+ +

関連情報

+ + + +

 

-- cgit v1.2.3-54-g00ecf