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

relationship between native semantics of HTML popover feature and ARIA might need to be normalized. #513

Open
Zhang-Junzhi opened this issue Apr 15, 2024 · 5 comments · May be fixed by #514

Comments

@Zhang-Junzhi
Copy link

The current spec hasn't mentioned anything about popover, which is a new HTML feature.
The relationship between native semantics of HTML popover feature and ARIA might need to be normalized.

@scottaohara
Copy link
Member

scottaohara commented Apr 15, 2024

Nothing specifically for the popover attribute itself

popovertarget on a button should not have an aria-expanded declared with it.

@Zhang-Junzhi
Copy link
Author

Zhang-Junzhi commented Apr 15, 2024

Nothing specifically for the popover attribute itself

popovertarget on a button should not have an aria-expanded declared with it.

Might popovertarget have a native semantics equivalent to aria-controls?

  1. Does popovertarget forbid the attribute aria-controls?
  2. Or just forbid the target id in aria-controls(in case the button controlls other elements besides the popover target)?

And there's also popovertargetaction, which needs to be considered.

@scottaohara
Copy link
Member

scottaohara commented Apr 15, 2024

It doesn’t have an implicit aria-controls.

popovertargetaction doesn’t add any a11y semantics

@Zhang-Junzhi
Copy link
Author

Zhang-Junzhi commented Apr 15, 2024

It doesn’t have an implicit aria-controls.

I think maybe we cannot safely exclude (at least in any case) the possibility of an implicit aria-controls from popovertarget.
Since I found that the ARIA spec says the following about aria-expanded:

If a grouping container that can be expanded or collapsed is not the accessibility child of the element that has the aria-expanded attribute, the author SHOULD identify the controlling relationship by referencing the container from the element that has aria-expanded with the aria-controls property.

That is to say, it might be proper to have an implicit aria-controls(or an ID implicitly added to aria-controls) if the popover element is not the child of the element with popovertarget.

@scottaohara
Copy link
Member

Being that I helped spec what was to be implemented for popover and its related attributes, I'm very confident that aria-controls is not used, nor is it going to be implicitly used.

It'd be very rare to have a popover as a child of the popovertarget - since that attribute is only valid on buttons. In the few cases where that could happen, an aria-controls relationship would be useless (beyond the fact that aria-controls is already pretty useless outside of with comboboxes).

scottaohara added a commit that referenced this issue Apr 15, 2024
Closes #513

the `aria-expanded` state is implicit when using the `popovertarget` attribute - and authors are not to use the ARIA attribute with this native HTML attribute.
@scottaohara scottaohara linked a pull request Apr 15, 2024 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants