In a mobile first world many websites use placeholder text to save space. Let's test to see if its a good idea. In the form field type in a first name. We will want to consider users who are blind, and users with cognitive disabilities.

Code used

<form>
<input type="text" placeholder="First Name">
</form>


Findings

Results for Screen Reader users when text is entered over top of the placeholder text

	JAWS 2018	NVDA 2018.1	VoiceOver
Firefox 61	Placeholder does not read	Placeholder reads first followed by Value	N/A
IE 11.165	Placeholder reads first followed by Value	Placeholder reads first followed by Value	N/A
Edge 42.17	Placeholder reads first followed by Value	Value reads first followed by Placeholder	N/A
Chrome 67 on WIN 10	Value reads first followed by Placeholder	Placeholder reads first followed by Value	N/A
Safari MacOS	N/A	N/A	Value reads first followed by Placeholder
Chrome on Mac	N/A	N/A	Does not read placeholder
Safari iOS	N/A	N/A	Does not read placeholder

 

For screen readers, support is uneven. On some stacks, the placeholder attribute will populate the Accessible Name in the accessibility API, because there is no other Accessible Name. When the user types in their first name, that text populates the Value bucket of the Accessible API, and the Placholder continues to read. The Accesssible Name Calculation loads the placeholder text and maintains it throughout the lifecycle of the tasks. However, on some systems we see that the label does not persistently read.

Users with Cognitive disabilities

For people with cognitive disabilities who are not using assistive technlology, the visible Label disappears as soon as a value is entered into the input, and for that reason a static placeholder is insufficient, because the user may not remember the label, and the value in the input may not be correct or may not sufficiently infer the label.

What does WCAG say?

3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)

The SC says labels OR instructions. In practice, in 10 years I've never seen instructions used in place of a label, although technically they could be used instead of a label.

Definition of Label in WCAG

label

text or other component with a text alternative that is presented to a user to identify a component within Web content

Note 1: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.

Note 2: The term label is not limited to the label element in HTML.

The notes of the definition make it clear that the WCAG WG intended the label to be visible, by saying it is presented to ALL users and by juxtaposing it to a "name" which can be hidden. As someone on the team that wrote WCAG 2.0 from 2002 onwards I can confirm that was our intention.

Solution

Many organizations are moving to floating labels which move out of the field and stay visible when there is a value entered in the input. It is an actual label which is positioned over the input and moved out with CSS when content is in the input. This is the best way to implement text that is inside the input, if it is to serve as the Accessible Name.

See Also

Test aria-describedby with placeholder text

Feel free to comment on Twitter @davidmacd

Author information:

David MacDonald is a veteran WCAG member, co-editor of Using WAI ARIA in HTML5 and HTML5 Accessibility Task Force Member. Opinions are my own.