1. Use the site on your phone. This helps find elements that do not scale well.
2. Review your content using the Content Accessibility Checklist. Especially:
   1. Ensure the writing is succinct, and grouped by headings, lists or other machine-readable structure.
   2. Ensure there are no images of text, that alt text accurately describes each image in context, that audio/videos have captions or transcripts, and there are no big animations.
   3. Check menus, links and headers for clarity. Make sure each label is unique, and is meaningful for readers who are not familiar with your unit's jargon or org chart.
3. Run automated content checkers.
   1. For sites in the University's SiteBuilder platform, use the built-in accessibility checker, especially its site-wide reports.
   2. For public-facing sites that are already published, run a test in DubBot.
   3. For other sites:
      1. WebAIM's WAVE plug in highlights content errors, offers explanations and suggests fixes. It also makes invisible elements visible (image alt elements, heading structure, etc), so you can see how screen readers interpret the page.
      2. Deque's AXE tool works similarly but provides feedback in a linear form, in a separate frame.

Proofread the design & document structure

1. While using WAVE, check the Structure tab:
   1. Do the listed headings form a logical outline? Are there any elements that are functioning visually as headings that are not in the list?
   2. Are there landmarks for key regions like the banner, navigation(s), main content and footer?
2. In WAVE, check the Contrast tab for font colors. Then use an eyedropper tool to manually check colors WAVE cannot detect:
   1. Hover and focus states for links and buttons
   2. Text on top of image backgrounds
   3. Tooltips or validation errors in forms
   4. Color choices inside images, such as charts, graphs and icons.
3. Check your responsive design:
   1. Does the theme reflow cleanly down to 320px widths without undue horizontal scrolling, and up to 2560px widths without blurry images or overly long lines?
   2. Can the menu and other components be used via touch on a phone?
   3. Can users zoom/enlarge the text? Never disable user-scaling.

Keyboard-only access is critical for accessibility; most assistive input devices work by simulating keyboard clicks.

To test, install Microsoft Accessibility Insights and run a full assessment, or perform manual keyboard testing: 

1. Make sure your browser is configured to enable full keyboard access.
2. Use the Tab key to advance through interactive elements on the page. Every element should clearly change on focus. Whatever changes should be eye-catching: more than a hairline, and a 3:1 contrast with the unfocused state.
   1. 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, especially if elements show and hide on scroll.
   2. 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).
3. Any interactive components should respond to expected key commands. These may include arrow keys, Spacebar, Enter and / or Esc keys rather than Tab. Some common patterns:
   1. Links:
      Enter (links go places: other pages or anchors in a page)
   2. Buttons:
      Enter and Spacebar (buttons change the current page, e.g. opening and closing panels; they are different controls than links, not just links with a visual button style; elements need to be the correct type)
   3. Checkboxes:
      Spacebar
   4. Radio buttons: 
      Arrow keys and spacebar, not Tab. The tab key should only stop on one radio button in each group. If it stops on several, the radios are not grouped correctly.
   5. Drop-down/select elements:
      Arrow keys, Enter, Escape. Tab should exit the flyout, not navigate within the flyout.
   6. Modal (pop-up) dialogs:
      After clicking the button that opens the dialog, your keyboard focus should be moved into the dialog, and be returned to the button when it closes. Usually 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. The Escape key should also close the modal.
   7. Dynamic tab panels:
      Arrow keys should navigate between options, Tab should jump from the options to the open panel contents. Note that tab panels user test poorly in many contexts and are not a recommended pattern for important or scrollable content. Many users will “miss” tabs after the first, especially if the tab list has been scrolled off screen by the end of the first tab panel.
   8. Scrollable elements:
      Arrow keys. Either the element itself or something inside it needs to be focusable for this to work, since arrow keys scroll the currently focused element.
   9. For all other simple elements look up the expected expected key commands before testing.
   10. Avoid using complex elements in public-facing content. If you need to be taught what a novel JavaScript widget is (e.g., a “tree grid”), assume the average keyboard or screen reader user also will need to be taught how to use it the first time. This is an unreasonable expectation for public-facing content. Most widgets with custom key commands like menubars are intended for use in software and Web apps, not websites.
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. All this should work on the mobile / responsive design as well; be sure to test both! Many people operate phones and tablets with assistive inputs.

Note: DIY is not enough for this. There is a lot of nuance, and different screen readers will react differently to certain errors. Request a test with us so we can fully test your site on screen readers and other assistive devices.

Before you start

1. Take the Testing Design & Code class.
2. Read through the WebAIM article for you chosen screen reader, likely VoiceOver on MacOS or NVDA on Windows.
3. Understand well that screen readers have several different browse modes, so there are specific keyboard shortcuts you need to learn to, say, advance to the next text element or heading or simulate a mouse click. The “Tab” key works the same as in Keyboard testing.
4. Understand that you should always hear the full equivalent of what you see. E.g., for a button to toggle a menu:
   1. The “name” of an element: “Menu”
   2. The “role” of the element: “Button”
   3. The current value or state of the element: “Expanded” or “Collapsed”
5. Understand that some screen readers try to compensate for invalid code. You should never hear the word “clickable;” that means the screen reader has detected something with a mouse click event listener that does not have a role.

Testing checklist

1. Repeat each of the keyboard testing steps, this time listening for names and roles. 
   Yes, you have to do that same checklist twice! Screen readers work differently from keyboards. Testing only with a screen reader enabled will miss elements that are not keyboard compatible, and testing only with a keyboard will miss elements with that cannot be converted to speech by a screen reader.
   1. Make sure roles match functionality. If something says it is a link, it should navigate, not open a dialog. If something functions as a button, it should have a button role and be in the tab order.
   2. Make sure the value or state changes for when buttons are clicked. Active navigation items and tabs should say things like “selected” or “current page,” toggles should indicate if they are expanded, collapsed or pressed. 
      Notes:
      1. You may need to move the cursor off and then back on to the element to hear the new state.
      2. Check that the state and label did not both change. E.g., if a “play” button changes to a “pause” button, either the label should change (play/pause) or the state (play/"play, pressed"), not both (play/"paused, pressed").
   3. Also make sure you hear status updates. When something meaningful changes on the page, you should hear about it; e.g. if a dialog opens, you should hear the name of the dialog, if search results appear after a long loading delay you should hear they are ready, if the down arrow moves the selection in a drop-down you should hear the new value.
   4. Do not simply verify that the page functions, verify that you can figure out how to operate it with your eyes closed. Code can pass technical requirements without actually being usable by a user who cannot see what is happening.
   5. Again: avoid using complex elements in public-facing content. If you need to be taught what a novel JavaScript widget is (e.g., a “tree grid”), assume the average keyboard or screen reader user also will need to be taught how to use it the first time. This is an unreasonable expectation for public-facing content. Most widgets with custom key commands like menubars are intended for use in software and Web apps, not public websites.
2. Step through the page again using the text browse mode, rather than the Tab key.
   1. Do text elements also have appropriate roles? E.g., heading, list item, etc.
   2. Do images have appropriate alt text?
   3. Are there repetitive/annoying/confusing extra things in the text? E.g., alt text the same as a caption, or hearing every news headline twice in a list.
3. Re-test anything that looks different in the mobile view. It is not uncommon to have different code for mobile and desktop menus.

And again: DIY is not enough for this. There is a lot of nuance, and different screen readers will react differently to certain errors. Request a test with us so we can fully test your site on screen readers and other assistive devices.