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

>Label or Instructions MUST be visible at all times to sighted users.

I think instructions can be in an accessible collapsible component... or
show up on focus. 3.3.2 Understanding says.

"Content authors may also choose to make such instructions available to
users only when the individual control has focus especially when
instructions are long and verbose."
https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html
​

​

Is there consensus that labels must be visible at all times?  I'd be fine
with that, I hate writing "Best Practice" on placeholder fields.

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 1:54 PM, Glenda Sims <glenda.sims@deque.com> wrote:

> 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    |    512.963.3773
> <(512)%20963-3773>
>
> *web for everyone. web on everything.* -  w3 goals
>
> On Fri, Jan 6, 2017 at 12:40 PM, Andrew Kirkpatrick <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
>> http://twitter.com/awkawk
>>
>> From: David MacDonald <david100@sympatico.ca>
>> Date: Friday, January 6, 2017 at 13:00
>> To: Glenda Sims <glenda.sims@deque.com>
>> Cc: "josh@interaccess.ie" <josh@interaccess.ie>, "lisa.seeman@zoho.com" <
>> 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?
>> Resent-From: WCAG <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
>> 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 <(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: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>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>