In episode 11 of the video podcast series, A11ycasts, How I do an accessibility check, Rob Dodson demonstrates a process he uses for quickly checking the accessibility of a page. This may not catch all errors, but it is a good place to start if you're just wanting to get a quick sense of things.
Basically, in his process, the tester does the following:
- Check keyboard accessibility by tabbing through page and interacting with all of the controls using only the keyboard.
- Is there a skip link?
- Can you access all necessary information and functionality using only the keyboard?
- Is there always a visible indication of where focus is? For instance, sometimes designers will use CSS to tun off focus highlighting, or to position focusable elements off-screen. In either case, this can prevent you from knowing where you are when you tab to a focusable element, and that is bad.
- Does the tab order make sense?
- Do you have enough time to complete any needed interactions?
- Perform a simple check with a screen reader (VoiceOver or NVDA), using the reading commands, bringing up a list of headings and landmarks, and interacting with controls on the page.
- Run a scan on the page using the aXe Chrome extension. This will catch a number of other problems, including most color contrast issues.
- For color issues that aXe flags but that it isn't sure are a violation, use the Chrome Inspector to check (and adjust) those colors. In the video Rob mentions Chrome Developer Tools for this, but the functionality he describes has now been incorporated directly into the browser itself, though in a slightly different way.
If the site is responsive, these same steps should be repeated for each breakpoint, resizing the viewport as needed.