search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
140 stars 55 forks source link

Error Prevention #33

Closed lseeman closed 7 years ago

lseeman commented 7 years ago

Current versions of SC and Definitions

Error Prevention

Current:

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)

  1. Reversible: Submissions are reversible.

  2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

  3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Proposed:

@@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, that submit user test responses or submit or store important information each of the following is true:

  1. Modify: A simple mechanism is provided to allow the user to assess and correct mistakes, including mistakes that might not be automaticaly identified. The user can repair information via clearly labeled actions and get back to the place they were at, in one clearly labeled action without unwanted loss of data.

  2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

  3. Confirmed: A summary is provided before submitting important information and the user is notified when they are about to submit the final information.

  4. Time frames for cancelling transactions can be programmiticaly determined@@

Suggestion for Priority Level

A

What Principle and Guideline the SC falls within.

Principle 3, Guideline 3.3 - Update to SC 3.3.4

Description

The intent of this Success Criterion is to give users with cognitive disabilities mechanisms for avoiding serious consequences that are the result of a mistake made when performing an action that they are unable to reverse or finding tasks too difficult to be managed correctly.

Benefits

People with cognitive impairments make many more mistakes in filling out forms than the general population. When mistakes cannot be easily corrected they can not complete the task.

For example, a user with a memory impairment may not remember that they have already added an item to their shopping cart and may add the item a second time within the same online session. They may confused the dates when booking a trip, or made numerous other mistakes. It is essential that people with cognitive impairments have the opportunity to check their work AND can fix their mistakes easily.

For people with cognitive disabilities, a process being theoretically reversible is not enough. Typically the process of reversing a transaction is too complex for them to manage without help. They may not have access to that help meaning they have to live with all the mistakes they have made. For example, when inputting credit card information incorrectly these mistakes can be devastating.

In addition if the process of correcting mistakes is too difficult, users may give up, either losing the transaction or buying unwanted items because of the one required item.

The effect of this happening multiple times is devastating and can result in a large number of users with disabilities avoiding using the Internet for many tasks.

The presence of a simple mechanism for modifying the number of items in the shopping cart at various times in the checkout process can significantly reduce the chances of an unwanted purchase by giving the user the ability to change the quantity associated with a product. In the same scenario, a summary of the order, including product quantities and associated costs, along with a notification prior to final order submission, gives the user the chance to identify any errors and confirm the choices made or make changes to the order.

In the example given, a summary of the purchase would show both the error in quantity as well as a higher then expected order total. (See Working Group Notes). In some cases a user may realize that a mistake has been made after the final submission of data.

Implementing timeframes for canceling transactions which are programmatic determined helps the user understanding the amount of time the user has to cancel a transaction and makes them less susceptible to scams.

Users with cognitive disabilities can make errors for a variety of reasons including problems with language, memory related disabilities, focus and attention related disabilities and attention with details. Because errors may occur without being noticed at any point in a process containing multiple steps, this Success Criterion helps users review and make corrections to input prior to final submission.

For example, a user with ADHD purchasing a travel ticket on a website may have poor attention to detail, low attention span and may be easily discouraged. As the user goes through the order completion flow, manual errors such as an incorrect billing address are not captured until all of the information is submitted. The successful completion of the order relies on the information provided at multiple steps in the process. While there may be significant error controls, for instance format correction and default values for the travel departure and arrival dates, if the manually inputted details are incorrect, the payment will not be processed correctly. An error due to lack of accuracy or attention to detail such as an incorrect street number or zip code in the billing address will result in a declined payment. If a summary is not provided before submitting the final order or the ability to go back in the process to make correction is not provided or is not clear the user may not understand the reason for the declined payment and abandon the order.

Related Resources

Resources are for information purposes only. No endorsement is intended or implied.

issue papers

Testability

If the website causes 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, confirm that:

  1. A sufficient technique is used for Checked, Confirmed and Modify or
  2. The submission can be Checked, Confirmed and Modify: via clearly labeled actions and get back to the place they were at, in one clearly labeled action without unwanted loss of data. AND

