Accessibility in the Definition of Done: Why It Matters & How to Get It Right
Including accessibility in your Definition of Done is one of the most effective ways to embed inclusive practice into agile delivery. It ensures digital products are not just functional, but accessible to everyone, right from the start.
But here’s the thing: too many Definitions of Done still forget one group entirely, disabled users.
We believe that accessibility isn’t something you bolt on at the end. It’s something you build in, from the start, and at every step.
Including accessibility in your DoD is one of the most powerful ways to make that shift.
Why include accessibility in the Definition of Done?
Adding accessibility to your Definition of Done helps move it from aspiration to expectation. It means accessibility isn’t dependent on one advocate remembering to raise it — it’s embedded in the process. And that benefits everyone:
- It creates shared understanding across teams
- It improves quality and reduces rework
- It makes inclusion part of your workflow, not just a separate project
Including accessibility in your DoD also helps you spot issues earlier, avoid legal and reputational risk, and deliver better experiences for every user.
What does an accessibility-focused Definition of Done look like?
Every team is different, but the checks you include should be practical, repeatable, and tailored to your workflows. Here are some examples of what you might include:
Passes automated accessibility tests
Use tools like Axe, WAVE or Lighthouse to catch common issues. No, automation won’t find everything, but it’s a great early warning system and safety net.
Reviewed against WCAG 2.2 AA
Have someone on the team (or a specialist) check new features against WCAG success criteria. Focus on things like keyboard access, semantic structure, and contrast.
Content follows readability and accessibility standards
Good accessibility is about more than code. Clear, structured, plain language content makes a huge difference for users with cognitive differences, low literacy, or who rely on screen readers.
Live regions and dynamic content tested
If you’re working with modals, dropdowns, alerts, or other dynamic elements, make sure they’re properly announced by assistive tech.
Accessibility statement updated
If your organisation has a public accessibility statement, updating it when new features go live shows transparency, and gives users a route to raise issues.
Embedding accessibility in the Definition of Done: More than compliance
Building accessibility into your Definition of Done isn’t about slowing things down with red tape. Quite the opposite — it helps you deliver higher-quality, lower-risk work, faster.
It also supports long-term change by reinforcing three essential pillars:
- Becoming Compliant: Demonstrating due diligence, getting your services accessible, and avoiding risk.
- Staying Accessible: Giving your teams the capability, confidence, and tools to deliver accessible products.
- Inclusive Culture: Embedding accessibility into everyday thinking, values, and practice.
How to add accessibility into your DoD
- Review your current DoD: Is accessibility mentioned at all? If not, where could it be included?
- Choose realistic checks: Start small if needed. Even one or two well-defined steps can have a big impact.
- Train your teams: Help everyone understand what those checks mean and how to meet them.
- Create a feedback loop: Update your DoD as you learn, test, and improve.
Let’s make ‘Done’ mean accessible
At Arc Inclusion, we work with organisations to embed accessibility across the entire product lifecycle, from initial research and strategy, through to design, development, testing, and rollout. Whether you’re reviewing your agile processes or building a culture of accessibility from the ground up, we’re here to help.