openameba/a11y-guidelines

[4.1.2]「HTMLの要素や属性を正しい役割で使用する」のタイトル・内容の再考

tokimari opened this issue · 1 comments

https://a11y-guidelines.ameba.design/4/1/2/

#262 と同様、HTMLに限定した記述になっていること、タイトルや内容から意味が理解しづらいことから、再考したいです。
4.1.1に準拠しても賄いきれない、「カスタムコントロール」を用いる場合に必要になる項目です。

カスタムコントロール(その言語の提供していない独自のユーザーインタフェースコンポーネント)を実装する場合、支援技術などのユーザーエージェントがそのコンポーネントを正確に解釈して実行できるよう、AccessibilityNameとroleを定義し、確認する

みたいなことを考えています。(もうちょっとやさしいにほんごで・・・)

ですので、この項目については事例すら怪しいと思っています(今更)
たとえばカルーセルやタブコンポーネントなど、WAI-ARIAを必要とするようなコントロールを想定しています。
実際の開発に近しい事例を掲載したいです。

ちょっとこれはじっくり考えたい・・ご意見募集です

タイトル案:

カスタムコントロールにAccessibilityNameとroleが適切に付与されている

概要案:

カスタムコントロールを実装する場合、支援技術などのユーザーエージェントがそのコンポーネントを正確に解釈して実行できるよう、AccessibilityNameとroleを付与し、支援技術を用いて動作確認をする。

カスタムコントロールとは カスタムコントロールとは、その言語の提供していない独自のユーザーインタフェースコンポーネントのことを指す。例えばタブ、 `` を使わないチェックボックスなど。カスタムコントロールは、開発者が機能をスクリプトで実装する必要がある。

具体例、実装方法案:
すみませんが全て書き直しでいきたいです・・!:bow::bow:
具体例としては、タブが一番分かりやすいかなと思ったのですが、spindle-uiにはないんですよね・・
SegmentedControlとかかな・・
https://ameba-spindle.web.app/?path=/docs/segmentedcontrol--large

テスト・チェック方法案:
今パッと浮かんだのがこんな感じで・・

Web:

  1. AccessibilityTree(ユーザ補助ツリー)のRole(役割)、Name欄に値が適切に反映されていることを確認する
    image
  2. Lighthouseなどのアクセシビリティ検証ツールで、不適切なroleの付け方をしていないかを確認する
  3. スクリーンリーダーなどの支援技術で操作し、想定通りの読み上げをされることを確認する

linterとか他に追加してもよいかも