- From: Marla Runyan <marlarunyan1@gmail.com>
- Date: Sat, 7 Jan 2017 09:50:01 -0500
- To: Andrew Kirkpatrick <akirkpat@adobe.com>
- Cc: Glenda Sims <glenda.sims@deque.com>, David MacDonald <david100@sympatico.ca>, "josh@interaccess.ie" <josh@interaccess.ie>, "lisa.seeman" <lisa.seeman@zoho.com>, Detlev Fischer <detlev.fischer@testkreis.de>, WCAG <w3c-wai-gl@w3.org>
- Message-Id: <CB9042EE-0832-4EF1-AA41-4D6F623B0F37@gmail.com>
Glenda, I totally agree: A placeholder alone in a form field does not qualify as a label for sighted users because it is not always present. Note: A placeholder, then supplemented by a label (even if the label does not visually appear until after the user focuses on the field) is enough to pass - so long as a label is always programmatically associated. BUT - What if the placeholder text is styled to meet contrast specs (4.5:1) and is also styled to remain visible until the user begins typing - would placeholder text under these conditions qualify as a visible label when a programmatic label is also present? Marla > On Jan 6, 2017, at 2:06 PM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote: > > Totally agree. > > So what is actually different from the current 3.3.2 then? > > Thanks, > AWK > > Andrew Kirkpatrick > Group Product Manager, Standards and Accessibility > Adobe > > akirkpat@adobe.com > http://twitter.com/awkawk > > From: Glenda Sims <glenda.sims@deque.com <mailto:glenda.sims@deque.com>> > Date: Friday, January 6, 2017 at 13:54 > To: Andrew Kirkpatrick <akirkpat@adobe.com <mailto:akirkpat@adobe.com>> > Cc: David MacDonald <david100@sympatico.ca <mailto:david100@sympatico.ca>>, "josh@interaccess.ie <mailto:josh@interaccess.ie>" <josh@interaccess.ie <mailto:josh@interaccess.ie>>, "lisa.seeman@zoho.com <mailto:lisa.seeman@zoho.com>" <lisa.seeman@zoho.com <mailto:lisa.seeman@zoho.com>>, Detlev Fischer <detlev.fischer@testkreis.de <mailto:detlev.fischer@testkreis.de>>, WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>> > Subject: Re: Re[2]: Should we require labels to be always visible? > > Andrew, > > In my book, the label can be an icon (or text). Here is how I have our experts consistently call this for 3.3.2 (with some thoughts related to 1.3.1 and 4.1.2) > Label or Instructions MUST be visible at all times to sighted users. > An icon (with appropriate alternative text) can serve as a label. Examples of common icons that label form fields (or user controls) include: magnifying glass (for search), 3 horizontal lines on top of each other (hamburger menu), gear (preferences or settings), trash can (delete or view trash depending on context). Remember, these are just a few examples. > A placeholder alone in a form field does not qualify as a label for sighted users because it is not always present. Note: A placeholder, then supplemented by a label (even if the label does not visually appear until after the user focuses on the field) is enough to pass - so long as a label is always programmatically associated. > Label or Instructions MUST be available at all times to a non-sighted users (programmatically determinable). > Of course...I have documented the title situations from H65....but do note that all 4 examples in H65 do have visual clues/information as to the purpose of the form control. > > Glenda > > glenda sims | team a11y lead | deque.com <http://deque.com/> | 512.963.3773 > > web for everyone. web on everything. - w3 goals > > On Fri, Jan 6, 2017 at 12:40 PM, Andrew Kirkpatrick <akirkpat@adobe.com <mailto:akirkpat@adobe.com>> wrote: >> It is worth noting that ARIA14 is not a technique for 3.3.2, but the reason you would generally use aria-label is because you don’t have a visible label so I agree that is difficult to detangle. >> >> David, when you say ‘allow the title on an input to serve as a label’ do you mean for 4.1.2 or 3.3.2? I assume the latter since 4.1.2 requires a name instead of a label, but the problem with using title is that there isn’t accessibility support for keyboard users with the title attribute. >> >> Jon, what if example 3 had an icon (magnifying glass) for the search button instead of the word “search” - would that make it fail in your view (assume that the alt is correctly provided)? >> >> Thanks, >> AWK >> >> Andrew Kirkpatrick >> Group Product Manager, Standards and Accessibility >> Adobe >> >> akirkpat@adobe.com <mailto:akirkpat@adobe.com> >> http://twitter.com/awkawk <http://twitter.com/awkawk> >> >> From: David MacDonald <david100@sympatico.ca <mailto:david100@sympatico.ca>> >> Date: Friday, January 6, 2017 at 13:00 >> To: Glenda Sims <glenda.sims@deque.com <mailto:glenda.sims@deque.com>> >> Cc: "josh@interaccess.ie <mailto:josh@interaccess.ie>" <josh@interaccess.ie <mailto:josh@interaccess.ie>>, "lisa.seeman@zoho.com <mailto:lisa.seeman@zoho.com>" <lisa.seeman@zoho.com <mailto:lisa.seeman@zoho.com>>, Detlev Fischer <detlev.fischer@testkreis.de <mailto:detlev.fischer@testkreis.de>>, WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>> >> Subject: Re: Re[2]: Should we require labels to be always visible? >> Resent-From: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>> >> Resent-Date: Friday, January 6, 2017 at 13:01 >> >> My thinking on that is that we allow a title attribute on an <input> to serve as a label, >> https://www.w3.org/TR/WCAG20-TECHS/H65.html <https://www.w3.org/TR/WCAG20-TECHS/H65.html> >> and also an aria-label technique 14 >> ARIA14: Using aria-label to provide an **** invisible label where a visible label cannot be used **** >> https://www.w3.org/TR/WCAG20-TECHS/ARIA14.html <https://www.w3.org/TR/WCAG20-TECHS/ARIA14.html> >> >> By approving those techniques, we've at least sent a confusing message that a visible label is not required in those situations. >> >> However, my preference is to plug those holes ... or issue an interpretation of 3.3.2 as per Jonathan or Glenda's examples, and remove or change those techniques. >> >> >> Cheers, >> David MacDonald >> >> CanAdapt Solutions Inc. >> Tel: 613.235.4902 <tel:(613)%20235-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/> >> >> 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:55 AM, Glenda Sims <glenda.sims@deque.com <mailto:glenda.sims@deque.com>> wrote: >>> Have y'all seen CB Averitt's examples of placeholders that morph into small labels (after you've started typing in the field)? CB's examples are posted here http://a11yideas.com/ <http://a11yideas.com/>testcode/test.html >>> >>> Also, I've been calling a WCAG failure based on 3.3.2 if there is no visible label. So, if a placeholder tries to serve as a label...but disappears (as you would expect) when you enter content in that field....and no visual label exists at that time....I think it really does fail 3.3.2. >>> 3.3.2 <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#minimize-error-cues> Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A) >>> Why? Because, that field is still something that a user can input into...and it is now missing it's label or instruction. >>> I'm open to the idea that I may have over-interpreted WCAG...but I'm usually not guilty of that mindset. >>> Let me give you the situation that convinced me..that placeholders that pretend to be labels, but vanish (and no visual label exists) after data is enter are a failure in my book: >>> Imagine a complex tax form with text fields that only have placeholders as labels. I enter my data, but I make a mistake. I have no one to see my data (and the form label) at the same time. This puts me in a situation where I cannot see the label/instruction and confirm I entered the right data. Fail: 3.3.2 Labels or Instructions. >>> G >>> >>> glenda sims | team a11y lead | deque.com <http://deque.com/> | 512.963.3773 <tel:(512)%20963-3773> >>> >>> web for everyone. web on everything. - w3 goals >>> >>> On Fri, Jan 6, 2017 at 10:26 AM, David MacDonald <david100@sympatico.ca <mailto: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 >>>> >>>> CanAdapt Solutions Inc. >>>> Tel: 613.235.4902 <tel:(613)%20235-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/> >>>> >>>> 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 <mailto:josh@interaccess.ie> <josh@interaccess.ie <mailto: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 <mailto:detlev.fischer@testkreis.de>> >>>>> To: w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>; david100@sympatico.ca <mailto: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> <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 <tel:613.235.4902> >>>>>>> >>>>>>> LinkedIn <http://www.linkedin.com/in/davidmacdonald100 <http://www.linkedin.com/in/davidmacdonald100>> >>>>>>> >>>>>>> >>>>>>> twitter.com/davidmacd <http://twitter.com/davidmacd> <http://twitter.com/davidmacd <http://twitter.com/davidmacd>> >>>>>>> >>>>>>> GitHub <https://github.com/DavidMacDonald <https://github.com/DavidMacDonald>> >>>>>>> >>>>>>> www.Can-Adapt.com <http://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 <http://www.davidmacd.com/disclaimer.html>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
Received on Saturday, 7 January 2017 15:39:30 UTC