Product
axe-core
Product Version
4.8.2
Latest Version
Issue Description
We are currently migrating our Web Component library to use the ElementInternals API to set default ARIA attributes, such as role, on all of our semantic host elements instead of sprouting these role attributes when the element is connected. This allows for setting default semantics, while still allowing for consumers to override these semantics if necessary. Upon doing so, axe is flagging some of these custom elements as critical issues that appear to be false positives.
It's worth noting that axe will not flag these elements if any non-empty text nodes appear in the shadow DOM of the element, or if the role attribute is set directly on the element.
Expectation
Custom Elements that use ElementInternals to set their default role should not be flagged by axe-core.
Actual
The extension produced the following critical error:
aria-label attribute cannot be used on a custom-progress-internals with no valid role attribute.
How to Reproduce
The following codepen is a reproduction in the simplest form that shows a custom element with a default role of progressbar set via ElementInternals, along with an aria-label set in the light DOM on the host:
https://codepen.io/drifty17/full/WNPgvoM
Open the axe extension in DevTools and scan the page to see the error:
Upon viewing the accessibility tree you can also see that the semantics appear to be set properly (tested with VoiceOver as well and it interpreted it correctly):
Additional context
I added an additional (working) example of a separate custom element for comparison that is identical except that it will sprout the role attribute when it connects to the DOM. When the role attribute is present on the element, axe does not flag the element, but when the same role is set via ElementInternals instead it does get flagged.
Product
axe-core
Product Version
4.8.2
Latest Version
Issue Description
We are currently migrating our Web Component library to use the
ElementInternalsAPI to set default ARIA attributes, such asrole, on all of our semantic host elements instead of sprouting theseroleattributes when the element is connected. This allows for setting default semantics, while still allowing for consumers to override these semantics if necessary. Upon doing so, axe is flagging some of these custom elements as critical issues that appear to be false positives.It's worth noting that axe will not flag these elements if any non-empty text nodes appear in the shadow DOM of the element, or if the
roleattribute is set directly on the element.Expectation
Custom Elements that use
ElementInternalsto set their defaultroleshould not be flagged by axe-core.Actual
The extension produced the following critical error:
How to Reproduce
The following codepen is a reproduction in the simplest form that shows a custom element with a default
roleofprogressbarset viaElementInternals, along with anaria-labelset in the light DOM on the host:https://codepen.io/drifty17/full/WNPgvoM
Open the axe extension in DevTools and scan the page to see the error:
Upon viewing the accessibility tree you can also see that the semantics appear to be set properly (tested with VoiceOver as well and it interpreted it correctly):
Additional context
I added an additional (working) example of a separate custom element for comparison that is identical except that it will sprout the
roleattribute when it connects to the DOM. When theroleattribute is present on the element, axe does not flag the element, but when the sameroleis set viaElementInternalsinstead it does get flagged.