RE: ACTION-1006 - to write a proposal for autosave on pages with forms from Richards, Jan on 2014-07-31 (w3c-wai-ua@w3.org from July to September 2014)

From: Richards, Jan <jrichards@ocadu.ca>
Date: Thu, 31 Jul 2014 21:00:13 +0000
To: User Agent Working Group <w3c-wai-ua@w3.org>
Message-ID: <0B1EB1C972BCB740B522ACBCD5F48DEB013A9AB360@ocadmail-maildb.ocad.ca>
Hi all,

I took ACTION-1009 today to send the 3 proposed SCs re: Autosave:

NEW 3.2.X Form Auto-Fill: The user can have the following information stored and used to auto-fill form fields at their request: (Level AA) - name - email address - phone number

(ed. this is updated from http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0024.html)

----

NEW 3.2.Y Save Form Entries: If the user agent provides a feature to save local versions of web content, then any form fields the user has filled retain their entries in the saved version. (Level AA)

(ed. this is split out of Kim's proposal http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0034.html)

----

EDIT 1.8.10 Provide Viewport History: For user agents that implement a history mechanism for top-level viewports (e.g. "back" button), the user can return to any state in the viewport history that is allowed by the content, including: (Level AA)
(a) restored point of regard,
(b) input focus,
(c) selection, and
(d) user's form field entries

(ed. reformatted as a list, added form field entry history)


Cheers,
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: Greg Lowney [gcl-0039@access-research.org]
Sent: July-31-14 4:13 AM
To: Kim Patch; Richards, Jan
Cc: User Agent Working Group
Subject: Re: ACTION-1006 - to write a proposal for autosave on pages with forms

A few more thoughts:

What priority level should it have? That's a lot of sub-requirements; are they all the same priority, and monolithic in the sense that failing any one should really cause the user agent to fail them all?

Is "autosave" an appropriate/acceptable term, or does it need to be something more cumbersome like "save automatically"?

Re the 2nd bullet item, is it really worth it to require separate user options for saving data vs. repopulating with it? Is the intention that the user might choose to have the data they entered saved, but might turn the automatic repopulation off and on? Is that important enough to require? Do any current user agents support it?

The 2nd bullet specifically says "non-submitted" autosaved forms; should the non-submitted part be moved to the basic SC instead of being limited to one sub-requirement? If submitted forms still need to be saved, but aren't used to repopulate the forms, what good are they? If you're trying to help people avoid reentering data, then presumably it is useful to remember submitted forms as well, as they may have to be used more than once.

Are we going with the "The user can specify" wording, which implies that the user can turn it off, or the "The user can have" wording that allow the user agent to provide this as a non-optional behavior?

I'm not clear what is mean by the final bullet. It says "permanently save a copy of...the page", not the data. Is that supposed to mean simply the normal "Save As" function but with the initial values set to their current values, or is it supposed to mean just saving the data associated with this form, merely defeating the normal circumstances that trigger the data reset per bullet item 3?

Re bullet 3, "reset...after a given time period", nite that this will require every piece of saved data to be timestamped in case the user changes the reset time. Every time the user agent starts up it will need to scan every piece to see if it's expired, as well as either setting a countdown timer for each one or checking them periodically when it runs. It seems like a lot of overhead for the benefit.

A fair number of SC have bullet items are essentially stand-alone requirements phrased as complete sentences, and I notice that of those only 1.2.1 and 1.4.4 fail to give titles to the bullet items. (This is not concerning SC like 1.2.2 which have lists of cases that don't stand on their own and are not complete sentences.) If we go that route with the proposed new SC, we should probably make it consistent with the others, giving something like this:

3.2.y Autosave Forms: The user can specify that user changes to form field pages be automatically saved locally: (Level AA)
* Saved states: Automatically saved form data includes the content of text input fields, the state of controls such as radio buttons and checkboxes, and point of regard.
* Auto-restore: The user can specify that an [non-submitted] autosaved form repopulate the same form page when it is opened again. [Or, Automatically saved form data repopulates the same form page when it is opened again.]
* Reset: The user can specify the circumstances under which autosaved fields be reset, including when the user agent closes, or after a given time period.
* Save Permanently: The user can permanently save a copy of the autosaved form field pages. [Clarify this one]

    Greg

-------- Original Message --------
Subject: Re: ACTION-1006 - to write a proposal for autosave on pages with forms
From: Kim Patch <kim@redstartsystems.com><mailto:kim@redstartsystems.com>
To: Richards, Jan <jrichards@ocadu.ca><mailto:jrichards@ocadu.ca>, Greg Lowney <gcl-0039@access-research.org><mailto:gcl-0039@access-research.org>
Cc: User Agent Working Group <w3c-wai-ua@w3.org><mailto:w3c-wai-ua@w3.org>
Date: 7/29/2014 11:05 AM

Thanks.

I think we can solve the timing issue by automatically resetting as Jan suggested, but also allowing the user to save a copy. I added this to the SC and also changed the Lara examples to support this.

I was picturing this as sidestepping the issue of the wrong field that lives forever because it would remember the last thing the user put in when the user had option to auto save locally on. The user could also turn off auto saving altogether.

I also made the terminology changes Greg suggested.

Revised Proposal:

3.2.y Autosave forms: The user can specify that form field pages be autosaved locally as they are changed by the user, including the content of text input fields, the state of controls such as radio buttons and checkboxes, and point of regard; the user can specify that a non-submitted autosaved form repopulate the same form page when it is opened again; the user can specify the circumstances under which autosaved fields be reset, including when the user agent closes, or after a given time period; and the user can permanently save a copy of the autosaved form field pages.

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 Bruno 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. She also opts to permanently save a copy of the form field in case she wants to check it again.

On 7/29/2014 9:10 AM, Richards, Jan wrote:
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>
___________________________________________________


--
___________________________________________________

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 Thursday, 31 July 2014 21:00:40 UTC