Testing your websites to ensure they are fully accessible is a lot of work. There are a bunch of tools out there to help you thoroughly test your sites – Siteimprove or Tenon, for example.
These automated tools do an excellent job at catching issues that are straightforward and programmatic. However, they are not an end-all-be-all solution to accessibility testing. Your users, regardless of their abilities or needs, are ultimately human beings. Therefore, part of your testing routine needs to involve humans.
Yes… I am suggesting you do more work. However, trust me. It’s worth it. At the end of the day, you will catch issues that an algorithm cannot, and your websites will be that much better for it.
Here are a bunch of tips that my team and I use at work to test our sites.
Keyboard navigability
As soon as you load a page, start tabbing through the elements on the page and test for the following things:
- Tab order
You can tab through items from left to right, top to bottom. - Tab ability
You should be able to tab through the entire page, without getting stuck. - Focus outline
All focused items are outlined and the outline is obviously visible (i.e. the outline should contrast well with the background). - Focused element
The focused item should be visible. - Skip links
Skip links exist and are visible when they have focus. Usually, skip links will be the first tabbable element on the page. - Off-canvas navigation
If there is an off-canvas navigation panel, you should be able to open the navigation, tab through the links inside of it, and close the navigation all with the keyboard. - Hover navigation (i.e. mega menus)
If there are navigation menus that a mouse user would see on hover, then you should be able to see the navigation by pressing the down arrow, tab through the links inside of that panel, and exit the navigation by pressing the up arrow.
Screen reader readability
Turn on your screen reader of choice. Have the reader read through the page sequentially and test for the following things:
- All content is read
The screen reader should not get stuck at any point. - Hidden content is not read
For example, the off-canvas navigation or a hidden search form should only be read by the screen reader when that element is actually visible on the page. - The content that is read makes sense
The biggest issues here are things like phone numbers, dates, abbreviations in general.
Landmarks… the screen reader test
Pull up the list of landmarks in your screen reader and test for the following things:
- Landmarks exist
All content on the page must be inside of a landmark container. Therefore, unless there is nothing on the page, at least one landmark must exist. - Existing landmarks have roles that make sense for their content
For example, a sidebar should have a complementary role, the main content of the page should have a main role, any navigation list should have a navigation role, etc. If this is not the case, a more appropriate landmark role should be used. - Redundant landmarks have labels
It is OK for a unique landmark to not have a label. However, if there is more than one of any given landmark role on the page, all of those landmarks must have labels. - Landmark labels are unique and make sense
It doesn’t help anyone to have two landmarks with the same label, especially if they are of the same role. Also, landmark labels should effectively describe the content inside of their landmark
Landmarks… the source code test
Yes, I am asking you to look at code too. You can do this by viewing source (Ctrl-U) in your browser or by using your browser’s developer tools. Test for the following things in the page’s source code:
- All content on the page is inside a landmark role
All means all: header logo, skip links, off-canvas navigation… everything. - Is there any content that should be put into a new landmark?
There could be some complementary content inside the main content or a header inside a section. - Landmarks are using the HTML5 semantic tags, not the role attribute
While the role attribute works, it is better form to use the HTML5 semantic tags for landmarks because it involves less code.
Links
Pull up the list of links in your screen reader and test for the following things:
- Links that go to different locations have unique names
A bunch of links that go to different URLs but all have the same link text confuse users because they cannot tell the difference between these links. These links must have unique link text or be given unique ARIA labels.
Ok, I know. This is a long list. But your users with thank you for all of this work. I promise.