How to Avoid Accessibility Problems under the Equality Act — and Fix Them When They Appear
Digital accessibility is no longer a niche concern in the UK. Under the Equality Act 2010, organisations have a duty not to discriminate against disabled people and, in many cases, to make reasonable adjustments. Public sector bodies have additional, more explicit obligations under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations.
Many organisations only confront accessibility seriously after receiving a complaint, negative feedback, or formal challenge. By then the work is more stressful, more costly, and more public than it needed to be.
A better approach is to treat accessibility as part of ordinary product quality — something considered during research, design, development and testing — rather than as a legal or compliance exercise that happens at the end. This reduces risk and produces better experiences for more people.
What accessibility means in a UK context
The Equality Act 2010 protects people from discrimination on the basis of disability and requires reasonable adjustments in the provision of services. While the Act itself does not prescribe detailed technical standards for websites, in practice the Web Content Accessibility Guidelines (WCAG) — usually level AA — are used as the accepted benchmark for digital accessibility.
Public sector organisations are explicitly required to meet WCAG 2.1 AA (with WCAG 2.2 now widely expected) and to publish an accessibility statement.
These standards cover principles such as:
Perceivable — information must be presentable in ways people can recognise
Operable — interface components must be usable in different ways, including by keyboard
Understandable — content and operation must be clear
Robust — content must work with current and future assistive technologies
In practical terms this includes text alternatives, keyboard access, colour contrast, focus management, form labels, heading structure, and compatibility with screen readers and other assistive technologies.
How to avoid problems in the first place
Prevention is significantly cheaper and calmer than remediation under pressure.
1. Build accessibility into the product process Accessibility decisions are made (or missed) throughout the lifecycle:
Research can include disabled people and people who use assistive technologies
Design can establish clear structure, focus order, contrast and inclusive interaction patterns
Development can implement semantic HTML, proper labelling, keyboard support and careful use of ARIA
Testing can include both automated checks and real assistive technology use
When accessibility is left until the end, it becomes a retrofit. When it is considered early, many barriers never appear.
2. Use WCAG as a practical guide Teams do not need to memorise every criterion, but they should understand the recurring high-impact areas:
Keyboard accessibility
Text alternatives for non-text content
Colour contrast
Form labels and clear error identification
Heading structure and reading order
Visible focus and logical focus order
Avoiding content that cannot be controlled or paused
3. Test with more than automated tools Automated scanners catch certain issues (missing alternative text, contrast failures, some missing labels). They miss many others — especially keyboard flows, screen reader interpretation, and cognitive clarity. Manual testing and, where possible, feedback from disabled people provide a far more realistic picture.
4. Treat accessibility as a shared responsibility Designers, developers, content designers and product owners all influence the outcome. When accessibility is framed solely as a development or compliance task, gaps are more likely to appear.
How to respond when problems are identified
If an audit, user feedback or formal complaint highlights accessibility barriers, a structured response is more effective than a rushed one.
Step 1: Understand the scope Clarify which pages, templates or user journeys are affected and which types of barriers have been found. A prioritised inventory is more useful than a long undifferentiated list of issues.
Step 2: Prioritise by user impact Not every issue carries equal weight. Barriers that prevent core tasks — navigation, forms, key content, account management, or essential service journeys — should usually be addressed first. This aligns with the idea of reasonable adjustments.
Step 3: Fix systematically Common remediation work includes:
Adding meaningful alternative text
Improving colour contrast
Ensuring full keyboard access and visible focus
Labelling form fields and describing errors clearly
Correcting heading hierarchy and document structure
Making custom components operable with assistive technologies
Providing captions or transcripts where relevant
Fixes should be tested, not merely implemented.
Step 4: Prevent recurrence Once urgent issues are resolved, update design systems, component libraries, content guidelines and quality checks so the same problems are less likely to reappear in future releases. Public sector bodies will also need to keep their accessibility statement up to date.
Common mistakes that increase risk
Several patterns regularly create avoidable problems:
Assuming a visual redesign is automatically accessible
Relying only on automated testing
Shipping custom interactive components without keyboard or screen reader support
Leaving accessibility review until after launch
Treating a single audit as a permanent solution
Making rapid, untested changes in response to a complaint
Accessibility is ongoing. Products change and new features introduce new risks. Continuous attention is more effective than occasional crisis response.
How accessibility connects to the wider product journey
Accessibility is not separate from good product work. It strengthens it.
Research that includes a wider range of people produces more robust insights. Design that considers diverse ways of perceiving and interacting tends to be clearer for everyone. Development that uses semantic, well-structured code is usually more maintainable. Testing that includes accessibility checks reduces last-minute surprises. Ongoing support provides a route for real users to report barriers after launch.
When accessibility is integrated rather than isolated, both inclusion and product quality improve.
Final thought
The most reliable way to avoid accessibility problems under the Equality Act is to stop treating accessibility as a legal or compliance add-on. Organisations that design and build with a broader range of human abilities in mind from the start face fewer complaints, lower remediation costs, and produce products that simply work better for more people.
When issues do appear, calm diagnosis, prioritised repair, and stronger ongoing practices are more effective than rushed or purely defensive responses.
At Whim & Wireframe, we treat accessibility as part of ordinary product craft — connected to research, design, development and testing rather than bolted on at the end. The result is not only reduced risk, but clearer, more resilient digital experiences.
If you are planning a new product, reviewing an existing one, or responding to accessibility feedback, the most valuable step is usually to bring accessibility into the core process rather than leaving it as a separate compliance exercise.