AND

  1. A sufficient technique is used for timeframes which are programmiticaly determined

Techniques

Sufficient technique for Checked, Confirmed and Modify

From WCAG

Sufficient technique for timeframes

  1. Using semantics for identifying timeframes (uses new semantics)
  2. Using RDFA for identifying timeframes (more difficult bu now supported)

Working groups notes

Thad - The SC requires pre-confirmation but what about post confirmation for example an email confirmation with the potential to modify or cancel a transaction within a given amount of time

rachaelbradley commented 7 years ago

I will sign up as SC manager for this issue.

joshueoconnor commented 7 years ago

Thanks @rachaelbradley I've added this to https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1#Current_SC_Managers

rachaelbradley commented 7 years ago

The revised SC proposed here: 1) Expands the application of 3.3.4 to data submitted and stored 2) Changes the priority from AA to A, and 3) Replaces Reversible with Modify 4) Redefines Confirmed 5) Adds timeframes

It references "important information" which is defined as: 1.information the user may need to complete any action or task including an offline task. 2.information the user may need to know related to safety, risks, privacy, health or opportunities.

Sufficient techniques Checked Existing technique G98 still applies Inline and point of submission data validation mechanisms are important but may not be sufficient

Confirmed •Provide a summary before submitting important information.

Modify •Provide a summary before submitting important information. Provide clear labels that allow users to repair information and return to the summary within one click. •Provide clickable breadcrumbs that allow users to see the previous steps, go back, and change them.

If this is treated as a replacement to 3.3.4, then we may want to consider including Reversible. If we treat this as an extension of 3.3.4, perhaps we can consider the following wording (I think the end items expand the scope such that it already includes all other areas of 3.3.4):

3.3.4a Error Prevention: For Web pages that allow the user to submit or store important information each of the following is true:

1.Modify: A simple mechanism is provided to allow the user to assess and correct mistakes, including mistakes that might not be automatically identified. The user can repair information via clearly labeled actions and return to the place they identified the error, in one clearly labeled action without unwanted loss of data.

2.Confirmed: A summary is provided before submitting important information and the user is notified when they are about to submit the final information.

3.Time frames for cancelling transactions can be programmiticaly determined@@

lseeman commented 7 years ago

I think we need to make it a stand alone

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Tue, 31 Jan 2017 03:59:22 +0200 rachaelbradley<notifications@github.com> wrote ----

The revised SC proposed here: Expands the application of 3.3.4 to data submitted and stored Changes the priority from AA to A, and Replaces Reversible with Modify Redefines Confirmed Adds timeframes It references "important information" which is defined as: 1.information the user may need to complete any action or task including an offline task. 2.information the user may need to know related to safety, risks, privacy, health or opportunities. Sufficient techniques Checked Existing technique G98 still applies Inline and point of submission data validation mechanisms are important but may not be sufficient Confirmed •Provide a summary before submitting important information. Modify •Provide a summary before submitting important information. Provide clear labels that allow users to repair information and return to the summary within one click. •Provide clickable breadcrumbs that allow users to see the previous steps, go back, and change them. If this is treated as a replacement to 3.3.4, then we may want to consider including Reversible. If we treat this as an extension of 3.3.4, perhaps we can consider the following wording (I think the end items expand the scope such that it already includes all other areas of 3.3.4): 3.3.4a Error Prevention: For Web pages that allow the user to submit or store important information each of the following is true: 1.Modify: A simple mechanism is provided to allow the user to assess and correct mistakes, including mistakes that might not be automatically identified. The user can repair information via clearly labeled actions and return to the place they identified the error, in one clearly labeled action without unwanted loss of data. 2.Confirmed: A summary is provided before submitting important information and the user is notified when they are about to submit the final information. 3.Time frames for cancelling transactions can be programmiticaly determined@@ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

joshueoconnor commented 7 years ago

@rachaelbradley Based on the proposed revision above - if this is ready for a Pull Request please do so and let me know.

