確認も取り消しもできずに支払いが確定するチェックアウト

ある劇場の予約ページは、二つのことを尋ねます。公演が11月13日（金）か11月14日（土）か、そしてチケットの枚数です。1枚24ドルです。利用者はログインしているので、カードが保存されています。欄の下には、チケットは返金も交換もできないという一文と、「今すぐ支払う」ボタンがあります。

金曜日のチケットを1枚買うつもりでしたが、途中で手が滑って、枚数が2になりました。「今すぐ支払う」を押すと、その場で48ドルが請求され、次のページには「予約が完了しました」と表示されます。変更する方法も、取り消す方法もありません。間違いは画面上にありましたが、確定する前にそれを示すものは何もありませんでした。

達成基準3.3.4「エラー回避（法的、金融、データ）」はレベルAAです。法的な義務や金融取引が発生するページ、利用者が管理するデータを変更・削除するページ、テストの回答を送信するページでは、次の三つのうち少なくとも一つが必要です。送信を取り消せること。入力エラーがチェックされ、修正できること。確定する前に、情報を確認し、確定し、修正する手段があること。このフォームは、どれも満たしていません。

購入について、W3Cが十分な達成方法として挙げるのは、送信の前に回答を確認して修正できる段階（G98）、注文後に変更や取り消しができる期限の明記（G164）、送信ボタンに加えた確認のチェックボックス（G155）です。入力のチェックは基準の二つ目の方法ですが、対象は入力エラー、つまり値が欠けている場合や、フォームが受け付ける範囲外の場合です。2枚のチケットも違う公演日も正しい選択で、どんなチェックでも見つけられません。W3Cは、この基準ではクライアント側の検証を推奨事項としてしか挙げていません。検証は3.3.1と3.3.3のためには大切ですが、意図しない正しい選択への対策にはなりません。

返金についての一文も役に立ちません。間違いが取り返せないことは伝えても、間違いを見つける機会は与えていないからです。

その負担は、いちばん負担に耐えにくい人にかかります。家計に余裕のない人にとって、間違った予約は何かを我慢することを意味し、例外を頼むには電話かメールが必要で、それ自体がまた別の障壁になります。

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

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

• 届く範囲・力が限られる 手のふるえがある人は、＋を二度押したり、一つ下の日付をタップしたりしやすく、その間違いがそのまま請求されます。
• 手の操作が限られる 音声入力は「2枚」を「に、枚」のように聞き違えることがあり、スイッチは目的の選択肢を一つ通り過ぎることがあります。読み返しがなければ、ソフトが何を選んだかを銀行の明細で知ることになります。
• 言語・認知・学習の能力が限られる 記憶、注意、読むことに困難がある人や、計算に困難がある人は、違う公演日を選んだり合計を読み違えたりすることがあり、確定する前に、内容を分かりやすく並べて見直す必要があります。
• 視覚を使わない スクリーンリーダーの利用者はフォームを一つずつ聞いていくため、いくつも前の欄で選んだ日付は、「今すぐ支払う」の前に二度と読み上げられません。
• 視覚が限られる 拡大して使う人は一度に数個の欄しか見えないため、日付、枚数、「支払う」ボタンが同時に画面に入ることがありません。

各欄にはラベルがあり、ボタンには名前があり、ページは自動チェックをすべて通ります。注文を確認できるか、取り消せるかは、複数のページとその裏のサーバーにまたがっており、スキャナーが実際のサイトで「支払う」を押すことはありません。EaseWebの診断は、支払いや注文を行うフォームを人の確認に回しますが、送信はしないため、サイトが三つの方法のどれを使っているか、そもそも使っているかは分かりません。コーディングアシスタントにこのフォームの「エラーを防いで」と頼むと、数値の欄にminとmaxを加えます。0枚や99枚は防げても、2枚は防げません。