Accessibility Audits Without A Rebuild: Part 2

The first accessibility audit gives clarity. The second phase determines whether anything changes for users. Many charity teams fix a few obvious issues, then drift back to old delivery patterns and reintroduce barriers in new campaigns. Part 2 is about implementation discipline: prioritising what blocks users, fixing at template level, and embedding checks into routine release work.

Prioritise by blocked journeys, not by issue count

Issue counts can mislead. Twenty low-impact issues on archive pages matter less than one blocking issue on donation or service access flow. Start with the journeys that supporters and beneficiaries rely on most.

1. Donation and payment confirmation paths.
2. Contact and support request forms.
3. Sign-up and preference update journeys.
4. Key service information and eligibility pages.

Fix templates, not isolated pages

Accessibility defects often come from shared components: form fields, buttons, modal dialogues, navigation patterns. Fixing individual pages wastes effort and allows regressions. Template-level remediation removes issues across many pages at once and creates more stable quality outcomes.

Backlog structure that works in small teams

Use a three-tier backlog so priorities are clear in sprint planning.

• Tier 1: blockers for critical journeys.
• Tier 2: high-impact template issues across many pages.
• Tier 3: lower-impact enhancements and content refinements.

Each item should include user impact statement, affected templates, acceptance criteria, and test method. Without these fields, accessibility work gets deprioritised during release pressure.

Testing model beyond automation

Automated scans should run in CI, but manual checks remain essential. Include keyboard-only journey tests, screen-reader spot checks, and colour-contrast checks in release definition of done.

Minimum manual checks per release

• Keyboard navigation through primary menu and key forms.
• Visible focus indicators on interactive elements.
• Screen-reader labels on form controls and error messages.
• No content traps in modals or overlays.

Governance: keep progress between campaigns

Accessibility progress fades when no one owns it. Assign an accessibility owner for quality control and a product owner accountable for backlog prioritisation. Report progress monthly with resolved blocker count, open blocker count, and regression incidents.

Accessibility is maintained by routine, not by one large audit. Teams that treat it like security patching tend to keep gains. Teams that treat it as a project tend to lose them.

90-day practical plan

1. Weeks 1-2: map blockers to top user journeys and assign owners.
2. Weeks 3-6: remediate high-impact templates and components.
3. Weeks 7-8: embed automated and manual checks in release process.
4. Weeks 9-12: run follow-up audit sample and address regressions.

Part 1 identifies barriers. Part 2 changes delivery behaviour so barriers do not keep returning. That is the difference between compliance theatre and genuine accessibility improvement for charity users.

Related reading: WordPress Hosting Decisions For Charities: What Matters, Google Workspace Vs Microsoft 365 For Charities and Digital Accessibility Governance For Charity Content Teams.