rachaelbradley commented 7 years ago

@joshueoconnor I added "Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them." because this seems to supersede the existing 3.3.4. The pull request is available.

mbgower commented 7 years ago

I feel like the existing 3.3.4 Error Prevention covers most of what is desired here, without a lot of the extra verbage. If there are problems with the existing guidance, small addendums should address the problem. The main addition is the time language, and I don't entirely understand the scenario it is trying to prevent or enforce.

Modify: A simple mechanism is provided...including mistakes that might not be automatically identified

This “Modify” is just the existing Confirm step with a bit more qualification on ease. I'm assuming the intent is that after being given a chance to modify, you get another chance? I thought that was part of the basic confirmation process, as described in the existing SC. I'm still trying to get my head around how you can surface mistakes that haven't been automatically identified.

Time frames for cancelling transactions can be programmiticaly determined

I was puzzled by this. Normally where I've seen timing in transactions, it is a timeout that cancels an incomplete transaction. You seem to infer that some sites have a system where if you don't cancel in a certain period of time, the transaction goes through? I would want to put language in saying that is a failure. Users must be required to confirm a transaction physically; a lack of response should not trigger a confirmation. By the way, "programmiticaly" is mispelled throughout document.

Suggested Priority Level

What is the rationale for making something that is more complex than the original AA SC into a level A? It seems pretty tough to defend.

Description

Why is this Description section reduced from the 3 paragraphs in the current SC's intent? Is this paragraph supposed to be an addendum to the existing intent section? Maybe Intent and Description aren't the same thing?

Benefits

For people with cognitive disabilities, a process being theoretically reversible is not enough

There seems to be overlap with #21 Task Completion. It is vital that the SCs are normalized in such a way that a failure has a single clear criterion against which it can be measured. When an error can be classified under multiple criteria, it creates confusion.

rachaelbradley commented 7 years ago

I agree that the current 3.3.4 covers a lot of what is covered here but we were told to write these as new criteria instead of modifying the existing ones.

Regarding modify, when we test accessibility we use tools that surface mistakes that can't be automatically identified by presenting us with data that only a human can evaluate. Possible practical example: I add an item to a cart but click the button an extra time. The system may not be able to determine I made a mistake but by presenting the information to me in a clear, timely way, I can determine there was a mistake. I should then be able to remove the duplicate from the cart. If I am not presented with the data until after the purchase, it would fail this criteria.

I believe the time frames listed may include those outside of the system interaction, such as returning a purchase or canceling a hotel reservation.

Can you clarify more where you see overlap with #21?

mbgower commented 7 years ago

@rachaelbradley,

I agree that the current 3.3.4 covers a lot of what is covered here but we were told to write these as new criteria instead of modifying the existing ones.

If this is supposed to be a new criterion, then why is it using the same title and most of the same language as an existing one? I'm going to jump out of the 3.3.4 discussion for a moment in this paragraph. I think there's been a major disconnect between the task force and the working group. Without a revamp of some approaches which COGA seems to have adopted, I'm not sure what can be done other than to address each candidate SC independently. But that is a tough way of trying to address what appear to me to be larger problems. Be happy to take that off line with you.

mbgower commented 7 years ago

regarding overlap with #21, I think I went and pasted in the wrong number. Let me try to wade through the COGA candidates and figure out which one I was talking about.

mbgower commented 7 years ago

I've just done a full review of this. My conclusion? I'm going to a suggest there is potential for a level A that could be: Confirm Important Information

For Web pages that submit or store important information, a read-only summary of the data is provided and users are notified they are about to submit the final information.

Rationale

I'm going to back up and go over a bunch of ground the task force must have travelled, but I think it will help show how these need to be tackled if they are to have a shot at making it into 2.1

3.3.4 is an existing AA SC. So it is required in a lot of jurisdictions and has good traction. The debate on whether we can alter an existing AA criterion is unresolved, but one thing seems clear to me: it will be tougher to alter an existing criterion in a way that causes a failure for sites which currently pass the 2.0 version. That seems to be the case here, so I'm going to break it down to understand the motive and see if we can find a more refined new SC.

