Accessibility rule: Role with implied hidden content has keyboard focus, explained
Some HTML element roles define that all sub-elements will automatically become presentational. Presentational means that the content is only for visual purposes.
For example, the button role defines that whatever is inside an element with a role of a button will not be announced. Consider a “Save” button where the button contains an image of a floppy disk visually presenting the action of saving. This image should not be announced by screen readers. The user only needs to know that by clicking the button, something will be saved, but they don’t need to know that there is an image of a floppy disk on the button.
This rule flags any child nodes (sub-elements) that are made presentational based on their parent role but can receive keyboard focus. When a focusable element is hidden, users will not know what happens if they click on the element.
Who is impacted by this barrier?
Screen readers have a hard time identifying and structuring a website’s navigation if elements can be focused on but, at the same time, are not exposed to assistive technology. Furthermore, being able to focus on elements that should be presentational only makes keyboard navigation cumbersome.
How does the rule work?
The rule checks that elements with a role that makes its children presentational do not contain focusable elements. The rule applies to elements with a semantic role defining its children to be presentational children, which are all of the following:
How to fix the issue?
You can fix the issue in two ways:
- Remove the child node with the focusable content.
- Change the parent element role so that it doesn’t have a child node containing focusable content. Of course, you should not change a button into a paragraph or any other role if it is intended to be a button. That would break the accessibility of the page.
Did you find it helpful?Send feedback