Web Governance
Avoid focus on hidden and presentational elements
4.1.2 Name, Role, Value
This document gives information about the related accessibility (glossary term, activate to view definition) checks:
Element marked as hidden must not be included in tab navigation
Elements intended as presentation-only contain focusable content
Elements that are hidden from assistive technologies with the aria-hidden attribute or that are presentational children should not be focusable. When a user navigates through content with the Tab key, these elements should not receive focus.
Presentational children are elements that are nested within parent elements that have specific roles. For the following roles button, checkbox, img, meter, menuitemcheckbox, menuitemradio, option, progressbar, radio, scrollbar, separator, slider, switch, and tab the child elements inside them are considered presentational and therefore must not be focusable.
When elements are either hidden or presentational, they do not have a name that can be read by assistive technologies like screen readers, which are used by visually impaired individuals to have content read aloud. This becomes a problem for the user if these unreadable elements can still receive keyboard focus, because the user might then encounter something they can interact with, but without knowing what it is.
This check affects the following users who have:
Visual impairments: Who access the site contents with a screen reader or screen magnification software.
Mobility impairments: Who navigate the page with speech recognition software.
Bridgit is a blind mother to a five-year-old girl and an 11-year-old boy:
“Sometimes, my screen reader just keeps saying "link, link, link" over and over. I know there’s something I can click on, but I have no idea what it is. I remember when I was taking a Spanish evening class, there were all these "link, link, link" things on the website that I didn’t understand. It wasn’t until a couple of weeks later that I figured out they were sections for each lesson that you could expand. Somehow, my screen reader picked up on those links, even though I hadn’t gotten to that lesson yet. So it just kept saying "link, link, link," and I was completely lost.”
This section provides some examples of the issue.
In this example, there is a “Close” button containing a <span> element that can receive keyboard focus. The <span> element is focusable because it has a tabindex="0". The issue arises because child elements of buttons are presentational. As a result, the <span> element is both presentational and capable of receiving keyboard focus.
Web Governance<button aria-label=”Close”><span tabindex=”0”>X</span></button>A screen reader user may experience that the button, which visually appears as a single "Close" button, is read as two separate interactive elements: "Close, Button" and "X, clickable." This can be confusing, as there is only one function involved.
An "Accept terms and conditions" checkbox is embedded within a <div> element with aria-hidden="true". This is an issue because the checkbox is focusable and therefore should not be hidden from the user.
<div aria-hidden=”true”>
<label for="terms">
<input type="checkbox" id="terms" name="terms" required>
Accept terms and conditions. </label>
</div>Screen readers typically cannot handle this checkbox correctly because it is marked with aria-hidden="true", which hides it from the screen reader. However, since the checkbox is still focusable, it cannot be completely hidden either.
The Acquia Web Governance platform flags instances of focusable elements that are either presentational children or marked as hidden by the aria-hidden attribute.
For the case of "Element with aria-hidden has no content in sequential focus navigation":
First, determine if the element is something that the user should be able to see and interact with.
If the element is interactive, remove the aria-hidden="true" attribute.
If the element is not meant to be interacted with, adjust the code so that the element is not included in the sequential focus navigation.
For the case of “Element with presentational children has no focusable content”:
Adjust the code so that the element is not included in the sequential focus navigation.
There might be other ways to fix these errors. See the “ACT rules” section below, which includes a link to a complete technical explanation of these checks.
For full instructions on how to review an accessibility issue, visit How to review an accessibility issue
Related accessibility conformance testing (glossary term, activate to view definition) rules.
Element with aria-hidden has no content in sequential focus navigation
Element with presentational children has no focusable content
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Presentational children are elements that are nested within parent elements that have specific roles. For the following roles button, checkbox, img, meter, menuitemcheckbox, menuitemradio, option, progressbar, radio, scrollbar, separator, slider, switch, and tab the child elements inside them are considered presentational and therefore must not be focusable.
When elements are either hidden or presentational, they do not have a name that can be read by assistive technologies like screen readers, which are used by visually impaired individuals to have content read aloud. This becomes a problem for the user if these unreadable elements can still receive keyboard focus, because the user might then encounter something they can interact with, but without knowing what it is.
This check affects the following users who have:
Visual impairments: Who access the site contents with a screen reader or screen magnification software.
Mobility impairments: Who navigate the page with speech recognition software.
Bridgit is a blind mother to a five-year-old girl and an 11-year-old boy:
“Sometimes, my screen reader just keeps saying "link, link, link" over and over. I know there’s something I can click on, but I have no idea what it is. I remember when I was taking a Spanish evening class, there were all these "link, link, link" things on the website that I didn’t understand. It wasn’t until a couple of weeks later that I figured out they were sections for each lesson that you could expand. Somehow, my screen reader picked up on those links, even though I hadn’t gotten to that lesson yet. So it just kept saying "link, link, link," and I was completely lost.”
This section provides some examples of the issue.
In this example, there is a “Close” button containing a <span> element that can receive keyboard focus. The <span> element is focusable because it has a tabindex="0". The issue arises because child elements of buttons are presentational. As a result, the <span> element is both presentational and capable of receiving keyboard focus.
<button aria-label=”Close”><span tabindex=”0”>X</span></button>A screen reader user may experience that the button, which visually appears as a single "Close" button, is read as two separate interactive elements: "Close, Button" and "X, clickable." This can be confusing, as there is only one function involved.
An "Accept terms and conditions" checkbox is embedded within a <div> element with aria-hidden="true". This is an issue because the checkbox is focusable and therefore should not be hidden from the user.
<div aria-hidden=”true”>
<label for="terms">
<input type="checkbox" id="terms" name="terms" required>
Accept terms and conditions. </label>
</div>Screen readers typically cannot handle this checkbox correctly because it is marked with aria-hidden="true", which hides it from the screen reader. However, since the checkbox is still focusable, it cannot be completely hidden either.
The Acquia Web Governance platform flags instances of focusable elements that are either presentational children or marked as hidden by the aria-hidden attribute.
For the case of "Element with aria-hidden has no content in sequential focus navigation":
First, determine if the element is something that the user should be able to see and interact with.
If the element is interactive, remove the aria-hidden="true" attribute.
If the element is not meant to be interacted with, adjust the code so that the element is not included in the sequential focus navigation.
For the case of “Element with presentational children has no focusable content”:
Adjust the code so that the element is not included in the sequential focus navigation.
There might be other ways to fix these errors. See the “ACT rules” section below, which includes a link to a complete technical explanation of these checks.
For full instructions on how to review an accessibility issue, visit How to review an accessibility issue
Related accessibility conformance testing (glossary term, activate to view definition) rules.
If this content did not answer your questions, try searching or contacting our support team for further assistance.