Here is what I see as altered:

  1. "or submit or store important information" has been added to the main criteria
  2. the option of making the transaction one of three (1 of 3) things (Reversible, Checked or Confirmed) has been altered into requiring three (3) actions to modify, check, and confirm.
  3. the concept of time frames for cancellation has been added
  4. the priority level has been switched from Level AA to A

I already questioned the last two, so I'll tackle the others in turn.

Submit or store important information

Can you please explain what this adds? The existing wording already states that it applies to situations that "modify or delete user-controllable data in data storage systems". Can you please give an example of something that is not covered by the existing language that is captured by "Submit or store important information". Is it as easy as making it "submit, modify or delete..."?

Reversible/Checked/Confirmed versus Modify, Check, Confirm

Reversible/Checked/Confirmed

In a practical sense, the three options in the existing SC have a lot of overlap. In particular, the third one seems to encompass the first:

A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

I would suggest that Reversible alone is ill-defined and a bit useless on its own (which is borne out in a review of the techniques), and that both Checked and Confirmed as defined include an ability to reverse a submission. For Checked, I have difficulty seeing how its language achieves more than 3.3.1 Error Identification and 3.3.3 Error Suggestion except maybe the inference that the phrase "Data entered by the user is checked for input errors" makes it a requirement to check as opposed to the looser "If an input error is automatically detected" language of 3.3.1 and 3.3.3.

Take away: a case could be made that requiring the third option could be a potentially more advanced SC -- or even that it could be proposed as a relatively low-impact alteration of 3.3.4, even if it does set the bar slightly higher.

Confirmed versus Modify

So what is different between the old "Confirmed" and the next "Modify"? I paste Confirmed just above. Here's the new text:

Modify: A simple mechanism is provided to allow the user to assess and correct mistakes, including mistakes that might not be automaticaly identified. The user can repair information via clearly labeled actions and get back to the place they were at, in one clearly labeled action without unwanted loss of data.

Cancellation

I previously mentioned my confusion with what this is trying to address. Is it there to capture a requirement for G164: Providing a stated time within which an online request (or transaction) may be amended or canceled by the user after making the request? If so, my concern with introducing it here is that it really is explicit to a legal transaction. Again, if we think of a potential new SC that is only talking about 'important' information and leaves all the legal/financial stuff as is, that may be a way of ejecting this.

Ramifications of changes

Would you consider creating or changing a password "important"? Does such a small item warrant this level of guidance? Would you really want a user to have to confirm the password change after they've changed it and submitted? Is that potentially going to confuse people? Speaking of passwords, how does the common practice of having a user re-enter data (such as a password or email) twice to confirm there were no typos fit into this guidance? Are there other 'important' small data entry scenario that don't fit the model? Are we potentially stifling innovation by making it this prescriptive?

Important information

Information the user may need to complete any action or task including an offline task.

I'm of the opinion that any information submitted by a user would be considered important, given this definition. Is a required field a better definition of something that is important? And do we think that all required fields are important? What happens when not all the information on the page is important? Is the SC only required to address inputs so designated?

Conclusion

If the desire is to introduce a new level A, it needs to be less than what is already required and it needs to add value. The item that is not required at the moment but would be useful is the ability to confirm the information after all changes. So, a potential for a level A could be something like "Submit Important Information" or "Submit Required Information". I thought aobut this

For Web pages that submit or store required information each of the following is true: Modify: A mechanism is provided to allow the user to assess and correct mistakes. Confirmed: A read-only summary is provided before submission, where the user is notified they are about to submit the final information.

However, on examination, as mentioned, modify is already caught by 3.3.1 and 3.3.3, so I think we can just focus on Confirmation. Note that I would advocate that the idea that required fields can be used as a determinant for important seems to have validity. I tried making it Confirm Required Information, but it didn't seem to scan as well. Hence my final suggestion, given at the start of this monologue. Confirm Important Information

