This document gives information about the related accessibility checks:
Element needs to have the right semantic role.
What
User interface controls must have the correct semantic roles.
The semantic role of an element can be set implicitly by its HTML tag or explicitly with the ARIA role attribute.
Why
Assistive technologies such as screen readers rely on semantic roles to accurately convey the purpose and functionality of input controls. For example, the button role indicates an element that triggers an action, such as a form submission or when you open a dialog box. The link role identifies navigational elements that take users to a different page or section. Similarly, a checkbox role signals an option that can be turned on or off with a toggle, while a radio button role represents a selectable choice within a group of options. Without the correct roles, these controls may be misinterpreted. Incorrect role assignment leads to confusion and hinders users that rely on assistive technologies from effective interaction with the control. Proper semantic roles ensure a clear and intuitive user experience.
This check affects the following users with:
Visual impairments: Who rely on screen readers to understand and navigate input controls.
Mobility impairments: Who navigate and interact with controls using alternative input devices.
User story
Bridgit is a blind mother to a five-year-old girl and an 11-year-old boy:
"I signed up for a customer communication course at the community college to help me get better at handling front desk work. They had this website with extra tips and templates for emails and phone scripts, but you had to click buttons to expand the sections. My screen reader did not even mention that there were buttons, so I just thought the page was empty in places. Later, someone told me about it, and I felt awful knowing that I had missed stuff that could have made my job easier. It is like, how am I supposed to learn if the tools they give me do not even work for someone like me?"
Examples
This section gives some examples of the issue.
Example: Date of birth field with inaccessible info icon
On a health insurance application form, users are required to input their date of birth. Next to the date of birth field, an info icon is provided to explain the required format (for example, MM/DD/YYYY) and to inform users about age restrictions for eligibility. However, this information is only revealed after the user clicks the icon. The info icon is implemented as a simple <span> element:
When a user navigates this form with a screen reader, the info icon is completely overlooked. The screen reader may announce a "?" question mark symbol, but it does not convey to the user that it functions as a button that can be activated to reveal additional information.
Example: Date of birth field with accessible info icon
On a health insurance application form, users are required to input their date of birth. Next to the date of birth field, an info icon is provided to explain the required format (for example, MM/DD/YYYY) and to inform users about age restrictions for eligibility. This information is revealed when the user interacts with the icon. The info icon is implemented with a proper semantic role <button>.
When a user navigates this form with a screen reader, the icon is announced as an interactive element. The screen reader announces:
“More info button, collapsed.”
This makes it clear to the user that they can interact with the icon to reveal important guidance.
How
How to review it.
The Web Governance platform highlights instances where the code indicates that elements can be activated with a mouse but are not coded as semantic links.
Your task is to evaluate whether these elements are interactive controls, for example, elements that users can interact with in the interface, and, if so, determine if they have an appropriate semantic role.
You should examine each element and ask yourself, "What is this?"
For example, the element could be a button, checkbox, radio button, or similar.
Once you have identified the type of element, you need to check whether it has the correct semantic role. For example, if you see a button on the screen, its semantic role should also be a button.
You can use the developer tools provided by your browser to inspect the semantic role of the element.
Right-click on the element that you want to inspect.
Select “Inspect” from the context menu.
In the DevTools panel, go to the “Elements” tab.
Click the “Accessibility” pane in the right-hand sidebar (if it is not visible, click the three-dot menu and enable it under "More tools").
Look for the “Role” field in the accessibility tree to see the semantic role of the element.
This indicates how the element is interpreted by assistive technologies.
If the role that is displayed in the accessibility tree matches what is actually shown on the website, you can mark this issue as "reviewed."
This document gives information about the related accessibility checks:
Element needs to have the right semantic role.
What
User interface controls must have the correct semantic roles.
The semantic role of an element can be set implicitly by its HTML tag or explicitly with the ARIA role attribute.
Why
Assistive technologies such as screen readers rely on semantic roles to accurately convey the purpose and functionality of input controls. For example, the button role indicates an element that triggers an action, such as a form submission or when you open a dialog box. The link role identifies navigational elements that take users to a different page or section. Similarly, a checkbox role signals an option that can be turned on or off with a toggle, while a radio button role represents a selectable choice within a group of options. Without the correct roles, these controls may be misinterpreted. Incorrect role assignment leads to confusion and hinders users that rely on assistive technologies from effective interaction with the control. Proper semantic roles ensure a clear and intuitive user experience.
This check affects the following users with:
Visual impairments: Who rely on screen readers to understand and navigate input controls.
Mobility impairments: Who navigate and interact with controls using alternative input devices.
User story
Bridgit is a blind mother to a five-year-old girl and an 11-year-old boy:
"I signed up for a customer communication course at the community college to help me get better at handling front desk work. They had this website with extra tips and templates for emails and phone scripts, but you had to click buttons to expand the sections. My screen reader did not even mention that there were buttons, so I just thought the page was empty in places. Later, someone told me about it, and I felt awful knowing that I had missed stuff that could have made my job easier. It is like, how am I supposed to learn if the tools they give me do not even work for someone like me?"
Examples
This section gives some examples of the issue.
Example: Date of birth field with inaccessible info icon
On a health insurance application form, users are required to input their date of birth. Next to the date of birth field, an info icon is provided to explain the required format (for example, MM/DD/YYYY) and to inform users about age restrictions for eligibility. However, this information is only revealed after the user clicks the icon. The info icon is implemented as a simple <span> element:
When a user navigates this form with a screen reader, the info icon is completely overlooked. The screen reader may announce a "?" question mark symbol, but it does not convey to the user that it functions as a button that can be activated to reveal additional information.
Example: Date of birth field with accessible info icon
On a health insurance application form, users are required to input their date of birth. Next to the date of birth field, an info icon is provided to explain the required format (for example, MM/DD/YYYY) and to inform users about age restrictions for eligibility. This information is revealed when the user interacts with the icon. The info icon is implemented with a proper semantic role <button>.
When a user navigates this form with a screen reader, the icon is announced as an interactive element. The screen reader announces:
“More info button, collapsed.”
This makes it clear to the user that they can interact with the icon to reveal important guidance.
How
How to review it.
The Web Governance platform highlights instances where the code indicates that elements can be activated with a mouse but are not coded as semantic links.
Your task is to evaluate whether these elements are interactive controls, for example, elements that users can interact with in the interface, and, if so, determine if they have an appropriate semantic role.
You should examine each element and ask yourself, "What is this?"
For example, the element could be a button, checkbox, radio button, or similar.
Once you have identified the type of element, you need to check whether it has the correct semantic role. For example, if you see a button on the screen, its semantic role should also be a button.
You can use the developer tools provided by your browser to inspect the semantic role of the element.
Right-click on the element that you want to inspect.
Select “Inspect” from the context menu.
In the DevTools panel, go to the “Elements” tab.
Click the “Accessibility” pane in the right-hand sidebar (if it is not visible, click the three-dot menu and enable it under "More tools").
Look for the “Role” field in the accessibility tree to see the semantic role of the element.
This indicates how the element is interpreted by assistive technologies.
If the role that is displayed in the accessibility tree matches what is actually shown on the website, you can mark this issue as "reviewed."
Web Governance