Web Accessibility Basics: A Practical Guide for UK and Ireland

Web accessibility is one of those topics that most businesses agree matters in theory, then quietly push to the bottom of the development backlog. That is a costly mistake, not just ethically, but commercially. Disabled people and their households control an estimated £274 billion in annual spending in the UK, a figure the disability charity Purple refers to as the “Purple Pound.” A website that excludes those users is not merely a non-compliant site; it is an underperforming one.

This guide explains what web accessibility means, what UK and Irish law requires, how the international web content accessibility guidelines work in practice, what a genuinely accessible website looks like at code and content level, and how to turn that knowledge into a roadmap you can actually maintain. Whether you are a business owner, a marketing manager, or a developer new to the subject, the sections below give you a working foundation for building and running an accessible website.

What is Web Accessibility?

Web accessibility means building websites, applications, and digital tools so that every person can use them, regardless of physical or cognitive ability. That covers permanent disabilities, including blindness, deafness, motor impairments, and cognitive conditions, but also situational limitations. A person watching a video in a noisy café without headphones benefits from captions just as a deaf user does. Someone recovering from a broken wrist benefits from keyboard navigation just as a person with a permanent motor impairment does.

The Web Accessibility Initiative (WAI), a programme run by the World Wide Web Consortium (W3C), defines web accessibility as allowing people with disabilities to perceive, understand, navigate, interact with, and contribute to the web. That last word, contribute, matters. Web accessibility is not only about consumption. It covers the ability to fill in a contact form, complete a checkout, submit a job application, or leave a review. Any point in a user journey where accessibility breaks down is a point where a real customer cannot complete a task.

For UK businesses, building an accessible website is not an optional design consideration. It is a legal one.

UK and Irish Legal Framework

Understanding the legal context matters before addressing technical detail, because the obligations differ between sectors and jurisdictions.

The UK Equality Act 2010 and Private Businesses

The UK Equality Act 2010 does not name websites explicitly, but case law has consistently confirmed that digital services fall under the “provision of services” obligation. Organisations providing goods or services to the public must make reasonable adjustments to avoid placing disabled people at a substantial disadvantage. Failing to maintain an accessible website can constitute indirect discrimination. The legal risk from a poorly built site is real and already tested in the courts, which makes web accessibility a compliance matter, not only a good-practice one.

Public Sector Accessibility Regulations 2018

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 go further. They impose specific, enforceable requirements on public sector organisations, including local councils, government departments, NHS bodies, and educational institutions, to meet WCAG 2.1 Level AA as a minimum. These regulations apply across the UK, including in Northern Ireland, where they cover the NI Executive’s digital services and local government portals. Non-compliant public bodies must publish an accessibility statement explaining any failures and their remediation timeline.

Irish Accessibility Law

In Ireland, the European Union (Accessibility of Websites and Mobile Applications of Public Sector Bodies) Regulations 2020 implement the EU Web Accessibility Directive, requiring Irish public sector sites to meet WCAG 2.1 Level AA. For private sector businesses, the Disability Act 2005 and the Equal Status Acts 2000 to 2018 set out the broader framework against discrimination in the provision of services.

For private businesses across both jurisdictions, the legal risk from an inaccessible website is often underestimated. A well-documented formal complaint under the Equality Act 2010 does not require a landmark test case; the principle is already established in law. Web accessibility compliance is, in practical terms, a risk management issue as much as a design one.

The WCAG Standards: POUR and Conformance Levels

The Web Content Accessibility Guidelines (WCAG) are the international benchmark for web accessibility. Published and maintained by the W3C, they sit behind almost every national regulation on accessible website design. The current version, WCAG 2.2, was published in October 2023 and introduces nine new success criteria beyond the 2.1 version that most official guidelines still reference.

The guidelines are structured around four core principles, known collectively as POUR.

Perceivable

Information must be presented in a way users can actually detect. If content only exists in one format, purely visual or purely audio, some users will be unable to access it at all. In practice, meeting this principle means providing text alternatives for images (alt text), captions for video content, transcripts for audio, and sufficient colour contrast so that text is readable against its background.

