W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2012

RE: For UAWG Action 644 (related to Undo)

From: Richards, Jan <jrichards@ocadu.ca>
Date: Fri, 13 Jul 2012 13:29:38 +0000
To: Greg Lowney <gcl-0039@access-research.org>
CC: "w3c-wai-ua@w3.org" <w3c-wai-ua@w3.org>
Message-ID: <0B1EB1C972BCB740B522ACBCD5F48DEB03ABC5E5@ocadmail-maildb.ocad.ca>
Comments with JR:

From: Greg Lowney [mailto:gcl-0039@access-research.org] 
Sent: July-13-12 3:19 AM
To: Richards, Jan
Cc: w3c-wai-ua@w3.org
Subject: Re: For UAWG Action 644 (related to Undo)

Hi Jan, 

Here are some things we need to think about. I apologize if these raise more questions than answers.

1. Re the proposed 3.2.X Undo, and more specifically the definition of "reversible user actions":

1.1) Would navigation between pages constitute a reversible user action? Does it matter whether it was accomplished directly (clicking a link or manually entering an address) vs. by other means (e.g. clicking a scripted element, which might have non-reversible effects in addition to navigation)? What about navigating to a page which auto-redirects? Actually, navigating to any web page could trigger unknown amounts of server-side processing, including changing the state of stored data, so would navigation not be covered?

JR: In the defn of reversible actions we could note that navigation is not a reversible action per se but that "SC 3.2.2 Back Button" applies.

1.2) The definition is broad enough to include changes to the UA UI (e.g. changing zoom setting or colors), which would make 3.2.X (Undo) overlap with 3.2.Y (Settings Change Confirmation). 

JR: Agreed, though if the changes involve typing some test, e.g. the name of a color, it feels like Undo should apply so maybe I should go back to it being a text-only undo.

1.3) The definition is also broad enough to include commands that move keyboard focus within the page, and that definitely seems too broad. 

JR: Agreed.

1.4) Would the definition exclude taking links or manipulating controls that had scripts associated with them, even though the script might be harmless? Since the difference is often invisible to users, it may seems random (i.e. broken) that some check boxes can be undone and others can't.

JR: Agreed

1.5) Would an undo command be considered a reversible user action? Would it go onto the same undo stack, or would the user agent need to have a separate command to undo Undo (e.g. a Redo command, not be confused with a Repeat Last Action command)?

JR: Right, though sometimes Redo and Repeat can be combined.

2. Re 3.2.Y (Settings Change Confirmation), first of all let me say that I would love to have this facility; I can't tell you how often I've pressed the wrong shortcut in Notepad++ and gotten into a mode that I can't figure out how to exit short of restarting the application. I've seen this in some applications (such as Adobe Lightroom), where it can sometimes be extremely useful but also, because these actions share the same undo stack as content changes, equally annoying and occasionally rendered useless.

2.1) Is this supported in any user agents?

JR: It is supported in that most user agents don't include irreversible settings changes.

2.2) I have trouble seeing mainstream applications adding confirmation prompts every time the user presses a shortcut, chooses a menu command, or enters a value into a toolbar field to change the zoom level and the like, and even if it's off by default. That would possibly affect a huge number of places in their code.

JR: That's not necessary. It's just (rare) irreversible things.

2.3) Some platforms (e.g. OS X) have a paradigm of applying changes as soon as the user changes the state of a control. For example, on OS X you can change the Key Repeat Rate slider by pressing arrow keys repeatedly (or letting them auto-repeat), and each press or repeat changes the setting immediately; would something like that have to prompt for confirmation after each key press or return, or break their normal model in order to avoid having to do so? I imagine adding a confirmation for every control click or drag would be very useful for the vast majority of people, even those who might benefit from some level of confirmations. 

JR: Android is like that to, but once again irreversible changes are rare.

Anyway, some tough things to think about.

And, just to be difficult, even though 3.2.2 (Back Button) is marked as Done, I'll point out that it's worded broadly enough that it, too, would seem to cover changes to user agent settings and view modes, thus making it overlap with 3.2.X AND 3.2.Y.

JR: Maybe I'll add "rendered content" in there.


-------- Original Message --------
Subject: Re: For UAWG Action 644 (related to Undo)
From: Richards, Jan <jrichards@ocadu.ca>
To: w3c-wai-ua@w3.org <w3c-wai-ua@w3.org>
Date: 7/10/2012 10:00 AM
It seems that I need to update the proposal (http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0028.html):

3.2.1 Form Submission: The user can specify whether or not recognized form submissions must be confirmed. (Level AA)## DONE 15 March 2012 
3.2.2 Back Button: The user can return to a previous state or view using a navigational back button or its equivalent. (Level AA) ## DONE 15 March 2012

3.2.X Undo: The user can sequentially reverse a series of *reversible user actions*. (Level A)

New glossary term: reversible user actions:
Actions that the user agent recognizes can be immediately and completely reversed because either:
(a) the actions occurred exclusively within the user agent user interface, without any server-side or client-side processing; or
(b) the web content provides a recognized programmatic method for passing an "undo" command.
Note: It is acceptable to collect a series of text entry actions (e.g., typed words, a series of backspaces) into a single reversible user action.

3.2.Y Settings Change Confirmation: If the user agent provides mechanisms for changing its user interface settings, it either allows the user to reverse the setting changes, or the user can require user confirmation to proceed. (Level A)

Some relevant URIs:



T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocadu.ca

Twitter @OCAD
Facebook www.facebook.com/OCADUniversity 

205 Richmond Street West, 2nd Floor, Toronto, Canada  M5V 1V3
Received on Friday, 13 July 2012 13:30:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:44 UTC