No mention of aria-placeholder in name/description calculation algorithm

[joanmarie]

Moving this over from https://github.com/w3c/aria/issues/337.

Should aria-placeholder be part of the accessible description calculation?

[scottaohara]

Hey @joanmarie

re: the open mozilla ticket expose placeholder object attribute for HTML placeholder, @stevefaulkner noticed we were also missing placeholder in HTML AAM's accName, so we added it.

[joanmarie]

As per today's ARIA WG discussion, I opened an issue against HTML-AAM regarding the ordering/preference of title versus placeholder. Since we want to be in sync with them, we should probably wait until we have consensus on that issue before deciding what we want to do in AccName. https://github.com/w3c/html-aam/issues/168

[jnurthen]

From the comments in w3c/html-aam#168 I think it is agreed that placeholder should come after title. @joanmarie should we keep this on the agenda for this week?

[joanmarie]

From the comments in w3c/html-aam#168 I think it is agreed that placeholder should come after title. @joanmarie should we keep this on the agenda for this week?

If we have more to discuss, then yes. If instead the plan is to move forward and bring AccName into alignment with what's in HTML-AAM, then I don't think this needs to be on the agenda -- at least not until we have a pull request for AccName or further questions for which input is required.

[jnurthen]

Sounds like a plan.

[stes-acc]

I still AM a bit confused regarding placeholder as fallback in accessible name / description computation.

UIA-mapping-wise, content is transported using own designated property: https://www.w3.org/TR/core-aam-1.1/:

MSAA/UIA mappings for aria-placeholder : Object Attribute: placeholder-text: / Property: AriaProperties.placeholder:

and https://w3c.github.io/html-aam/ points to the https://www.w3.org/TR/core-aam-1.1/ for mapping of placeholder.

With other words, Jaws, NVDA whatsoever will speak placeholder by default no matter what is in accName/accDescription. At least this default makes sense for me.

Html-aam 5.1.1 maps placeholder as last resort and ARIA-WG decision in 3/7/19 meeting was to follow them here in the ARIA accessible name computation module.

In consequence, if placeholder will be mapped now in accName as last resort for cases like

<input type="text" placeholder="Search"/>

we will have a filled accName: <”Search”> AND a filled Object Attribute: placeholder-text:<”Search”> AND AT must DECIDE to speak ONLY ONCE of them on focus. That’s the caveat. Who is going to tell AT that?

In the last WG meeting minutes, it was said: “if you have a valid name and not description that idea is placeholder goes into the description”

The question is now REALLY and it must be made crystal clear if placeholder is rated as

a) “valid name” b) “tolerated fallback”

If a), then placeholder string

<label for=”ip1”>Cities</label> <input type="text" id=”ip1” placeholder="Search"/>

Will NOT go into accName but into accDescription.

If b) then placeholder string

<input type="text" placeholder="Search"/>

will go into accName (as discussed above). But what is with accDescription in this case? Read on.

Things get a bit more complicated now if we add a tooltip:

<input type="text" placeholder="Search" title=”Search for cities”/>

According to the logic given above, there must be now a precedence ruling applied for title vs. placeholder which is currently title > placeholder (is that so decided?) yielding accName=”Search” and accDescription=”Search for cities”.

But as a potential side effect of this mapping rule for this, in

<input type="text" placeholder="Search"/>

since title is NOT defined, do we have also an automatic fallback mapping of placeholder being mapped to the accDescription when title is missing in such cases? If so, this leaves us with accName=”Search” AND accDescription=”Search” AND a filled Object Attribute: placeholder-text:<”Search”> which AT needs to fiddle out what to speak now and what not because of redundancy.

I think in consequence when title or aria-describedby is NOT defined for that node, placeholder should not mapped AT ALL to accDescription.

This is what I meant saying we need concrete “what will happen” examples to discuss this.

[accdc]

Hi, I did mention moving this into the Description property conditionally, but with feedback from John and others, the group decision seems to be tilting towards having this be part of Name only, which is how the HTML AAM states this.

If this is the case, then placeholder content would only appear as Name if there were no prior labelling mechanisms detected, such as all those listed prior including the title attribute, otherwise placeholder would not appear in either Name or Description, and assistive technologies would then have to do whatever they wish with that information as they currently do now, because the placeholder content would not appear anywhere within either as part of AccName.

Does this make sense? Is this what people think this should do?

[devarshipant]

If this is the case, then placeholder content would only appear as Name if there were no prior labelling mechanisms detected, such as all those listed prior including the title attribute...

HI @accdc -- what are your thoughts on giving precedence to placeholder over title in the naming computation?

Here is the use case with placeholder + title + value on an input control.

• <input type="text" placeholder="First name" value="Dev" title="only first name">

The result (with Chrome 72 / JAWS 2019) 'First Name Dev only first name' seems okay as placeholder is concise (and hopefully vetted to be meaningful). I think Chrome already computes placeholder (First name) as name and title (only first name) as description in the accessibility tree as shown below.

However, the proposed HTML AAM gives precedence to title over placeholder in the name computation (see 3 and 4 below):

1. If the control has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1.
2. Otherwise use the associated label element(s) accessible name(s) - if more than one label is associated; concatenate by DOM order, delimited by spaces.
3. If the accessible name is still empty, then: use the control's title attribute.
4. Otherwise use the control's placeholder attribute.
5. If none of the above yield a usable text string there is no accessible name.

[accdc]

We did actually go over that, and the goal of the mappings is part of the role parody project, where it was brought up that these two specs need to be in alignment, so if we did make it so that placeholder whent before title, then the HTML AAM would need to change this to match this instead.

I'm not strongly aligned with either, but I need there to be ARIA WG agreement which one is the best course to follow, and if the latter, then the Web Platforms WG would need to agree as well.

[scottaohara]

to resolve this issue:

1. add mention of aria-placeholder in the html aam spec.
2. eventually (probably after aria-description issue is merged into accname as that will create merge conflicts otherwise) make mention of aria-placeholder in accName spec as a last-resort naming mechanism.
3. accName needs to eventually reference back to HTML AAM for specific elements and how they can be named (this might eventually then undo point 2).
4. generally HTML AAM needs a similar update for the naming computation section as I have recently done for descriptions. this would better support point 3 as well.

[spectranaut]

Link to discussion, which Scott summarized above, in today's meeting: https://www.w3.org/2022/10/27-aria-minutes#t07

[mbgower]

I thought I'd add an example of where I'm encountering this lack of clarity on placeholder as a problem in relation to Label in Name, which reads:

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Most of the time, a search input has no visible text label but it DOES have placeholder text. This is such a common pattern now that even where there is TONS of space available to put in a label, as in this example from the Google home page, there is no label, yet a placeholder provides some context (in this image "Search Google or type a URL").

Often these search mechanisms display a magnifying glass as a visual cue to the 'search' nature of the input. These icons may or may not be exposed to AT (they're often hidden to reduce verbosity from input type="search" and/or role="search").

For someone trying to meet Label in Name, the placeholder text is likely to be read by a speech input user, so it makes sense to ensure all or some of it is in the accessible name.

There is also the situation where the placeholder value may be a good differentiator for multiple search inputs on one page (one in header for site, one on the page for filtering, etc).

I'm not defending or celebrating the convention of ditching labels on search inputs (or in logon dialogs). I'm just flagging this real-world common convention.

Thanks for your efforts in this messy space!

[cookiecrook]

FYI WPT PR #42093 is about to be merged according to what's in the HTML-AAM spec. If this issue changes those expectations, please file a new issue on https://github.com/web-platform-tests/interop-2023-accessibility-testing/issues