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 WCAG standards work in practice, and what a genuinely accessible website looks like at code and content level. 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 maintaining 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 ensuring people with disabilities can 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, making 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 Compliance 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, achieving WCAG compliance for 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 Compliance Levels

WCAG success criteria are assigned to one of three conformance levels, and understanding the distinction helps businesses set the right web accessibility target.

For most UK and Irish businesses, targeting WCAG 2.2 Level AA is the right objective. It satisfies legal obligations, covers the majority of user needs, and aligns with GOV.UK design standards. It is also the level that ProfileTree recommends as a baseline for all new web builds.

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. This is not only an accessibility requirement; it is basic good design. Research consistently shows that high-contrast, clearly structured layouts reduce cognitive load for all users, not just those with visual impairments.

Understanding colour scheme importance sits at the intersection of brand identity, web accessibility, and usability. 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”.

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.

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. 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. Building web accessibility awareness into team workflows, rather than relying on periodic audits, produces more consistent results.

Structured digital training that includes web accessibility principles helps marketing and content teams understand their role in maintaining a compliant, inclusive website. 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.

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