A useful self-test: if you removed every image from your page and replaced it with its alt text, would the content still make sense to someone who cannot see the visuals? If the answer is no, web accessibility work is needed on those images.

Operable

Every function on an accessible website must be usable without a mouse. Keyboard navigation, where users press Tab to move between interactive elements and Enter to activate them, is the baseline requirement. This matters for users with motor impairments, but also for anyone relying on a screen reader, a switch device, or voice control software. Beyond keyboard access, the Operable principle covers giving users enough time to complete tasks, avoiding content that flashes rapidly (a seizure risk), and providing navigation landmarks that help users find content efficiently.

WCAG 2.2 added “Focus Appearance” as a new criterion under this principle. Interactive elements must have a clearly visible focus indicator so keyboard users always know where they are on the page.

Understandable

The content and the interface both need to be clear. This principle covers the readability of the text itself and the predictability of how the interface behaves. Error messages on forms must explain what went wrong and how to correct it. Navigation must behave consistently across pages. The page language must be declared in the HTML so that screen readers use the correct voice and pronunciation.

WCAG 2.2 also introduced “Accessible Authentication” under this principle. Sites cannot require users to solve cognitive puzzles as part of a login process unless an accessible alternative is provided alongside it. For business websites with gated content or client portals, this is a criterion worth checking specifically.

Robust

Content must be built to work with current and future assistive technologies. This is a code quality principle at its core. Semantic HTML, correct ARIA attributes, and well-structured markup allow screen readers, voice control software, and browser accessibility tools to interpret and interact with the page correctly. Code that looks right visually but relies on non-semantic markup can be completely unreadable to an assistive technology, creating web accessibility failures that no visual test would catch.

WCAG Conformance Levels: A, AA and AAA Explained

WCAG success criteria are assigned to one of three conformance levels, and understanding what each one actually requires helps you set a realistic target rather than guessing at what “compliant” means.

Level A covers the most fundamental barriers. A site that fails Level A has features that make it impossible for some disabled users to access any content at all: images with no alt text, form fields with no labels, video with no audio alternative, or navigation that cannot be reached by keyboard. This is the floor, not the goal, and many business websites fail multiple Level A criteria without their owners realising it.

Level AA is the standard referenced in UK and Irish legislation and required for public sector sites. It meets every Level A requirement and adds criteria such as a minimum colour contrast ratio of 4.5:1 for normal text, captions for live video, consistent navigation across pages, and the ability to resize text to 200 per cent without losing content or function. WCAG 2.2 added further Level AA criteria on top of this, including the Focus Appearance requirement already mentioned and larger minimum touch target sizes for mobile interfaces. For most UK and Irish businesses, WCAG 2.2 Level AA is the practical target, and it is the level ProfileTree recommends as a baseline for all new web builds.

Level AAA includes requirements that are not realistic across an entire site, such as sign language interpretation for all pre-recorded audio content. The W3C does not recommend organisations target AAA site-wide. It is more useful as a reference point for a small number of high-priority pages, such as a contact form or a page serving an audience with particularly high access needs, while the rest of the site holds to AA.

Building an Accessible Website

Meeting WCAG Level AA in practice involves changes across code, content, and design. The following areas cover the majority of web accessibility failures found on business websites.

Semantic HTML, Keyboard Navigation, and ARIA

Semantic HTML means using HTML elements for their intended purpose. A heading is marked up as an h1, h2, or h3, not as a bold paragraph with a large font size. A navigation menu uses the nav element. A list uses ul or ol. A button that triggers an action is a button, not a styled div.

Screen readers and other assistive technologies rely on these structural signals to describe the page to users. A screen reader user navigating by headings will miss content that uses visual styling instead of actual heading tags. A div element styled to look like a button will not respond to keyboard input the way a genuine button element does, which is a common and often overlooked web accessibility failure in custom-built interfaces.

