Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

Manual accessibility testing process

Rebekah-Hernandez edited this page Feb 25, 2020 · 5 revisions

We use automated testing to make sure that our software works as well as possible, but automated tests don’t catch everything. That’s why we also do manual accessibility testing and encourage you make the testing a part of your normal routine of work.

Decide when to do the testing

  • Test in an environment that mimics the end users experience (for example, staging)
  • Include manual accessibility testing as part of each story’s acceptance criteria to ensure nothing gets shipped without being tested
  • The UX team is responsible for making sure sure testing gets done, but anyone on the team can conduct the testing

Do a quick audit with a scanning tool

  • As new features are released into staging, do a quick Lighthouse audit on accessibility to help you identify problems that may have gone unnoticed by the team. Lighthouse is an easy to use auditing tool from Google. You can use Lighthouse to audit a page’s performance, accessibility, best practices, and SEO right from your Google Chrome browser or from the command line.

Create a testing scenario

  • Develop a checklist of things you will manually test that you can run through every sprint or use a reference such as the ICT Testing Baseline

Check keyboard access to test:

Tab order

  1. Tab through your site and make sure that the elements of focus are appropriate and follow the order of the Document Object Model (DOM).
  2. Here’s a quick reference on what to look for when tabbing through.

Accessible tables

  • Ensure your tables are accessible and have structural markup to identify headers and data cells, so that you are not relying on visual cues alone

Rollovers

  • Avoid the use of mouse-only elements such as rollover menus

Keyboard traps

  • Check that the keyboard focus is never trapped in a loop.

Image links

  • Confirm all relevant images have image tags and alt attributes.

Focus indicators

  • Ensure that keyboard focus is always visible when moving through the page on the keyboard.
    • Particularly focus outlines should be visible on interactive elements on the page such as form fields, buttons, and links.

Labeling and semantics

  1. Turn on your screen reader and tab through the fields.
  2. Change text scaling to make sure nothing breaks.
    • Text size
      • Confirm the use font size is 10pt minimum
    • Color
      • Ensure that all text has a contrast ratio of 4.5:1 with the background
    • Text style and font
  3. Review that all form labels have explicit input labels

Then use screen reader to test your scenarios

  1. First, determine if the USFS ACIO has a licensed screen reader available for use
  2. If not, there are a number of screen readers on the market if the USFS organization doesn't have one already, so select one that fits your budget, testing needs and just test
    1. Here’s a quick reference on what to look for to make the page accessible for folks using a screen reader.

Create new issues

Ensure that the team addresses any barriers to accessibility you find.

  • Double check you can recreate the bug
  • File bugs according to your bug filing process on your issues board
  • Create acceptance criteria/definition of done
Background
How we work
Technical Information
Past efforts
Open Forest Scale Up Tool Box
User Research
Support
Support Manual
Support Guide for Frontline Staff
Product Management Information
Clone this wiki locally