Categories
HTML Accessibility

short note: why isn’t role=presentation/none allowed on focusable elements?

The man who mistook a hydrant cover for an early prototype of R2D2.

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.

Further listening

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

Leave a Reply

Your email address will not be published.