入力の途中で読まれてしまうか、まったく読まれないエラーメッセージ

紅茶の店のチェックアウトで、最初にメールアドレスを、その下に電話番号を尋ねています。アドレスはブラウザー側で確かめるため、誤りがあると、注文を送る前に欄の下へ「メールアドレスを「[email protected]」のような形式で入力してください」と表示されます。画面が見える人には、このメッセージが赤い文字で現れます。スクリーンリーダーの利用者に何が聞こえるかは、確認がいつ動くかによって変わります。この店のフォームは、よくある二通りの作り方の両方で作られています。

一つ目の作り方では、キーを押すたびに欄を確かめ、メッセージをアラートとして送ります。スクリーンリーダーの利用者が「s」と打つと、その文字に続けて、重なるように「メールアドレスを「[email protected]」のような形式で入力してください」と読まれます。まだ1文字しか打っていません。数文字先の「sam@s」はアドレスとして正しいためメッセージは消えますが、「sam@shop,」でまた誤りになり、そのあとに打つ文字に重なって、アラートがもう一度読まれます。今打っている途中のアドレスへのエラーなのか、打とうとしたアドレスへのエラーなのか、聞き分けられません。

二つ目の作り方では、欄を離れたときにだけ確かめ、メッセージを欄の下のただの段落に出します。同じ利用者がドットの代わりにカンマを打って「sam@shop,com」と入力し、Tabキーを押します。スクリーンリーダーは「電話番号（任意）、編集テキスト」と読むだけです。エラーは画面上に出ていますが、場所はもう離れた欄の下です。戻っても「メールアドレス、編集テキスト、必須、sam@shop,com」と読まれ、何かがおかしいことは伝わりません。注文が送れなくなって、初めて気づきます。

フォーカスを動かさずに現れるエラーは、ステータスメッセージです。達成基準4.1.3は、操作の結果や「エラーの存在」を伝える変化をステータスメッセージと定義し、フォーカスを受け取らずに役割やプロパティによって利用者へ伝えられることを求めています。Understandingのページは、それを「作業を不必要に妨げない形で」行うべきだとし、重要でも急ぎでもない内容への role="alert" や aria-live="assertive" を失敗例に挙げています。一つ目の作り方では、キーを押すたびに確認が動き、メッセージが変わるたびにアラートへ書き込まれます。入力途中のアドレスへのエラーは、重要でも急ぎでもありません。利用者がこれから変えるはずの状態を伝えているだけです。ブラウザーはページの求めるとおりに動いています。アラートの領域は文言が変わればすぐに読まれ、利用者が単語を打っている途中かどうかは考慮されません。

二つ目の作り方では、メッセージを役割のない p に書き込むため、エラーが現れても何も読まれないステータスメッセージになり、今度は読まれないという理由で4.1.3を満たしません。達成基準3.3.1の目的も果たせません。3.3.1は、自動的に検出した入力エラーについて、エラーのある項目を特定し、エラーを文字で説明することを求めています。Understandingのページは、その目的を、エラーが起きたことに利用者が気づき、何が誤っているかを判断できるようにすることだとしています。この例では説明はあるものの、欄の下に表示された文字でしかありません。欄と結び付けるものがなく、aria-invalid も aria-describedby もないため、欄は誤りのないものとして読まれます。Understandingのページは、こうしたマークアップを3.3.1の要件とはしていません。とはいえ、それもライブリージョンもなければ、エラーを知る方法は欄の先を1行ずつ読み進めることだけです。Tabキーで問題なく進めたように思えたあとに、そうする人はいません。

この問題に出会うのは、チェックアウトや会員登録のフォームです。スマートフォンで使われることが多く、欄の下のエラーが画面キーボードに隠れることもあります。

10グループ中2グループに影響

• 全盲 （影響あり）
• 弱視 （影響なし）
• 色覚 （影響なし）
• ろう （影響なし）
• 難聴 （影響なし）
• 発話 （影響なし）
• 手の操作 （影響なし）
• 筋力・可動域 （影響なし）
• 認知 （影響あり）
• 光過敏 （影響なし）

• 視覚を使わない スクリーンリーダーの利用者は、アドレスを打ち終える前に、入力した文字に重なってエラーを聞かされます。打ち進めるうちに正しくなったり誤りに戻ったりするたび、また読まれます。欄を離れたときに確かめる場合は何も聞こえず、欄に戻っても、エラーのない欄として読まれます。
• 言語・認知・学習の能力が限られる 1文字目でエラーが現れ、入力のあいだに出たり消えたりすると、まだしていない誤りを指摘されたことになり、入力していた内容から注意がそれてしまいます。

スキャンはフォームを読み込み、ラベルの付いた欄と、その下の空の段落を見つけます。何も入力しないため、エラーが現れる様子は見えず、それがいつ現れるかも分かりません。EaseWebの監査は実際に入力します。メール欄に4文字を打ってTabキーを押し、キーを押しているあいだにフォーム内のライブリージョンへ書き込みがあったときや、Tabキーのあと、どのライブリージョンにも入っていない新しい文字がフォームに現れたときに、人が確かめる項目として挙げます。その文字が欄のエラーかどうか、スクリーンリーダーで何が読まれるかは、人が確かめます。一つ目の作り方では、スキャンには aria-invalid、aria-describedby、role="alert" がそろった、正しく見えるマークアップが見つかることさえあります。React Hook Formのアクセシビリティの例が示すのもこの形で、フォームのエラーをアクセシブルにするよう頼まれたAIアシスタントが、この形を加えることもあります。問題はコードが動くタイミングにあり、スクリーンリーダーを有効にして欄に入力して、初めて分かります。