RE: [REVIEW REQUESTED][ARIA] placeholder

Hi Brian,

On mobile devices title is not rendered to sited users when you hover over
it. At least placeholder is visible until you type over it.

My thoughts are that placeholder should be in the name calculation to deal
with situations where the author left the label out so that the user is not
left with nothing. Accessibility compliance rules shoul enforce actual
labeling <label for>, aria-labelledby, etc.

You don't want be in a situation where you pick up a mobile app or go to a
kiosk to buy a ticket and the author forgot to test for accessibility and
be left with nothing as there is nobody for us to scream at about it not
being accessible. It is fallback. :-)

Rich

Rich Schwerdtfeger



From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To: Steve Faulkner <faulkner.steve@gmail.com>, Matthew
            King/Fishkill/IBM@IBMUS
Cc: Joseph Scheuhammer <clown@alum.mit.edu>, Joanmarie Diggs
            <jdiggs@igalia.com>, W3C WAI Protocols & Formats
            <public-pfwg@w3.org>, Alexander Surkov
            <surkov.alexander@gmail.com>
Date: 04/06/2015 12:31 PM
Subject: RE: [REVIEW REQUESTED][ARIA] placeholder



> It is not being called an acceptable alternative, it is being and has
already been implemented as  a fallback source when other sources are not
available.

I still don’t understand why it makes sense for placeholder to have greater
priority in the naming calculation than title, because if you have a form
field that has both a placeholder and a title on it, the browser now
automatically chooses placeholder as the accessible name.

Also, the fact that placeholder is in the naming calculation at all,
implies to any developer reading it that placeholder is an “acceptable
alternative” with greater priority than title, which does pass all HTML
validators.

From: Steve Faulkner [mailto:faulkner.steve@gmail.com]
Sent: Monday, April 06, 2015 3:14 AM
To: Matthew King
Cc: Bryan Garaventa; Joseph Scheuhammer; Joanmarie Diggs; W3C WAI Protocols
& Formats; Alexander Surkov
Subject: Re: [REVIEW REQUESTED][ARIA] placeholder

Hi Matt,
On 5 April 2015 at 19:37, Matthew King <mattking@us.ibm.com> wrote:
 On 4 April 2015 at 20:07, Bryan Garaventa <
 bryan.garaventa@ssbbartgroup.com wrote:
 > If it were possible to show that 5560 examples across the web used
 > the following syntax:
 >
 > <div role=”checkbox” aria-selected=”true”></div>
 >
 > Would we have to say in the spec that this is a valid use of the
 > checkbox role and it’s supporting state by getting browsers to map
 > aria-selected to checkbox?
 >
 Steve Faulkner <faulkner.steve@gmail.com> wrote on 04/05/2015 01:17:57 AM:
 > Hi Bryan, the analogy does not make sense. The examples provided are
 > a random sample of usage from approx 80,000 web sites.

 Steve, If a random sample demonstrated high frequency usage of selected in
 the way Bryan described, how does the analogy fail?

Because what bryan describes simple does not work for anyone currently,
what I am describing works for the majority of users now and is a common
practice now. I am not saying we should advise authors that it is
conforming to use the placeholder as a label, in fact I advised the
opposite in the HTML5 spec [
http://www.w3.org/TR/html5/forms.html#the-placeholder-attribute].

The accessible name calculation for many elements has, as implemented,
included non conforming sources, inclusion in the accessible name
calculation rules for UA implementations does not mean that it is
conforming for authors, it means that in the absence of conforming sources,
sources which are known to include useful information should be included.



 If a random sample demonstrated that the <p> element or <<span> elements
 immediately preceding an input very frequently contained a valid label if
 if another labeling technique was not used, does that mean we should make
 those elements part of the accessible name calculation?

This what some AT already do, but I don't consider it a practice that
browsers should or need to implement.


 Steve continues:
 > What I am trying to illustrate is that how placeholder content is used
 in
 > accessible name calculation needs to take into account how
 > placeholder is used in web sites, in the wild, not how we wish it
 > would be used.

 I am questioning whether placeholder should be allowed to be a part of the
 name calculation. Yes, it may sometimes have a useful value. But, I am not
 convinced that calling it an acceptable alternative to the long list of
 options we already have available to authors is a good idea. Other random
 samples could demonstrate how using placeholder as a label would be
 extremely confusing to AT users.

It is not being called an acceptable alternative, it is being and has
already been implemented as  a fallback source when other sources are not
available.


 Another equally valid position could be .... Authors have had enough
 warning and guidance against this practice so too bad for the 5,560 in
 your random sample. Kill the pernitious practice before the random sample
 of 80k turns of 60k such pages. Make all conformance checkers fail them.

There is nothing to say that accessibility checkers should not fail the use
of placeholder in this context. HTML conformance checkers are another
issue.


 Another possibility is to force user agents to fix the accessibility
 problems with placeholder presentation so that they really could be a
 fully accessible alternative.

Suggest asking the implementers on list how that is to be accomplished.
Getting implementers to change the behaviour of mainstream UI for
accessibility purposes is not easy.



 Another possibility is for new options in HTML or CSS that make it super
 easy for authors to use the label element in a way that is both completely
 accessible and mobile friendly so that the desire to co-opt placeholder
 for this purpose evaporates.

Suggest asking the implementers on list how that is to be accomplished and
providing concrete proposals on how to make that happen.



 To some, it may feel the placeholder as alternative label train has left
 the station. But, before jumping on board, I am curious to know if we are
 evaluating the potential efficacy of other viable paths.

Suggest getting feedback from implementers.

--

Regards

SteveF
HTML 5.1