Integrate accessibility into every code change

How does Mighty Acorn Digital approach web accessibility?

At Mighty Acorn, we strive to meet the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA, not only because it is the required standard for government contracts, but because it aligns with our mission to deliver digital services that work for everyone. Building for the public means building for the full range of people who make up that public, including those with disabilities.

We treat accessibility compliance as a shared responsibility across the team. Every engineer at Mighty Acorn is expected to understand the baseline of manual accessibility testing and apply it as part of their normal development workflow. We also support each other through pairing, education, and even certification.

To make accessibility more approachable, we've put together documentation around how to think about disabilities, read guidelines, and test for accessibility compliance. We consider how disabilities affect the way people interact with the web and what we can do to improve that experience. We integrate accessibility into our engineering practices through automated and manual testing to catch issues early.

How do we get started with web accessibility guidelines?

WCAG, the accessibility specification, can be intimidating. It's detailed and technical in nature, and can have many well-meaning accessibility practitioners lost at the outset. While every web engineer should eventually become comfortable reading and citing WCAG, we can apply the same principles more broadly by learning about how the guidelines were organized and how folks with disabilities use the products we build.

In our accessibility testing documentation, we review the POUR principles of accessibility: Perceivable, Operable, Understandable, and Robust. These POUR principles are how WCAG is organized, and so learning about POUR is a great way to begin learning to read WCAG.

Additionally, there are many mental models about how we think about accessibility. For example, doctors will often use a "medical model," focused on identifying the cause of a disability and finding a solution that works for the person affected. In web development, we don't need to concern ourselves with specific medical diagnosis, and so it can be helpful to adopt a "functional model" of accessibility. This mental model focuses on practical solutions, tools, and design to improve usability for people with disabilities.

We can categorize disabilities into six functional categories: visual, auditory, visual-auditory, motor, cognitive, and vestibular. Each can impact how a user accesses web content, and can be accounted for in design and development by learning about the accessibility improvements that impact each functional area. Other types of disabilities exist but do not often impact how a user interacts with the web, such as speech or autoimmune disabilities. Not all disabilities are permanent, as well. Some limitations are temporary but still cause some difficulty in using the web. According to the CDC, cognitive and mobility-based disabilities are the most common types.

Resources for accessibility research

The World Wide Web Consortium (W3C) is the main international standards organization for the internet, and the publisher of WCAG. Their site explains accessibility guidelines and contains quick tips for developers getting started with building accessible web content.

WebAIM (Web Accessibility in Mind) is a non-profit organization providing resources for web developers interested in accessbility, like this contrast checker and techniques for WCAG conformance.

Deque Systems is a digital accessibility company with automated testing tools like axe dev-tools. They also host an annual virtual conference, bringing together a community of developers, designers, and accessibility professionals.