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. Look over your content with the Content Accessibility Checklist 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. Check your content again on a phone. Make sure images, tables and forms scale down to the small screens nicely.
3. Run a simple automated test. Two 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 Design & Code

4. In addition to the above, check the "structure" tab in WAVE. Do the headings form a logical outline, including 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?
5. 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.
6. 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).
7. Either install Microsoft Accessibility Insights and run a full assessment, or do manual keyboard testing: make sure your browser is configured to enable full keyboard access, and then use the Tab key to advance through the page.
   1. Every element should clearly change on focus. You should never have to squint and try to figure out where your cursor went.
   2. As you Tab, you should be able to reach every link, button and form item, and you should be able to Shift+Tab back through them in reverse. Make sure it works in both directions if elements show and hide on scroll.
   3. 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).
   4. Pages with navigation before the content should have a "skip to main" link -- and clicking it should transfer focus to the content area.
   5. Any custom interactive components like dropdowns, modals and slideshows should also respond to expected key commands, possibly including arrow keys, spacebar, enter and/or esc.
   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, so that the cursor doesn't end up hidden beneath the modal with no way back into it.
   7. All this should work on the mobile/responsive design as well; be sure to test both.
8. Request a consultation with us so we can finish your DIY testing on our collection of screen readers.