Design approach to accessibility

pencil icon to denote design

We love a challenge. We know designs can be unique, vibrant, and accessible. To meet this goal, we created and improved tools that can effect positive change when it comes to accessible designs.


Designers create experiences in many ways. Many use Sketch, some use Photoshop, and some write code. These experiences include complex interfaces, animation, and other rich elements. These elements are often unit tested, but may lack full-page tests. This can create a situation for errors to appear.

We maintain an end-to-end test script using open-source libraries to catch automated errors. We call it axe-e2e. The script reads a sitemap, opens each page, and runs an accessibility scan. It logs errors to a CSV file or a terminal window, giving designers a list of things to review.

Accessibility worksheets

Asking “Are we accessible?” as a yes or no question is not the best approach. Accessibility is an unbounded metric. We can build products with zero automated errors, and still be inaccessible. If users cannot navigate by keyboard, zoom, or understand what we are asking of them, we have failed.

Our answer? Create a worksheet that calculates accessibility scores. The worksheet asks testers to log four levels of automated errors. It also accepts a pass or fail grade for manual tests. By inputting these values and view counts, auditors receive a custom score. Zero is a perfect accessibility score, anything higher is room for improvement.

Testing in the pipeline

WCAG 2.0 Level AA is our benchmark for accessibility compliance. It offers specific details for building sites and applications. The specification also provides pass or fail criteria for many accessibility scenarios.

Each time the CI/CD build process runs, it checks every page for Section 508 and WCAG Level A/AA violations. This allows designers to focus on more nebulous issues like color and language.

We believe in pushing best practices when we have the chance to do so. Many of our interfaces rely on the USWDS web components. These UI elements are open-source, so anyone can contribute. We made a pull request to add best practice rule checking, which the maintainers accepted.

The time is now

Accessibility is everyone’s responsibility. By building and improving these tools, we do our best to affirm that goal every day.