How to test
Links & Buttons
Testing links and buttons is essential to ensuring a site is accessible and functional for all users.
1 How to test
Test with your keyboard first
Navigate through the page using only the tab
and shift + tab
keys on your keyboard to reach all links and buttons.
Test with screen readers second
Use a screen reader, such as NVDA (for Windows) or VoiceOver (for macOS) and browse the page using your arrow keys to reach all links and buttons.
2 What to test for
✓ Ensure disabled controls are focusable but not actionable, and have an aria-disabled="true"
attribute
Preferred
|
Disabled but not focusable
|
|
|
Pass
|
Fail
|
This button expressed its state as expanded or collapsed
|
This button is not conveying it's state.
|
|
|
✓ Ensure skip to & same-page links move focus for screen reader and keyboard users
Pass
|
Fail
|
Home
|
|
Open a modal
I am a modal
And I was correctly triggered by a button even though it looked like a link!
|
Open a modal
I am a modal
But I was triggered by a link which is unexpected!
|
If it goes somewhere, it’s <a>
link.
- When the user clicks a link, they are taken to a different location in the site.
- Either another page or even another area of the same page
- A link can look like a big shiny button but it must be coded as
<a>
link
- An interactive link should have a valid href value so it can receive keyboard focus.
For example <a href="/some-page">...</a>
.
- Buttons cause an action to occur on the same page
- Submit a form (even when submission takes you to a new page)
- Open a menu
- Launch a modal
- Expand details
- A button can look like a link, but it must be coded as a
<button>
- 2.4.4 Link Purpose (In Context)
- 2.5.3 Label in Name
- 3.2.4 Consistent Identification
- 4.1.2 Name, Role, Value
Resources