RE: [REVIEW REQUESTED][ARIA] placeholder

I understand, thanks.

What I’m trying to point out though, is that having it there within the naming calculation is an all or nothing result as it is currently implemented within the accessibility tree on Windows, which you can see by running the following code in Firefox and checking the accessibility tree object for each form field.

<div role="heading" aria-level="1" id="sharedGroupLbl"> Travelling </div>

<form>

<label for="dept1"> Departure </label>
<input id="dept1" placeholder="mm/dd/yyyy" title="Set the date you plan to leave" aria-describedby="sharedGroupLbl" />

<label for="ret1"> Return </label>
<input id="ret1" placeholder="mm/dd/yyyy" title="Set the date you plan to return" aria-describedby="sharedGroupLbl" />

</form>

E.G For field 1
Name: Departure
Description: Travelling
Value: ""
All other information is lost, including both title and placeholder.

I think Joseph's proposal to put placeholder within its own property instead of using Name or Description would solve this by letting the AT handle how it is represented, so it could still be handled correctly on mobile devices that don't render titles. 

There is also an issue when title and aria-describedby overwrite each other as well.



From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] 
Sent: Tuesday, April 07, 2015 8:30 AM
To: Bryan Garaventa
Cc: Joseph Scheuhammer; Steve Faulkner; Joanmarie Diggs; Matthew King; W3C WAI Protocols & Formats; Alexander Surkov
Subject: 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

Bryan Garaventa ---04/06/2015 12:31:49 PM---> It is not being called an acceptable alternative, it is being and has already been implemented as

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

Received on Tuesday, 7 April 2015 17:59:08 UTC