A friend and colleague pondered why ARIA
role=presentation and its facsimile
role=none is not allowed on focusable elements?
The answer is, theses days, purely a function of implementation reality. It don’t work on interactive elements or indeed any focusable elements, regardless of their semantics.
role=none is used on a non-interactive element such as
aside, its role semantics are suppressed. The role is not exposed in the browser accessibility tree and is therefore not announced by screen readers.
tabindex attribute is added to the element, making it focusable, the role semantics are no longer suppressed. Likewise on controls, such as
input type=text, the role semantics are not suppressed. The role is exposed in the browser accessibility tree and is announced by screen readers.
Try it for yourself:
See the Pen
Untitled by steve faulkner (@stevef)
For a complete list of where and when ARIA attributes are allowed to be used on HTML elements, refer to the ARIA in HTML specification.
2 replies on “short note: why isn’t role=presentation/none allowed on focusable elements?”
This is a problem for form-associated custom elements which include a built-in input in their shadow root, as an implementation detail.
Authors will want to hide the shadow input from the accessibility tree, since the FACE asserts it’s own semantics via ElementInternals.
I would like to see implementers relax this rule for inputs in the shadow of a FACE
Hi Benny, can you provide a text case for the issue you are describing?