Where native HTML semantics are insufficient, WAI-ARIA (Accessible Rich Internet Applications) attributes provide additional context for assistive technologies. Custom dropdown menus, modal windows, tab panels, and dynamic content updates all benefit from ARIA roles and properties. For example, a collapsible panel can use aria-expanded=”true” or aria-expanded=”false” to communicate its current state to screen readers.

The ProfileTree web development team builds pages with semantic structure as a baseline requirement, not a retrofit. Proper heading hierarchy and keyboard-accessible interactive elements are significantly cheaper to build correctly from the start than to audit and fix after a site has launched.

Colour Contrast and Visual Hierarchy

WCAG 2.2 Level AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Many websites, particularly those using light grey text on white backgrounds, fail this web accessibility criterion without realising it.

Colour must not be used as the only means of conveying information. If a form field is highlighted in red to indicate an error, the error must also be communicated in text. That is an accessibility requirement, but it is also just good design: high-contrast, clearly structured layouts reduce cognitive load for every user, not just those with visual impairments.

Reviewing a site’s palette against WCAG contrast requirements using a free tool such as the WebAIM Contrast Checker is one of the quickest improvements most websites can make, and it has zero cost.

Alt Text and Descriptive Link Writing

Alt text is the written description attached to an image in HTML. Screen readers read it aloud in place of the image, and search engines index it. Writing accurate alt text is one of the most impactful and most neglected tasks in content management, and it is a direct WCAG compliance requirement under the Perceivable principle.

Bad alt text: alt=”image1.jpg” or alt=”” on an informational image. Acceptable alt text: alt=”A developer reviewing code on a laptop”. Strong alt text: alt=”Developer reviewing a WCAG compliance audit report on a second screen”. Decorative images that add no information should carry an empty alt attribute so screen readers skip them rather than reading the file name aloud.

The same principle applies to link text. A link that reads “click here” tells a screen reader user nothing about the destination. Screen reader users commonly navigate by listing all the links on a page, so “click here” repeated twelve times provides no meaningful information. Descriptive anchor text such as “view our web design process” or “download the WCAG 2.2 quick reference” serves both web accessibility and SEO simultaneously.

This connection between accessible content writing and effective digital marketing is worth noting. Accessible copy, which is clear, specific, and informative, is also the kind of copy that converts. ProfileTree’s content creation work applies these principles across client websites, treating descriptive, purposeful language as a foundation rather than a finishing touch.

Forms, Error Handling, and Authentication

Forms are one of the most common web accessibility failure points on business websites. Every input field needs a visible, properly associated label, not just placeholder text that disappears when a user starts typing. Error messages must be specific: “Please enter a valid email address” is more useful than a red border with no explanation. Where possible, errors should be identified in the page title or announced to screen readers automatically.

WCAG 2.2’s “Redundant Entry” criterion also requires that users are not asked to re-enter information they have already provided within the same process. This is particularly relevant for multi-step checkout flows, application forms, and booking systems on e-commerce or service websites, where poor form accessibility can directly reduce completed transactions.

Platform-Specific Fixes: WordPress, Wix and Shopify

Most published WCAG guidance is written with developers in mind. If you manage your own website on a mainstream CMS, the practical steps look a little different depending on the platform.

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 real problems. The theme is where most accessibility failures start: non-semantic heading structures, insufficient colour contrast in the default palette, and navigation menus that cannot be operated by keyboard are all common in free and budget themes. When choosing a WordPress theme, look for one carrying the “Accessibility Ready” tag in the official theme repository, which indicates it has passed a baseline set of checks. The WP Accessibility plugin provides useful quick fixes, including skip navigation links and focus indicators, though it does not substitute for proper theme development.

Wix has improved its accessibility tooling in recent years, with built-in features such as automatic alt text suggestions and keyboard navigation in newer templates, plus an “Accessibility Wizard” that walks through common issues. The main limitation is reduced control over the underlying HTML compared with WordPress, which can make some Level AA fixes harder to implement without developer access to the code. For SMEs on Wix with straightforward sites, the built-in tools will take you a reasonable distance towards Level A. Reaching a consistent Level AA usually needs more manual attention, particularly around colour contrast in custom colour schemes.

