RE: please can you update your vote

Since both 20 and 24 hours are randomly chosen numbers, it doesn’t seem like it matters much to users. Therefore I think it should be 20 to make requirements consistent, predictable, and avoids conflict with 2.2.1. I get your points, David, and they are helpful. Still, if you are implementing this, it’s nice to have the same time exception for both SCs.

Regarding the new language, I think it’s fine and addresses most of the concerns I had. I do agree that we should be a little more specific about what the “warning” needs to be, so that it will be available for all. It’s not a deal-breaker; I would be ok with this language if the exception is 20 hours.

Perhaps (as someone else suggested):
“Where data can be lost due to timeouts, users are warned <<++ in text ++>> at the start of a process about the length of inactivity that generates the timeout, unless the data is preserved for a minimum of a <<--24-->> <<++20++>> hours.”

Kim

From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Thursday, May 04, 2017 8:24 AM
To: Gregg C Vanderheiden; lisa.seeman
Cc: Marc Johlic; w3c-waI-gl@w3. org
Subject: Re: please can you update your vote

I'm fine with 20 hours....

Lisa prefers 24 because it's cognitively easier to say "this time tomorrow" rather than add up 20 hours (or this time tomorrow minus 4 hours) ... but given 20 is in WCAG 2 my explanation above might be more difficult to understand than simple making it 20 hours.


Cheers,
David MacDonald



CanAdapt Solutions Inc.

Tel:  613.235.4902

LinkedIn
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_davidmacdonald100&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=kp0eVNTQYQE4200Kwn957VmP4w0iton7iSmEFsf8BUU&e=>

twitter.com/davidmacd<https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_davidmacd&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=JKGwv_TRw3-JtoGxvGOmg9xjXzJmQHuiru5m3iToYzM&e=>

GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DavidMacDonald&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=Wh-jsY9N6yxelAAZu2fyOPw0Vxkwq4tKdJcRKeu6DSE&e=>

www.Can-Adapt.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.can-2Dadapt.com_&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=pY6gnAFf5UGH9kcSP2nEPW65Fyy5ioAyC9RwWznsfBw&e=>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.davidmacd.com_disclaimer.html&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=EMLfkhpGkjz08WqF-5KjjcsQU7pWWKOpfaFTMZ8tKM0&e=>

On Wed, May 3, 2017 at 10:55 PM, Gregg C Vanderheiden <greggvan@umd.edu<mailto:greggvan@umd.edu>> wrote:
ditto.

Unless there is something magic about those 4 hours — I would use the same number to avoid having to answer lots of questions about why it was important for one of them to be 4 hours longer than the other.   Also — we chose 20 instead of 24 the first time for a reason — which I wish we had documented better.  (does it say in Understanding WCAG 2.0 ?)


Gregg C Vanderheiden
greggvan@umd.edu<mailto:greggvan@umd.edu>



On May 3, 2017, at 4:56 PM, Marc Johlic <marc.johlic@gmail.com<mailto:marc.johlic@gmail.com>> wrote:

David wrote:
"the reason I'm fine with the 24 hrs on this and 20 on 2.2.1 is that the SCs have a different purpose or at least a different raison d'etre.

2.2.1 was to allow someone an arbitrarily long time to do *continuous* work, whereas this one is aimed at providing a way for someone to *take a break* from continuous work."

Thanks David - great explanation!  While my preference would be that they both match (20 or 24), your explanation has swayed me to vote GO on this one.

-Marc



On Wed, May 3, 2017 at 11:59 AM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:
I'm fine with 20 hoursOR 24 hours.... 20 actually made sense at the time when we put it in  ... and the purpose of it in 2.2.1 was that we were looking for an arbitrary "long time" that someone might be working on a web site and we figured that everyone needs to sleep at least 4 hours a day. So they would not be working on anything for more than 20 hours.

the reason I'm fine with the 24 hrs on this and 20 on 2.2.1 is that the SCs have a different purpose or at least a different raison d'etre.

