Website Accessibility Explained
22nd Jul 2026 13 minutes read 14 sections
Overview
Accessibility often enters website discussions through legislation, procurement or WCAG compliance. That can make it sound like a technical requirement to complete before launch.
Web accessibility recognises that people use digital services in different ways. Some rely on assistive technologies, while others navigate, read or interact with content differently because of a disability. Accessible websites account for those differences rather than assuming everyone uses the same device, controls or senses.
Accessibility affects content, design, development, testing and ongoing website management. This guide explains what it means in practice, how WCAG supports it and what organisations need to consider after a website launches.
What is web accessibility?
Web accessibility means removing barriers that could prevent people from using a website independently. Rather than assuming every visitor has the same abilities or uses the same technology, it recognises the different ways people access, understand and interact with digital services.
Accessibility helps people complete tasks independently rather than requiring assistance because of barriers created by the website. Whether someone is applying for a job, paying a bill, booking an appointment or reading important information, those services should remain available to them.
People’s needs can also change. Someone recovering from an injury may need to navigate by keyboard for a while, while changes in vision, hearing or dexterity can affect how an older person uses a website. Designing with these situations in mind also helps remove barriers faced by disabled people.
Who does accessibility support?
Ensuring your website offers accessibility support can help a wide variety of users, including those with visual, hearing or motor impairments, those with cognitive or learning disabilities, neurological conditions and age-related issues.
People experience disability in different ways, so an improvement that helps one person may make little difference to another. Accessible websites need to address a variety of barriers rather than rely on one feature or solution.
Why accessibility matters
For many organisations, a website has become one of the primary ways people access information, complete tasks and use services. If parts of that website cannot be accessed or understood, some visitors may be excluded from services that others can use without difficulty. Accessibility helps reduce those barriers, allowing more people to participate independently.
This is particularly important where websites provide access to essential services and information. Applying for a job, arranging healthcare, managing finances, accessing education or contacting a public service increasingly happens online. When digital services are inaccessible, the consequences can be far more serious than mere inconvenience. They can prevent people from accessing information and opportunities that many of us take for granted.
Accessibility requirements in the UK
Accessibility is also an important legal consideration.
In the UK, most public sector websites and mobile applications must meet WCAG 2.2 Level AA under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. They must also publish an accessibility statement and keep it under review.
Private and voluntary sector organisations should also consider their responsibilities under the Equality Act 2010. They may need to change how their services are provided so disabled people are not placed at a substantial disadvantage, including when those services are accessed online.
Accessibility is increasingly considered during procurement exercises as well. Organisations may be asked to demonstrate how their websites have been designed, developed and tested against recognised accessibility standards before contracts are awarded.
How accessibility improves a website
Accessibility is not only about compliance.
Many accessibility improvements also improve the experience for everyone using a website. Clear navigation helps people find information more quickly. Well-structured content is easier to scan and understand. Descriptive links make journeys easier to follow, while well-designed forms reduce mistakes and frustration. Good colour contrast improves readability across different devices and environments.
Most people will not know that accessibility informed these choices. They will simply find the website easier to read, navigate and use.
Understanding WCAG
When organisations talk about website accessibility, they are usually referring to the Web Content Accessibility Guidelines, commonly known as WCAG.
Developed by the World Wide Web Consortium (W3C), WCAG is an internationally recognised set of guidelines for designing, developing and testing accessible digital content. Rather than prescribing how every website should look, WCAG provides a shared framework for identifying and removing barriers that could stop people from accessing online information and services.
WCAG gives organisations, designers, developers and accessibility specialists a common standard to work towards. It provides testable criteria for consistently assessing a website and identifying where improvements are needed.
The four principles of WCAG
WCAG is built around four fundamental principles of Perceivable, Operable, Understandable and Robust, also known as POUR. Together they describe the qualities every accessible website should be.
A website should be:
P
Perceivable
Information and interface components should be presented in ways that people can perceive, regardless of how they access the content.
O
Operable
People should be able to navigate the website and use its features through different input methods, including keyboards and assistive technologies.
U
Understandable
Content and interactions should be clear, predictable and easy to understand.
R
Robust
The website should be built using technologies that work reliably with different browsers, devices and assistive technologies, both now and as those technologies continue to evolve.
Each principle is supported by several guidelines, which are then broken down into individual, testable success criteria. These success criteria form the basis of accessibility testing and auditing.
WCAG conformance levels
WCAG defines three levels of conformance.
Level A
The minimum level of accessibility. These success criteria address the most fundamental barriers that could prevent someone from accessing content or completing basic tasks.
Level AA
The level most organisations work towards and the level commonly referenced in legislation and procurement. To conform at Level AA, a website must meet all applicable Level A and Level AA success criteria.
Meeting a conformance level shows that the relevant WCAG criteria have been satisfied. It is a useful measure of progress, although people may still encounter barriers when using the website.
Level AAA
Level AAA contains further criteria for improving accessibility. It is not usually applied across an entire website because some requirements will not suit every type of content or service.
WCAG provides a valuable benchmark, but conformance should not become a checklist exercise. Testing still needs to consider whether people can use the website successfully in practice.
What web accessibility looks like in practice
Accessibility influences almost every part of a website. Some improvements are immediately visible, while many happen behind the scenes through the way content is written, interfaces are designed, and websites are built. Together, these decisions determine whether visitors can successfully use a website regardless of how they access it.
Content
Clear headings, logical structure, descriptive links, meaningful page titles and accessible tables and documents.
Images
Useful alternative text for meaningful images, appropriate treatment of decorative images and no essential information trapped inside graphics.
Navigation
Consistent navigation, complete keyboard access, visible keyboard focus, skip links and useful breadcrumbs.
Forms
Clear labels and instructions, helpful validation, accessible error messages and suitable autocomplete support.
Design
Sufficient contrast, readable typography, suitable spacing and layouts that continue to work when people zoom or resize the page.
Development
Semantic HTML, correctly used controls, accessible interactive features and reliable support for browsers and assistive technologies.
Accessibility depends on content, design and development working together. Strong technical foundations will not make confusing content accessible and clear content cannot overcome poorly built features.
Accessibility features that work behind the scenes
Some accessibility features are visible. Others are built into the way the website works and may only become apparent when someone needs them.
Examples include:
- full keyboard navigation throughout the website
- ensuring keyboard users never become trapped within a page or dialogue
- helping screen readers announce important changes on a page
- reducing animations for people who experience motion sensitivity
- Captions and/or transcripts for embedded video and audio media
- audio descriptions where appropriate
- Being able to enlarge a web page, without it becoming unusable
- layouts that adapt as people zoom in
- buttons and links that are large enough to use comfortably
- accessible PDF documents
Many visitors will never notice these features, but they can determine whether someone else can use the website at all.
Visual design is only one part of accessibility. Many improvements involve careful development that supports assistive technologies and different ways of interacting with a website, often without changing how the website appears for most users.
How accessibility is tested
An automated check can identify some problems, but it cannot confirm whether the whole website is accessible. A proper review draws on more than one type of testing.
Automated testing
Automated tools can quickly pick up common problems such as missing alternative text or form labels, poor heading structure, low colour contrast and some HTML errors.
These tools provide an excellent starting point and can identify problems consistently across large websites. However, they cannot determine whether a website is genuinely easy to use or whether someone can successfully complete important tasks using assistive technologies.
Manual testing
Some problems only become clear when someone manually works through the website. This might involve using a keyboard, checking pages with a screen reader and trying forms or other interactive features. Automated scans can miss barriers in all of these areas.
Testing with disabled people
Disabled people may spot problems that do not appear during a technical review. Asking them to carry out typical tasks can show where the website becomes difficult to use.
Accessibility audits
Accessibility audits usually bring together automated checks, manual testing and a review against WCAG. The amount of work involved will depend on the website itself, the features being tested and how detailed the findings need to be.
No single organisation gives a website permanent approval as accessible. A specialist may audit or certify it at a particular point, but further checks are still needed as the site changes.
A thorough audit can show where barriers exist, which issues should be addressed first and what further work is required. It will not usually include the content, design or development changes needed to fix everything it identifies, so those costs should be considered separately.
Keeping a website accessible after launch
A website can meet accessibility requirements at launch and become less accessible as new content is added.
Developers establish the technical foundations during a project, but the website will continue to change. Editors publish new pages, upload documents, add videos, update services and introduce new layouts. Each change can create barriers if accessibility is not considered.
This makes accessibility part of day-to-day website management, not a one-off development task. Maintaining an accessible website depends both on how it was built and how people use and manage it afterwards.
Editors and content owners need to consider accessibility whenever they publish or update something. This includes writing useful alternative text, keeping headings in the right order, using descriptive links and making sure new PDFs, videos and other content are accessible. Accessibility statements should also be reviewed when the website or its content changes.
A well-designed content management system can make accessible choices easier by limiting unsuitable colours, providing structured heading options and prompting editors to add alternative text. However, no system can prevent every problem. Editors may paste formatted content from other sources, choose headings for their appearance rather than their meaning or upload documents and videos that have not been made accessible. Clear guidance and suitable training are particularly important when new people begin managing the website.
Accessibility is not the responsibility of one person or team. Designers, developers, editors, website owners and organisational leaders all influence whether a website remains accessible.
Design
Layouts that are easy to read, with suitable contrast and consistent controls.
Development
Code and interactive features that work with keyboards and assistive technology.
Content
Headings in the right order, useful links, appropriate alternative text and accessible documents and media.
Governance
The organisation agrees how accessibility will be handled, who is responsible and where it needs to be considered in procurement and other decisions.
Ongoing management
Training for editors, regular checks and action when new problems appear.
When these responsibilities are built into everyday website management, maintaining accessibility is far easier than correcting problems after they have accumulated.
Web accessibility FAQs
Does accessibility limit design?
Accessibility often influences design decisions, but it rarely prevents organisations from creating attractive, distinctive websites. In many cases, it encourages better design by placing greater emphasis on clarity, usability and consistency.
Is accessibility only for blind users?
Accessibility supports people with a wide range of visual, hearing, motor, cognitive and neurological conditions, while many accessibility improvements also benefit people with temporary injuries or changing circumstances.
Can accessibility be added later?
Some improvements can be made later, but many are much easier to address during planning, design and development.
Can automated tools certify accessibility?
Automated testing is an important part of accessibility assessment but cannot replace manual testing, user testing or professional judgement.
Does accessibility improve SEO?
Accessibility is intended to help people use websites, not to improve search rankings. Some good practices, including semantic HTML, meaningful page titles and well-structured content, can also help search engines understand a website.
Google’s Lighthouse tool includes a separate accessibility audit, but this should not be confused with its SEO audit or treated as evidence that an accessibility score directly affects rankings.
Does every website have to meet WCAG?
Not every organisation has the same legal responsibilities, but accessibility is not only a public sector issue. In the UK, organisations should also consider their responsibilities under the Equality Act 2010. Following recognised standards such as WCAG is widely regarded as good practice when creating accessible digital services.
Does accessibility make websites more expensive?
Accessibility is usually most cost-effective when it is considered from the beginning of a project. Retrofitting accessibility after a website has been designed or developed can require additional work, but many accessibility improvements are relatively small when incorporated into normal design, content and development processes.
Accessibility is ongoing
WCAG helps organisations identify and reduce barriers, but meeting the standard is only part of the work. The way a website is written, designed, built and managed will still determine how easy it is for people to use.
The work also continues after launch. New pages, documents, videos and features can introduce barriers, so organisations need appropriate processes, training and regular testing to maintain the standards established during the original project.
An accessible website is not simply launched. It is looked after.
