法的義務・金銭的取引・データ変更・回答送信のエラー回避:
達成基準 3.3.4 を理解する
この達成基準の意図
この達成基準の意図は、障害のある利用者が元の状態に戻すことのできないタスクを行った際、ミスをしたことによる重大な結果を未然に防ぐことができるように することである。例えば、払い戻し不可の航空券の購入、又は証券取引口座での株購入の注文は、重大な結果につながる金銭的な取引である。利用者が発着日を間違えれば、その利用者は交換できない誤った日付の航空券を購入したことになってしまう。利用者が購入する株式の数を間違えると、意図した数よりも多くの株式を購入したことになってしまう。どちらのミスも、すぐに処理される取引であり、後から変更することはできないものであり、また非常に高価である。同様に、旅行サービスのウェブサイトにある旅行履歴のように、後から使用する必要のあるデータベースのデータを無意識に修正又は削除してしまった場合、そのエラーを元の状態には戻せないことがある。また、試験のデータもこの達成基準に当てはまる。なぜなら、試験の妥当性を確保するためには、利用者は一度送信した回答を修正することができないからである。そのため、利用者が自分の送信内容に誤りがないかどうかを確認できるようにする必要がある。
障害のある利用者は、ミスをしてしまう可能性が高い。読字障害のある利用者は、数字と文字を取り違えてしまうことがあるし、運動障害のある利用者は間違ってキーを押してしまうことがある。元の状態に戻せるようにすることによって、利用者が重大な結果につながる恐れのあるミスを修正できるようになる。また、入力内容を確認して修正できるようにすることで、重大な結果につながることをしてしまう前に、利用者がミスに気づくことができるようになる。
利用者が自分で制御可能なデータというのは、利用者がアクセスすることを想定したデータのことを指す（例えば、ユーザーアカウントの氏名、住所など）。アクセスログ及び検索エンジンの監視データのようなものを指すわけではない。
達成基準 3.3.4 の具体的なメリット
ミスによる重大な結果を未然に防ぐ手段を提供することによって、ミスをする可能性の高い障害のある利用者すべてに役立つ。
達成基準3.3.4 の事例
注文内容の確認
ある小売店がウェブでオンラインショッピングのサービスを顧客に提供している。注文が送信されると、利用者が注文内容に間違いがないかを確認できるように、注文した商品、各商品の数、送り先の住所、支払方法などの注文情報が表示される。利用者は、注文内容を確認したり、変更したりすることができる。
株式売買
ある金融サービスのウェブサイトで、利用者は株をオンラインで売買できる。利用者が株の売買の注文を送信すると、システムは市場が開いているかどうかを確認する。時間外だった場合は、利用者にその取引が時間外取引になることを知らせて、通常の取引時間外であることに伴うリスクについても伝える。そして、利用者はその注文をキャンセルするか、確認することができる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
（まだ文書化されていない）
達成基準3.3.4 の実装方法及び不適合事例 - 法的義務・金銭的取引・データ変更・回答送信のエラー回避
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされている場合にのみ、次に挙げる実装方法により、この達成基準を満たすことができる。
達成基準を満たすことのできる実装方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の実装方法（又は、実装方法の組合せ）がある。
達成基準 3.3.4 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能、または効果的であるとは限らない。
どのような不可逆のアクションが起きそうになっているかを利用者に知らせる（リンク追加予定）
SCR18: クライアントサイドのバリデーション及びアラートを提供する (Scripting)
エラーを含むフィールドにフォーカスを置く（リンク追加予定）
プルダウンメニューの各項目の最初では、同じ用語や同じ文字の組み合わせの使用を避ける（リンク追加予定）
達成基準 3.3.4 のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準 3.3.4 に適合していないとみなした、よくある不適合事例である。
（今のところ、文書化されている不適合事例がない）
重要な用語
- ウェブページ
単一の URI から HTTP で得たリソース（埋め込まれていないリソース）と、 ユーザエージェントがこのリソースと一緒にレンダリングすることを意図したりレンダリングに用いたりするその他のリソース（埋め込まれているリソース）を合わせたもの。
注記 1： どのような「その他のリソース」（埋め込まれているリソース）も主たるリソース（埋め込まれていないリソース）と一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされる必要があるわけではない。
注記 2： このガイドラインの適合範囲に含まれる対象となるウェブページは、「埋め込まれていない」リソースでなければならない。
事例 1： すべての埋め込まれている画像とメディアを含んだウェブリソース。
事例 2： Ajax を用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しており、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンク又はボタンがあるが、ウェブページ全体の URI は変わらないもの。
事例 3： カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツのモジュール一式から表示させるコンテンツを選択できるようなもの。
事例 4： ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
- メカニズム
結果を得るためのプロセス又は手法。
- 入力エラー
利用者が提供した情報で、受け付けられないもの。
注記： 以下のものが含まれる：
ウェブページでは必須とされているが、利用者が入力を省略した情報
利用者が入力したが、要求されたデータ形式あるいは値ではない情報
- 利用者が自分で制御可能
利用者によってアクセスされるためのデータ。
注記： これは、インターネットのログや検索エンジンの監視データのようなものは指していない。
事例 ： ユーザアカウントのための氏名と住所のフィールド。
- 法的な義務
法的に拘束力のある義務あるいは利益が発生する取引。
事例 ： 結婚許可証、株取引（金銭上および法的）、遺言、ローン、採用、軍隊への入隊登録、あらゆる契約、など