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.
When 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.
When a 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)
on CodePen.
Further reading
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?