Axe-core: Placeholder does not get recognized as label

[erikkroes]

Expectation: An <input> with a placeholder-attribute does not get recognized as having an accessible name

Actual: When I run aXe on FireFox at https://app.element.io/#, I get a violation on the search input. The input has a placeholder which should create an accessible name. Both FireFox and Chrome use this to create an accessible name, but aXe does not.
<input type="text" class="mx_RoomSearch_input" placeholder="Search" autocomplete="off" value="">
aXe still gives the violation "Form elements must have labels".

Motivation: It looks like a false positive.

axe-core version: 3.5.5
axe-webdriver, extension or other integration version: 4.5.3
Browser and Assistive Technology versions: FireFox 78.0.2

[straker]

Thanks for the issue. Tested in Safari/VO, IE11/JAWS, and Firefox/NVDA and all use the placeholder for the accessible name. Also confirmed in the accessible name computation spec.

[WilcoFiers]

I'd like to see Chrome+JAWS too, if it works there (in addition to the above, I agree we should add it in. I had no idea this was spec'ed. I heard when this went into Firefox, wasn't supported anywhere else at the time. Pretty surprised it works in IE.

[straker]

Confirmed in Chrome/JAWS

<input placeholder="foo bar baz">

"foo bar baz edit, foo bar baz typeof text"

[WilcoFiers]

alrighty, lets add placeholder to accessibleText

[WilcoFiers]

Don't agree with that label. This is a false positive.

[BogdanCerovac]

This one seems to be a bit more complex - although placeholder is accessible to assistive tech, it may be having other problems when used in combination - without visible label for example. So I guess it is not enough to only say it is a false positive.

This article describes the details that I think we should consider: https://www.deque.com/blog/accessible-forms-the-problem-with-placeholders/

Is it possible to make the rule a bit more context aware? I think it has to be, to really give correct answer... Something in this direction:

1. just a placeholder is not enough, element must also have a visible label,
2. placeholder contrast 4.5:1

This change can in my opinion encourage bad practice of using only a placeholder for inputs and should probably be investigated with context in mind.

[erikkroes]

Whether a placeholder is advisable or not (please don't), the feedback from Axe is a false positive in the context of WCAG. When contrast is an issue, it should report that.

[BogdanCerovac]

That's why I am against your suggestion in the first place - "please don't will soon be forgotten" as multiple users will argue that automatic tools don't report it as an issue, I am afraid.

It has the potential to encourage bad practices because it can be interpreted as if placeholder alone is enough. But it is not - in my opinion - because it can not guarantee a "persistent" label (in this case for sighted users).

This suggestion will allow a form with no "real" labels - for example made only of inputs with placeholders which would then fail Success Criterion 3.3.2: Labels or Instructions; https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html (when field is filled there is no way to see the label).

Imagine a form of 10+ fields with only placeholders as hints for the inputs.

So - I must oppose this suggestion if it is not at the same time also verifying presence of the alternative - visible - label.
Every documentation from the WebAIM that I've studied is supporting my concerns.

I guess this issue should at least be discussed more widely in the accessibility community before just accepting that placeholder alone is suitable for all users.

[WilcoFiers]

The label rule has a bit of a misleading identifier. The purpose of it is to check if a form control has an accessible name. As long as autocomplete does that in a way that is widely supported, that passes what axe-core tests in this rule. I get the issue with autocomplete, but it isn't inherently inaccessible, as long as there is some alternative. A common example of it would be if the field is adjacent to a button:

<input autocomplete="Search query" />
<button>search</button>

[BogdanCerovac]

OK, I get all the points made here, but I still can not agree with it as it will most probably encourage (even more) "placeholder abuse" if it will not consider the context around elements as well.

Assistive tech. reading the placeholder as label is one thing but then again, using placeholder as only "label" will not be accessible for sighted users with for example short memory problems.
And autocomplete example is maybe OK if check also takes the sibling elements into account (I am afraid that some design patterns will take the sibling button away for example).

I do not have any mandate here and so I can just hope that this change will not bring more harm to accessibility with allowing labels that are actually not accessible to all users (without context) to be treated as such.

[padmavemulapati]

Placeholder is recognised as label and its passing when Placeholder has something even it is escape characters and failing when placeholder is not present or placeholder has no contents.
<input id="target" placeholder="woohoo" />
<input id="target" />
<input id="target" placeholder="" />
<input id="target" placeholder=" \t \n \r \t \t\r\n " />

[straker]

No docs required

[mandrasch]

Hey (disclaimer: #a11y newbie here ;-)),

just a quick question regarding this:

Do I understand it correctly that axe does not perform an additional check for "Success Criterion 3.3.2: Labels or Instructions; https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html (when field is filled there is no way to see the label)." as @BogdanCerovac pointed out?

Demo: https://cdpn.io/mandrasch/debug/OJWOXbX/ZorBaLWLzjbM

No error on axe, WAVE:

(As I would expect it for WCAG testing)

Thanks in advance!

[dylanb]

@mandrasch please ask questions like this in the axe Community Slack, the short answer is "no" for axe-core, but "yes" for the axe Pro Forms tool -> https://axe.deque.com/