RE: Placeholder behavior

+1 for mapping as fallback in accessibleDescription instead of accessibleName.

Of course, the best would be an Accessibility API extension instead of fallback mapping to old properties until hell freezes over just because it is easier to do. 

Placeholder is mainly for input help info and therefore belongs in an help-designated platform Accessibility API property. 

Regards
Stefan

-----Original Message-----
From: Sailesh Panchang [mailto:spanchang02@yahoo.com] 
Sent: Dienstag, 7. Oktober 2014 15:47
To: Andrew Kirkpatrick; Alastair Campbell
Cc: Web Content Accessibility Guidelines Working Group
Subject: RE: Placeholder behavior

The present algorithm  does refer to attributes like alt, title, aria-label, aria-labelledby and the HTML label explicitly. The "placeholder" attribute which was in the list earlier is the only one that has been stripped out.  

The email that started this thread alluded to the HTML5 specs and the accessibility barriers documented there. It says the placeholder is meant to  provide a hint / advisory text and clearly is not a substitute for the label. So I do not understand the rationale for its inclusion in accessible name calculation. It is alright for accessible description at best. And it fails SC 3.3.2 for sure simply because the placeholder is not a label.
Yet, like H65, the placeholder  may be used for single field forms like the search form or say for multi-part  fields like phone# or SSN provided there is a common label like a legend. When a title is used in these situations, SC 3.3.2 is not flagged. If it is a fallback for accessible name in these limited circumstances, it might help to include such examples following the algorithm. 
I do not agree that it is okay to use it for login forms for user name and password.  
Regards,
Sailesh

Received on Tuesday, 7 October 2014 14:05:40 UTC