W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Re: please can you update your vote

From: David MacDonald <david100@sympatico.ca>
Date: Thu, 4 May 2017 09:24:18 -0400
Message-ID: <CAAdDpDbWmgaLnMpnR-AUxUnNKdw8_WSGXouDDPbdqM=CnPbJ+w@mail.gmail.com>
To: Gregg C Vanderheiden <greggvan@umd.edu>, "lisa.seeman" <lisa.seeman@zoho.com>
Cc: Marc Johlic <marc.johlic@gmail.com>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
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



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.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:55 PM, Gregg C Vanderheiden <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
>
>
>
> On May 3, 2017, at 4:56 PM, Marc Johlic <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>
> 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
>>>>>
>>>>
>>>>
>>>
>>
>
>
Received on Thursday, 4 May 2017 13:24:54 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:13 UTC