For Web pages that submit or store important information, a read-only summary of the data is provided and the user is notified they are about to submit the final information.

mbgower commented 7 years ago

I think I've refined my suggested text for the better:

For Web pages that submit or store important information, a read-only summary of the data is provided so the user can confirm the final information before submission.

I'm assuming an ability to cancel the submission is inherent in this statement and is unnecessary to include. Thoughts?

rachaelbradley commented 7 years ago

Based on conversation today:

(A) For Web pages that require user input, a read-only summary of the data is provided so the user can confirm the final information before submission.

Note: Log-ins are exempt from this standard.

Questions: Is the ability to return to correct implicit in this or should it be called out?

Is an AA SC needed to explicitly call out giving the user the ability to modify after identifying an error or is this implicit in 3.3.3, the new one above, and the new return criteria?

On Thu, Feb 16, 2017 at 12:37 PM, Mike Gower notifications@github.com wrote:

I think I've refined my suggested text for the better:

For Web pages that submit or store important information, a read-only summary of the data is provided so the user can confirm the final information before submission.

I'm assuming an ability to cancel the submission is inherent in this statement and is unnecessary to include. Thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/33#issuecomment-280402236, or mute the thread https://github.com/notifications/unsubscribe-auth/AUNHhhiy8Onl4DC3psXy0Ueukx-Fn_6kks5rdIlhgaJpZM4K9Hds .

jnurthen commented 7 years ago

I'm concerned that this would disallow services which submit everything in the background such as cloud office suites. Can we ensure that this is taken into account as I think this would fail this language currently.

On Thu, 16 Feb 2017 at 10:49 rachaelbradley notifications@github.com wrote:

Based on conversation today:

(A) For Web pages that require user input, a read-only summary of the data is provided so the user can confirm the final information before submission.

Note: Log-ins are exempt from this standard.

Questions: Is the ability to return to correct implicit in this or should it be called out?

Is an AA SC needed to explicitly call out giving the user the ability to modify after identifying an error or is this implicit in 3.3.3, the new one above, and the new return criteria?

On Thu, Feb 16, 2017 at 12:37 PM, Mike Gower notifications@github.com wrote:

I think I've refined my suggested text for the better:

For Web pages that submit or store important information, a read-only summary of the data is provided so the user can confirm the final information before submission.

I'm assuming an ability to cancel the submission is inherent in this statement and is unnecessary to include. Thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/33#issuecomment-280402236, or mute the thread < https://github.com/notifications/unsubscribe-auth/AUNHhhiy8Onl4DC3psXy0Ueukx-Fn_6kks5rdIlhgaJpZM4K9Hds

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/33#issuecomment-280422071, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpQPxaLlvh9fHLjhoaWU47hGwOT3w6Sks5rdJongaJpZM4K9Hds .

mbgower commented 7 years ago

@jnurthen, can you please elaborate? Scenario and concern?

jnurthen commented 7 years ago

@mbgower thinking of something like office online (or any of the other cloud document services), they certainly require user input but providing a read-only confirmation of the changes would not be practical. I'm not sure how they could meet this requirement.

There are many other cases too where any operation is part of a more involved process. For example in a cloud IDE someone is likely making a whole host of changes at once. In order to meet this requirement you would essentially have to provide a diff of all of the changes between the current and previous versions essentially mandating the IDE to integrate a version control system. While this may be a good idea it seems a stretch for a level A requirement.

mbgower commented 7 years ago

We discussed this scenario, and I hope we just need to have some better language in Intent about this. Initially I used "important" but the definition of that word is so broad that it was meaningless in the context of this discussion (definition posted earlier in thread).

"Require" also may not work; but assuming we get the right word to define things, do you agree with the overall approach we're taking here?

So, as things stand, it hinges on what anyone considers "require user input". The most obvious example: any form input that has a Required field would apply. This guidance is targetted primarily at form entry. But I think we want to keep it a bit more broad than that.

