Web Content Accessibility Guidelines: A UK SME Guide
Table of Contents
Around one in five people in the UK lives with a disability. If your website does not meet the web content accessibility guidelines, you are effectively turning away a significant share of potential customers before they reach your products or services. That is not a theoretical risk. Under the Equality Act 2010 in Great Britain and the Disability Discrimination Act 1995 in Northern Ireland, businesses have a legal duty to make reasonable adjustments so that disabled people can access their services, and websites are included.
This guide explains what the web content accessibility guidelines (WCAG) actually require, what the law means for your business depending on where you operate, and how to move from awareness to practical action without overhauling your entire site in one go.
You will find: the four core WCAG principles, a breakdown of conformance levels A, AA and AAA, platform-specific advice for WordPress, Wix and Shopify users, and a phased approach to compliance that suits a realistic SME budget.
The four WCAG principles every business owner needs to know
The web content accessibility guidelines are published by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI). They set the international standard for making websites usable by people with visual, auditory, motor, cognitive and language-based disabilities. Every WCAG requirement traces back to four foundational principles, usually referred to by the acronym POUR.
Perceivable
Information on your website must be presented in ways that all users can perceive. In practice, this means providing text alternatives for images, captions for video content, and ensuring that nothing is communicated by colour alone. A common failure is a button that turns green to indicate success, with no text label confirming what happened. For a user with colour blindness, that button communicates nothing. When ProfileTree’s web design team builds sites, alt text and colour contrast ratios are built into the design brief from the outset rather than added as an afterthought before launch.
Operable
Every function on your website must be operable without a mouse. Users who rely on keyboards, switch devices or voice recognition software need to navigate menus, complete forms, and activate buttons using keyboard inputs alone. The Tab key should move logically through every interactive element on the page, and the currently focused element should always be visibly highlighted. Dropdown menus and modal dialogues are common failure points in sites built without this requirement in mind.
Understandable
Content must be written and organised so that users can understand both the information and how the interface works. This covers readable language, consistent navigation, clear error messages on forms, and predictable behaviour when users interact with elements. If clicking a link opens a new browser window, users should be warned in advance. If a form field is required, that should be clear before submission, not only in an error message that appears afterwards.
Robust
Your site must work across a wide range of browsers, devices and assistive technologies, including screen readers such as NVDA and VoiceOver. Code quality matters here. Semantic HTML, correctly implemented ARIA attributes and valid markup all contribute to robustness. A site that looks fine in Chrome but fails completely when accessed via a screen reader has a robustness problem, even if it passes visual design checks. ProfileTree’s web development team tests across assistive technologies as part of quality assurance on accessibility-scoped builds.
The legal framework: Equality Act 2010 vs DDA 1995
One area where most published accessibility guides fall short is the legal distinction between Great Britain and Northern Ireland. The two legal frameworks are different, and conflating them can leave NI-based businesses with an incomplete picture of their obligations.
The Equality Act 2010: England, Scotland and Wales
In England, Scotland and Wales, the Equality Act 2010 requires service providers to make reasonable adjustments to ensure disabled people can access services on a comparable basis to non-disabled people. The Act does not name websites specifically, but courts and tribunals have consistently interpreted digital services as within scope. The “reasonable adjustment” duty is ongoing, not a one-off fix. What counts as reasonable depends on the size of the organisation, the cost involved and the benefit to disabled users.
There is no single enforcement body that proactively audits private sector websites. Legal risk typically comes through complaints from disabled users, which can result in county court or employment tribunal claims. The Equality and Human Rights Commission (EHRC) can also take action against organisations in persistent or systemic cases. Reputational damage from public complaints is often the more immediate concern for SMEs.
The Disability Discrimination Act 1995: Northern Ireland
Northern Ireland operates under the Disability Discrimination Act 1995 (DDA 1995) rather than the Equality Act 2010, as equality legislation in Northern Ireland is devolved. The practical obligations are broadly similar: service providers must not treat disabled people less favourably and must make reasonable adjustments to remove barriers to access. The Equality Commission for Northern Ireland (ECNI) handles enforcement and guidance for NI businesses.
For NI-based SMEs, the key point is that “UK accessibility law” references in most online guides are written with GB in mind. If you are based in Belfast or anywhere in Northern Ireland, the DDA 1995 and ECNI guidance are the relevant starting points. The substance of what you need to do to your website is very similar, but your legal reference point and the enforcement body are different.
Public sector websites: stricter requirements
If you work with public sector clients or receive public funding, additional regulations may apply. The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require public bodies to meet WCAG 2.1 AA as a minimum and publish an accessibility statement. These regulations do not apply to most private SMEs, but contractors providing digital services to public bodies are increasingly expected to meet the same standard.
| Region | Legislation | Enforcement body | Standard referenced |
|---|---|---|---|
| England, Scotland, Wales | Equality Act 2010 | EHRC | WCAG 2.1 AA (recommended) |
| Northern Ireland | DDA 1995 | ECNI | WCAG 2.1 AA (recommended) |
| Public sector (UK-wide) | Public Sector Bodies Regulations 2018 | GDS / EHRC | WCAG 2.1 AA (mandatory) |
WCAG conformance levels: A, AA and AAA explained
WCAG success criteria are organised into three conformance levels. Understanding what each Level actually requires helps you set realistic targets and prioritise what to fix first.
Level A: the minimum floor
Level A covers the most fundamental barriers. A website that fails Level A has features that make it impossible for some disabled users to access any content at all. Examples include images with no alt text, form fields with no labels, and video content with no audio alternative. A site that cannot be navigated by keyboard at all fails at Level A. This is the baseline, not the goal. Many SME websites fail multiple Level A criteria without their owners being aware of it.
Level AA: the realistic target for most businesses
Level AA is the standard recommended for private sector websites and mandated for public sector sites in the UK. It meets all Level A requirements and adds criteria around colour contrast (a minimum ratio of 4.5:1 for normal text), captions for live video, consistent navigation across pages, and the ability to resize text to 200% without loss of content. WCAG 2.2, published in October 2023, added further Level AA criteria, including focus appearance requirements and additional mobile touch target sizes. For most SMEs, achieving Level AA compliance is the practical goal.
Level AAA: aspirational and context-dependent
Level AAA includes requirements that are not feasible for all content types, such as sign language interpretation for all pre-recorded audio content. The W3C does not recommend that organisations target Level AAA site-wide. It is more useful as a reference for specific high-priority pages, such as those serving users with the highest access needs, or where your audience includes a high proportion of disabled users. Targeting AAA for a contact form or key product page while maintaining AA across the rest of the site is a reasonable approach for organisations with the capacity.
| Level | What it covers | Realistic target for SMEs? |
|---|---|---|
| A | Fundamental barriers: alt text, keyboard access, basic form labels | Minimum — aim higher |
| AA | Colour contrast, captions, consistent navigation, text resize | Yes — this is the goal |
| AAA | Sign language, extended audio description, complex requirements | Selective pages only |
Making your website accessible: platform-specific advice
Most published WCAG guidance is written with developers in mind. If you manage your own website on a mainstream CMS platform, the practical steps look different. Here is what matters most on the platforms UK SMEs actually use.
WordPress accessibility
WordPress is the most widely used platform for SME websites and has reasonably good accessibility support at the core level, but theme and plugin choices can introduce significant problems. The theme is where most accessibility failures originate: non-semantic heading structures, insufficient colour contrast in the default palette, and navigation menus that are not keyboard-operable are all common in free and budget themes.
When selecting a WordPress theme, look for one that carries the “Accessibility Ready” tag in the official theme repository. This indicates it has passed a baseline set of accessibility checks. For plugins, the WP Accessibility plugin provides a useful set of quick fixes, including skip navigation links and focus indicators, though it does not substitute for proper theme development. If your WordPress site was built by an agency, it is worth requesting an accessibility review as part of any ongoing web development work. ProfileTree’s team regularly conducts these as part of site audits and redevelopments.
Wix accessibility
Wix has improved its accessibility tooling in recent years and includes some built-in features, such as automatic alt text suggestions and keyboard navigation in newer templates. The platform’s “Accessibility Wizard” provides a guided checklist of common issues. The main limitation with Wix is the reduced control over HTML output compared to WordPress, which can make certain Level AA fixes difficult to implement without developer access to the underlying code. For SMEs on Wix with straightforward sites, the built-in tools will take you a reasonable distance towards Level A compliance. Reaching a consistent Level AA requires more manual attention, particularly around colour contrast in custom colour schemes.
Shopify accessibility
Shopify’s Dawn theme, the current default, was built with accessibility considerations and performs reasonably well against WCAG 2.1 AA criteria. The more significant risks come from third-party apps and custom theme modifications. Many Shopify apps add front-end elements, including popups, product filters and loyalty widgets, that introduce keyboard traps, insufficient focus indicators or non-descriptive buttons. If your Shopify store has accumulated multiple third-party apps, an accessibility audit of those integrations specifically is a worthwhile exercise. Video content on product pages also requires captions to meet Level AA; this is a common omission in eCommerce sites that use video for product demonstrations.
A phased roadmap to WCAG compliance for SMEs
A full WCAG audit and remediation of a complex website can be significant work. For most SMEs, a phased approach is more practical. Start with the fixes that eliminate the highest legal risk and the highest impact on users, then work progressively towards full Level AA conformance.
Phase 1: high-impact visual fixes
The first priority is the fixes that automated tools can identify and that carry the highest legal and reputational risk. Run your site through a free tool such as WAVE (wave.webaim.org) or Google’s Lighthouse accessibility audit (built into Chrome DevTools). Address the errors first, which typically include missing alt text, form fields without labels, and missing page titles. Then move to colour contrast failures, which automated tools flag reliably. These fixes can be made incrementally without a full site rebuild.
Phase 2: keyboard navigation and structural fixes
Once visual and labelling issues are resolved, test your site using only the Tab key and no mouse. Can you reach every menu item, button, link and form field? Is the focus indicator visible at all times? Does the Tab order follow a logical reading sequence? Structural fixes at this stage include adding a “skip to main content” link (which bypasses repeated navigation for keyboard users), ensuring heading levels are hierarchically correct (H1 followed by H2, not H1 jumping to H4), and verifying that modal dialogues trap focus correctly and return it on close. These fixes typically require a developer and are a natural part of any accessible navigation improvement project.
Phase 3: content and form accessibility
This phase covers the ongoing content decisions that affect accessibility. Every image added to the site needs descriptive alt text. Every video needs captions. PDFs need to be tagged and structured for screen reader access. Forms need clear error identification and correction guidance. This is where your content team’s practices matter as much as the initial build. Building accessibility checks into your content workflow, rather than treating it as a one-off technical fix, is how organisations maintain compliance over time. ProfileTree’s digital training programmes cover content accessibility for non-technical team members, helping marketing and content teams understand what accessible publishing looks like in practice.
Phase 4: professional audit and accessibility statement
Once the most significant issues have been addressed, a professional accessibility audit provides an independent assessment of your conformance level, identifies remaining barriers that automated tools may miss, and provides a documented basis for your accessibility statement. A professional audit for an SME website typically involves a combination of automated scanning, manual expert review and screen reader testing.
Costs vary widely: free automated tools give a partial picture, while a thorough manual audit from an accessibility specialist starts at several hundred pounds and scales with site complexity. Publishing an accessibility statement on your site is required for public sector bodies and is best practice for all organisations. It demonstrates good faith, informs users about known limitations, and provides a mechanism for users to request accessible alternatives.
A note on accessibility overlays
A number of third-party “overlay” tools claim to make websites accessible with a single script. These tools add a widget to your site that allows users to adjust font sizes, colours and other visual settings. They are not a substitute for genuine WCAG compliance. Overlays do not fix underlying code issues and can, in some cases, make sites harder to use for screen reader users by adding conflicting ARIA attributes. The Web Accessibility Initiative and disability organisations, including Scope and AbilityNet, have been consistent on this point. If a solution promises full WCAG compliance with no developer involvement and minimal cost, treat that claim with scepticism.
Meeting the web content accessibility guidelines is not a single project with a completion date. It is a commitment built into how you commission, build and maintain your website. The practical starting point for most UK SMEs is an honest assessment of where the site currently sits against Level AA, prioritised fixes for the most significant barriers, and a content workflow that keeps accessibility in mind going forward. ProfileTree’s web design and development team works with SMEs across Northern Ireland, Ireland and the UK to build sites that meet WCAG requirements from the ground up. Talk to our web development team if you want to understand where your site currently stands.
Frequently asked questions
Is web accessibility a legal requirement for small businesses in the UK?
Yes, in practice. In Great Britain, the Equality Act 2010 requires service providers to make reasonable adjustments so that disabled people can access their services. Websites are included. In Northern Ireland, the equivalent legislation is the Disability Discrimination Act 1995. Neither law specifies WCAG compliance by name, but WCAG 2.1 AA is the accepted standard against which “reasonable adjustment” is typically measured. The risk for private SMEs comes primarily through complaints from disabled users, which can result in county court proceedings. There is no proactive enforcement body that routinely audits small business websites.
What are the four main principles of the web content accessibility guidelines?
The four principles are perceivable, operable, understandable and robust, commonly referred to as POUR. Perceivable means users can access content through at least one of their senses, including text alternatives for images and captions for video. Operable means all functionality is available by keyboard, not just mouse. Understandable means content is readable, and interfaces behave predictably. Robust means content works across different browsers and assistive technologies, including screen readers. Every individual WCAG success criterion maps back to one of these four principles.
What is the difference between WCAG 2.1 and WCAG 2.2?
WCAG 2.2 was published in October 2023 and builds on WCAG 2.1 by adding nine new success criteria. The most relevant additions for SMEs include: focus appearance requirements at Level AA (the visual indicator showing which element has keyboard focus must meet minimum size and contrast thresholds), larger minimum touch target sizes for mobile interfaces, and the removal of the “Parsing” criterion that previously concerned HTML validation. WCAG 2.2 also removes the WCAG 2.1 criterion 4.1.1 Parsing, which was considered obsolete. If your site was audited against WCAG 2.1 AA, it is worth re-checking against the 2.2 focus appearance criteria specifically, as this is the area most likely to require additional work.
Can a small business be taken to court for a non-accessible website in the UK?
Yes, though it is not common. Legal action against private businesses over website accessibility is less frequent in the UK than in the United States. The more typical pattern is a formal complaint to the business followed by a request for a reasonable adjustment. If the complaint is not resolved, a disabled user can bring a claim in the county court under the Equality Act 2010 (or through the Equality Commission for Northern Ireland under the DDA 1995). The greater practical risk for most SMEs is reputational: a public complaint about accessibility exclusion carries significant brand impact, particularly in the current environment where disability inclusion is under increased scrutiny. Taking proactive steps is considerably less costly than responding to a complaint after the fact.
Is there a difference between accessibility law in England and Northern Ireland?
Yes. England, Scotland and Wales operate under the Equality Act 2010. Northern Ireland operates under the Disability Discrimination Act 1995, as equality legislation in Northern Ireland is devolved. The practical obligations for website owners are broadly similar under both laws, but the legal framework and the enforcement body differ. In NI, the Equality Commission for Northern Ireland (ECNI) handles complaints and guidance rather than the Equality and Human Rights Commission (EHRC). Most online guides to UK web accessibility are written with Great Britain in mind, so NI-based SMEs should verify they are referencing the correct legislation.
Do accessibility overlay tools make a website WCAG-compliant?
No. Accessibility overlay widgets add a toolbar to your site that lets users adjust visual settings such as text size and contrast. They do not fix the underlying code issues that cause WCAG failures. Automated tools check for detectable issues at the point of page load, which overlays can sometimes mask without resolving. More significantly, overlays can interfere with how screen readers interact with a page, occasionally making it harder to use for the very users they claim to help. Organisations, including the W3C WAI, AbilityNet, and Scope, have all published guidance advising against treating overlays as a compliance solution. Genuine WCAG conformance requires addressing the source code and content practices.
How do I check if my website meets the web content accessibility guidelines?
Start with free automated tools: WAVE (wave.webaim.org) and the Lighthouse audit built into Google Chrome DevTools both provide a useful starting picture. Run them on your most important pages, including the homepage, a product or service page, a contact form and any checkout or booking flow. Automated tools catch a portion of WCAG failures reliably, particularly contrast, missing labels and missing alt text, but they cannot detect all issues. Manual testing is also needed, including keyboard-only navigation testing and screen reader testing (NVDA is free on Windows; VoiceOver is built into macOS and iOS). A professional audit combines automated scanning with expert manual review and provides a defensible record of your conformance level.