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

Yep.  I agree as well.  Labels OR instructions.

G

glenda sims    |   team a11y lead   |    deque.com    |    512.963.3773


*web for everyone. web on everything.* -  w3 goals

On Fri, Jan 6, 2017 at 2:49 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

> Ø  I think instructions can be in an accessible collapsible component...
> or show up on focus. 3.3.2 Understanding says.
>
>
>
> I’d agree that instructions could be used as well.
>
>
>
> Jonathan
>
>
>
> *From:* David MacDonald [mailto:david100@sympatico.ca]
> *Sent:* Friday, January 06, 2017 3:19 PM
> *To:* Glenda Sims
> *Cc:* Andrew Kirkpatrick; josh@interaccess.ie; lisa.seeman; Detlev
> Fischer; WCAG
>
> *Subject:* 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 <(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 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-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/>
>
>
>
>    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>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>