The next standard we’ll explore in our series on understanding WCAG 2.0 is 3.3.4 Error Prevention. This standard is required for WCAG level AA compliance, which is part of what Section 508 requires. Here’s the complete text (it’s a long one):
3.3.4 Error Prevention (Legal, Financial, Data): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
Here’s the idea: sometimes users, especially those with disabilities (and me, as you’ll see in a minute), submit forms either by accident or without fully understanding what happens when the form is submitted. Imagine, for example, someone with motor control issues who accidentally presses enter early while filling out a form, submitting it. This standard asks us to make sure that one of the three things in that list applies to the form.
There are a number of circumstances where we don’t need to do anything at all. For example, say we have a web form in our ERP that lets us set an address. As long as changing the address again is easy (for example, by filling out the form again), and we’re shown what the new address is after submission (either as a confirmation, or just with a page reload on submit), then we’re in good shape.
But we need to look for web forms that are not easily reversible. For instance, let’s look at a situation which may or may not have happened in my life about ten years ago. I was trying to pay a bill online. When paying it, I misplaced a decimal point, and paid ten times as much as I owed (like this: $3000.0). The system processed my payment without complaint, overdrawing my checking account, bouncing a $2.00 check at the library, and leading to so very many bank fees. A simple confirmation page (which, to be fair, they’ve added), or even better, a confirmation page that warned me my payment only had one 0 after the decimal point, would have saved me a lot of grief.
What’s tricky about this accessibility requirement is that most of us rely on third party services for these kinds of legal, financial, and data programs. We buy our ERP system and payment processing systems from vendors, rather than create them at home. Even though we’re not doing development ourselves, we’re still responsible for ensuring our systems are complaint. If your system is receiving updates, and compliance won’t be available by January 18th, 2018, you may need to file a bug with your vendor.
If you’d like to know more about this method, check out these examples and techniques.
Interested in more? Check out the listing of all the posts in this series.