2.2.1 was to allow someone an arbitrarily long time to do *continuous* work, whereas this one is aimed at providing a way for someone to *take a break* from continuous work.



Cheers,
David MacDonald


CanAdapt Solutions Inc.
Tel:  613.235.4902<tel:(613)%20235-4902>
LinkedIn
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_davidmacdonald100&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=kp0eVNTQYQE4200Kwn957VmP4w0iton7iSmEFsf8BUU&e=>
twitter.com/davidmacd<https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_davidmacd&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=JKGwv_TRw3-JtoGxvGOmg9xjXzJmQHuiru5m3iToYzM&e=>
GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DavidMacDonald&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=Wh-jsY9N6yxelAAZu2fyOPw0Vxkwq4tKdJcRKeu6DSE&e=>
www.Can-Adapt.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.can-2Dadapt.com_&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=pY6gnAFf5UGH9kcSP2nEPW65Fyy5ioAyC9RwWznsfBw&e=>


  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.davidmacd.com_disclaimer.html&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=EMLfkhpGkjz08WqF-5KjjcsQU7pWWKOpfaFTMZ8tKM0&e=>

On Wed, May 3, 2017 at 11:33 AM, Marc Johlic <marc.johlic@gmail.com<mailto:marc.johlic@gmail.com>> wrote:
I updated my vote and added my comments to the survey for Timeouts (copied here).  Providing this is the wording:

"Where data can be lost due to timeouts, users are warned at the start of a process about the length of inactivity that generates the timeout, unless the data is preserved for a minimum of a 24 hours."


My comments:

I'm still not comfortable with the" 24 hours" piece. I prefer 24 hours - I think 24 hours makes more sense than 20 hours - BUT I feel we will have conflicts, confusion, and issues if this SC uses 24 hours while the closely related 2.2.1 Timing Adjustable uses 20 hours.

It's frustrating. IMO the best option would be to go with 24 hours here and update 2.2.1 to 24 hours as well. But if that's not an option I'm thinking this SC should use 20 hours as well until both can be updated.

-Marc

On Wed, May 3, 2017 at 11:04 AM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:
Re: Timeouts

>>>"Where data can be lost due to timeouts, users are warned at the start of a process about the length of inactivity that generates the timeout, unless submitted data is preserved for a minimum of a 24 hours." (Level A)

I think this language meets the 9 requirements of a WCAG SC.  https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria

We might want to say "warned in text" or some other improvement to the line "warned at the start of a process"  but that is editorial...  I'm a +1 to include it in next draft.

Re: Minimize User Errors

"The user can select from a choice of valid input values, unless there are more than thirty one valid values for any section of the input field or unless this interferes with the main purpose of the content (such as an evaluation application).

Alternative formats of separator characters such as dash, dots, bracket and spaces are accepted in numerical inputs except for the use of a dot as a decimal mark."
I think this meets the requirements of an SC.

I don't think the SC limits the drop down list to only 31... it just says that there is no requirement to meet the SC if there are more than 31 selections to chose from.

So for instance, if a control said "choose your country" it would be not failure of this SC to provide a <select> dropdown with 196 countries... nor would be a requirement to use a dropdown. In other words, a textbox with an accessible name saying "Your country" would pass this.

Also, I don't think this SC limits the author to <select> boxes. They could also use checkboxes or radio buttons, or picker widgets like a date picker or any other of a host of ways that users can select choices among a group.

So from my perspective this SC language is viable for inclusion in the next draft. It's a big requirement but I think its value is well established. My only concern is that these days I find <select> boxes to be finicky to work with screen readers. Sometimes it is because there is a layer of <li> elements on top of the <select> to style the drop down. Sometimes it just that some screen readers have trouble with labels on <select> for reasons I can't explain. However, that seems like something that will be overcome. I support the SC.



Cheers,
David MacDonald


