Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A generic element (with aria-live) intervening with the parent/descendant relationship. #2423

Open
giacomo-petri opened this issue Jan 31, 2025 · 2 comments
Labels

Comments

@giacomo-petri
Copy link
Contributor

I was checking one of the Failed examples in the ACT Rules about "ARIA required context role" (Failed example 3). I'm unsure about the expected violation of the acc parent/descendant relationship in the following case:

<div role="list">
	<div aria-live="polite">
		<div role="listitem">List item 1</div>
		<div role="listitem">List item 2</div>
	</div>
</div>

The accessibility parent si defined as:

The accessibility parent of a DOM element is the parent of the corresponding accessible object in the accessibility tree. In terms of the DOM, the accessibility parent is one of the following:

  • The DOM parent of the element.
  • The DOM ancestor of the element with only elements of role generic or none intervening.
  • A DOM element with aria-owns set to the DOM ID of the DOM element in question.
  • A DOM element with aria-owns set to the DOM ID of an ancestor of the DOM element in question, with only elements of role generic or none intervening.

So, it looks like the code above is valid.

On the other hand, the generic role states:

However, unlike elements with role presentation, user agents expose generic elements in accessibility APIs when permitted accessibility attributes have been specified. User agents MAY otherwise ignore generic elements if such permitted attributes have not been specified.

so, the generic element with aria-live="polite" is exposed. I don’t believe this impacts the validity of the code above, but I’d appreciate confirmation.

Last, but not least, in Presentational Roles Conflict Resolution:

If an element has global WAI-ARIA states or properties, user agents MUST ignore the none/presentation role and instead expose the element's implicit role.

we have a generic element with a global property, causing the UA to ignore the none role and expose the implicit role (which is still none). This shouldn’t impact the validity of the code.

Thoughts?

Thanks

@scottaohara
Copy link
Member

Good catch. The list isn’t working right with that intervening generic on iOS, from my quick testing on my phone.

I would submit that the reference to generic is not clear enough- in that browsers prune generic roles, essentially treating them like role=none, except when the global attributes are present or they’re focusable. Then they’re exposed as generic roles.

So either the spec needs to update to throw in the caveat that by generic, it means generic so long as it has no a11y importance - or - browsers/at need to adjust to allow generics even when they aren’t ignored, to not break expected a11y parent/child relationships.

@WilcoFiers
Copy link
Contributor

Thanks for raising this @giacomo-petri. It also seems to me this is the same problem that role=none has. It allows global ARIA attributes, except that role=none is sometimes explicitly ignored as per presentational role conflict. Generic would seem to be the same thing. If a generic role meets any of the conditions in presentational role conflict, user agents must put it in the accessibility tree, otherwise they must ignore it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants