Test For Accessibility

Note that we teach and encourage familiarity with screen readers, but do not recommend departments do their own screen reader testing. Effective and comprehensive screen reader testing requires multiple devices, a lot of training and a lot of practice. Please request a consultation before launch.

Testing Content

  1. Explore your site with the 11 Key Accessibility Factors in mind. Clear, succinct, well organized content is the first step towards an accessible site.
    1. Check your menus, links and headers for clarity. If you have not yet tested these on a real user, consider stopping by the Usability Lab.
    2. Break up long blocks of text in to smaller chunks or lists.
    3. Watch for text in images.
    4. Make sure your videos have closed captions.
    5. Give tables, forms, charts and graphs a close look for effective labeling. Make sure they work well on phones, and make sure they do not rely on color alone to communicate any important concepts.
  2. Explore your site again on phones and tablets. Make sure images, tables and forms scale down to smaller screens nicely.
  3. Run some simple automated tests on key pages. There are three free tools we recommend for content authors:
    1. WebAIM's WAVE tool will highlight errors inline in your content, with plain-language explanations of what it thinks is wrong and how you might fix it. It also makes invisible elements visible (image alt elements, heading structure, etc), so you can see how screen readers interpret the page. Install the browser plugin if you want to test content that requires a login to access.
    2. Deque's AXE tool works similarly but is much less visual, listing what it finds in a separate frame, next to the page. Some users love Wave's bright and colorful inline icons, others prefer this more linear approach.

Testing Code

  1. Make sure somebedy is testing the content (as above).
  2. Check the "structure" tab in WAVE. Do the headings form a logical outline? Are there visually hidden headings for critical non-content elements like the main navigation and search? Are there landmarks for key regions like the banner, navigation(s), main content and footer?
  3. Check the "contrast" tab in WAVE. Be sure to manually check colors the tool won't detect: text on top of image backgrounds, hover and focus states on links and buttons, tooltips or validation errors in forms, color choices in charts and graphs, etc.
  4. Check your responsive design.
    1. Make sure the theme reflows cleanly down to 320px widths without horizontal scrolling (as much as possible) and up to 2560px widths without blurry images or extremely long line lengths.
    2. Make sure the menu and any other interactive components can be used via touch on a phone.
    3. Make sure users can pinch-to-zoom on a phone ("user-scalable" should never be disabled).
  5. Install Microsoft Accessibility Insights, and run a full assessment. This tool is developer-focused, quite rigorous, and will guide you through additional keyboard testing, HTML validation and some of the advanced tests we do in our detailed audits.
  6. Either as part of the Accessibility Insights assessment (it will guide you through these steps) or on your own, make sure the menu and any other interactive components can be used with a keyboard alone. First make sure your browser is configured to enable full keyboard access, and then check for the following:
    1. You should have a "skip to main" link -- and it should work!
    2. Every element should clearly change on focus. You should never have to squint and try to figure out where your cursor went.
    3. You should be able to Tab forward through every link, button and form item, and Shift+Tab back through them in reverse. Make sure it works in both directions.
    4. Keyboard shortcuts should follow standards on all custom interactive components like dropdowns, modals and slideshows.
    5. The order that items are highlighted when tabbing should match the order you read them -- left to right, top to bottom. Exceptions should be rare and logical (e.g., it might make sense for the "close" button in an alert to come after its content, even if it is at the top right).
    6. If a button causes a modal to appear, focus should be moved into it, and be returned to the button when it closes. And focus should be "trapped" in the modal until the modal is closed, if the modal covers the screen and doesn't automatically close, so that the cursor doesn't end up hidden beneath the modal with no way back into it.
  7. Request a consultation with us so we can finish your DIY testing on our collection of screen readers.