Re: Re[2]: Should we require labels to be always visible?

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
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

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



*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 Fri, Jan 6, 2017 at 11:55 AM, Glenda Sims <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/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    |    512.963.3773
> <(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>
> 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-placeh
>>>>> older1.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/>
>>>>>
>>>>>
>>>>>
>>>>>    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 Friday, 6 January 2017 18:00:54 UTC