Website Accessibility: What UK Businesses Must Do
A solicitor in Leeds updates her firm's website, adds a client enquiry form, and assumes the job is done. Six months later a prospective client with a visual impairment can't read the form fields, can't submit, and leaves. No complaint is filed, but that client is gone. UK accessibility law has had teeth for years, and most small business websites are still not compliant. Here is what the rules actually require, and a practical place to start.
On this page
What UK Law Says
The Equality Act 2010 requires organisations to make “reasonable adjustments” so that disabled people can access goods and services, and that includes your website. There is no exemption for small businesses or sole traders. The Act covers any organisation serving the public, so if someone cannot use your site because of a visual impairment, a motor condition, or a cognitive difficulty, you are potentially in breach. On top of that, public sector bodies must also meet the Public Sector Bodies Accessibility Regulations, which mandate compliance with WCAG 2.1 AA as a minimum standard and require a published accessibility statement. Private sector organisations are not bound by those specific regulations, but the Equality Act still applies and carries real weight if a complaint reaches a tribunal.
Know which standard applies to you, audit your site against it, and document what you find. A website accessibility checklist is the most useful starting point because it turns a broad legal concept into concrete, fixable items.
Who Is Covered
Public sector organisations face the toughest rules under the Public Sector Bodies Accessibility Regulations (PSBAR), which came into force in 2018 and require government websites and apps to meet WCAG 2.1 AA as a legal baseline. Private businesses are not subject to PSBAR, so it is easy to assume accessibility law does not apply to them. It does.
The Equality Act 2010 covers any organisation that provides goods, facilities or services to the public, and a commercial website counts as a service. A disabled user who cannot complete a purchase, book an appointment, or read your terms because of a missing accessibility feature could bring a claim against you. It does not require the site to be wildly broken either. Something as mundane as images with no alt text, or a checkout form that a screen reader cannot navigate, could be enough to form the basis of a complaint.
Take an online clothing retailer as a concrete example. If a visually impaired customer cannot use the checkout because the form fields carry no labels that assistive technology can read, that business faces real legal exposure, not just bad press. The practical gap between PSBAR and the Equality Act is narrower than most people think. A thorough audit of how your site performs for real users is where most businesses discover these issues exist at all.
The WCAG Standard
Which level applies to you
The benchmark UK regulators and courts point to is WCAG 2.1 Level AA, published by the World Wide Web Consortium. It sits in the middle of three conformance levels. Level A is the floor, AA is what most organisations are held to, and AAA is reserved for specialist services where every user has a specific accessibility need. Public sector bodies in the UK are legally bound to AA under the Public Sector Bodies Accessibility Regulations, and private businesses facing an Equality Act claim will almost certainly be measured against the same standard. AA is the target.
The four principles behind the standard
WCAG organises its requirements under four principles. Perceivable means users can see or hear your content, so images need alt text and videos need captions. Operable means every function works without a mouse, keyboard-only navigation included. Understandable means your forms give clear error messages and your language does not require a law degree. Robust means the code is clean enough for screen readers and assistive tools to interpret reliably, which is where a lot of otherwise decent sites fall apart.
A Practical Accessibility Checklist
Images, keyboard navigation, and colour contrast
Start with images. Every image that carries meaning needs an alt attribute describing what it shows, not just its filename. A photo of a solicitor’s office front door should read something like “Front entrance of Smith & Co Solicitors on Market Street”, not “img_0047.jpg”.
From there, tab through your entire page using only the keyboard. Every link, button and form field should receive a visible focus state and respond correctly. If your cursor disappears into the page and you lose track of where you are, something is broken. Check colour contrast next. The visual design choices that look sharp in a mockup often fail in practice. Body text needs a contrast ratio of at least 4.5:1 against its background, and WCAG’s own contrast checker will give you a pass or fail in seconds.
Forms, links, and heading structure
Form fields need visible labels that stay on screen, not placeholder text that vanishes the moment someone starts typing. Links should say where they go. “Click here” tells nobody anything. “Download our accessibility policy PDF” does the job.
Finish with heading structure. One H1 per page, then H2s for major sections, H3s beneath those. Screen readers use that hierarchy to navigate, so skipping levels causes real confusion for users who rely on them.
WordPress Sites Have a Specific Problem Here
WordPress is brilliant for building sites quickly. That speed has a cost, and accessibility is often where it shows up first.
Page builders and theme frameworks generate a lot of markup automatically, and that markup frequently bypasses the standards that screen readers and keyboard users depend on. The most common pattern I see is icon-only buttons with no accessible label at all. A sighted user reads “close” or “menu” because they see the icon. Assistive technology reads nothing, or reads the raw CSS class name, which is meaningless. Form fields are another consistent weak spot. Automatically generated contact forms often pair an input with a placeholder rather than a real <label> element, which means the field label vanishes the moment someone starts typing.
Slider and carousel components tend to produce focus traps or expose every slide to the DOM at once, confusing the reading order completely. Dropdown navigation built by theme frameworks often fails keyboard traversal too, because the aria-expanded attribute either is not there or never updates its state.
None of this means WordPress itself is inaccessible. The problem is that many of these tools were built for visual output, not the kind of structural integrity that makes a site work for everyone. Catching these issues requires getting under the surface, not just running a quick automated scan.
Accessibility Statements
When you are legally required to publish one
An accessibility statement is a published page on your website that explains how accessible it is, what known issues remain, and how visitors can contact you if they hit a barrier. For public sector bodies in the UK, publishing one is a legal requirement under the Public Sector Bodies Accessibility Regulations 2018. If you run a council website, an NHS service, a university, or any other public authority, you have no choice in the matter. The statement must follow a specific format, reference the WCAG 2.1 AA standard, and be updated at least annually. Skipping it is not a grey area.
Why private sector businesses should bother anyway
Private sector businesses are not legally required to publish one, but doing it anyway is useful. It signals to disabled users that you have thought about them, and it gives you a credible place to log known issues you are still working through rather than pretending they do not exist. Writing a basic statement takes an hour or two. The Government Digital Service publishes a sample template you can adapt, and most of the content is factual, what you tested, when, and what you found.
Getting the Technical Side Fixed
Automated scanning tools will flag the obvious problems, colour contrast failures, missing alt text, unlabelled form fields. They miss a significant portion of real accessibility issues. Screen reader behaviour, keyboard navigation order, focus states that disappear mid-page, ARIA labels applied in the wrong place, these are the things that only show up when someone reads the code and tests it properly. That kind of audit takes time, and cutting corners on it means the problems move somewhere less visible rather than disappearing.
Most businesses do not need a six-month remediation project. They need someone who looks at what is broken, fixes the structure, and documents what was changed and why.
That is the approach taken here at Yorkshire Design. The work is technical and thorough, and it is not rushed, because a quick pass rarely holds up. If your site has not had a proper accessibility review and you want the detail done right, a good first step is to understand how hidden site problems affect real users, then get in touch to talk through what an honest audit would involve for your specific setup.