We've all been there: receiving an accessibility audit report and feeling the sting of a failing grade. At Answer Digital, we've learned some costly lessons about accessibility audits. We know how important it is and how teams often fail.

By Richard Walker and Beth Kish

Our recent session at A11y North, "How to Fail an Accessibility Audit," covered the three most common pitfalls and what they mean for teams who want to build accessible services

Why audits matter - opportunity to improve

Beyond being the right thing to do, accessibility can also be a legal requirement with laws like the UK’s Public Sector Bodies Act and the European Accessibility Act (EAA). An audit can be a reliable way to gain confidence.

However, to get the most out of an audit you must understand its limitations:

- It’s a snapshot
It validates the current build, but doesn't guarantee future versions stay accessible. Ongoing commitment is required.

- It’s a baseline
It measures compliance, but usability needs real user feedback

- It’s a process
Expect to iterate and retest before reaching your final goal.

A few points of failure are expected and provide the necessary insight to improve. It’s rare to see an audit with zero issues, and the only real failure would be to fail to improve.

The real risk lies in the period of panic that occurs when results are more complex than anticipated. By analysing these situations, we’ve identified three common pitfalls that teams can avoid to ensure a smooth path to compliance.

The pitfalls: time, expertise, and complexity

There are three common traps that consistently lead to accessibility audit failures

- Expertise
"We don’t know how": Accessibility requires interpretation, and it's difficult to know what you don't know.

- Time
"We’ll do it later": Putting accessibility off until the end is the most common and damaging mistake.

- Complexity
"We thought it was simple": Accessibility is more than a UI checklist. It involves understanding how assistive technology works and how your design impacts users.

Low confidence, high impact

Teams often have a lower baseline for accessibility compared to other requirements like security or performance. While the latter benefit from established standards, clear business cases, and dedicated specialists, accessibility is often less loved.

This lack of institutional knowledge makes it difficult for teams to "know what they don’t know," especially when projects are resourced without accessibility expertise in mind. Consequently, when audits occur, the lack of experience can lead to reactive costly fixes. Building this expertise takes time and requires a proactive shift towards including accessibility in every stage of planning, from initial resourcing to dedicated team learning.

Skipping accessibility to save time, always backfires

Time constraints often lead teams to deprioritise accessibility, but this approach backfires during the final audit. Use these tactics to stay on schedule:

1. Start at discovery: Plan accessibility into your strategy and roadmap from the start, make sure the goals are clear.
2. Test incrementally: Reduce the burden by testing components as they are built. This supplements full compliance testing.
3. Don't skip the full test: Plan for a comprehensive test. Small, incremental checks can sometimes miss complex interaction issues.
4. Plan for fixes: Leave time for remediation to avoid rushing, some things won’t be quick fixes.
5. Document constraints: When time truly runs out, be prepared to justify remaining issues through a disproportionate burden assessment.

It’s more than a checklist

Accessibility is frequently underestimated as a simple checklist of UI fixes. In reality, it involves layers of technical and functional complexity that can easily derail a project.

1. Surprise complexity

There are several areas where "surprise complexity" emerges:

• Assistive Technology Learning Curve: Simply turning on a screen reader is not enough. Understanding how users actually navigate such as using shortcuts and heading structures requires dedicated learning
• The "Accessible Component" Trap: Accessible components are useful but they can still be implemented in an inaccessible way, and integration may lead to issues.
• Compounding Test Requirements: Accessibility does not exist in a vacuum. It must be layered onto cross-browser and cross-device testing. This adds a lot of time to the testing process.

2. The limits of automation

A common pitfall is over-relying on automated testing tools. While helpful, these tools are limited by their inability to understand context and meaning.

• Coverage Gap: Automation is typically cited as able to catch up to 30% of issues. A recent internal audit at Answer found that only 15% of our actual bugs were detectable by automation.
• False Confidence: Automation can confirm the presence of an attribute (like alt text), but it cannot judge accuracy of that text. High automated pass rates often mask a poor user experience.
• AI: While AI-driven remediation is improving, WCAG standards require human interpretation and it’s important that your team understands them

3. High-impact fixes

Some requirements are deeply entwined with a product's core design. Retrofitting these later is often a security or engineering issue.

• Session Management: Requirements for extendable session timeouts often conflict with pre-approved security and authentication processes. Changing this late in the game can be tricky.
• Data Persistence: Requirements for re-populating fields (to prevent data loss) may require a rethink of how your application handles state and data storage.
• Third-Party Dependencies: If you use "Off-The-Shelf" or third-party components, you lose control over accessibility. If those components are inaccessible, mitigation is often difficult or even impossible

To avoid complex fixes like these all data, architecture and security aspects need to be considered as part of the accessibility strategy, it’s not just the front-end layer.

The final lesson: embrace the "Fail"

Accessibility is a discipline, not a checklist. It requires expertise and strategic planning. However, it’s important to maintain perspective: an audit failure is not a reflection of poor work.

Because of the complexity of standards and the variety of assistive technologies, teams may receive "fails" on their first pass.

Use these findings to improve. By preparing for the known complexities and staying proactive, you put your team in the best possible position to respond.

This blog post is based on a presentation by Beth Kish and Richard Walker at A11y North #8: Testing and Learning, 10/09/2025

Reach out to us:
Richard Walker: [email protected]
Beth Kish: [email protected]