I think we need a definition of "User Interface Element"

[DavidMacDonald]

Recently, a Twitter thread got pretty interesting.

https://twitter.com/davidmacd/status/1040194227181780994
https://twitter.com/patrick_h_lauke/status/1041272243018522624

So I did some testing
http://davidmacd.com/blog/does-aria-label-override-static-text.html

AT is all over the map on it.

Then I dug into the spec to try to figure out what is supposed to happen in the accessible name calculation or in the aria-spec, when aria-label is on static content. the spec says the aria-label is to provide an "ACCESSIBLE NAME" and the glossary definition for an ACCESSIBLE NAME says it is for a "user interface element".
But there does not appear to be a definition for "user interface element" in the HTML spec, in the ARIA spec, the NAME COMPUTATION spec.

So would the following HTML elements be "user interface elements" to which the accessible name calculations should apply?

• heading,
• paragraph,
• div,
• span,
• legend,
• unordered or
• ordered list,
• list item.

Its probably dumb to place an aria-label on any of these, but its happening in the wild. Some clarity here would help direct screen reader manufacturers.

[devarshipant]

Good points @DavidMacDonald. I think at a minimum, it would help for the spec to mention scenarios where aria-label should be used to give an acc name (e.g., on elements that are 'natively focusable,' 'made focusable' like widgets, and structures like data tables).

[carmacleod]

Just to add some insanity to the discussion, :) there may be some scenarios where allowing aria-label/aria-labelledby on a div, for example, could be useful.

Consider the following markup (also available in div-with-label.html on github):

	<p>Styled spans with aria-label on parent div:</p>
	<div aria-label="Price: $4.99">
		<span>Price:</span>
		<span style="padding-left: 4px;">$4</span>
		<span style="vertical-align: super; font-size: 70%;">99</span>
	</div>

Visually, this looks like:

The author made an attempt to provide an accessible name, and the Chrome Accessibility Tree did expose the aria-label as "Price: $4.99", however both NVDA and JAWS say "Price: $499" instead of "Price: $4.99" (a significant difference in price that is only apparent visually).

We are looking at other ways to make it possible for authors to communicate styling that affects how text should be spoken, however allowing aria-label/aria-labelledby on div would be an easy thing for authors to understand and use.

What I don't know is how allowing accessible names on all of these elements would affect AT performance. Seems like it could take some time to check all divs/spans/etc for accessible names.

[jnurthen]

@carmacleod this is role=static which was discussed and previously rejected.
At the moment if you really need to do it you could use role="img". After all the rendering of the price is a little like a graphic so it doesn't feel too wrong.
There is even a branch which lives on https://rawgit.com/w3c/aria/role-static/#static
You can find some more gory details in meeting minutes like these https://www.w3.org/2018/01/11-aria-minutes.html#item02

[stes-acc]

We are looking at other ways to make it possible for authors to communicate styling that affects how text should be spoken, ..

I think the upcoming CSS Speech Module will address this better.

[carmacleod]

@jnurthen

this is role=static which was discussed and previously rejected.

Interesting - thank-you. With my author hat on, I like the power and simplicity of role="static".
However, as the discussion points out, that power can be used for good or (unintended) evil.
So I will defer to the group's decision to reject it. :)

@DavidMacDonald, thank-you for bringing this up. It may have implications for #699, so quite timely.
Your test results show that clarity is definitely needed. Interesting that aria-label[ledby] and aria-describedby are sometimes treated differently by AT for static elements. Some of the results look like AT bugs (for example, landmark labels should all be read). It would be useful to open AT issues for those.

For fun, here's another one seen in the wild:
<label aria-label="invisible label" for="input-id"></label>
NVDA/JAWS read the aria-label (quickly tested in Chrome), but it's pretty weird code.

@jamesn said:

We have discussed having a new value for "Accessible Name required" in the aria spec where we could say yes/no/not allowed.

Maybe we could use Name From: in the role Characteristics table. Currently, values are:

• "author"
• "author, contents"
• "n/a" (for abstract roles)

We could also say strictly "contents", which would mean author-supplied labels aren't allowed.
(Would need to explain this somewhere up front).

That may only be part of the story, though, because if the author makes an element interactive (and adds aria-haspopup, say), then maybe an author-provided aria-label would be allowed.

@stes-acc

I think the upcoming CSS Speech Module will address this better.

Thanks - wow: pause-before: weak; pause-after: strong; More things to think about for the not-yet-finalized aria-textseparation attribute for the generic role.

[jnurthen]

Can someone dig through this and determine if this is still necessary with the new name prohibited on "generic" elements.

Also noting that https://www.w3.org/TR/css3-speech/ is not a thing - the spec is obsolete.

If someone determines it is still necessary a PR with a proposed definition would help speed things up - otherwise I'm going to need to move this to 1.3

[scottaohara]

I do not think this is necessary anymore.

The naming prohibited as well as work being done on role parity essentially does away with the question of what roles should allow for naming. Updating ARIA in HTML and HTML AAM to further note what HTML elements can receive naming will also help to add further clarity.