At the opposite end, we do not want to involve email messages, blog entries, chat clients, social media posts or any other form of voluntary user input that is not required for a process. The original language used the idea of "submission". We also discussed "transaction". The thing is that one can argue that any time I post text in social media, it is a submission and a kind of transaction.

mbgower commented 7 years ago

Before I go too far down a rabbit hole, if we try it with "transaction" does that resolve your issue, @jnurthen ?

For Web pages that require user input to complete a transaction, a read-only summary of the data is provided so the user can confirm the final information before submission.

rachaelbradley commented 7 years ago

If we go back to a simplified version of the scope with some of the newer revisions, does that resolve the concerns?

(A) For web pages that that cause data transactions to occur, that modify or delete data in storage systems, or that that submit user test responses or other important information, a read-only summary of the data is provided so the user can confirm the final information before submission.

Important information - Information the user may need to complete an action or task including an offline task.

Note: Log-ins are exempt from this standard.

Questions: Is the ability to return to correct implicit in this or should it be called out?

mbgower commented 7 years ago

Hi Rachael, Typo: "that that". Happens on 2nd and on 3rd lines. You've added more words, which forms a bit of distraction from what is still the key problem: we're too broad. Most web participation, including all posts we put in social media, are now "data in storage systems"; "important" information being something I need to complete a "task" is a pretty broad catch all. So the boundaries are still very fuzzy.

If you look back at the original 3.3.4 language, they have contained it to a fairly measurable group of scenarios. Do they capture enough that we can just use that language and append?

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, a read-only summary of the data is provided so the user can confirm the final information before submission.

That may ultimately be a good starting point. The intent seems to have been to expand that context. Maybe if we try to voice situations that are not caught by the above, we can expand it in such a way it does not become so general as to catch the stuff we don't want included? Comments? Thoughts?

mbgower commented 7 years ago

I'd still like to work in the idea that this applies where a user is required to enter data. It's tough to convey clearly, and maybe it's not a metric others like. Anyway, here's my latest attempt to simplify this to the point where it is clear; it can be given proper context in the Understanding doc.

Where a user is required to enter data to complete a transaction, a read-only summary of the data is provided so the user can confirm the final information before submission.

I think we can proceed with either this or the retread of 3.3.4 language I posted in my previous comment, and see what the response of the WG is. They may feel it is clear enough that we can seek public responses, which will help guide this.

mbgower commented 7 years ago

By the way, I do think "Confirm Important Information" is a good SC name, which also helps give the short term context.

mbgower commented 7 years ago

@rachaelbradley, just wondering what the status is on this candidate. I was also wondering if the exception note could have its net cast a bit wider to capture some of the other items we mentioned:

Note: Log-ins, searches and voluntary user-initiated actions such as online comments are exempt from this requirement.

rachaelbradley commented 7 years ago

SC for consideration by the group is below (note the removal of "read-only")

Confirm Important Information Level A

SC Text: Where a user is required to enter data to complete a transaction, a summary of the data is provided so the user can confirm the final information before submission.

Note: Log-ins and single, simple-text field transactions are exempt.

Definition Transaction: An exchange of information between individuals or groups

Testing If applicable, confirm a summary step is presented before submission and while changes can still be made. Confirm that all user entered data is present. Confirm that the display format is simple and read only (no form fields or other distractions).

Sufficient Techniques Existing Technique - G98 New Technique – Preview (Example GitHub, Word) New Technique – Query (Provide full query before submission of searches that occur as part of a financial transaction)

Related SCs 3.3.1 Error Identification 3.3.4 Error Prevention (Legal, Financial, Data): 3.3.6 Error Prevention All

mbgower commented 7 years ago

Why was read-only removed? That seems to me to be a critical point, both to distinguish it from 3.3.4 and from the principle of this being a confirmation -- not a mechanism for correction.

rachaelbradley commented 7 years ago

The rewrite of this SC above has lost the modify concept. In WCAG 2.0 this concept is implicit in 3.3.1 but not explicitly called out. We would like to call out the need to provide users with the ability to correct mistakes once identified, whether identified through automated error checking (3.3.1) or through user identification (new SC above). Proposed text is below:

Error Correction Level A

A simple mechanism is provided to allow the user to correct mistakes at any point before the final submission of information, including mistakes that might not be automatically identified. The user can repair information and return to the place they identified the error, through a few clearly labeled actions without unwanted loss of data.

rachaelbradley commented 7 years ago

@mbgower "read-only" implied that the summary could never be editable. This may not always be the case, though it often is. Based on our conversation, I believe the word is intended to convey "without markup, tags, or form fields." This seemed like something could address in techniques.

lseeman commented 7 years ago 
        It is fine for it also to be a mechanism for correction. Enabling correction is a good thingAll the bestLisa SeemanLinkedIn, Twitter---- On Thu, 16 Mar 2017 20:14:03 +0200  Mike Gower<notifications@github.com> wrote ----Why was read-only removed? That seems to me to be a critical point, both to distinguish it form 3.3.4 and from the principle of this being a confirmation -- not a mechanism for correction.  —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.
rachaelbradley commented 7 years ago

Mike, Lisa and Rachael discussed on 10 May and agreed to keep read only. The examples of editable fields were not useful enough to justify removing read ony.

rachaelbradley commented 7 years ago

Suggested rewording to better incorporate exception:

SC Title: Confirm Important Information Level: A Where a user is required to enter data to complete a transaction, a read-only summary of the data is provided so the user can confirm the final information before submission, except for Log-ins and single, simple text field transactions.

rachaelbradley commented 7 years ago

Based on email discussion, suggested revised wording:

SC Title: Confirm Important Information Level: A Where a user is required to enter data to complete a non-reversable transaction between individuals or groups, a read-only summary of the data is provided so the user can confirm the final information before submission, except for Log-ins and single text field transactions.

mbgower commented 7 years ago

complete a non-reversable transaction between individuals or groups

Can you explain the rationale for this rewording? It seems to have significantly curtailed the scope from the prior "complete a transaction" wording, and made the context a lot harder to understand.

bruce-usab commented 7 years ago

Copy and past from a recent off-list email…

I think we should keep 3.3.4 at Level AA. I am open juggling level assignments of 2.0 SC, but it is news to me that people feel that 3.3.4 is underrated. I understood the objective to be a Level A Error Prevention SC, and I feel like we are getting closer to that.

If we keep Confirm Important Information lightweight enough, I think it can be Level A. Removing the middle part from 3.3.4 of “modify or delete user-controllable data in data storage systems, or that submit user test responses” is moving in that direction. Do we agree that option (3) from 3.3.4 is easier for developers than options (1) or (2)? If so, then I think your first option is not controversial as a Level A SC:

For Web pages that cause legal commitments or financial transactions for the user to occur, a mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

I actually like the second option you gave better. I agree that “read-only” and “summary” would need to be in the glossary, and that the definitions proposed are fine. I think the SC could be rewritten without “data” being a defined term. On the other hand, “single-line text field transaction” needs a definition if it stays. My suggestion is:

For Web pages that cause legal commitments or financial transactions for the user to occur, a read-only summary of the information entered by the user is provided before finalizing the submission, except for log-ins and single-line text fields of 40 characters or less.

rachaelbradley commented 7 years ago

To add context to the previous post, after discussion, we've proposed two possible ways forward.

Recommended Way Forward

Change 3.3.4 from AA to A

Confirm Important Information For Web pages that cause legal commitments or financial transactions for the user to occur, a mechanism is available for reviewing, confirming, and correcting information before finalizing the submission. (AA)

Alternate Approach

Confirm Important Information For Web pages that cause legal commitments or financial transactions for the user to occur, a read-only summary of the data is provided so the user can confirm the final information before submission, except for log-ins and single text field transactions.

Definitions

DavidMacDonald commented 7 years ago

What is the advantage of "read only", what if the DEV wants to simply let the user edit the fields directly while reviewing.