Shopify’s Dawn theme, the current default, was built with accessibility in mind and performs reasonably well against WCAG 2.1 AA criteria. The bigger risks come from third-party apps and custom theme changes: popups, product filters, and loyalty widgets frequently introduce keyboard traps, weak focus indicators, or buttons with no descriptive label. If a Shopify store has accumulated several third-party apps, it is worth auditing those integrations specifically. Product videos also need captions to meet Level AA, a common gap on stores that use video for product demonstrations.

If your site was built by an agency, ask for an accessibility review as part of any ongoing development work. ProfileTree’s team conducts these regularly as part of site audits and redevelopments.

Accessibility and AI Readability

Web accessibility and AI readability are more closely connected than most guides acknowledge, and this relationship has direct implications for how businesses think about their digital presence.

Large language models, the technology behind ChatGPT, Perplexity, and Google AI Overviews, parse web pages in ways that share structural dependencies with screen readers. An AI agent reading a page to extract an answer needs the same things a screen reader does: a clear heading hierarchy that signals topic structure, labelled images that describe their content in text, link text that provides context, and semantic markup that distinguishes navigation from content from supplementary material. A page built with div elements, unlabelled images, and ambiguous link text is difficult to parse for a machine learning system just as it is for a blind user relying on VoiceOver.

This has practical implications for organic search performance. Pages cited in AI Overviews tend to have clean structure, self-contained sections, and information that can be extracted independently of surrounding content. An accessible website architecture is, increasingly, the same architecture that earns AI citations. Businesses that treat WCAG compliance as a purely technical requirement are missing the broader commercial return that web accessibility investment delivers.

How to Test Your Site for WCAG Compliance

Testing for web accessibility requires a combination of automated scanning and manual review. Automated tools identify a significant proportion of failures quickly, but they cannot evaluate everything. They cannot judge whether alt text is meaningful, whether error messages are genuinely helpful, or whether keyboard navigation follows a logical sequence. A thorough web accessibility audit always combines both approaches.

Automated Testing Tools

Three free tools cover the majority of automated web accessibility checking.

WAVE (from WebAIM) scans a page and flags errors, alerts, and structural elements visually. It is browser-based, requires no installation, and identifies missing alt text, heading structure problems, colour contrast failures, and missing form labels.

Axe DevTools is a browser extension for Chrome and Firefox that integrates directly into developer tools. It provides a prioritised list of issues with explanations linked to the relevant WCAG success criteria, making it particularly useful for developers working through web accessibility fixes systematically.

Google Lighthouse is built into Chrome DevTools and provides an accessibility score alongside performance, SEO, and best-practice scores. It is useful for a quick directional audit, though it catches roughly 30 to 40 per cent of WCAG issues automatically and should not be treated as a complete web accessibility assessment on its own.

Manual Testing

Automated tools are a starting point, not a finish line. Manual testing should include a keyboard-only navigation test (remove the mouse and attempt to complete key user journeys using Tab, Shift+Tab, Enter, and arrow keys), a screen reader review using NVDA on Windows, VoiceOver on Mac and iOS, or TalkBack on Android, and a visual check at 200 per cent zoom to confirm that layouts do not break or overlap.

For organisations commissioning web design or development work, building web accessibility requirements into the project brief from the outset is significantly more cost-effective than testing and remediating after launch. The ProfileTree team approaches web development projects with WCAG 2.2 Level AA as a baseline specification, including automated accessibility testing as part of the QA process.

Training Your Team

Web accessibility compliance is not solely a development responsibility, and technical fixes only address the current state of a site. Content editors who write alt text, marketers who commission video without requesting captions, and product managers who approve designs without checking contrast ratios are all stakeholders in whether a site stays accessible over time.

Different roles need different knowledge. Developers need semantic HTML, ARIA, and keyboard accessibility patterns. Designers need colour contrast ratios, touch target sizes, and accessible typography. Content creators need heading hierarchy, descriptive link text, alt text, and caption requirements. Procurement staff need to know which accessibility questions to ask suppliers before a contract is signed.

