Re: Should we require labels to be always visible?

+1

And I love your staircase/elevator analogy Shailesh.

I'll borrow it, <smile>

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 13, 2017 at 2:07 PM, Sailesh Panchang <
sailesh.panchang@deque.com> wrote:

> This following statement has been documented for H44 right from the
> start and is widely understood to be the WG's stance on SC 3.3.2:
> "However, for Success Criterion 3.3.2, the label element must be
> visible since it provides assistance to all users who need help
> understanding the purpose of the field".
> The requirement for label to be provided to all users (i.e. be
> rendered) is covered by SC 3.3.2. More recently, in 2014, the HTML5
> specs explicitly stated that the placeholder is not meant to be a
> label substitute and cautioned of accessibility problems in case of
> transgressions.
> True screen readers read the placeholder attribute text as if it were
> a label even after user enters data. But the value of the attribute is
> meant to be a hint or data format example and such - not a label
> substitute.
> Because developers use it as a label substitute does not make the
> practice valid.
> It may be noted that  the placeholder text is not treated as the
> default  value for the field. The form fails validation if the
> required attribute is present.
> Most will agree that  incorporating both elevators and a staircase
> for a building takes up more space and resources. But will anyone
> argue that elevators can be dispensed with because  say 75% of people
> can use stairs?
> Likewise the placeholder may save space on the screen... but it is
> incorrect use  of the attribute as per the specs and a violation of SC
> 3.3.2.
> Not requiring a visible label for each form field will not strengthen WCAG
> 2.0.
> The exceptions:
> Search form with a  textbox with a visual cue and search button
> Multi-part fields like phone# or social security# with suitable cue /
> formatting to indicate purpose of fields.
> Form within a table (typically not over 6 rows) where the row and
> column headers provide the required visual cues. e.g. survey form with
> radio button choices or a form in which data needs to be entered in a
> separate column for each applicant for instance.
>
> Thanks and regards,
> Sailesh Panchang
>
>
> On 1/7/17, David MacDonald <david100@sympatico.ca> wrote:
> > I'm glad to hear this consensus emerging...
> >
> > We have Paciello, Deque, Nomesa, SSB, myself and others all with this
> > interpretation...
> >
> > 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 Sat, Jan 7, 2017 at 12:41 PM, Katie Haritos-Shea GMAIL
> > <ryladog@gmail.com
> >> wrote:
> >
> >> I agree with Patrick
> >>
> >> ​​​​​* katie *
> >>
> >> Katie Haritos-Shea
> >> Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
> >>
> >> Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn Profile
> |
> >> Office: 703-371-5545 | @ryladog
> >>
> >> NOTE: The content of this email should be construed to always be an
> >> expression of my own personal independent opinion, unless I identify
> that
> >> I
> >> am speaking on behalf of Knowbility, as their AC Rep at the W3C - and -
> >> that my personal email never expresses the opinion of my employer, Deque
> >> Systems.
> >>
> >> -----Original Message-----
> >> From: Patrick H. Lauke [mailto:redux@splintered.co.uk]
> >> Sent: Saturday, January 7, 2017 12:31 PM
> >> To: w3c-wai-gl@w3.org
> >> Subject: Re: Should we require labels to be always visible?
> >>
> >> On 07/01/2017 14:50, Marla Runyan wrote:
> >> > 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?
> >>
> >> No because once something has been entered in the field, there is no
> more
> >> visible text acting as a label present for sighted users who are not
> >> using
> >> AT.
> >>
> >> Contrast is orthogonal to this discussion, as it's a separate issue.
> >>
> >> P
> >> --
> >> Patrick H. Lauke
> >>
> >> www.splintered.co.uk | https://github.com/patrickhlauke
> >> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> >> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> >>
> >>
> >>
> >>
> >
>