- From: Richards, Jan <jrichards@ocadu.ca>
- Date: Tue, 29 Jul 2014 13:10:22 +0000
- To: Greg Lowney <gcl-0039@access-research.org>, Kim Patch <kim@redstartsystems.com>
- CC: "Richards, Jan" <jrichards@ocadu.ca>, User Agent Working Group <w3c-wai-ua@w3.org>
- Message-ID: <s2qil8reup1nmw97gtpnmadt.1406639204819@email.android.com>
Hi Greg Great points. It's definitely a hairy issue. I was thinking the timing note should be normative with a limit of at most 24 hrs. Jan Sent from my mobile. -------- Original message -------- From: Greg Lowney Date:07/28/2014 4:49 PM (GMT-05:00) To: "Richards, Jan" ,Kim Patch Cc: User Agent Working Group Subject: Re: ACTION-1006 - to write a proposal for autosave on pages with forms Looks pretty good, although I have a few suggestions and concerns. I'd be okay with a time limitation, as Jan suggests, although perhaps it should be longer than a single session since crashing or power loss, often when one needs to try again, usually starts a new session...unless we implying that the browser needs to auto-save and restore sessions. Jan, did you imagine this as a recommendation in the Implementing document, or something in the normative text? As was pointed out on the call, if the form lacks a consistent address or its content varies over time, restoring content may not be possible. Does that warrant an explicit exception? (It may also not possible to restore the state of custom controls, but that would be covered over the general exception for Recognized Content Only.) For terminology, I would recommend changing "text blocks" to text input fields, as I for one think of "text blocks" as referring to blocks of static text. Similarly I'd switch "checkmarks" to "check boxes" as that's the term used in the HTML standard, and change "indicators" to the more general "controls" because they are used for both input and output. Might want to say that what is saved and restored "including the *content of text input fields*, and the *state of* controls such as radio buttons and checkboxes". There is a potential problem if the user agent restores values that were set as initial state, and not changed by the user. For example, Annie brings up a web form that shows a list of servers, each with a checkbox showing whether it is online or offline. She can simply look at these for information, or can toggle the checkbox and then click "OK". While she's looking at it, her browser crashes, so she restarts it and navigates to the form. Since the server populates the form with the current status, we would not want the browser to restore the checkboxes to the states they had when it crashed, since the servers' statuses might have changed since then. Even if she had manually unchecked a checkbox before the crash, would we want it to uncheck it again? Both cases could be very problematic, especially if she does not realize that it has changed it for her--it could very well be buried in a long list, and so not obvious, and it might lead her to accidentally make changes she didn't want. Jan's suggestion that it be time-limited would reduce this risk, but not eliminate it. By "as they are populated" did you mean only when they are changed by user input? Many controls are populated by the server, or by a script when the page first loads, and I think of the term as including both cases. If a page is marked Do Not Cache or similar, should that affect how user content is saved, and should we acknowledge an exception for that? Should we make explicit exception for security and privacy concerns? For example, it should not save the contents of (recognized) password fields, but even saving draft email messages is potentially problematic. Are there any cases where it's not practical for the user agent to store values locally, e.g. a web-based user agent, or a portable user agent invoked from a read-only medium? On the call someone pointed out how annoying it can be when a browser remembers and forever after keeps suggesting an incorrect or misspelled string, and of course this is worse for people for whom the task o of correcting them is difficult or time-consuming. Did we want to say anything about resetting or editing saved values? Or do we expect that user agents will only save the most recently entered values? Greg -------- Original Message -------- Subject: Re: ACTION-1006 - to write a proposal for autosave on pages with forms From: Richards, Jan <jrichards@ocadu.ca><mailto:jrichards@ocadu.ca> To: User Agent Working Group <w3c-wai-ua@w3.org><mailto:w3c-wai-ua@w3.org> Date: 7/28/2014 10:48 AM Hi Kim, I'd like to see some kind of time constraint when saving this degree of user information. -Jan (MR) JAN RICHARDS PROJECT MANAGER INCLUSIVE DESIGN RESEARCH CENTRE (IDRC) OCAD UNIVERSITY T 416 977 6000 x3957 F 416 977 9844 E jrichards@ocadu.ca<mailto:jrichards@ocadu.ca?Subject=Re%3A%20AUWG%20Teleconference%20for%2017%20March%202014%20%28Boston%20time%20has%20changed%20-%20%20please%20re-check%20time%29&In-Reply-To=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E&References=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E> ________________________________ From: Kim Patch [kim@redstartsystems.com<mailto:kim@redstartsystems.com>] Sent: July-24-14 3:34 PM To: User Agent Working Group Subject: ACTION-1006 - to write a proposal for autosave on pages with forms ACTION-1006 - to write a proposal for autosave on pages with forms We talked about expanding 3.2.2 or 1.8.10 and decided we needed new SC. Proposal: 3.2.y Autosave forms: The user can specify that form field pages be autosaved locally as they are populated, including text blocks, indicators such as radio buttons and checkmarks indicators, and point of regard; the user can specify that a non-submitted autosaved form repopulate the same form page when it is opened again. Intent of Success Criterion 3.2.y: Users who need to fill out a form over several sessions or who accidentally leave a page before a form is fully filled out need to have a way to pick up where they left off rather than having to start over again. Having the ability to retrieve a partially or fully filled out form field helps these users more successfully fill out forms. Users who have trouble remembering what they filled out need to be able to look it up. Examples for Success Criterion 3.2.y: - Bruno tires easily. He begins to fill out a long form, but cannot finish. He lies down to rest, and the form times out. When he comes back the browser offers to restore the unsaved session. He opts to restore the session, and goes on to fill out the rest of the form at the point where he left off. This ability allows Jeremy to fill out long forms even though he can’t maintain focus for the full amount of time it takes to fill out the form, and even if the form times out. - Marjorie uses speech recognition software. Occasionally the software mishears what Marjorie says as a command she doesn’t intend. She is half way through filling out a complicated form that includes many comments when the software interprets some of the words she is saying as a command to go to a different page. When she recovers from the speech input error by returning to the page a few seconds later the browser offers to restore the unsaved session. She opts to restore the session, and goes on to fill out the rest of the form at the point where she left off rather than losing her work. - Lara is very forgetful. She remembers that she filled out a form to comment on software she uses, but cannot remember if she included a certain comment. She retrieves the form field from her browser and checks it to remind herself. -- ___________________________________________________ Kimberly Patch President Redstart Systems, Inc. (617) 325-3966 kim@redstartsystems.com<mailto:kim@redstartsystems.com> www.redstartsystems.com<http://www.redstartsystems.com> - making speech fly Blog: Patch on Speech +Kim Patch Twitter: RedstartSystems www.linkedin.com/in/kimpatch<http://www.linkedin.com/in/kimpatch> ___________________________________________________
Received on Tuesday, 29 July 2014 13:10:57 UTC