WCAG - Screen Reader NVDA reading placeholder information

Question

I came across a problem working with a screen reader (NVDA) reading placeholder information when it was not supposed to.

I have input with a title and placeholder. The screen reads placeholder first and then reads the title:

<div>
  <input type='text' placeholder='DD.MM.RRRR' title='Insert date correctely in the format DD.MM.RRRR' />
</div>

Based on the information provided by the web, the NVDA shouldn't read placeholder at first place, it should only be available for visual purposes. I've already tried some workarounds using aria-describedby and aria-placeholder .

The basic question is how to make placeholder invisible for screen readers?

JSFiddle

Answer 1

Screen readers will read the placeholder attribute when the field is empty.

This is expected behaviour in screen readers that support placeholders.

I think the confusion comes where it is advised not to use a placeholder instead of a label.

The reason is that once the field is filled in a lot of screen readers will not read the placeholder (as it is no longer shown) and so a completed field no longer has a name that can be read out by the screen reader. (plus visible labels help people with cognitive disabilities etc.)

So assuming that in production you have a <label> that is visible and is properly associated with your <input> then there is nothing you need to do here.

Answer 2

Adding on to what @GrahamRitchie said, keep in mind that all interactive elements have an "accessible name" and an "accessible description". Both are typically announced by a screen reader although you can change your screen reader settings to turn off the description (sometimes referred to as a "hint" in the screen reader settings).

How the accessible name and description are computed can be very handy in understanding this situation. There is a precedence list of attributes that are inspected to compute the name and description. Once an attribute is found, the remaining items in the precedence list are ignored. It's basically this:

• aria-labelledby
• aria-label
• placeholder attribute or <label> element
• other stuff
• title attribute

So if you have both an aria-labelledby attribute and a <label> element, only the aria-labelledby attribute will be used because it has higher precedence. The label will be ignored.

That being said, since your original code had an <input> that didn't have a label, the accessible name used the placeholder attribute. If you change your code to have a <label> , then the label will have higher precedence than the placeholder and the placeholder will be ignored for the accessible name . However, the placeholder might be considered for the accessible description.

You can see this in the accessibility inspector in Chrome. In the panel where CSS is usually displayed, there is an "Accessibility" tab (usually hidden in the ">>" menu).

Displaying the accessibility properties helps understand what is being announced by the screen reader.

Notice the "Name" (which is the accessible name) is "DD.MM.RRRR" and it says it comes from the placeholder attribute. It also says the "Description" (which is the accessible description) is "Insert date correctly...", which comes from the title attribute (but the tool doesn't tell you which attribute contributed to the accessible description).

If you were to have a <label> for your <input>

<label for="foo">date</label>
<input id="foo" type='text' placeholder='DD.MM.RRRR' title='Insert date correctely in the format DD.MM.RRRR' />

Notice how the accessible name changes. The placeholder is no longer used. The description stayed the same.

Now, all that being said, there are still two confusing points. The accessible name calculation , in step D, says if there's an attribute or an element that provides alternative text, then use it. But the example they give of an attribute is title . But down in step I (eye), it says if there's a tooltip attribute, then use it. Well, the title attribute IS the tooltip attribute so why is it used as an example in step D if it's going to be used in step I? I don't know, sorry. It's an ambiguity in the spec.

And just to add to the confusion, even though Chrome shows the accessible description is the title attribute, the placeholder is STILL read after the description, as if it were part of the description, even though it's not shown as part of the description in the inspector. I would consider that a bug. Whether it's a Chrome bug or NVDA bug remains to be determined.