Mighty Acorn

A fearless approach to QA and web accessibility

Ren Iris

We’ve previously written about the many benefits of automated testing, in terms of improving end-user experiences and delivery processes. This capability intersects with other QA and testing efforts, such as for accessibility. To expand our own methodology and capabilities, we’ve partnered with Fearless. Recently, we spoke with Darren, a QA and accessibility expert from Fearless about the importance of automating accessibility testing.

Terms and (digital) conditions

Let’s define terms to establish general context, as well as contexts relevant for civic tech and government clients.

Digital accessibility

Darren and I first spoke about his journey into QA and automated accessibility testing. He developed an interest during university that grew during an internship; it’s now a specialty of his at Fearless. Darren cited the W3C Web Accessibility Initiative as a starting resource. Per the Initiative, web accessibility means designing and developing websites, tools, and technologies so that people with disabilities can use them.

Web accessibility efforts also benefit people without disabilities: clear navigation, defined mobile and desktop views, captions, and alt text support context-enriched user experiences.

Fearless and Mighty Acorn Digital also refer to Section508.gov, which provides documentation on digital accessibility compliance with Section 508 of the Rehabilitation Act. The site now features a content library—“a centralized, searchable hub of Section508.gov guidance and resources to help digital accessibility experts and practitioners quickly find what they need.”

Each project has its own needs and each client their own requirements, but whenever possible, Darren and his team advocate to deliver projects in alignment with WCAG Level AA standards. This QA approach aligns with Mighty Acorn’s best practices; we also deliver with WCAG AA. On joint projects, we have a shared system that streamlines accessibility testing.

WCAG lists the following 4 principles (also known as “POUR”; this is an overview / introduction) to its accessibility guidelines:

1. Perceivable

  • Offer text alternatives that help people consume non-text content
  • Include captions for multimedia content
  • Create adaptable content that can be presented differently—including with assistive technologies—while preserving key details
  • Increase contrast to help users quickly navigate, process information, and distinguish between foreground and background

2. Operable

  • Ensure all functionalities are available using a keyboard alone; also ensure people can use inputs beyond a keyboard
  • Provide enough time for users to navigate through motion-based elements
  • Avoid any content that can cause seizures or similar physical reactions
  • Provide navigational options and directions so that users can find the content they seek

3. Understandable

  • Develop content that is understandable in context and sequence / can appear and operate predictably
  • Help users avoid errors, as well as correct them when possible

4. Robust

  • Current-state improvements and maintenance: Maximize compatibility with current user tools and assistive technologies
  • Future-state preparation: Maximize compatibility with future user tools and assistive technologies

QA and accessibility testing

QA is used across industries—but industry-specific benchmarks make consistent applications difficult. For our purposes in civic tech, we’re discussing QA as it relates to accessibility testing. While “general” QA centers on performance, functionality, and security, accessibility testing focuses on usability.

In civic tech especially, accessibility testing and Section 508 adherence are “essential for compliance, usability, and business success.” It helps teams keep funding, avoid fines and reputational damage, and promote a better overall user experience.

Testing (manual and automated) and QA are context specific and often subjective. In the traditional era of testing, QA checks are conducted at a project’s end. This can create a delivery bottleneck—any errors found during the delivery stage require fixing, which often disrupts deadlines.

These contexts inform why Mighty Acorn leads projects with an agile development and delivery approach. As the Agile Manifesto notes, in software development we prioritize “individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.” While administrative tasks are a necessary part of each project, Mighty Acorn engineers are quick to pivot when they find a different solution that provides more benefits to end users.

We also aim to help clients avoid costly rework. This means including the tester’s perspective—and their subject matter expertise—in workstreams as early as possible, building in usability testing throughout the project. When accessibility and QA testing are “shifted left, many important elements can be caught and corrected before resources are allocated.”

Why shift left: Reasons to care

Darren and Mighty Acorn engineers underscore the importance of “shift-left testing.” It’s a framework for coding generally, but it also applies to QA. In shift-left QA / accessibility testing, this means we start searching for and catching QA errors from the start to avoid bottlenecks at the end of delivery.

Considering accessibility needs from the earliest stages of a project helps the focus remain on user needs. For example, when building a website, during the wireframe and prototyping stage, testers assess accessibility considerations such as the “scalability of the interface, mouse-less navigation, color contrast, [and] semantic structure.” Responsive design and accessibility resources resolve “most accessibility issues at this early stage.”

Additionally, with AI tools and automated testing constantly improving, it’s becoming easier to fold accessibility checks into usual QA ones. Integrate both manual and automated testing into QA processes to ensure that a broad audience can use—as intended—software products, websites, and services.

How to center accessibility

Increase total user access by focusing on underserved users; create a QA / accessibility framework that’s actionable, repeatable, and scalable project to project. Agree on “ideal” and “real” guidelines, maintaining documentation of all involved roles, ownership, approvals / peer reviews needed, and final processes. Implementing accessibility and QA standards is a team effort—we all benefit from this awareness and can contribute to better user experiences.

Quick resource list

Copyright © 2026 Mighty Acorn Digital Inc.