CanAdapt Solutions Inc.
Tel:  613.235.4902<tel:(613)%20235-4902>
LinkedIn
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_davidmacdonald100&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=kp0eVNTQYQE4200Kwn957VmP4w0iton7iSmEFsf8BUU&e=>
twitter.com/davidmacd<https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_davidmacd&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=JKGwv_TRw3-JtoGxvGOmg9xjXzJmQHuiru5m3iToYzM&e=>
GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DavidMacDonald&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=Wh-jsY9N6yxelAAZu2fyOPw0Vxkwq4tKdJcRKeu6DSE&e=>
www.Can-Adapt.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.can-2Dadapt.com_&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=pY6gnAFf5UGH9kcSP2nEPW65Fyy5ioAyC9RwWznsfBw&e=>


  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.davidmacd.com_disclaimer.html&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=EMLfkhpGkjz08WqF-5KjjcsQU7pWWKOpfaFTMZ8tKM0&e=>

On Wed, May 3, 2017 at 10:19 AM, John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>> wrote:
Hi Lisa,

Re: Timeouts

Reviewing that GitHub issue, and the final language being proposed remains unclear (to me).  Are we now being asked to vote on the following text as the new proposed Success Criteria:

"Where data can be lost due to timeouts, users are warned at the start of a process about the length of inactivity that generates the timeout, unless submitted data is preserved for a minimum of a 24 hours." (Level A)

If that is the case, I support this new language - This SC is ready to go.


************

Re: Minimize User Errors

"The user can select from a choice of valid input values, unless there are more than thirty one valid values for any section of the input field or unless this interferes with the main purpose of the content (such as an evaluation application).

Alternative formats of separator characters such as dash, dots, bracket and spaces are accepted in numerical inputs except for the use of a dot as a decimal mark."
I am concerned that this SC has lost its way, and morphed into something different.

What started as a requirement to Minimize User Errors has now devolved to a SC that appears to target the <select> element only, by setting a maximum number of child <option> values (i.e. 31).

While I can see the value in limiting or constraining choices/options to aid with memory and other coga issues, I question whether the current language is sufficient to address the core issue originally articulated:

"The intent of this Success Criteria is to minimize user generated errors by detecting, and when reliable and possible, automatically correcting common input errors."

One possible "Technique" to avoid/meet this new SC would be to simply not use <select> elements in your forms (and thus avoiding *any* quantity of values being offered) - which I do not think is the intent of the Coga TF, nor something that I could support.

As such, while I strongly support the intent of this proposed SC, I reject that current revised language as "missing the mark", and request further editorial revisions.

JF

On Wed, May 3, 2017 at 8:06 AM, lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>> wrote:
Hi

I have edited the time outs and Minimize user errors  drafts. I think we may be very near consensus. Please can you update your vote
1) Timeouts: https://www.w3.org/2002/09/wbs/35422/Timeouts_Issue14/

2) Minimize user errors: https://www.w3.org/2002/09/wbs/35422/minimize-user-errors-13/



For Minimize user errors we need to point out in the understanding section that the user can also enter free form text and that if any section of the input field is like a field record (so if each digit going up to 9 in a large number is not included)

You will also find in the github issue some more notes. please feel free to add there more clarifications that may be needed.

All the best

Lisa Seeman

LinkedIn<https://urldefense.proofpoint.com/v2/url?u=http-3A__il.linkedin.com_in_lisaseeman_&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=q-eMk2M96t8RoXzgrMeaApdSHIru-aFfVV9F8-KQqac&e=>, Twitter<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_SeemanLisa&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=TNPSf5_s1C7GQN2fKXOGh6t05xN18F4fA5Kt3Nyy0IU&m=UUR_QgSKMcBVZmuHZD08Uz1Vv5jby7Ig4jJ6x_qAKfU&s=y7mrX7AVTHEgAL3Zcgn5MjgOC259HRXE3PhbuoJvUis&e=>




--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion