This repository has been archived by the owner. It is now read-only.

Undo #38

Closed
lseeman opened this Issue Nov 27, 2016 · 16 comments

Comments

Projects
None yet
10 participants
@lseeman
Contributor

lseeman commented Nov 27, 2016

Current versions of SC and Definitions

SC Shortname:

Undo

SC Text:

Users are provided with the ability to undo an action and to correct mistakes such that:

  • A user can go back steps in a process via a clearly labeled action.
  • The user can repair information via a clearly labeled action and get back to the place they were at, via a clearly labeled action, without unwanted loss of data.

Suggestion for Priority Level:

A

Related Glossary additions or changes

None

What Principle and Guideline the SC falls within.

Principle 3, Guideline 3.3.3

Description

The intent of this Success Criterion is to allow users to easily undo steps in a process at any point in the process, and not just at the confirmation prior to submission.

This is especially important for people with learning and cognitive disabilities, who make many more mistakes than most people. They may realize their mistake at any point and need to correct it. For example, a work group member was booking a trip online. Due to their dyslexia, they selected a destination with a similar spelling to their intended destination. They noticed this at a later step when trying to book a hotel. The user needs to correct the mistake then, and not wait for the confirmation just prior to submission. If the user is not able to check for and correct a mistake immediately, they run the risk of forgetting their mistake later on or abandoning the whole process.

It is vital for people who are prone to making mistakes, that data they have entered correctly is not deleted when undoing a mistake. Each time the user has to reenter data, there is a new chance for new mistakes to occur. Therefore, if the user has to redo a form each time they correct one section, it can become impossible to submit all the data correctly.

For example, when booking a trip a user can make a mistake at many points, such as incorrect dates, location, hotel, flight, etc. If the user typically makes one or two mistakes in the process, they need to take breaks and double check their work a few times. If a detail is incorrect, such as booking a hotel that is too far away from an event, they must be able to fix that detail. However, if they need to redo the whole process, then when they reenter the other data they are likely to make another mistake. For example, they might invert the dates. If they need to redo the process again from the beginning a third time, they will be tired and probably make more mistakes. Hence the task becomes impossible.

Benefits

Those who have difficulties accurately entering information correctly or perceiving errors will need to undo incorrect actions. It allows all users, but especially those with learning and cognitive disabilities, to re-check data entered and make necessary changes if errors have occurred.

Undo can simplify actions, reduce fear of failure, and make it possible for users to complete their task.

The benefits of having data remaining intact, even if submitted in error, allows for correction for users with poor short term memory and for those with learning disabilities.

It is part of the COGA theme to prevent the user from making mistakes and make it easy to correct mistakes when they do occur.

Related Resources

Issue Paper: Online Payments

COGA Techniques

See also

Testability

In a process which requires a user to enter data, confirm that at every step all of the following are true for the user:

  • Can go back steps in a process via a clearly labeled action.
  • Can repair information via a clearly labeled action and
  • Can get back to the place they were at, via a clearly labeled action
  • Their other data has not been lost and does not need to be replaced

Techniques

  • Clickable breadcrumbs provided with previous steps and data is not lost
  • Providing back and undo features without unwanted data loss
  • Using semantics and personalization to log the steps and return to a step in the process

working groups notes (optional)

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jan 26, 2017

Member

Conceptually, would you say this is related /extends 3.3.6 Error Prevention (All), but at AA level? Does it replace/cross over with 3.3.4 Error Prevention (Legal, Financial, Data) (also at AA).

If an authors satisfied this proposed SC at AA, would they automatically be passing 3.3.4 AA and 3.3.6 AAA ?

Member

patrickhlauke commented Jan 26, 2017

Conceptually, would you say this is related /extends 3.3.6 Error Prevention (All), but at AA level? Does it replace/cross over with 3.3.4 Error Prevention (Legal, Financial, Data) (also at AA).

If an authors satisfied this proposed SC at AA, would they automatically be passing 3.3.4 AA and 3.3.6 AAA ?

@joshueoconnor

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Feb 4, 2017

Contributor

@NeilMilliken Can you give me a status update on this please?

