1480831 - Error in Accessible Name Calc - Placeholder not eligible for Accessible Name

Status: NEW

(Core :: Disability Access APIs, defect, P3)

Description

[glenda.sims]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.2 Safari/605.1.15

Steps to reproduce:

There is a mistake in the way the Firefox Accessibility Inspector is calculating accessible name. It is currently reporting (for a field that only has a placeholder) that the placeholder is the accessible name.

Code to test: <input type="text"  name="first"  placeholder="First Name" id="first">
Sample of code to test: https://codepen.io/goodwitch/pen/OwEmEw
Firefox Accessibility Inspector reports this field as having an accessible name of “First Name”


Actual results:

According to the W3C Accessible Name Calc, placeholder is not eligible to be considered when determining the accessible name. https://www.w3.org/TR/accname-1.1/


Expected results:

Firefox Accessibility Inspector should report the accessible name as null.

Comment 1

[James Teh [:Jamie]]

Note that this applies more broadly to Firefox accessibility (including what gets exposed to AT), not just to the Inspector.

The current implementation was done in bug 545817 (AFAIK, before the spec included any guidance on this). When there is nothing else to expose as the accessible name, we use the placeholder.

I agree that this implementation does not comply with the spec. The question is whether this is a bug in the spec or a bug in Firefox. :)

While we certainly don't want to expose the placeholder as the name if there's already a name, it seems sensible (to me, anyway) to use the placeholder if there's nothing else we can use for the name. I'd argue that an unnamed accessible is a lot worse for users than conflating laceholder and label... and it certainly doesn't "hurt" users. Note that Chrome has the same behaviour.

Glenda, what are your thoughts on this? If you agree, the next step would I guess be filing a bug against the spec.

Comment 2

[glenda.sims]

Hi Jamie,  I'm pretty sure that the Accessible Name calc defined at the W3C purposefully did not include placeholder. I'm double-checking with the W3C now.  I'll keep you posted on what they say.

Comment 3

[jon.avila]

In my opinion a placeholder is not the same as an accessible name and allowing it to become the accessible will only allow developer to rely on it to provide an accessible name -- which it should not.  The placeholder acts more like a description or hint and provides an example value -- not accessible name.  The W3C accessible name calculation understanding as indicated in the HTML accessibility API document is correct and the calculation in Firefox is not according to the standard.  Would you allow the file name of an img to be used as the accessible name of the image if non-existed?

Comment 4

[James Teh [:Jamie]]

(In reply to jon.avila from comment #3)
> In my opinion a placeholder is not the same as an accessible name

I'm not arguing it is.

> and
> allowing it to become the accessible will only allow developer to rely on it
> to provide an accessible name -- which it should not.

And yet the title attribute is a valid source for the accessible name, despite the fact that it doesn't look like a label. It could be equally argued that permitting this allows developers to rely on the title attribute instead of a better, more visible labelling mechanism.

> The W3C accessible name calculation understanding as
> indicated in the HTML accessibility API document is correct and the
> calculation in Firefox is not according to the standard.

Normally, W3C specs don't become standards without at least two implementations of everything (though the rules have been relaxed for ARIA). This is largely to ensure that things are implementable and reasonable in the wild. Two of the major implementations (Firefox and Chrome) don't implement this as specified. I haven't checked in Safari and Edge, so maybe those browsers served as the demonstrable implementation. Still, the fact that Firefox isn't the only browser doing this at least raises questions about whether this is a practical mapping.

> Would you allow
> the file name of an img to be used as the accessible name of the image if
> non-existed?

That is a totally unreasonable comparison. The src of an img was never intended for user consumption and could thus be totally meaningless. In contrast, placeholder is definitely meant for user consumption. I'd like to see at least one reasonable, realistic example of where using placeholder as name (in the absence of any other name) hurts users more than having no name at all. The fact that there is very little practical information as to how some of these spec decisions were reached (beyond apples to chickens examples such as placeholder vs img src) is concerning at best.

Comment 5

[glenda.sims]

Hey Jamie,

Just a quick note to let you know that I'm still looking for clarification at the W3C on this.  And...for what it is worth...I've personally changed my mind.  I think you are right (and the spec needs to change).  I'll keep you posted.  And thanks for everything you do to make the web accessible for all.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #1)

> While we certainly don't want to expose the placeholder as the name if
> there's already a name, it seems sensible (to me, anyway) to use the
> placeholder if there's nothing else we can use for the name. I'd argue that
> an unnamed accessible is a lot worse for users than conflating laceholder
> and label... and it certainly doesn't "hurt" users. Note that Chrome has the
> same behaviour.

That is my thinking. However I have to notice that aria-placeholder was never mapped to accessible name, even as a last resort. Iirc HTML mapping guidelines was used to say that @placeholder should be used as a fallback name, but it was removed in favor of  conformance with aria-placeholder. I argued against this, saying it could make web sites less accessible, but iirc was told that @placeholder with no name should be considered an authoring error.

Comment 7

[James Teh [:Jamie]]

(In reply to glenda.sims from comment #5)
> And...for what it is worth...I've personally changed my
> mind.  I think you are right (and the spec needs to change).

FWIW, I'm keeping an open mind on this. And if we can't get the spec changed, I think Firefox should change this behaviour; compliance with the spec is of utmost importance. That said, if the end result is that the spec shouldn't change, I'd like to see some solid, real world examples as to where this behaviour is harmful to users.

(In reply to alexander :surkov (:asurkov) from comment #6)
> I have to notice that aria-placeholder was
> never mapped to accessible name, even as a last resort. Iirc HTML mapping
> guidelines was used to say that @placeholder should be used as a fallback
> name, but it was removed in favor of  conformance with aria-placeholder.

This is a tricky one. If an author is using ARIA attributes, it's reasonable to assume they have at least some idea of what they're doing; i.e. I'm not sure why an author would choose aria-placeholder when there's an obvious (arguably more obvious) aria-label in the same spec. However, HTML placeholder is a bit different; <label> looks very different visually to placeholder, and it's not unreasonable to think that an author might be less aware of correct semantics than an author using ARIA itself.

> I argued against this, saying it could make web sites less accessible, but
> iirc was told that @placeholder with no name should be considered an
> authoring error.

I actually agree: it *should* be considered an authoring error. A validation tool should absolutely flag this as an error. That doesn't mean we shouldn't try to map this "error" such that it hurts users less when authors screw it up, unless we inadvertently hurt users in doing so. The earlier example from comment 3 of using src in place of alt would hurt users, as would trying to "guess" labels for completely unlabelled form fields. The former might result in non-intelligible names and the latter might result in misleading the user (e.g. a label for a different field). In contrast, placeholder is associated with the same field, so at worst, it might be more of an example than a real label, but it's still not "misleading" (and thus hurting) the user.

Comment 8

[David MacDonald]

http://davidmacd.com/blog/is-placeholder-accessible-label.html

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.