Re: Should we require labels to be always visible?

Gregg wrote:

> But I think Andrew’s point is —  if it is not ALWAYS needed — then it
should not be  REQUIRED by a SC.

"ALWAYS" is a pretty high bar to meet. What do we do/say when it is for
"...99.999% of the time"?

​>​
​> OR - we need to add something to the SC that says when it is REQUIRED to
be there and when not.

...but can that be abstracted to language in a way that clearly defines
when and when not?

I think we could likely come up with a list of "when probably not", but
again, that leaves open a subjective decision which may not be answered
with a True/False statement. It, in effect, becomes an RFC 2119 SHOULD,
which states: "This word, or the adjective "RECOMMENDED", mean that there may
exist valid reasons in particular circumstances to ignore a particular
item, but the full implications must be understood and carefully weighed
before choosing a different course.
​"​

Using that as a starting point, could we not then list conditions under
which the requirement could be ignored?

JF

On Fri, Jan 6, 2017 at 1:11 PM, <alands289@gmail.com> wrote:

>
>
> This reads to me as: If the developers/designers are not using a component
> with a text alternative, then they MUST use a visible label to pass. This
> is because of *Note 1: *A label is presented to all users
>
>
>
> Alan Smith
>
>
>
> *From: *Gregg C Vanderheiden <greggvan@umd.edu>
> *Sent: *Friday, January 6, 2017 2:02 PM
> *To: *Jonathan Avila <jon.avila@ssbbartgroup.com>
> *Cc: *Glenda Sims <glenda.sims@deque.com>; Andrew Kirkpatrick
> <akirkpat@adobe.com>; 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?
>
>
>
> a couple/few things here to help clarify the discussion perhaps
>
>
>
>
>
>
>
> 1) (re previous post)  there is no such things as a  SHOULD REQUIREMENT.
>   Anything with SHOULD is not normative by definition.    It is advisory.
>   So it would not be an SC (which are normative).
>
>
>
> 2) We word the SC as TRUE / FALSE statements.    There are no should’s or
> shall’s in an SC.
>
>      however you must do all of the normative requirements if you want to
> conform.  (that is how conformance is defined in standards).  So all SC are
> “Shall’s” if you will in effect.
>
>
>
> 3) NOTES  cannot add or detract from the normative statement.  They can
> only explain.    Since the SC below requires as LABEL OR COMPONENT WITH
> TEXT ALTERNATIVE  there is *no requirement for a label* in the SC. Just
> EITHER a label  OR  a component with text alternative.      So Note 1 is
> not a requirement — it is simply a description of what the word label means
> - for those who are confused.
>
>
>
>
>
> Gregg C Vanderheiden
>
> greggvan@umd.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Jan 6, 2017, at 12:36 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
> wrote:
>
>
>
> Ø  +1 to Jonathan's interpretation/recommendation.
>
>
>
> *For the record below is the definition which is marked normative*
>
>
>
> *label*
>
> text <https://www.w3.org/TR/WCAG20/#textdef> or other component with a text
> alternative <https://www.w3.org/TR/WCAG20/#text-altdef> that is presented
> to a user to identify a component within Web content
> <https://www.w3.org/TR/WCAG20/#contentdef>
>
> *Note 1: *A label is presented to all users whereas the name
> <https://www.w3.org/TR/WCAG20/#namedef> may be hidden and only exposed by
> assistive technology. In many (but not all) cases the name and the label
> are the same.
>
> *Note 2: *The term label is not limited to the label element in HTML.
>
>
>
>
>
> Jonathan Avila
>
> Chief Accessibility Officer
>
> SSB BART Group
>
> jon.avila@ssbbartgroup.com
>
> 703.637.8957 <(703)%20637-8957> (Office)
>
>
>
> Visit us online: Website <http://www.ssbbartgroup.com/> | Twitter
> <https://twitter.com/SSBBARTGroup> | Facebook
> <https://www.facebook.com/ssbbartgroup> | LinkedIn
> <https://www.linkedin.com/company/355266?trk=tyah> | Blog
> <http://www.ssbbartgroup.com/blog/>
>
> Don't miss *Trends in Accessibility & Electronic Documents* on Wed 12/7!
> <http://info.ssbbartgroup.com/Accessibility-Trends-and-Documents.html?mkt_tok=eyJpIjoiWXpsak9XWTJNbUV5T1RneiIsInQiOiJzWWlWT2FiUnpjS1hOYmx5dzdHRUs1d0lcL2Y4VjBHU1EyRWZuSm40aFQ2TE51Zm4wUU9PaGowcGN4Nm5UdFhnMTVxUHFBSHAwR21BODV1UGc2TFloV1NaUFNvbE8wU05IV2>
>
>
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination,
> distribution or copying of this communication is strictly prohibited.
>
>
>
> *From:* Glenda Sims [mailto:glenda.sims@deque.com <glenda.sims@deque.com>]
>
> *Sent:* Friday, January 06, 2017 12:34 PM
> *To:* Jonathan Avila
> *Cc:* Andrew Kirkpatrick; Shawn Lauriat; David MacDonald;
> josh@interaccess.ie; lisa.seeman; Detlev Fischer; WCAG
> *Subject:* Re: Re[2]: Should we require labels to be always visible?
>
>
>
> +1 to Jonathan's interpretation/recommendation.
>
>
>
> Glenda (Goodwitch) Sims
>
>
> 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 11:27 AM, Jonathan Avila <
> jon.avila@ssbbartgroup.com> wrote:
>
> Ø  https://www.google.com – it has title=“search” and
> aria-label=“search”, does it need a visible label?
>
>
>
> We’ve had this discussion many times on the list.  I believe the current
> SC 3.3.2 requires visible labels for all input based on the normative
> definition and note of label in WCAG 2.0.
>
>
>
> A visible label doesn’t have to be text and could be an icon, button or
> graphic such as  a “search” button that is in close proximity to the input
> field.  A placeholder would serve as the visual label when the field does
> not have text in it.  As soon as the field has text in it then another
> visual label would be needed.  I support the float label technique
> described here:
>
> http://bradfrost.com/blog/post/float-label-pattern/
>
>
>
> Jonathan
>
>
>
> Jonathan Avila
>
> Chief Accessibility Officer
>
> SSB BART Group
>
> jon.avila@ssbbartgroup.com
>
> 703.637.8957 <(703)%20637-8957> (Office)
>
>
>
> Visit us online: Website <http://www.ssbbartgroup.com/> | Twitter
> <https://twitter.com/SSBBARTGroup> | Facebook
> <https://www.facebook.com/ssbbartgroup> | LinkedIn
> <https://www.linkedin.com/company/355266?trk=tyah> | Blog
> <http://www.ssbbartgroup.com/blog/>
>
> Don't miss *Trends in Accessibility & Electronic Documents* on Wed 12/7!
> <http://info.ssbbartgroup.com/Accessibility-Trends-and-Documents.html?mkt_tok=eyJpIjoiWXpsak9XWTJNbUV5T1RneiIsInQiOiJzWWlWT2FiUnpjS1hOYmx5dzdHRUs1d0lcL2Y4VjBHU1EyRWZuSm40aFQ2TE51Zm4wUU9PaGowcGN4Nm5UdFhnMTVxUHFBSHAwR21BODV1UGc2TFloV1NaUFNvbE8wU05IV2>
>
>
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination,
> distribution or copying of this communication is strictly prohibited.
>
>
>
> *From:* Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
> *Sent:* Friday, January 06, 2017 11:51 AM
> *To:* Shawn Lauriat; David MacDonald
> *Cc:* josh@interaccess.ie; lisa.seeman; Detlev Fischer; WCAG
>
>
> *Subject:* Re: Re[2]: Should we require labels to be always visible?
>
>
>
> One of the other classic cases:
>
>
>
> https://www.google.com – it has title=“search” and aria-label=“search”,
> does it need a visible label?
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Group Product Manager, Standards and Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
>
>
>
> *From: *Shawn Lauriat <lauriat@google.com>
> *Date: *Friday, January 6, 2017 at 11:45
> *To: *David MacDonald <david100@sympatico.ca>
> *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 11:46
>
>
>
> 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>
>
>
>
>
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion