Understanding AA and AAA Accessibility: What Businesses Need to Know in 2026

Website accessibility is no longer a “nice to have” for businesses. Between the Equality Act 2010, the European Accessibility Act (EAA) now in force across the EU, and growing expectations from users and search engines alike, making your website accessible is a legal, commercial, and ethical priority.

This guide breaks down what AA and AAA accessibility standards mean, what UK businesses are legally required to do, and how to get your website up to standard.

The Legal Landscape: What UK Businesses Need to Know

Accessibility legislation has moved quickly over the past two years, and the requirements on businesses are now clearer and more enforceable than ever.

The Equality Act 2010 remains the primary piece of UK legislation. It requires all organisations, including private businesses, to make “reasonable adjustments” so that disabled people are not put at a substantial disadvantage when accessing services. Websites and apps fall under this. If a customer can’t complete a purchase, submit an enquiry, or access key information because of poor accessibility, that could constitute discrimination under the Act.

The Public Sector Bodies Accessibility Regulations 2018 require public sector websites and apps to meet WCAG 2.1 AA as a minimum. While this doesn’t apply directly to private businesses, it sets the benchmark. Many businesses working with government contracts or public sector clients are now expected to meet the same standard.

The European Accessibility Act (EAA), which came into force across all EU member states on 28 June 2025, is the biggest shift. It applies to any business that provides products or services to consumers in the EU, regardless of where that business is based. If your website is accessible to EU users, or if you sell into EU markets, the EAA applies to you. The technical standard it references is WCAG 2.2 AA. For UK businesses, this means the Equality Act covers your domestic obligations, while the EAA covers your EU-facing activity. In practice, building to WCAG 2.2 AA satisfies both.

What Are AA and AAA Accessibility Standards?

AA and AAA are two levels of compliance within the Web Content Accessibility Guidelines (WCAG), the internationally recognised framework for digital accessibility. WCAG 2.2, published in October 2023, is the latest version and the standard now referenced by the EAA.

The guidelines are organised around four principles, known as POUR: Perceivable, Operable, Understandable, and Robust. Every requirement in WCAG sits under one of these four principles.

AA Accessibility: The Baseline Standard

Level AA is the globally accepted baseline for most websites. It addresses the most common barriers affecting blind, low-vision, deaf, and mobility-impaired users, and is what the Equality Act and EAA both expect as standard. Here’s what it actually requires, in plain English.

Perceivable

Perceivable means your content can be accessed by everyone, regardless of how they’re experiencing it.

Text alternatives (1.1) – Any image, video, or non-text element on your site needs a written description. The most common example is alt text on images, read aloud by screen readers to users who can’t see the image. Every meaningful image needs alt text that describes its content or purpose clearly.

Captions and transcripts (1.2) – If your site includes video or audio content, people with hearing impairments need another way to access it. Captions for video and transcripts for audio are the standard approach here.

Colour contrast – How readable is your text for someone with low vision? WCAG requires a minimum contrast ratio of 4.5:1 between text and its background. Brand colours that look great in a logo often fail this test at small sizes on a white background, so your palette needs checking against a contrast tool.

Operable

Operable means users can navigate and interact with your site regardless of how they’re accessing it.

Keyboard accessibility (2.1) – Not everyone uses a mouse. People with mobility impairments often navigate entirely by keyboard, and every function on your website needs to work that way. If a user can’t tab to your navigation, fill in your forms, or activate your buttons using only a keyboard, the site fails this requirement.

Enough time (2.2) – Think about timed sessions and auto-refreshing content. If your site times users out, moves content automatically, or runs checkout timers, users must be able to pause, stop, or extend these without losing their place.

Seizure-inducing content (2.3) – Anything that flashes more than three times per second can trigger seizures in users with photosensitive epilepsy. The requirement is simple: don’t include it.

Consistent navigation (2.4) – Users should be able to find their way around your site reliably. Navigation menus, search bars, and other wayfinding elements need to appear in the same place and work the same way across pages, so users always know where they are.

Focus not obscured (2.4.11) – When a keyboard user tabs to an element, that element must be at least partially visible on screen. A common failure here is sticky cookie banners or headers that sit on top of content, completely hiding the item a user has navigated to.

Dragging movements (2.5.7) – Where your site uses drag-and-drop interactions, there must always be a single-click alternative. Google Maps handles this well: you can drag to move the map, or click the arrows instead. Any drag interaction without that fallback fails this criterion.

Target size (2.5.8) – All clickable elements and buttons must be at least 24×24 CSS pixels. This matters for mobile users and for anyone with reduced motor control who needs a bigger area to tap or click accurately.

Understandable

Understandable means both your content and your interface are clear and predictable.

Readable language (3.1) – Write clearly and avoid unnecessary jargon. Where technical terms are unavoidable, provide explanations or definitions inline so users don’t have to go elsewhere to understand what they’re reading.

Predictable behaviour (3.2) – Your site shouldn’t surprise or disorient users. Unexpected pop-ups, automatic redirects, or navigation that changes from page to page all undermine confidence in the site. Consistency matters.

Input assistance (3.3) – Good form design isn’t just about layout. Every field needs a clear, permanent label (not placeholder text that vanishes when you start typing), and when something goes wrong, the error message needs to explain exactly what the problem is and how to fix it.

Accessible authentication (3.3.8) – Logging in should never depend entirely on a user’s ability to remember something, solve a puzzle, or transcribe distorted text. At minimum, your authentication process must offer an alternative: support for password managers, an email link, biometrics, or similar. Object recognition (identifying images) and personal content recognition are also acceptable alternatives. In practice, this means removing pure CAPTCHAs without fallback options.

Robust

Robust means your site is built on clean, valid code that works reliably across different browsers and assistive technologies.

Logical structure (4.1) – The way your content is organised in the code matters as much as how it looks on screen. Semantic HTML, using elements like <nav>, <main>, and <header> alongside properly nested heading levels, gives assistive technologies the structure they need to interpret your content correctly.

Browser and assistive technology compatibility (4.1) – Following web coding standards ensures your site works not just in the browsers you’ve tested, but across the full range of tools your users might be using. Invalid or poorly structured code is often invisible to the naked eye but breaks entirely for screen reader and voice control users.

AAA Accessibility: Going Further Than Compliance

Level AAA is the highest tier of WCAG compliance. Full AAA compliance across an entire site is rarely practical, and WCAG itself acknowledges that it isn’t achievable for all content types. However, applying AAA criteria selectively to your most critical pages can make a meaningful difference for users with more complex needs. Achieving AAA compliance requires meeting all the AA requirements and addressing the following stricter guidelines.

Enhanced Perceivability

Sign language interpretation (1.2.6) – For users who rely on sign language as their primary language, captions alone aren’t enough. This criterion requires sign language video alongside any pre-recorded audio and video content.

Alternative presentations (1.3.4) – Where content relies on sensory characteristics, such as 3D modelling or spatial audio, an alternative way to access the same information needs to be available.

Reading level (1.4.8) – Consider the range of people reading your content. AAA requires that text is written to a reading level appropriate for the audience, with additional support provided where content is unavoidably complex. This is particularly relevant for legal, medical, or technical information.

Enhanced Operability

Keyboard shortcuts (2.1.3) – For users navigating complex interfaces by keyboard, shortcuts speed things up significantly. AAA asks that these are implemented for complex UI components, not just basic navigation.

Interface customisation (2.2.1) – Some users need to adjust how a site looks to use it comfortably. This criterion asks that you allow users to change text spacing, colour schemes, and other presentation preferences rather than locking them into your defaults.

In-page navigation (2.4.10) – Long pages can be difficult to navigate for keyboard and screen reader users. Providing navigation mechanisms that allow users to jump to specific sections within a page, rather than scrolling through everything, is what this criterion addresses.

Focus not obscured: enhanced (2.4.12) – The AA version requires that keyboard-focused elements are at least partially visible. AAA takes this further: when focus lands on an element, that element must be completely visible, with no part of it obscured by other content.

Focus appearance (2.4.13) – When a user has navigated to an element by keyboard, it needs to be clearly visible as selected. The focus indicator (typically a border or outline) must meet minimum size and contrast requirements. In practical terms: a button that’s been focused should have a surrounding border or highlight that’s large enough and different enough in colour that it’s impossible to miss. The contrast between the focused and unfocused states should be at least 3:1.

Enhanced Understandability

Additional cues (3.3.5) – For complex or technical content, extra context and guidance helps users understand what they’re reading. This goes beyond plain language, into proactive support for users who might otherwise be lost.

Form guidance (3.3.6) – Rather than waiting for errors to occur, this criterion asks that you offer instructions upfront on how to complete forms and interactive elements. Preventing mistakes is better than correcting them after the fact.

Cognitive accessibility (3.3.7) – Content should be readable and understandable by users with cognitive disabilities, which may require simpler language, additional explanation, or extra time and support to process information.

Accessible authentication: enhanced (3.3.9) – The same principle as the AA version, but stricter. No exceptions for object recognition or personal content. Every authentication step must offer a non-cognitive alternative, with no workarounds.

Enhanced Robustness

Wider assistive technology compatibility (4.1.3) – Beyond supporting mainstream screen readers and keyboards, AAA asks that you strive for compatibility with a broader range of assistive technologies used by people with less common disabilities.

Code validation (4.1.4) – Validating your code against current web standards improves reliability and compatibility across all technologies, including those that haven’t been built yet.

Common Accessibility Barriers on Business Websites

Even well-designed websites often have accessibility issues hiding in plain sight. These are the most common problems we see.

Colour contrast failures are one of the most frequent issues. Brand colours that look great on screen often fail WCAG contrast requirements when used as text on light backgrounds. Testing your brand palette against a WCAG contrast checker before signing off any design is essential.

Missing or poor alt text leaves screen reader users unable to understand images on your site. Product images, team photos, and infographics all need descriptive alt text that conveys meaning. Decorative images should use an empty alt attribute (alt=””) so screen readers skip them entirely rather than reading out the file name.

Inaccessible forms are a major barrier, particularly on e-commerce sites and lead generation pages. Forms that rely solely on colour to indicate errors, placeholder text that disappears when typing begins, and missing field labels all create problems. Every form field should have a visible, permanent label, and error messages should clearly explain what needs correcting.

Removed focus states are surprisingly common. The visible outline that appears when keyboard users tab through interactive elements is often removed for aesthetic reasons. Without it, keyboard navigation becomes impossible.

Poor mobile accessibility affects a significant proportion of your users. Touch targets that are too small, elements that overlap on smaller screens, and interactions that only work with precise gestures all create barriers. WCAG 2.2’s minimum target size requirement of 24×24 CSS pixels addresses this directly.

How to Assess and Improve Your Website’s Accessibility

Start with an audit. Automated tools like WAVE, Google Lighthouse, and axe DevTools will catch a range of technical issues, including missing alt text, contrast failures, and structural problems. They’re a good starting point, but they won’t catch everything. Automated testing typically identifies around 30-40% of accessibility issues.

Follow up with manual testing. Navigate your site using only a keyboard. Try completing your most important user journeys (making a purchase, submitting an enquiry, finding key information) without a mouse. Can you reach every link, button, and form field? Can you tell where you are on the page at all times? Test with a screen reader to hear how your site sounds to someone who can’t see it.

Involve real users where possible. Testing with people who use assistive technologies daily reveals barriers that no automated tool or manual audit will find.

Publish an accessibility statement. This should outline what standard you’re working to (e.g. WCAG 2.2 AA), any known limitations, and how users can report issues or request content in alternative formats. While only legally required for public sector bodies, it’s good practice for any business and signals a genuine commitment to accessibility.

Accessibility Is Good for Business

The improvements you make for accessibility, clear navigation, readable content, well-structured forms, and fast-loading pages, are the same improvements that reduce bounce rates, increase conversions, and boost SEO. Google’s algorithms favour well-structured, semantic HTML, and many accessibility best practices directly support organic search performance.

An accessible website also reaches a wider audience. In the UK, around 25% of people report having a disability. That’s a significant portion of your potential customers. Beyond disability, accessibility improvements help older users, people on slow connections, mobile users in bright sunlight, and anyone who benefits from a clearer, simpler experience.

Summary

Website accessibility in 2026 isn’t optional for businesses. The Equality Act 2010 covers your domestic obligations, the European Accessibility Act applies if you serve EU customers, and WCAG 2.2 AA is the standard both reference. Beyond compliance, accessible websites perform better commercially, reach more people, and deliver a stronger user experience across the board.

The practical steps are straightforward: audit your site, fix the most impactful issues first (contrast, alt text, keyboard navigation, forms), and build accessibility into your development process going forward rather than treating it as an afterthought.

Website Accessibility FAQs

What are the best tools to test website accessibility?

• WAVE (wave.webaim.org) is a free browser extension that highlights accessibility errors directly on your page, including contrast issues, missing alt text, and structural problems
• Google Lighthouse is built into Chrome DevTools and provides an accessibility score alongside performance and SEO audits
• axe DevTools is a browser extension that runs detailed automated checks and explains how to fix each issue
• Colour Contrast Analyser by TPGi is a desktop tool for checking specific colour combinations against WCAG contrast ratios

No automated tool catches everything; manual testing with a keyboard and screen reader is essential alongside automated scans

How do I perform a basic accessibility check on my website?

1. Start with an automated scan using WAVE or Lighthouse to catch obvious technical issues.
2. Then test manually: unplug your mouse and try navigating your site using only the Tab, Enter, and arrow keys. Can you reach every link, button, and form field? Can you tell where you are on the page at all times?
3. Check your images for meaningful alt text, your forms for visible labels and clear error messages, and your text for sufficient contrast.
4. If you want to go further, test with a screen reader (VoiceOver on Mac, NVDA on Windows) to hear how your site sounds to someone who can’t see it.

What is the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2, published in October 2023, builds on WCAG 2.1 by adding nine new success criteria. It’s backwards-compatible, meaning if you meet 2.2, you also meet 2.1. The key additions are:

• Target size (AA): Clickable elements must be at least 24×24 CSS pixels, improving usability on mobile and for users with motor impairments
• Focus not obscured (AA): Keyboard-focused elements can’t be completely hidden by other content like sticky headers or cookie banners
• Dragging movements (AA): Any drag-and-drop interaction must have a simple single-click alternative
• Accessible authentication (AA): Login processes can’t rely solely on cognitive tests; alternatives like password managers, email links, or biometrics must be supported
• Consistent help (A): Help mechanisms like chat widgets or contact links must appear in the same place across pages
• Redundant entry (A): Users shouldn’t have to re-enter information they’ve already provided in the same session

WCAG 2.1 remains the standard referenced in UK public sector regulations, but WCAG 2.2 is what the European Accessibility Act is built on and is the standard most forward-thinking businesses are now working to.

What are the guidelines for making e-commerce websites accessible?

E-commerce sites have some of the highest stakes when it comes to accessibility, because barriers directly prevent people from spending money with you. The key areas to focus on are:

• Product images need descriptive alt text that conveys what the product looks like, not just its name
• Filters and sorting should be keyboard-accessible and clearly labelled, not reliant on drag-and-drop or hover interactions
• Add to basket and checkout flows must work with keyboard navigation and screen readers; every form field needs a visible label, and error messages should explain exactly what’s wrong
• Payment forms should support autofill and not rely on CAPTCHAs or cognitive tests for authentication
• Touch targets on mobile need to meet the 24×24 CSS pixel minimum, particularly for quantity selectors, size pickers, and checkout buttons
• Price and availability information should be presented as text, not embedded in images, so screen readers can announce it

Test your full purchase journey from product search to order confirmation using only a keyboard. If you can’t complete a purchase without a mouse, neither can a significant number of your customers.

What legal requirements exist for website accessibility in the UK?

The Equality Act 2010 is the primary legislation. It requires all businesses to make reasonable adjustments so that disabled people can access services, and websites are included. WCAG 2.1 AA is widely accepted as the benchmark for what constitutes a “reasonable adjustment” in practice.

The Public Sector Bodies Accessibility Regulations 2018 mandate WCAG 2.1 AA for government and public sector websites. Private businesses aren’t directly covered, but those working on public sector contracts are often required to meet the same standard.

The European Accessibility Act (EAA), in force since June 2025, applies to any business providing products or services to EU consumers, regardless of where the business is based. It references WCAG 2.2 AA as its technical standard. If your website is accessible to EU users, or if you sell into EU markets, you need to comply.

In practice, building to WCAG 2.2 AA satisfies all three.

What are some tips for writing accessible alt text for images?

Good alt text describes the content and purpose of an image in a way that makes sense to someone who can’t see it. Keep it concise but specific. “A woman using a laptop at a desk” is better than “image” or “photo”, but “A customer completing an online order on a laptop” is better still if that’s the context.

For product images, include relevant details like colour, style, and distinguishing features. “Navy blue wool overcoat with double-breasted buttons” tells a screen reader user what they’re looking at. If an image contains text, the alt text should include that text in full. Decorative images that don’t add meaning should use an empty alt attribute (alt=””) so screen readers skip them entirely. And avoid starting alt text with “Image of” or “Picture of”; screen readers already announce it as an image, so this is redundant.