- From: Katie Haritos-Shea <ryladog@gmail.com>
- Date: Fri, 6 Jan 2017 19:00:34 -0500
- To: Michael Pluke <Mike.Pluke@castle-consult.com>
- Cc: David MacDonald <david100@sympatico.ca>, "lisa.seeman" <lisa.seeman@zoho.com>, Gregg C Vanderheiden <greggvan@umd.edu>, Detlev Fischer <detlev.fischer@testkreis.de>, Joshue O Connor <josh@interaccess.ie>, Shawn Lauriat <lauriat@google.com>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-ID: <CAEy-OxEKJiyjmEod3Y7g7BM-ZeYG27kgbBkWro2XHa+A02QEJw@mail.gmail.com>
I agree, and again will point out that this also important for those with low vision.... Katie Haritos-Shea 703-371-5545 On Jan 6, 2017 6:47 PM, "Michael Pluke" <Mike.Pluke@castle-consult.com> wrote: > I think Gregg: > > - is right to make the warning about the need to only consider things > that “disproportionately affect People with disabilities”; > - and also completely correct in identifying that this will be a > disproportionate problem for many people with cognitive, language and > learning disabilities. > > > > This is probably not the only example where what might conventionally be > viewed as a usability issue (i.e. something that aids or hinders use for > all users) becomes an accessibility issue for many people with cognitive, > language and learning disabilities as it will create a barrier to use that > they are unable to overcome i.e. they may be totally unable to understand > what is happening or they may be sufficiently confused to cause them to > abandon what they are trying to do. > > > > Isolating all of the issues that fall into this category and knowing where > to draw the line has been the task of the COGA TF and is now the task for > everyone to understand and hopefully, in most cases such as this, agree. > > > > Mike > > > > *From:* Gregg C Vanderheiden [mailto:greggvan@umd.edu] > *Sent:* 06 January 2017 21:24 > *To:* Katie Haritos-Shea <ryladog@gmail.com> > *Cc:* Shawn Lauriat <lauriat@google.com>; David MacDonald < > david100@sympatico.ca>; Joshue O Connor <josh@interaccess.ie>; > lisa.seeman <lisa.seeman@zoho.com>; Detlev Fischer < > detlev.fischer@testkreis.de>; GLWAI Guidelines WG org <w3c-wai-gl@w3.org> > *Subject:* Re: Should we require labels to be always visible? > > > > Good comments > > > > > > remember that WCAG is only about problems that disproportionately affect > People with disabilities. If this is a problem for all users— it falls > outside of WCAG. > > > > > > In this case — I think it is pretty easy to make a case that for > cognitive, language, and learning disabilities — having the cues for what a > field means disappear is a disproportionate problem. But be sure to make > the case this way. > > > > > > g > > > > > > > > Gregg C Vanderheiden > > greggvan@umd.edu > > > > > > > > On Jan 6, 2017, at 12:17 PM, Katie Haritos-Shea GMAIL <ryladog@gmail.com> > wrote: > > > > +1 Shawn! > > > > ** katie ** > > > > *Katie Haritos-Shea* > *Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)* > > > > *Cell: 703-371-5545 <(703)%20371-5545> **|* *ryladog@gmail.com* > <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile* > <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545 > <(703)%20371-5545> **|* *@ryladog* <https://twitter.com/Ryladog> > > NOTE: The content of this email should be construed to always be an > expression of my own personal independent opinion, unless I identify that I > am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - > that my personal email never expresses the opinion of my employer, Deque > Systems. > > > > *From:* Shawn Lauriat [mailto:lauriat@google.com <lauriat@google.com>] > *Sent:* Friday, January 6, 2017 11:46 AM > *To:* David MacDonald <david100@sympatico.ca> > *Cc:* josh@interaccess.ie; lisa.seeman <lisa.seeman@zoho.com>; Detlev > Fischer <detlev.fischer@testkreis.de>; WCAG <w3c-wai-gl@w3.org> > *Subject:* Re: Re[2]: Should we require labels to be always visible? > > > > As my two cents, I would say always required, and beyond helping around > cognitive and low-vision, to situational impairments: > > - If the browser helpfully fills in all fields, with duplicate entries > in four of them, you have no way of knowing what data really belongs in > which field. > - If you start to fill out a form and then the phone rings, diverting > your attention for an extended period, you won't remember the fields. Even > if you just have focus in the field, the placeholder falls off. > > Beyond that, using placeholder as a label goes against HTML spec > <https://www.w3.org/TR/2011/WD-html5-20110525/common-input-element-attributes.html#the-placeholder-attribute>. > I know everyone does it these days, so I always say that the label should > move from inside/over the input to above or next to it, so it remains > visible. > > > > Limited space comes down to a design challenge, not a reason to forgo a > visible label. > > > > -Shawn > > > > On Fri, Jan 6, 2017 at 11:26 AM, David MacDonald <david100@sympatico.ca> > wrote: > > I would say it's already a best practice... > > > > Lisa, are those with cognitive disabilities likely to loose track of what > the field label is, if it disappears after they click on it? Is that a > common complaint out in the wild about placeholder text for labels? > > > 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 Fri, Jan 6, 2017 at 11:15 AM, josh@interaccess.ie <josh@interaccess.ie> > wrote: > > <chair hat off> > > >Would it help the cognitive community if the label is always visible. > > I like the demo David :-) > > I couldn't see my clients wearing having to do that. On mobile, there are > times when screen real estate is so sparse that at best you get an icon and > placeholder text. > > I just don't think that would fly as a MUST, as best practice maybe. As > long as it fits into the look and feel guidelines etc. > > My 2 cents > > Josh > > > > > ------ Original Message ------ > From: "Detlev Fischer" <detlev.fischer@testkreis.de> > To: w3c-wai-gl@w3.org; david100@sympatico.ca > Sent: 06/01/2017 16:03:31 > Subject: Re: Should we require labels to be always visible? > > That's one way of doing it, but there will be others. So the requirement > might be EITHER have external visible label OR if using placeholder, show > label next to field after focussing field. > Note that some implementations keep the placeholder text visible even > after focussing (mostly grey text) until you start typing, which I > personally find confusing. Not sure whether some SC (COGA?) or technique > addresses this yet. > > David MacDonald schrieb am 06.01.2017 16:51: > > > Most of the sites I evaluate these days seem to have placeholder text for > labels. An aria-label helps, but the label still disappears on focus or on > clicking into the field. > > > Would it help the cognitive community if the label is always visible. So > for placeholder labels, should we require that the label appears near the > field when the user clicks or tabs to the field? Like this? > > > http://davidmacd.com/widgets/floating-label/floating-placeholder1.html < > http://davidmacd.com/widgets/floating-label/floating-placeholder1.html> > > > Cheers, > David MacDonald > > > > CanAdapt Solutions Inc. > > Tel: 613.235.4902 > > LinkedIn <http://www.linkedin.com/in/davidmacdonald100> > > > twitter.com/davidmacd <http://twitter.com/davidmacd> > > GitHub <https://github.com/DavidMacDonald> > > www.Can-Adapt.com <http://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> > > >
Received on Saturday, 7 January 2017 00:01:18 UTC