- From: David MacDonald <david100@sympatico.ca>
- Date: Thu, 4 May 2017 09:24:18 -0400
- 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>
- Message-ID: <CAAdDpDbWmgaLnMpnR-AUxUnNKdw8_WSGXouDDPbdqM=CnPbJ+w@mail.gmail.com>
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