Digital Accessibility

How we build and launch technology for everyone

All frontends we build for public consumption will meet the WCAG 2.1 AA Standard.

Development #

Most accessibility issues stem from the use of bells and whistles. The best way to avoid accessibility issues is to build for functionality, and avoid overly visual, contextual, or “cute” solutions to information display and retrieval tasks. Pure HTML can’t be messed up, blink tags aside.

Alas, folks expect sites to be pretty. Rather than reinventing the wheel, we’ll use standard libraries of components that have accessibility ratings, along with standard flexbox layouts, to minimize the number of cases in which we’re hand-rolling anything that can introduce accessibility issues.

In the process of drafting contracts with potential clients we will discuss their target audience, and what accessibility issues are most likely to be present in those populations. We’ll strive for a baseline of usability across a variety of accessibility concerns, but will think more carefully about the intersection of the use case and the need, which might be justifiably narrow in non-public projects.

Launch Process #

Prior to the public launch of anything we build, we’ll go through the process of evaluating the accessibility of the project in a standardized way.

1. We’ll create a document (Accessibility Evaluation or AE) to track accessibility concerns and mitigations for the project.
2. We’ll conduct automated testing (and record the results + fixes in the AE). WC3 has a variety of recommendations for tools that can help us identify potential issues, and we’ll use a bouquet of them to get a baseline level of accessibility.
3. We’ll perform one or more code audits (ex: using standard NPM test harness for WCAG standards) and record the results in the AE.
4. We’ll perform a manual walkthrough of the WCAG 2.1 AA Standard’s description and note any areas for concern or testing in the AE.
5. We will perform manual testing using adaptive technologies from targeted populations. If we’re not familiar with a given piece of adaptive software, we’ll contract with a member of a community likely to use the platform with accessibility requirements to perform manual testing for the areas of concern, using the AE to inform a targeted test plan.
6. We’ll establish some automated testing to prevent automatically detectable regressions.
7. In feedback forms, we’ll encourage users to report accessibility concerns.
8. We’ll publish the AE to the same audience as the project.