Firefox uses it if accessible name wasn't provided otherwise. I think this makes sense not depending whether placeholder has own accessibility API mapping.

There's currently the following note for the accessible name calculation involving @placeholder at [1]:

"When the placeholder and aria-placeholder attribute are both present, and the placeholder attribute is non-empty, the user agents MUST expose the value of the placeholder attribute, and ignore @aria-placeholder.  If @placeholder is empty, then user agents MUST expose the value of @aria-placeholder."

I'm wondering why this wouldn't be the other way around, namely @aria-placeholder winning over @placeholder? This would be consistent with the way that @aria-* typically overrides the usual author-supplied label or name.

And in terms of including @placeholder in the name calculation, I assume we're happy with the fact that this will make @placeholder a legitimate way to meet WCAG 2.0 SC 4.1.2 [2]?


[1] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element

[2] http://www.w3.org/TR/WCAG20/#ensure-compat-rsv

Forgot to ask if we shouldn't also be mapping @placeholder to @aria-placeholder?

*** Bug 28270 has been marked as a duplicate of this bug. ***

(In reply to Jason Kiss from comment #2)
> There's currently the following note for the accessible name calculation
> involving @placeholder at [1]:
> 
> "When the placeholder and aria-placeholder attribute are both present, and
> the placeholder attribute is non-empty, the user agents MUST expose the
> value of the placeholder attribute, and ignore @aria-placeholder.  If
> @placeholder is empty, then user agents MUST expose the value of
> @aria-placeholder."
> 
> I'm wondering why this wouldn't be the other way around, namely
> @aria-placeholder winning over @placeholder? This would be consistent with
> the way that @aria-* typically overrides the usual author-supplied label or
> name.

as I understand it the current trend is aria steps back before native markup if they are in conflict. So if the HTML control supports @placeholder then @aria-placeholder should be ignored and it should be considered as an author error.

(In reply to Jason Kiss from comment #3)
> Forgot to ask if we shouldn't also be mapping @placeholder to
> @aria-placeholder?

I'm not sure that mapping is correct word to describe the relationship, because we get into nonsense if @placeholder is mapped to @aria-placeholder, and @aria-placeholder is ignored when @placeholder is present. But surely @aria-placeholder is ARIA equivalent of HTML @placeholder and vice versa.

There's this from the ARIA spec [1]:

"Authors need to associate elements in the document to a WAI-ARIA role and the appropriate states and properties (aria-* attributes) during its life-cycle, unless the elements already have the appropriate implicit WAI-ARIA semantics for states and properties. In these instances the equivalent host language states and properties take precedence to avoid a conflict while the role attribute will take precedence over the implicit role of the host language element."

That suggests as you say, that @placeholder should take precedence over @aria-placeholder. 

I'm now thinking I was just confused by this note re @placeholder following the name calculation section. Correct me if I'm wrong, but here "expose" does not have to do with using it as source in name calculation? And in that case the note should be moved to the @placeholder entry in the mapping table? 

But this does get me wondering about @aria-label taint precedence over a properly associated and explicit <label> In the name calculation? It would be author error to have both, but why does the ARIA value override native label feature for name calculation? Anyone care to edumacate me?

WRT mapping of @placeholder, I meant shouldn't its mapping leverage the same mapping for @aria-placeholder, ie we can point to it and note "Use WAI-ARIA mapping"?


[1] http://www.w3.org/TR/wai-aria-1.1/#usage

From the HTML side I would think that use of aria-placeholder on elements that use of placeholder is conforming, will be non-conformaing. I don't see any reason why aria-placeholder would be needed in this case, do you?

Making @aria-placeholder non-conforming when used on element with conforming @placeholder makes sense. Where does this non-conformance get expressly noted?

(In reply to Jason Kiss from comment #8)
> Making @aria-placeholder non-conforming when used on element with conforming
> @placeholder makes sense. Where does this non-conformance get expressly
> noted?

it's a good question, which spec should take care of it, both?

(In reply to alexander surkov from comment #9)
> (In reply to Jason Kiss from comment #8)
> > Making @aria-placeholder non-conforming when used on element with conforming
> > @placeholder makes sense. Where does this non-conformance get expressly
> > noted?
> 
> it's a good question, which spec should take care of it, both?

Should it be noted in ARIA in HTML? https://specs.webplatform.org/html-aria/webspecs/master/#docconformance

placeholder should not be part of the name calculation. Please link to the Core accessibility api mapping spec. for how to map placeholder. aria-placeholder is part of ARIA 1.1

(In reply to Rich Schwerdtfeger from comment #11)
> placeholder should not be part of the name calculation. Please link to the
> Core accessibility api mapping spec. for how to map placeholder.
> aria-placeholder is part of ARIA 1.1

hi Rich, so browsers should remove their current @paceholder acc name implementations? I think that will result in a lot of form fields without accessible names.

(In reply to Rich Schwerdtfeger from comment #11)
> placeholder should not be part of the name calculation. Please link to the
> Core accessibility api mapping spec. for how to map placeholder.
> aria-placeholder is part of ARIA 1.1

The ARIA wg have concluded that placeholder is not to be used as a fallback source for accessible name, can browser reps respond to this and commit to changing any current implementations?

I had a look back through the minutes of PF and ARIA meetings for the last month or so trying to find discussion on placeholder, to no avail. If anyone can point me to discussion of the issue other than the April PF thread i cited in the Description of this bug, it would be much appreciated.

note: currently all browsers map placeholder to acc name when no other source of acc name is found
http://www.html5accessibility.com/tests/placeholder-labelling.html

I would disagree with wg conclusion because
* that will regress the web accessibility. HTML5 placeholder a11y mapping exists for years and adopted by the web, while the proposed mapping is not yet supported by all browsers and all ATs.
* that may be semantically incorrect since the web authors do use placeholder instead labels occasionally.

HTML AAM is no longer an ARIA Deliverable. If you wish to pursue this issue please file at https://github.com/w3c/html-aam/issues