search

dequelabs / axe-core

Accessibility engine for automated Web UI testing
https://www.deque.com/axe/
Mozilla Public License 2.0
5.75k stars 746 forks source link

Axe doesn't fail use of the ARIA role attribute or global ARIA attributes on non-HTML elements #4502

Open Wildebrew opened 1 week ago

Wildebrew commented 1 week ago

Product

axe-core

Feature Description

Axe scans do not fail custom non-HTML elements with ARIA. The following elements pass: <foo-button role="button" tabindex="0">fake button</foo-button> or <foo-input aria-describedby="err1"</foo-ipput>

This type of scenario is common in design systems, especially for container elements, e.g. <foo-dialog role="dialog" aria-modal="true" aria-label="Warning!"> </foo-dialog> instead of <foo-dialog data-a11ylabel="warning"> resulting in <div role="dialog" aria-label="Warning">

Ultimately this may be a question for the ARIA spec but my limited testing reveals inconsistent support, also I believe this cannot be valid but I haven't found exact evidence for that.

WilcoFiers commented 1 week ago

Hey Birkir, long time no speak!

I'm not sure what you think the accessibility problem of this would be. As far as I'm aware custom elements can have roles and ARIA attributes just like native elements can. Can you share some of the tests you've done to show where this might not work?

Wildebrew commented 1 week ago

Likewise :) I'm out of the office today through Thursday but I'll go through my observations and post back a summary to this issue.

At the end of the day one shouldn't have to fail valid markup because of inconsistent accessibility support, but it's always on our collective radar.

WilcoFiers commented 1 day ago

Any updates @Wildebrew?