Contributor

joshueoconnor commented Feb 4, 2017

@NeilMilliken Can you give me a status update on this please?

@NeilMilliken

This comment has been minimized.

Show comment
Hide comment
@NeilMilliken

NeilMilliken Feb 13, 2017

I don't think that it replaces either 3.3.6 or 3.3.4 but there is overlap.

NeilMilliken commented Feb 13, 2017

I don't think that it replaces either 3.3.6 or 3.3.4 but there is overlap.

@michael-n-cooper

This comment has been minimized.

Show comment
Hide comment
@michael-n-cooper

michael-n-cooper Feb 18, 2017

Member

Put in draft as proposal e86a1e1

Member

michael-n-cooper commented Feb 18, 2017

Put in draft as proposal e86a1e1

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 28, 2017

Member

Updated the issue description to reflect the FPWD text.

Member

awkawk commented Feb 28, 2017

Updated the issue description to reflect the FPWD text.

rachaelbradley added a commit that referenced this issue May 12, 2017

Update error-prevention-legal-financial-data.html
Moving the portion of this for error correction to #38, Undo.
@rachaelbradley

This comment has been minimized.

Show comment
Hide comment
@rachaelbradley

rachaelbradley May 12, 2017

When we broke apart issue #33, a portion overlapped with this issue. The concern Mike Gower and I have with current wording is that it may be too broad, requiring sites to retain actions and data everywhere. . We suggest the following title and wording which has a much more targeted scope. @lseeman has made an initial review of this.

Error Correction
A
Where a user is required to enter data to complete a transaction, a mechanism is provided to allow the user to correct mistakes and return to the place where they identified the error through clearly labeled actions without unwanted data loss.

rachaelbradley commented May 12, 2017

When we broke apart issue #33, a portion overlapped with this issue. The concern Mike Gower and I have with current wording is that it may be too broad, requiring sites to retain actions and data everywhere. . We suggest the following title and wording which has a much more targeted scope. @lseeman has made an initial review of this.

Error Correction
A
Where a user is required to enter data to complete a transaction, a mechanism is provided to allow the user to correct mistakes and return to the place where they identified the error through clearly labeled actions without unwanted data loss.

@jake-abma

This comment has been minimized.

Show comment
Hide comment
@jake-abma

jake-abma May 28, 2017

Contributor

Some contribution about wording.

Users are provided with the ability to undo an action and to correct mistakes

Undo an action is singular here while as with “correct mistakes” I expect “undo actions…” (plural)

via a clearly labeled action.

Better to add where there should be “at least one clearly labeled action” (there may be step numbers and back/next buttons present)

A user can go back steps in a process

Will it be mandatory or will edit do in overview page?

…to undo an action and to correct mistakes…

Shouldn’t it be “and/or” instead of “and”

clearly labeled action

Is there a definition for what is right and wrong for “clearly”?
Will numbers do..., or only bullets..., or do we need textual descriptions of the steps?

without unwanted loss

Also here the term unwanted is a bit flaky, what is unwanted?

At the Description I see the text “easily undo steps” but I guess it must be “easily undo actions in a step”

At Testability there is “In a process which requires “. I can think of steps where the data is not mandatory but optional.

The bullet points at Testability mention the clearly labeled action in multiple ways. The first is to go back steps, the other to repair information. Then again to get back to the previous step. Refinement of the term would be pleasant as this may cause confusion.

Their other data has not been lost and does not need to be replaced

What does the ‘replaced’ here means? Filled in again…?

As @rachaelbradley suggested in her comment I see the benefit of a more targeted scope.

Where a user is required to enter data to complete a transaction

Why only transaction here? The need for error correction is broader and limiting the scope this much seems to strict and also the SC text “Error correction” is not appropriate for only transactions.

Also here the and/or would fit better.

to allow the user to correct mistakes

Should be to correct “errors” (as this is the text of the SC)

and return to the place where they identified the error

Is this where the error is or where they identified it… (could be they identified it at step 3 while the error is at step 1)

Contributor

jake-abma commented May 28, 2017

Some contribution about wording.

