[extra88]

Adding a name to an element without a role, like span or div, is technically invalid; in this example, only the <ul> elements have valid names added to them, because they implicitly have the role of "list."

Also, aria-label and aria-labelledby replace the contents of an element when the contents would otherwise be the name; if the <span> elements where <p> instead (which has an implicit role), screen readers would only read "IMDb rating" and not "IMDb 8.2."

What might be happening is the aria-label attributes are ignored but the title attributes are used as a description after the contents. For some elements `title` can be used as an element description; I think descriptions are also invalid without a role but they may get used anyway.

I think it's best for a visualizing tool to not display attribute information that won't be used by screen readers.

[afloatboat]

That's some good feedback and I honestly think this should have been an definition list from the start.

I was interested about how it would change if I replaced those `span` with `p` and it still reads the entire block for me with VoiceOver.

- Parental guidance, group

- [arrow right]

- end of, Parental guidance, group

- [arrow right]

- 14+

- [arrow right]

- Production Year, group

- …

When I look at the Chrome Accessibility Tree it shows

heading "Tags"

  paragraph "Parental guidance"

    StaticText "14+"

  paragraph "Production year"

    StaticText "2016"

When I revert back to the span the `paragraph` is replaced by `generic`. I only have hands on experience with VO so I imagine that JAWS/NVDA might yield different results.

I do believe you're right that this shouldn't be a `aria-label` and I will replace it with `aria-description`, but I don't think that we can say that `aria-label` should only be used to fully replace the contents, as a landmark container would also be named by aria-label: https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/...

Edit: I just tested this but `aria-description` is not read at all. And https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... seems to indicate that aria-label should still be ok, but the div does have a `role="application"`

[extra88]

Be aware that the vast majority of people who rely on VoiceOver use Safari as their browser; on mobile devices, they have no choice. There are some ways in which Chrome for Mac does a better job of managing its accessibility tree than Safari but there are a bunch of other issues.

Accessible Name and Description Computation is complicated, some elements can get their name from their contents and some can't; frankly, I can't keep it all straight in my head.

https://www.w3.org/TR/accname-1.2/

Additionally, there's what the specs say and what browsers and screen readers actually do.

VoiceOver doesn't support the `aria-description` attribute yet. The `title` attribute is often computed as an element's description, when it's not computed as its name (it's not a good choice for naming elements, except <iframe>).

https://a11ysupport.io/tech/aria/aria-description_attribute

`role="application"` isn't a good role for static content and should only be used when letting a screen reader used its keyboard shortcuts would interfere with the user operating interactive controls (which should rarely be the case).

https://www.w3.org/TR/wai-aria-1.2/#application

[afloatboat]

Don’t get me wrong, I was just making an observation about a ‘role’ being specified. Not suggesting the role=“application” should be used here.

Ultimately in my case I’m leaning to either replacing the production year, parental guidance and IMDb rating with a dl or prepending sr-only titles to the individual tags.

I tested the page with VO on Safari and got the same results as on Chrome. So the good thing is that in practice the current setup appears to be accessible, but it’s frustrating that the theory seems to be different and just not clearly defined.