Short, role-specific sessions tend to work better than one long general briefing. A focused session with a content team on writing useful alt text and structuring headings correctly is more likely to change day-to-day habits than a half-day course trying to cover everything for everyone. Structured digital training that includes web accessibility principles helps marketing and content teams understand their part in keeping a site compliant and inclusive, and ProfileTree’s digital training programmes can be built around these specific skills, from WCAG fundamentals to practical inclusive design techniques.

For Northern Ireland businesses in particular, the combination of legal obligation, the commercial opportunity of the Purple Pound, and the structural benefits for AI-powered search makes web accessibility one of the higher-return digital investments available.

Building Your Accessibility Roadmap

A one-off audit and fix cycle is not a strategy. Without a plan, accessibility work competes with every other development priority and usually loses, and the same problems tend to reappear after the next redesign or content update. A working roadmap turns audit findings into a sequenced set of actions with an owner, a timeline, and a way of checking progress.

Establish ownership first. Name the person responsible for accessibility before any technical work begins. For most SMEs, this is the website owner, a marketing manager, or whoever commissions development work. The person needs enough authority to approve budget and to raise accessibility as a requirement in every brief given to designers, developers, and content creators. If you work with an external agency, ask directly how it handles WCAG compliance during design and build, not just at the end. “We run a scan before launch” usually means a remediation backlog on day one.

Run a prioritised audit. Combine automated scanning with manual keyboard and screen reader testing, and log every issue against a severity rating: Critical (blocks access entirely), Serious (creates a notable barrier), Moderate (causes difficulty), or Minor (cosmetic). Critical and Serious issues on your highest-traffic pages go to the top of the queue; Minor issues can be batched into routine maintenance.

Set measurable standards. A one-page checklist is usually more useful to a small team than a long policy document. A practical version covers alt text for every image, correct heading order, WCAG 2.2 Level AA colour contrast, visible form labels, descriptive link text, captions on video, and keyboard access for every interactive element. Once these are the default expectation for every content update, compliance stops being a one-off project and becomes normal practice.

Schedule regular reviews. A single fix cycle is a project, not a strategy. Run automated scans on your highest-traffic pages regularly, review a rotating set of pages manually each quarter, and reset the baseline with a full review once a year. Keep a short changelog of what changed and when, for example “Added alt text to all product images; fixed keyboard trap in navigation menu.” That record is your evidence of good-faith progress if a complaint or supplier compliance question ever arises.

Where Accessibility Strategies Go Wrong

Two patterns explain most of the accessibility work that has to be repeated from scratch.

The first is treating accessibility as a one-time project rather than an ongoing process. Every content update, plugin change, or redesign can introduce new barriers, and a strategy without a review cadence will drift back towards where it started. Scheduling automated scans and a periodic manual check as standing items in your website management workflow prevents the kind of build-up that later feels like a full remediation project.

The second is separating accessibility from the design brief. Many businesses commission a website and only request an accessibility audit afterwards, by which point barriers are already built into the design system, the component library, and the content templates. Fixing them post-launch costs considerably more than specifying WCAG requirements upfront. Accessibility belongs in the brief, not the QA checklist: when commissioning web design or development work, specify WCAG 2.2 Level AA as a delivery requirement and ask how the agency tests for it at each stage of the build. ProfileTree’s digital strategy services include accessibility planning as part of project scoping, so compliance requirements are addressed before a line of code is written.

Taking the Next Step

WCAG compliance is a baseline, not a ceiling. The businesses that handle web accessibility well treat it as a design value rather than a checklist item, building it into briefs, development standards, and content workflows from the start. That approach produces sites that are faster to audit, cheaper to maintain, and demonstrably better for every user, not only those with disabilities.

As Ciaran Connolly, founder of ProfileTree, notes: “The businesses we work with that treat accessibility as a development standard from day one spend far less on remediation and see measurably better performance across both organic search and conversion, because an accessible site is simply a better-built site.”

If you would like a review of your current site’s web accessibility or want to discuss building WCAG 2.2 compliance into an upcoming project, get in touch with the ProfileTree team to start the conversation.

Frequently Asked Questions