Users are provided with the ability to undo an action and to correct mistakes

Undo an action is singular here while as with “correct mistakes” I expect “undo actions…” (plural)

via a clearly labeled action.

Better to add where there should be “at least one clearly labeled action” (there may be step numbers and back/next buttons present)

A user can go back steps in a process

Will it be mandatory or will edit do in overview page?

…to undo an action and to correct mistakes…

Shouldn’t it be “and/or” instead of “and”

clearly labeled action

Is there a definition for what is right and wrong for “clearly”?
Will numbers do..., or only bullets..., or do we need textual descriptions of the steps?

without unwanted loss

Also here the term unwanted is a bit flaky, what is unwanted?

At the Description I see the text “easily undo steps” but I guess it must be “easily undo actions in a step”

At Testability there is “In a process which requires “. I can think of steps where the data is not mandatory but optional.

The bullet points at Testability mention the clearly labeled action in multiple ways. The first is to go back steps, the other to repair information. Then again to get back to the previous step. Refinement of the term would be pleasant as this may cause confusion.

Their other data has not been lost and does not need to be replaced

What does the ‘replaced’ here means? Filled in again…?

As @rachaelbradley suggested in her comment I see the benefit of a more targeted scope.

Where a user is required to enter data to complete a transaction

Why only transaction here? The need for error correction is broader and limiting the scope this much seems to strict and also the SC text “Error correction” is not appropriate for only transactions.

Also here the and/or would fit better.

to allow the user to correct mistakes

Should be to correct “errors” (as this is the text of the SC)

and return to the place where they identified the error

Is this where the error is or where they identified it… (could be they identified it at step 3 while the error is at step 1)

@rachaelbradley

This comment has been minimized.

Show comment
Hide comment
@rachaelbradley

rachaelbradley Jun 30, 2017

@jake-abma I've incorporated your comments and corrections into account in the new SC text, with the exception of the limitation to transactions. We have been struggling with appropriate wording for this SC and #33. We need to exclude situations such as IM but leave an appropriately useful scope. Recommendations would be appreciated.

rachaelbradley commented Jun 30, 2017

@jake-abma I've incorporated your comments and corrections into account in the new SC text, with the exception of the limitation to transactions. We have been struggling with appropriate wording for this SC and #33. We need to exclude situations such as IM but leave an appropriately useful scope. Recommendations would be appreciated.

@rachaelbradley rachaelbradley self-assigned this Jun 30, 2017

@lseeman

This comment has been minimized.

Show comment
Hide comment
@lseeman

lseeman Jul 5, 2017

Contributor

Hi Rachael, thanks for joining us on this.
I also pluralized the "action" because it might take more then one action

Let me know if that is a problem

Contributor

lseeman commented Jul 5, 2017

Hi Rachael, thanks for joining us on this.
I also pluralized the "action" because it might take more then one action

Let me know if that is a problem

@rachaelbradley

This comment has been minimized.

Show comment
Hide comment
@rachaelbradley

rachaelbradley Jul 6, 2017

New potential wording (uploads to GIT are failing).

Where users are required to enter data to complete a transaction, a mechanism is provided to undo an action or correct an error and return to the place where they identified the error through at least one clearly labeled action without data loss, except when the data loss is part of the correction.

rachaelbradley commented Jul 6, 2017

New potential wording (uploads to GIT are failing).

Where users are required to enter data to complete a transaction, a mechanism is provided to undo an action or correct an error and return to the place where they identified the error through at least one clearly labeled action without data loss, except when the data loss is part of the correction.

@lseeman

This comment has been minimized.

Show comment
Hide comment
@lseeman

lseeman Jul 6, 2017

Contributor

Rachel this is a completely diffrent usecase
this should be in error prevention

Contributor

lseeman commented Jul 6, 2017

Rachel this is a completely diffrent usecase
this should be in error prevention

@lseeman

This comment has been minimized.

Show comment
Hide comment
@lseeman

lseeman Jul 13, 2017

Contributor

Changes to the SC text, based in survey and comment https://www.w3.org/2002/09/wbs/35422/COGA_undo/results
Users are provided with the ability to undo an action and to correct mistakes such that:

