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

[Wildebrew]

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]

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]

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]

Any updates @Wildebrew?