type のフォーム画面のアクセシビリティを考える
Webアクセシビリティの勉強をしています。今回は type の新規登録フォームを検証してみます。
チェック1：axe DevTools で機械的なチェック
axe は、オープンソースのアクセシビリティ検証ライブラリーです。Lighthouse のアクセシビリティ監査にも、この axe のエンジンが使われています。今回は、axe の DevTools を使ってみます。freee のアクセシビリティー・ガイドラインにも紹介されていたから、たぶんよいものなんだと思います。
Chrome の DevTools から簡単に使うことができます。「Scan ALL of my page」するだけです。
Critical の警告が出たのは、3点。フォームのラベル要素指定がありませんでした。確かに、このようなHTMLのつくりでは、どのインプット項目がどのラベルなのかを構造的に読み取ることができません。
画面表示を見ることができる場合、フォーム・コントロールの目的は周囲のテキストとの位置関係から容易に推測することが可能な場合も多いですが、スクリーン・リーダーを利用している場合、位置関係を正確に把握することが困難な場合も多く、結果としてフォーム・コントロールの目的を判断することも困難になってしまいます。フォーム・コントロールと周囲のテキストを明示的に関連付ける（ラベル付けする）ことによって、スクリーン・リーダーなどの支援技術は、そのフォーム・コントロールの目的をユーザーに伝えることができます。
フォーム・コントロールのラベル付けの必要性 — freeeアクセシビリティー・ガイドライン Ver. 202110.1 ドキュメント
チェック2：フォームがキーボードのみで操作可能かチェック
WCAG 2 への配慮を考えると、キーボードのみでフォーム操作が完結できることが望ましいと考えられます。
type では、以下の部分がTabキーでの操作ができませんでした。これはアウトです。
- 性別選択ボタン
- メール受け取りのチェックボックス
- スカウト受け取りのチェックボックス
会員登録ボタンは、フォーカス時に見た目の変更がなく、フォーカスしているのかどうかわかりづらくなってしまっている点が惜しかったです。`:hover` でビジュアル変更はよくやりますけど、アクセシビリティのためには `:focus` または `:focus-visible` でも何かしらの効果を入れてあげたいです。