-The user can return to the location they were at, prior to the change in context, via visible or clearly labeled controls without unwanted loss of data unless the data loss is part of the correction; or
-the user can repair information entered without unwanted loss of data unless the data loss is part of the correction.

Exceptions:

-Where allowing the user to undo an action or maintaining data may cause harm such as adding risk to the user privacy or security.
-Where the user has confirmed an action it does not have to be reversible.
-Where allowing the user to undo an action may interfere with the essential function of the content.
-Where the action can no longer be controlled by the site.

Contributor

lseeman commented Jul 13, 2017

Changes to the SC text, based in survey and comment https://www.w3.org/2002/09/wbs/35422/COGA_undo/results
Users are provided with the ability to undo an action and to correct mistakes such that:

-The user can return to the location they were at, prior to the change in context, via visible or clearly labeled controls without unwanted loss of data unless the data loss is part of the correction; or
-the user can repair information entered without unwanted loss of data unless the data loss is part of the correction.

Exceptions:

-Where allowing the user to undo an action or maintaining data may cause harm such as adding risk to the user privacy or security.
-Where the user has confirmed an action it does not have to be reversible.
-Where allowing the user to undo an action may interfere with the essential function of the content.
-Where the action can no longer be controlled by the site.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jul 13, 2017

Contributor

Just so it isn't lost, I suggested on the call:

Users can undo an action by returning to the action, and correct data entry by repairing the information entered without unwanted loss of data except when:

That is not perfect (e.g. what's an action?), but I thought it would help to distill down first, then build up to fill the gaps.

NB: I thought that data loss could be part of the correction that you wanted, therefore simplified it a bit.

Contributor

alastc commented Jul 13, 2017

Just so it isn't lost, I suggested on the call:

Users can undo an action by returning to the action, and correct data entry by repairing the information entered without unwanted loss of data except when:

That is not perfect (e.g. what's an action?), but I thought it would help to distill down first, then build up to fill the gaps.

NB: I thought that data loss could be part of the correction that you wanted, therefore simplified it a bit.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jul 14, 2017

Contributor

I think we need to say some context. Perhaps leverage the "steps in a process" language from the conformance section. Also revising "unwanted" adjective.

When an action is one of a sequence of steps that need to be completed in order to accomplish an activity, Users can undo an action by returning to the step, and correct data entry without unwanted loss of data or repair the entry in another way, except where:

  • Where the user has confirmed an action it does not have to be reversible.
  • allowing the user to undo an action may interfere with the essential function of the content.
  • the action can no longer be controlled by the site.
  • the user has initiated the loss of data after having been informed of the effect of activating a control
Contributor

DavidMacDonald commented Jul 14, 2017

I think we need to say some context. Perhaps leverage the "steps in a process" language from the conformance section. Also revising "unwanted" adjective.

When an action is one of a sequence of steps that need to be completed in order to accomplish an activity, Users can undo an action by returning to the step, and correct data entry without unwanted loss of data or repair the entry in another way, except where:

  • Where the user has confirmed an action it does not have to be reversible.
  • allowing the user to undo an action may interfere with the essential function of the content.
  • the action can no longer be controlled by the site.
  • the user has initiated the loss of data after having been informed of the effect of activating a control
@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jul 14, 2017

Contributor

Should the the loss of data aspect only apply when part of a sequence of steps?

I wasn't sure so kept it separate, but this version implies it is scoped to stepped processes.

Contributor

alastc commented Jul 14, 2017

Should the the loss of data aspect only apply when part of a sequence of steps?

I wasn't sure so kept it separate, but this version implies it is scoped to stepped processes.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jul 14, 2017

Contributor

@alastc Yes that is my intention.... also, I accidentally edited your comment above , so if you want to preserve your language please re-enter it in the comment.

AC - ok, have done ;-)

Contributor

DavidMacDonald commented Jul 14, 2017

@alastc Yes that is my intention.... also, I accidentally edited your comment above , so if you want to preserve your language please re-enter it in the comment.

AC - ok, have done ;-)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.