見つからず理由も分からない無効なボタン

購入手続きの最後に、「利用規約に同意する」のチェックボックスと、その下に「注文する」ボタンがあります。チェックを入れるまで、ボタンは灰色です。マウスを使う見える人なら、チェックボックスが原因だと推測できるかもしれません。それ以外の人には分かりません。

あるサイトでは、ボタンはクラスで灰色にしているだけです。スクリーンリーダーの利用者がTabで移動すると「注文する、ボタン」と読み上げられ、使えるように聞こえます。クラスがポインターの操作を止めているのでクリックは効きませんが、Enterではフォームが送信され、ページの上にエラーが出て戻ってきます。別のサイトでは、ボタンに disabled 属性があります。キーボード利用者がTabを押すと、チェックボックスから下の「配送と返品」のリンクへ直接移り、ボタンには一度も止まりません。Tabで移動するスクリーンリーダーの利用者にはボタンがあることも伝わらず、何が足りないのかもページのどこにも書かれていません。

何かを待っている操作では、どれも同じことが起きます。入力が終わっていない手順の「次へ」、変更のないフォームの「保存」、サイズを選ぶ前の「カートに入れる」、空のメッセージの「送信」などです。

達成基準4.1.2では、操作部品の状態をプログラムで取得できることが求められます。使えないことも状態の一つです。ボタンが使えない見た目なのにコードが何も伝えていなければ、支援技術は普通のボタンとして読み上げ、キーボードでも動いてしまいます。これが、この達成基準の不適合です。

disabled 属性のあるボタンは状態を伝えるので、4.1.2は満たします。それでも利用者は先に進めません。ブラウザーはそのボタンをTabの移動先から外して薄く描き、WCAGも無効な部品のコントラストを求めないため、ボタンを見つけられないことも、名前を読めないこともあります。このトピックが求めるのは達成基準より少し先で、部品を見つけられ、無効な理由が分かることです。

この問題は、ほかの欄をすべて入力し終えた、手続きの最後に起きます。スマートフォンの長いフォームでは、チェックボックスが画面の上に隠れ、見える人にも灰色のボタンしか見えないことがあります。

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

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

• 手の操作が限られる キーボード利用者は、マウスには反応しないのにEnterでは送信されるボタンに着くか、無効なボタンを素通りするため、フォームを送れる状態かどうかが分かりません。
• 視覚を使わない スクリーンリーダーの利用者には、灰色のボタンが「注文する、ボタン」と読み上げられるか、Tabで移動すると無効なボタンにまったく出会わず、理由も読み上げられません。
• 視覚が限られる 無効なボタンは薄く描かれ、コントラストも問われないため、弱視の人は名前を読めず、送れる状態に変わったことにも気づかないことがあります。
• 言語・認知・学習の能力が限られる 理由のない灰色のボタンでは、どの欄が原因かを自分で探す必要があり、フォームをあきらめる人もいます。

axeなどのツールは、ボタンに名前と役割があるかを確かめます。クラスで灰色にしたボタンにはどちらもあるので、通過します。無効なボタンはコントラストのチェックから意図的に外され、理由が示されているかを確かめるものもありません。コード生成AIは、状態を直すために disabled 属性を使うことが多く、ボタンは届かないまま、理由もないまま残ります。aria-disabled を使う場合は、操作を止めるのを忘れがちで、「使用不可」と読み上げながら送信できてしまいます。フォームをTabで移動し、入力が終わる前にボタンを押して、何が伝わるかを確かめてください。