Accessibility is a core part of quality. If people cannot use your site, the site fails.
If you run a business, charity, school, council service, or public platform, it also brings legal risk. Public sector bodies have clear duties under the UK accessibility regulations Source 3 . Other organisations still face duties under equality law and related guidance Source 4 .
Accessibility isn’t only about disability
Many people hear “accessibility” and think “screen readers” or “blind users”. Those users matter. They are one part of the work.
Accessibility means your site works for people with:
- Long-term impairments (e.g. visual, hearing, cognitive, motor)
- Temporary issues (e.g. broken arm, eye infection, concussion)
- Situational barriers (e.g. using a phone in bright sunlight, browsing one-handed while holding a baby)
- Technological limits (e.g. older phones, poor connections, assistive technology)
You will not know what a user is dealing with. They should not need to explain it.
More access means more reach
Accessibility is not only compliance. It is reach and reliability.
- More people can complete tasks.
- Journeys work across more devices and input methods.
- Support load drops when forms and content behave.
- Cleaner pages load faster and fail less.
WCAG 2.2 sets the baseline most teams aim for Source 1 . Good testing covers automated checks and manual verification on real journeys Source 2 .
Why so many websites get it wrong
Many teams treat accessibility as a box to tick near the end. Design and build decisions land first. Testing lands later. If the foundation is weak, fixes cost more and take longer.
This leads to:
- Users getting blocked from key tasks.
- Lost enquiries, donations, and sign-ups.
- Complaints, reputational damage, and legal pressure.
- Sites that feel fragile and hard to change.
Many issues are straightforward to resolve, once someone finds them and prioritises them.
What I do differently
I treat accessibility as part of delivery. It shapes content, design, components, and QA from the start.
Everything I build is:
- Navigable by keyboard Source 1 .
- Clear and readable, with predictable structure Source 1 .
- Checked with screen readers on key templates and forms Source 2 .
- Built with usable form errors and input guidance Source 5 Source 7 .
- Designed for real journeys, not ideal paths.
If your current site fails key checks, I’ll tell you. If you want a site that works for more people, I’ll build it.
Or request a Site Score for a clear breakdown of your current site. The quick report is free.
Sources
- [1] W3C. Web Content Accessibility Guidelines (WCAG) 2.2. Back to article
- [2] W3C WAI. Evaluating Web Accessibility Overview. Back to article
- [3] GOV.UK. Accessibility requirements for public sector websites and apps. Back to article
- [4] Bird and Bird. UK accessibility requirements for websites and mobile applications. Back to article
- [5] W3C. WCAG 2.2, Guideline 3.3 Input Assistance. Back to article
- [6] W3C WAI. Forms tutorial. Back to article
- [7] GOV.UK Design System. Error message component. Back to article
- [8] W3C WAI. Accessibility Statement Generator. Back to article