Consider prohibiting author naming certain elements #160
Comments
@joanmarie have asked @sideshowbarker if he could gather some data. |
Can you be more specific about which other elements fall under that “and that like”? As far as HTML, does it basically mean any HTML elements that aren’t defined as labelable? https://html.spec.whatwg.org/multipage/forms.html#category-label …in other words, any element that’s not one of the following?
|
|
At present aria-label, aria-labelledby, and aria-describedby, only work on a subset of elements/elements with certain explicit roles. There is information in the Using ARIA Note and also this [blog post[(https://developer.paciellogroup.com/blog/2017/07/short-note-on-aria-label-aria-labelledby-and-aria-describedby/). FWIW I tend to agree with @joanmarie. Hearing an accessible name for something without knowing what that something is, would be confusing to me as a consumer. For example: May look like an icon but a screen reader would simply announce "Tequila". No information about whether it's text, an image, a button, or any other thing. |
|
So I notice that https://developer.paciellogroup.com/blog/2017/07/short-note-on-aria-label-aria-labelledby-and-aria-describedby/ says:
…but https://www.w3.org/TR/using-aria/#practical-support-aria-label-aria-labelledby-and-aria-describedby says:
So would we want to include |
No as these are implementation (AT bugs), the info is correctly conveyed in the acc tree and it is desirable to provide accessible names for such elements, to disambiguate multiple instances of the same element. |
|
From browser implementation perspective having lesser checks is a good thing, thus if @aria-label is exposed as accessible name on any accessible object, then it's nice and simple code. Having said that if has no use case and thus considered useless, then it makes sense to say this is en author error, but should the browser attempt to fix it, I'm not sure. |
|
There are definitely elements where aria-label makes no sense - But are there any use cases for using it as replacement text (ignoring AT support for now) to improve voicing? For example: |
|
I was directed here from this comment. validator/validator#776 (comment)
These elements are all very similar to one another.
Also see these links: https://www.w3.org/TR/html5/sections.html#headings-and-sections
|
|
@Dan503 please see: section and grouping element accessible name computation as this covers what you're asking about. @stevefaulkner already noted in this thread to @sideshowbarker that |
|
What should happen for elements with the Also looks like you need to allow aria-label on unexpected places like (BTW the CSS live editing example works in FF, Chrome and Safari) |
|
Another edge case - the https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-title |
|
Here's some data for "aria-label[ledby] on div/span with no role" in the wild. Glancing through the data below, it looks to me like many of the places where authors put aria-label[ledby] on a div or span with no role are just bugs (forgotten role, unnecessary aria-label, etc). :) However, I did notice a couple of valid use cases that we need to ensure we don't invalidate.
<a href="/shop/cart" class="cartTotal">
<span class="glyphicon glyphicon-shopping-cart" aria-label="Shopping cart"></span>
</a>
<a id="informationManagement" class="nav-link" data-target="#" href="/information-management" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">
Information management <span class="ion-ios-arrow-down"></span>
</a>
<div class="dropdown-menu mega-menu" aria-labelledby="informationManagement">
... dropdown menu containing list of links goes here ...
</div>Data for aria-label[ledby] on div/span with no role: |
|
Thanks for this @carmacleod Per the ARIA WG meeting yesterday, it seems consensus has moved to e.g. <button>
<span aria-label="foo"></span>
</button>should just be <button aria-label="foo"></button>still some things to further consider in this thread though... need to confer with @stevefaulkner on how we want to move forward. |
|
@dd8 presently |
|
@scottaohara Yep - just flagged it up as an edge case. It's unlike everything else ARIA applies to because it's exposed through the browser UI and not through the document - although it's arguably like the |
|
though the |
|
So it has a name calculation in: and is allowed by: Does this make sense, and at what point would the label be voiced? |
|
I've just run a couple of quick tests using:
```<body aria-label="Lorem ipsum">...</body>
```
And:
```<body aria-labelledby="title">
...
<h1 id="title">Lorem ipsum</h1>
...
</body>
```
I can't get NVDA, Jaws, or Narrator, to report the accessible name of
the body element, using Chrome, Edge beta, or Firefox.
This was a very quick test though.
|
|
On macOS VoiceOver/Safari 12 the With the
Without an
|
|
|
<a href="/" aria-label="home">
<i class="icon icon-home"></i>
</a> |
|
no one is disputing that @Dan503 ? There's already a naming algorithm for anchor elements. |
|
That comment didn't include |
|
That is different than being allowed to be given an accessible name via |
It should be noted that the screen reader outputs the label differently depending on the navigation method. I.e. with many elements, which are labelled with The label in the aria-label is used, however, e.g., to give the element in the element overview a label, in quick navigation or in tab navigation or to output the beginning and the end of a grouping with a label. This already works very well with JAWS, for example with the following test file:
|
|
As Joanie noted "screen readers are all over the map on this front" While it's true that JAWS may handle such examples in some cases, it's not a reliable way to expose information, and also not consistent with how other screen readers can handle similar patterns, making it problematic and something that should be advised against. |
|
It seems to me that it is not defined which HTML elements and ARIA roles are transparent despite explicit labeling (e.g. with If my assumption is correct, I can make suggestions on which elements should be transparent. JAWS is just an example, because it seems to me that it is some of the rare cases where screenreaders are better than the specification. If the screenreader were to label all elements equally according to AccName, most web pages would not work. |
|
@JAWS-test noted, and this sort of information will be incorporated into the current work that's being done to address this issue already. |
|
Here's scottaohara comment from #282 (comment), which I like how it summarizes the issue: "A bit of clarity there though. The naming prohibited in ARIA 1.2 is not a MUST, as naming such elements/roles is done in the wild now and it was not ARIA's intent to completely remove any naming mechanisms for those elements, but rather to inform authors that the elements shouldn't receive a name due to lack of consistently in it being exposed / desire that these elements really shoudn't be named." So if it reflects accurately the consensus on the issue, then the next thing left is to figure out which elements are affected and then how to inform authors that naming of such elements should be avoided. Does it sound about right? |
|
FWIW, I wrote a blog post several years ago which explains some of the complexity here and why screen readers ignore aria-label/ledby in cases like these. I think these proposed changes would address most of this, but I thought it worth providing the additional reference. |
Yes, it would be great if the group could decide that and then update the ARIA spec with some normative document-conformance requirements.
To help with that, the https://validator.w3.org/nu/ HTML checker has for quite a while now been emitting warnings for cases where But neither of those documents is normative. So what would be great is if we had actual authoritative, normative document-conformance requirements for this. And to be clear I don’t mean that the requirements need to be “must” requirements; they can be “should not” requirements and still be normative. |
|
In Material-UI, we use this pattern for the tooltip implementation: <span aria-label="Foo is commonly used with bar">Foo</span>It seems that there are not yet any official guidelines w3c/aria-practices#128. cc @eps1lon. |
|
@oliviertassinari please see role=generic in the ARIA 1.2 specification which recently entered candidate recommendation.
|
Question: Should
div,span,i,b, and the like supportaria-labelandaria-labelledby? Technically they do. And maybe they should. But I'm leaning towards no. Consider:<div aria-label="foo">A whole bunch of text goes here.</div>I would think and hope a screen reader should present "A whole bunch of text goes here." rather than "foo". I suppose one could make the case that a screen reader should present "foo" followed by "A whole bunch of text goes here." But I've not seen any such guidance to that effect. And some discussion in the ARIA Working Group suggests that screen readers are all over the map on this front.
IF all elements should be author-nameable, then I think we need authoring guidance and AT developer guidance to ensure interoperability. IF all elements should not be author-nameable, then I think we need the HTML-AAM's name calculation section should state this.
Related: During an ARIA WG discussion on this matter, the concern was raised that maybe our prohibiting naming of elements now would break legacy content. If memory serves me, one of the maintainers of the HTML-AAM is also a master of querying what is out there in the wild. 😄 If my recollection is correct, having that data would be neat. 😄
See also: w3c/aria#833
The text was updated successfully, but these errors were encountered: