Re: ACTION-1349: Creation of aria-placeholder

BTW, it would be entirely possible for browsers to implement placeholder 
and embedded labels in ways that actually enhance usability and 
accessibility for everyone.
The limitation is not in the native host language ... it is a matter of UA 
design.
There could also be UA preferences to support this.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Fred Esch/Arlington/IBM@IBMUS
To:     "W3C WAI Protocols & Formats" <public-pfwg@w3.org>, 
Date:   01/15/2015 08:40 AM
Subject:        Re: ACTION-1349: Creation of aria-placeholder



Dominic,

I see what you mean about aria-placeholder vs the HTML placeholder 
attribute.  But it seems like we are giving developers guidance in the 
text.

Authors SHOULD present this hint to the user by displaying the text
inside a blank unfocused control.

And the note is full of warnings for developers.

Note: As is the case with the related HTML placeholder attribute, use of
placeholder text as a replacement for a displayed label can reduce the
accessibility and usability of the control for a range of users
including older users and users with cognitive, mobility, fine motor
skill or vision impairments. While the hint given by the control's label
is shown at all times, the short hint given in the placeholder attribute
is only shown before the user enters a value. Furthermore, placeholder
text may be mistaken for a pre-filled value, and as commonly implemented
the default color of the placeholder text provides insufficient contrast
and the lack of a separate visible label reduces the size of the hit
region available for setting focus on the control.

It might be better if the MDN note was added to the HTML doc rather than 
an aria doc, but if we can't get it in there, it would add stronger 
guidance.
MDN note 
Note: Do not use the placeholder attribute instead of a <label> element. 
Their purposes are different: the <label> attribute describes the role of 
the form element; that is, it indicates what kind of information is 
expected, the placeholder attribute is a hint about the format the content 
should take. There are cases in which the placeholder attribute is never 
displayed to the user, so the form must be understandable without it. 

It seems like the HTML placeholder attribute should be picked up from 
standard controls without the need for a special aria property.  Is the 
aria-placeholder attribute for custom controls? Or could a developer do 
something like what is shown below and we would be happy with that?

<input type="text" name="fname" placeholder="First name" 
aria-placeholder="high school nickname"> 

I would think an input without an different placeholder and 
aria-placeholder would be more consistent with general guidance and be 
preferable. 

<input type="text" name="fname" placeholder="First name">  
Regards, 

Fred Esch 
Accessibility, Watson Innovations
AARB Complex Visualization Working Group Chair
W3C SVG A11y Task Force 




Dominic Mazzoni ---01/15/2015 10:40:36 AM---I like that note, but would it 
make sense for ARIA? After all, aria-placeholder itself wouldn't make

From: Dominic Mazzoni <dmazzoni@google.com>
To: Fred Esch/Arlington/IBM@IBMUS
Cc: "W3C WAI Protocols & Formats" <public-pfwg@w3.org>
Date: 01/15/2015 10:40 AM
Subject: Re: ACTION-1349: Creation of aria-placeholder



I like that note, but would it make sense for ARIA? After all, 
aria-placeholder itself wouldn't make something displayed - it's just a 
way to notify AT that a placeholder is there, maybe implementedvia an 
overlay or something.

On Thu, Jan 15, 2015 at 7:10 AM, Fred Esch <fesch@us.ibm.com> wrote: 
Joanie,

I like what you have, but I also like the note from MDN 
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input  as the 
MDN note explicitly states not to use a placeholder instead of a label. 

Note: Do not use the placeholder attribute instead of a <label> element. 
Their purposes are different: the <label> attribute describes the role of 
the form element; that is, it indicates what kind of information is 
expected, the placeholder attribute is a hint about the format the content 
should take. There are cases in which the placeholder attribute is never 
displayed to the user, so the form must be understandable without it. 



Regards, 

Fred Esch 
Accessibility, Watson Innovations
AARB Complex Visualization Working Group Chair
W3C SVG A11y Task Force 




Joanmarie Diggs ---01/15/2015 09:56:56 AM---Hi all. Proposed text for 
aria-placeholder follows. It's lifted pretty much

From: Joanmarie Diggs <jdiggs@igalia.com>
To: W3C WAI Protocols & Formats <public-pfwg@w3.org>
Date: 01/15/2015 09:56 AM
Subject: ACTION-1349: Creation of aria-placeholder




Hi all.

Proposed text for aria-placeholder follows. It's lifted pretty much
verbatim from the HTML5 spec. Thoughts?

<proposal>
Represents a short hint (a word or short phrase) intended to aid the
user with data entry when the control has no value. A hint could be a
sample value or a brief description of the expected format.

Authors SHOULD present this hint to the user by displaying the text
inside a blank unfocused control.

Note: As is the case with the related HTML placeholder attribute, use of
placeholder text as a replacement for a displayed label can reduce the
accessibility and usability of the control for a range of users
including older users and users with cognitive, mobility, fine motor
skill or vision impairments. While the hint given by the control's label
is shown at all times, the short hint given in the placeholder attribute
is only shown before the user enters a value. Furthermore, placeholder
text may be mistaken for a pre-filled value, and as commonly implemented
the default color of the placeholder text provides insufficient contrast
and the lack of a separate visible label reduces the size of the hit
region available for setting focus on the control.
</proposal>

--joanie

Received on Friday, 16 January 2015 00:23:24 UTC