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

Layer's related aria-haspopup misplaced/misused #7192

Closed
Malvoz opened this issue Jul 1, 2020 · 3 comments
Closed

Layer's related aria-haspopup misplaced/misused #7192

Malvoz opened this issue Jul 1, 2020 · 3 comments
Labels
accessibility Anything related to ensuring no barriers exist that prevent interactions or information access

Comments

@Malvoz
Copy link
Member

Malvoz commented Jul 1, 2020

Currently, aria-haspopup is improperly set on the layer list's and control's container div element:

container.setAttribute('aria-haspopup', true);

The aria-haspopup description suggests that the attribute should be set on the element that triggers additional content (which is <a class="leaflet-control-layers-toggle"> in this case).

Indicates the availability and type of interactive popup element, such as menu or dialog, that can be triggered by an element.

It might be a good idea to check out the different patterns in the W3C ARIA Practices documentation to establish what sort of pattern would best fit the layer control (for example the disclosure widget).

@johnd0e
Copy link
Collaborator

johnd0e commented Jul 2, 2020

Currently, aria-haspopup is improperly set on the layer list's and control's container div element:

See d18f624.
It's sole function is proper functioning on Windows phones, and it seems ok.

@Malvoz
Copy link
Member Author

Malvoz commented Jul 2, 2020

@johnd0e Interesting, I found the explainer from Microsoft (and related mailing list conversations W3C, WebAIM).

The issue withstanding is that the triggering element does not have aria-haspopup, which per definition "indicates the availability" of popup content. When a user with a screen reader focuses the layer control, the screen reader wont convey information from ARIA attributes in (arbitrary) parent elements.

@johnd0e johnd0e added the accessibility Anything related to ensuring no barriers exist that prevent interactions or information access label Sep 17, 2020
@Malvoz
Copy link
Member Author

Malvoz commented Mar 26, 2021

Even if aria-haspopup was properly conveyed to users of assistive technology by moving it to the <a> control, it would be incorrect to do so because aria-haspopup has requirements on the type of content it controls:

aria-haspopup:

Authors MUST ensure that the role of the element that serves as the container for the popup content is menu, listbox, tree, grid, or dialog, and that the value of aria-haspopup matches the role of the popup container.

(note that the value true as currently used is treated as menu)

None of which I believe are appropriate for the layer controls list.

I'm closing this, superseded by #7526.

@Malvoz Malvoz closed this as completed Mar 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Anything related to ensuring no barriers exist that prevent interactions or information access
Projects
None yet
Development

No branches or pull requests

2 participants