Re: Should we require labels to be always visible?

+1 to Sailesh too!

Katie Haritos-Shea
703-371-5545

On Jan 13, 2017 2:38 PM, "David MacDonald" <david100@sympatico.ca> wrote:

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