What Is Website Accessibility?

One in five people in the UK has a disability. That is 14.6 million people. Some use screen readers to navigate websites. Some cannot use a mouse. Some need high contrast to read text. Some process information differently and need clear, simple language.

Website accessibility is the practice of building websites that work for all of them — not as a favour, but as a fundamental design requirement.

What Accessibility Actually Means in Practice

An accessible website is one that can be perceived, understood, navigated, and interacted with by people regardless of their abilities or the technology they use. In concrete terms, this means:

• A blind person using a screen reader can navigate your site, understand images through alt text, and complete forms without visual cues.
• A person with motor impairments can operate every feature using only a keyboard — no mouse required.
• A person who is deaf or hard of hearing can access the content of any video or audio through captions or transcripts.
• A person with a cognitive disability can understand your content because it uses clear language, consistent navigation, and predictable behaviour.
• A person with low vision can read your text because it has sufficient colour contrast and can be enlarged without breaking the layout.
• A person with epilepsy is not put at risk by flashing content or highly saturated colour fields.

Accessibility is not about adding an overlay widget or a special "accessible version" of your site. It is about building the site properly in the first place.

The Legal Position in the UK

In the UK, website accessibility is covered by the Equality Act 2010, which requires service providers to make "reasonable adjustments" to ensure disabled people can access their services. Since websites are a means of delivering services, they fall within scope.

There is no specific UK law that mandates WCAG compliance by name. However, WCAG Level AA is universally recognised as the technical standard that demonstrates "reasonable adjustments" have been made. Courts and regulators treat it as the de facto benchmark.

For public sector organisations, the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 are more explicit: public sector websites must meet WCAG 2.1 Level AA and publish an accessibility statement.

From June 2025, the European Accessibility Act applies to organisations selling products or services in the EU, including e-commerce, banking, and transport. If you serve EU customers, WCAG 2.1 AA compliance is effectively mandatory.

What Is WCAG?

The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility, published by the World Wide Web Consortium (W3C). They define success criteria organised around four principles, known by the acronym POUR:

• Perceivable — Information must be presentable in ways that all users can perceive. This includes alt text for images, captions for video, and sufficient colour contrast.
• Operable — The interface must be operable by all users. This includes keyboard navigation, no time limits that cannot be extended, and no content that causes seizures.
• Understandable — Content and interface behaviour must be understandable. This includes readable text, predictable navigation, and input assistance on forms.
• Robust — Content must be robust enough to work with current and future assistive technologies. This means valid HTML, proper ARIA usage, and semantic markup.

WCAG has three conformance levels:

• Level A — The bare minimum. Addresses the most critical barriers. If your site fails Level A, some users literally cannot use it.
• Level AA — The standard target. Addresses the majority of accessibility barriers for the majority of users. This is what the law expects.
• Level AAA — The gold standard. Not always achievable for all content types, but pursuing it demonstrates genuine commitment to inclusion.

The current version is WCAG 2.2, released in October 2023. For a detailed comparison with the previous version, see our article on the differences between WCAG 2.1 and 2.2.

The Most Common Accessibility Failures

After auditing hundreds of websites using the PEER framework (which checks 87 WCAG 2.2 rules plus custom heuristic rules), we consistently see the same issues. The WebAIM Million report confirms our findings — these are the most common failures across the web:

• Insufficient colour contrast — Text that does not meet the minimum 4.5:1 contrast ratio against its background. This is the single most common accessibility failure, affecting over 80% of websites. Light grey text on white backgrounds is the worst offender.
• Missing alt text on images — Screen readers cannot describe an image if no alt text is provided. Every meaningful image needs descriptive alt text. Decorative images need alt="" to be skipped.
• Missing form labels — Input fields without associated <label> elements leave screen reader users guessing what information is required.
• Empty links and buttons — Links wrapping images without alt text, or buttons with only icons and no accessible name, are invisible to assistive technology.
• Broken heading hierarchy — Jumping from H1 to H4, or using headings for visual styling rather than document structure, makes screen reader navigation confusing.
• No keyboard navigation — Interactive elements that only respond to mouse clicks exclude users who navigate by keyboard, including many motor-impaired users.

What Automated Testing Can and Cannot Do

Automated tools like axe-core (which PEER uses) can detect approximately 30–40% of WCAG success criteria. They are excellent at catching structural issues: missing alt text, contrast failures, missing form labels, broken ARIA, heading hierarchy problems.

What they cannot catch includes:

• Whether alt text is actually meaningful (they can detect its presence, not its quality)
• Whether keyboard navigation follows a logical order
• Whether focus indicators are visible enough in context
• Whether content is cognitively accessible
• Whether custom components behave correctly with screen readers

This is why a PEER audit includes automated testing as a baseline, but recommends manual testing with real assistive technology and user testing with disabled people for a comprehensive assessment.

Accessibility Overlays: Why They Do Not Work

Accessibility overlay widgets — tools like UserWay, AccessiBe, or AudioEye that add a toolbar to your site promising one-click compliance — are widely criticised by the accessibility community. The National Federation of the Blind, the American Council of the Blind, and numerous accessibility professionals have issued statements against them.

The reasons are straightforward:

• They cannot fix structural HTML problems (which is where most accessibility issues live)
• They often introduce new accessibility barriers
• They do not provide legal protection — several organisations using overlays have been sued successfully
• They add page weight and performance overhead
• They signal to disabled users that the site was not built with them in mind

The only reliable path to accessibility is building it into the website itself.

How to Check Your Website's Accessibility

There are several ways to get started:

• Browser extensions — The axe DevTools extension (free) runs automated checks in your browser. It catches the structural issues.
• Keyboard testing — Press Tab through your entire site. Can you reach every interactive element? Can you see where focus is? Can you operate menus, forms, and modals without a mouse?
• Screen reader testing — Try navigating with NVDA (free, Windows) or VoiceOver (built into Mac/iOS). If you cannot complete a key task, neither can a blind user.
• PEER audit — Our PEER audit runs 87 WCAG 2.2 rules plus custom detection rules across your entire site (not just the homepage), on both desktop and mobile, and reports issues with full evidence including page URLs, element selectors, and remediation guidance.

The Business Case

Beyond legal compliance, accessible websites consistently outperform inaccessible ones on every metric that matters:

• SEO — Accessibility best practices (semantic HTML, alt text, heading structure, link text) are directly rewarded by search engines.
• Conversion rates — Usable forms, clear navigation, and readable content improve completion rates for all users, not just disabled users.
• Market reach — The spending power of disabled people in the UK is estimated at £274 billion annually (the "purple pound").
• Brand reputation — Organisations that visibly prioritise inclusion build trust with all customers.
• B Corp certification — The JEDI Standards V2.2 require website accessibility assessment (JEDI2.m, JEDI2.q, JEDI2.p) for certification.

Where to Start

If you have never assessed your website's accessibility, start with these three steps:

• Run a PEER audit to understand the scale and nature of the issues.
• Fix colour contrast first — it is the most common issue and usually the easiest to resolve (often a single CSS variable change).
• Add alt text to every image and labels to every form input. These are the highest-impact fixes for screen reader users.

Accessibility is not a destination. It is a practice — something you build into your workflow, test regularly, and improve continuously. The PEER framework gives you a baseline measurement and a roadmap. The work starts from there.