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<mailto:mattking@us.ibm.com>> wrote:
On 4 April 2015 at 20:07, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto: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<mailto: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<http://www.w3.org/html/wg/drafts/html/master/>