W3 WCAGクイックリファレンスガイドを読んでいます ここにあります
WAI ARIA WCAGコンプライアンスのために表示する項目を選択するオプションがあります-WAI-ARIAはWCAGコンプライアンスに必要かどうか?私には分かりません。
WCAGレベルのAAコンプライアンスを満たすサイトを構築するのは初めてであり、それが適切に行われていることを確認する必要があります:)
番号。
要件(つまり、ガイドライン)はこのドキュメントにのみあります。
Webコンテンツアクセシビリティガイドライン(WCAG)2.0
W3C勧告2008年12月11日
ガイドラインは通常、テクノロジーに中立で抽象的なものであるため、 HTMLだけでなく、Webコンテンツ全般に適用されます 。したがって、requireringWAI-ARIA属性は意味がありません。
ただし、ガイドラインに準拠するために、できます(ただし、そうする必要はありません!) WCAG 2.0のテクニックを使用してください 。特定のテクニックがWAI-ARIA属性に依存している場合があります。ただし、これも規範的ではありません。通常、ガイドラインにはいくつかの適用可能なテクニックがあり、ほとんどの場合、テクニックで説明されていないソリューションを使用する可能性があります。
したがって、ガイドラインに従う必要があり、対応するテクニックがWAI-ARIAを使用するソリューションを説明している場合、必ずしもそれを使用する必要はありません。別のテクニック(WAI-ARIAを使用しない)または文書化されていないソリューション )canもガイドラインを満たす可能性があります。もちろん、特定の制限によってすべてのケースで代替ソリューションが許可されない場合があるため、WAI-ARIAを使用したソリューションが唯一の可能なソリューションである場合があります。
私はこれがすでに回答されていることを知っていますが、別の質問から参照されたので、私はこの情報をここに貼り付けて、より最近の読者のために考えました。上記の答えを補足します。
適切な意味論的および構造的HTMLを使用している場合、おそらくARIAは必要ありません。間違った要素(壊れたライブラリやフレームワークなど)を使用する必要がある場合は、使用する必要があるかもしれませんが、それは開始する方法ではありません。
いつものように、コンテキストが重要であり、包括的ステートメントが常に適用されるわけではありません。
役に立つ場合、ARIAの使用には3つの(5つの)「規則」があります(これらは推奨事項ですが、最良の効果を得るために規則として扱う必要があります)。
ARIAの使用に関する最初の規則 :できる場合ネイティブHTML要素[ HTML51 ]または属性とセマンティクスと動作を使用できます要素を転用してARIAの役割、状態、またはプロパティを追加してアクセス可能にする代わりに、[そうすること]の代わりに、組み込み済みが必要です。
ARIA使用の2番目のルール :本当に必要な場合を除いて、ネイティブのセマンティクスを変更しないでください。
ARIA使用の3番目のルール :すべてのインタラクティブARIAコントロールはキーボードで使用できる必要があります。
ARIA使用の4番目の規則 :visiblefocusableで_role="presentation"
_または_aria-hidden="true"
_を使用しないでください素子。 visiblefocusable要素でこれらのいずれかを使用すると、一部のユーザーは「何もない」に焦点を当てることになります。
ARIA使用の5番目のルール :すべてのインタラクティブ要素には アクセス可能な名前 が必要です。インタラクティブ要素は、そのアクセシビリティAPIアクセス可能な名前(または同等の)プロパティに値がある場合にのみ、アクセス可能な名前を持ちます。