Re: please can you update your vote

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>
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
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
> On Wed, May 3, 2017 at 11:33 AM, Marc Johlic <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>
>> 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
>>>
>>>
>>>
>>> *Can**Adapt* *Solutions Inc.*
>>>
>>> Tel:  613.235.4902 <(613)%20235-4902>
>>>
>>> LinkedIn
>>> <http://www.linkedin.com/in/davidmacdonald100>
>>>
>>> twitter.com/davidmacd
>>>
>>> GitHub <https://github.com/DavidMacDonald>
>>>
>>> www.Can-Adapt.com <http://www.can-adapt.com/>
>>>
>>>
>>>
>>> *  Adapting the web to all users*
>>> *            Including those with disabilities*
>>>
>>> If you are not the intended recipient, please review our privacy policy
>>> <http://www.davidmacd.com/disclaimer.html>
>>>
>>> On Wed, May 3, 2017 at 10:19 AM, John Foliot <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>
>>>> 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/200
>>>>> 2/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 <http://il.linkedin.com/in/lisaseeman/>, Twitter
>>>>> <https://twitter.com/SeemanLisa>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> John Foliot
>>>> Principal Accessibility Strategist
>>>> Deque Systems Inc.
>>>> john.foliot@deque.com
>>>>
>>>> Advancing the mission of digital accessibility and inclusion
>>>>
>>>
>>>
>>
>