There are tests developers and QA testers can run before getting to more advanced or in-depth accessibility testing. This post discusses some of these tests.
The following items should be checked:
- Automated testing
- Keyboard testing
- Images
- Forms testing
- Contrast
Automated testing
Use TPGi ARC or Deque aXe automated accessibility testing tool. Ensure that all errors highlighted by the tool are fixed. Keep in mind that automated tests will only catch a maximum of 40% of accessibility issues. This is only to capture the easy things.
Keyboard testing
This is done with nothing else than your keyboard. No mouse/trackpad/trackball. No screen reader
- Can you navigate to every interactive element on a page with only using the keyboard?
- Can you navigate backwards back to the top of the page using only the keyboard?
- Is there a visual focus indicator on all interactive elements? If not, ensure there are.
- Were there any tab stops that don’t have a visible element on the page? If yes, ensure there aren’t.
- Were there any tab stops on elements you can’t interact with? e.g. a heading, or an image. If yes, ensure there aren’t.
- Can you trigger all interactive elements using only the keyboard?
- Can you use custom select elements and auto suggest using only the keyboard?
Images
- Is there clear and concise alt text on all informative images?
- Is there null or empty alt attribute on all decorative images?
- Is the alt text for images that are the only content in a link describing the link’s destination rather than the image?
Learn the difference between decorative and informative images with the alt decision tree
Forms
- Are there clear and concise visible labels for all form inputs?
- Are the visible labels programmatically associated to the form inputs?
- Are visible labels and programmatic labels the same? If you have two different labels and they aren’t using the same text, make sure they do.
- Are placeholders used instead of labels? If yes, ensure there are actual labels and placeholder isn’t relied upon.
- Are error messages programmatically associated to the input?
- Are required fields programmatically marked as required?
- Are custom elements (e.g. custom select) replicating their HTML equivalent for all functionality?
Contrast
- All regular text (i.e. smaller than 18 px) has at least 4.5:1 contrast ratio against the background
- All large text (i.e. 18 px or larger) has at least 3:1 contrast ratio against the background
- All non-text elements have at least 3:1 contrast ratio against the background
- Inline links with no underline have at least 3:1 contrast ratio against the text around the links (and have a visible differentiator on hover and focus)
Screen reader testing
Screen reader testing is critical to testing for accessibility. It takes some time and effort to learn and understand how to use a screen reader for testing. I recommend doing testing with screen readers, but only after the previous series of manual and functional tests have been conducted and come back “clean”.