3.3.4 Is error checking really enough?

[cliffbert]

3.3.4 says: 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:

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.

However, for important transactions, is it enough that "Data entered by the user is checked for input errors and the user is provided an opportunity to correct them"? It sounds like if there is an automated error checking feature, and if no errors are found, the transaction can then be submitted. This would allow such transactions to occur without the chance for additional review by the user, which could still be life-changing in a negative way.

As an example, the user correctly fills in all the data needed to buy a large amount of financial stocks: name, address, bank account or other payment method. All the data is correct; no errors are detected. As such, the system then submits the transaction without asking for confirmation or providing an opportunity to review the transaction before submission. But it would seem that we might still want Reversible or Confirmed to be required in such a situation.

[detlevhfischer]

@cliffbert I think you have a good point. I have always assumed the second option would imply some sort of presentation of input provided before the user commits to send (which is in fact like the third option). Bu this is not explicitly called for in option 2, and what kind of data checking goes on is not specified (like: if you transfer money and it is more than X, you are asked to confirm that this is the correct amount). This seems a loophole I'd like to see closed as well.

[avkuo]

Hm, how about something like... A/B/C/D below? I have bolded change ideas.

A:
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 two of the following is true:

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.

B:
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, the following is true:

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.

C:
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:

Reversible
Submissions are reversible.
Checked
Data entered and confirmed 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.

D: No change to AA, but provide further clarification in either [https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html] or [https://www.w3.org/WAI/WCAG22/quickref/#error-prevention-legal-financial-data]

[cliffbert]

Interesting! Option A seems best since not all such transactions are reversible. It also seems to cover options B and C (without requiring reversibility).

Option D: I don't see how it can be clarified to fix the problem without changing the requirements first.

[patrickhlauke]

Agree that there seems to be a loophole here in the "Checked" option. Oddly, if you interpret/change the "Checked" option to also mean that users are given the choice to correct things even if there aren't any errors, it then effectively covers the same ground as the "Confirmed" option, so it does seem like the idea was that these are separate concepts, so a simple handwave/explanation in the understanding won't be enough.

The understanding's intent does talk about:

Providing the ability to review and correct information gives the user an opportunity to detect a mistake before taking an action that has serious consequences.

Review and correct, not review or correct. Of course, this thin-slices the meaning a bit, but can be used initially to argue the point.

I fear this will need an actual normative change to the SC wording.

[bruce-usab]

@avkuo -- option D please, since that is only one which is a not normative change. Might you proposed something?

Consider an old school single page web form. All the fields are live, and a submit button at the end. How is that not enough for meeting "A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission" ?

[cliffbert]

But what if you have a multi-page form with error checking, but the error checking cannot check certain inputs for correctness?

e.g. The multi-page form can check certain things like your zip code or other verification info but it cannot check for the correctness of the amount to transfer or the account to transfer it to. Having not detected any errors, it submits the transaction.

So it may pass the error-checking requirement but still not provide enough safeguards, such as review.

[bruce-usab]

So it may pass the error-checking requirement but still not provide enough safeguards, such as review.

Agreed, that is a possibility. The way 3.3.4 is worded -- "at least one of the following is true" -- means there could be a gap.

There is a higher end-user expectation for a multi-page form than with a single-page form. I think that difference might be teased out in Understanding or with a new failure technique. Any volunteers?

@cliffbert -- I would be inclined to argue that your example does not meet 3.3.4. It is a multi-page form, so there is no good reason why the process would not include an additional confirmation step on the transfer. OTOH, the developer might say that they meet "Checked" because the system checks for a valid amount and account number (and would have notified the end-user if there was a problem).

[patrickhlauke]

OTOH, the developer might say that they meet "Checked" because the system checks for a valid amount and account number (and would have notified the end-user if there was a problem).

exactly this. that's the gap, since developers can (and will) claim that, and with the current normative wording, they'd be right (regardless of any soft / best practice "end-user expectation" we can nudge developers towards in the understanding doc)

[avkuo]

@avkuo -- option D please, since that is only one which is a not normative change. Might you proposed something?

Consider an old school single page web form. All the fields are live, and a submit button at the end. How is that not enough for meeting "A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission" ?

yes, I am noodling on what an option D might be for comparison