Accessibility becomes a sprint full of fixes, an audit report turns green, and everyone moves on. That is the approach I want to challenge. What happens to the next feature, the next design or the next piece of content?
I support web accessibility and the legislation behind it. My frustration is with treating it as a temporary project that one developer can finish for the rest of the organisation. We need a way of working that keeps our websites and apps accessible as they change.
What is WCAG?
WCAG stands for Web Content Accessibility Guidelines. These W3C guidelines describe how to make web content accessible to people with disabilities, including visual, auditory, motor and cognitive disabilities. They organise their requirements around four principles: content should be perceivable, operable, understandable and robust. The W3C overview of WCAG explains the standard and its versions.
Where the European Accessibility Act fits in
The European Accessibility Act (EAA) requirements have applied since 28 June 2025 to specified products and services, including consumer e-commerce services. This is not a blanket rule covering every business or website. The scope matters, and there are exemptions, including for microenterprises providing services, as well as transitional provisions. The EU provides an overview of the accessibility requirements and exceptions.
WCAG is a technical standard; the EAA and its national implementation establish legal obligations. Do not assume that a WCAG score alone tells you whether you meet all applicable requirements. For a team, both the legal scope and the accessibility standard being used need to be clear.
1. The familiar approach
Get your (European Accessibility) Act together
A deadline approaches. A product owner, manager or IT lead adds accessibility tickets to an already crowded sprint. One developer becomes the accessibility expert, designers adjust colours, and everyone hopes the extra work will be finished before the deadline.
Taking action is good. Fixing a missing label or an unusable control helps someone. The trouble starts when the organisation treats those repairs as a one-off exercise and assumes normal development can continue unchanged.
Computer says no yes
In projects where I worked as a consultant, I often saw external vendors deliver spreadsheets listing accessibility findings for individual URLs. Those reports gave designers and developers useful work to act on. The risk is letting the spreadsheet become the entire accessibility strategy.
An automated scan and a full accessibility audit are different things. Scanners can detect certain problems, but some checks need human judgement. A tool might find a missing text alternative without being able to decide whether an existing description is useful. As W3C explains about evaluation tools, tools assist evaluation; they cannot establish accessibility on their own.
A green report is useful evidence about what was checked. It does not prove that every user can complete every task, or that the next release will remain accessible.
2. Problems with our approach
Finishing tickets is not enough
My problem is with declaring the job done. Will the application still work with a keyboard after another hundred features? Will a redesigned form keep its labels and error messages? Will new content have meaningful headings and links?
When knowledge sits with one person, everyone else can keep introducing the same problems. An accessibility specialist can guide the team and investigate difficult issues, but the rest of the team still needs the skills and responsibility to deliver accessible work.
Compliance matters. So does what happens between assessments. Users need to book, buy, apply or find information every day, including the day after your audit.
Fix the source of recurring problems
Imagine a shared checkout component used on twenty pages. An audit finds that keyboard focus disappears when its dialog closes. Fixing one page leaves the other nineteen with the same problem. Fixing the component, checking its different uses and adding a regression check addresses the recurring cause.
That is why I want teams to look beyond the URL in a spreadsheet. Findings should feed back into components, design patterns, content guidance and review habits. A component library helps, but accessible components can still be combined into an inaccessible journey. The finished experience needs checking too.
3. Make accessibility part of everyday delivery
Fix urgent barriers while the team learns
Do not wait for everyone to finish training before fixing a barrier that prevents someone from completing a task. Tackle urgent problems while building the team's knowledge and agreeing on a sustainable approach. These activities can run in parallel.
Prioritise by impact on users, especially essential journeys such as signing in, submitting a form or checking out. Take quick wins where they help, but keep difficult blockers visible and assigned. W3C's guidance on interim repairs offers a useful starting point.
Give everyone a basic understanding of accessibility, then deepen the knowledge relevant to their role. A practical session navigating your own product with a keyboard can make the discussion much more concrete than a list of abstract requirements.
Give each role clear responsibilities
Shared responsibility needs specific agreements. I would start with these:
- Product owners: include accessibility in acceptance criteria, make time for testing and prioritise reported barriers.
- Designers: specify contrast, focus states, interaction behaviour and error states before handover.
- Developers: use appropriate HTML, implement keyboard interaction and focus management, and review shared components and complete journeys.
- Content authors: write clear headings, descriptive links, useful text alternatives and understandable instructions.
- QA: combine automated checks with manual evaluation and record the scenarios, states and assistive technologies tested.
The exact division will vary by team. Agree who does each check and who follows up on findings, so that “everyone's responsibility” does not become nobody's responsibility.
Add accessibility to the Definition of Done
For a customer-facing feature, I would use a short checklist like this as a starting point:
- The task can be completed using a keyboard, with visible focus and no keyboard traps.
- Headings, labels, names and states communicate the structure and purpose of the interface, including with a screen reader.
- Instructions and errors are understandable and associated with the relevant controls.
- Contrast is checked, and information does not depend on colour alone.
- Zoom and narrow layouts preserve access to content and controls.
- Automated checks have run, and relevant manual checks cover the complete journey, including errors and dynamic states.
- Fixes to shared patterns are checked in their other uses, with regression coverage where practical.
This is a working checklist, not a complete conformance assessment. Adapt it to the feature and your agreed WCAG version and level, using the WCAG quick reference for the applicable criteria.
Test with people as well as tools
Include people with disabilities in research and usability testing. Seeing someone try to complete a real task can reveal problems that a ticket or scan does not explain well. W3C recommends combining user involvement with standards-based evaluation: neither a successful session with one person nor an automated result represents everyone's experience.
Keep automated checks in the development workflow, use manual checks for the behaviour they cannot assess, and make it easy for users to report barriers. Give those reports an owner and follow up on them.
Dev, test, sleep, repeat
Accessibility needs attention when designs change, components are updated and content is published. Review recurring findings with the team. Update your guidance when it falls short. Bring in specialist help where the team needs it, and share what you learn.
I want an organisation to be able to explain how it keeps accessibility working after the original tickets are closed. That is the part a deadline-driven cleanup misses. Accessibility is part of our work, and it needs to stay there.
If your team needs help turning this into practical frontend and review habits, read about my consultancy work and team guidance.
LOL! This hits way too hard 😂 Greate write up, need to share this with my team.