When people talk about web accessibility standards<\/strong>, they are often using one phrase to describe a few different things at once. That can include laws such as the Equality Act 2010<\/a>, regulations such as The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018<\/a>, and technical standards such as WCAG 2.2<\/a>.<\/p>\n\n\n\n So, while these terms are closely linked, they are not all the same thing. Some set out the legal expectations around accessibility, while others provide the practical benchmark websites are measured against. In most cases, when people ask what standard a website should meet, they are really asking what set of criteria it should be built and reviewed against in practice.<\/p>\n\n\n\n There is not one single document called the UK web accessibility standard. Instead, the picture is made up of a few connected parts:<\/p>\n\n\n\n For public sector websites and mobile apps, those regulations require organisations to make their digital services accessible and publish an accessibility statement. In practice, that means working to WCAG 2.2 at Level AA, which is the benchmark widely used to assess whether a website is accessible.<\/p>\n\n\n\n Outside the public sector, there is not one separate set of UK website accessibility regulations in the same way. But that does not mean accessibility is optional. Under the Equality Act 2010<\/a>, UK service providers have a legal duty to make reasonable adjustments for disabled people. In practice, WCAG 2.2 AA<\/a> is still the clearest and most widely recognised benchmark to work towards when designing, building, and reviewing a website.<\/p>\n\n\n\n So, when people ask what standard a website should meet in the UK, the most practical answer is usually this: WCAG 2.2 AA is the benchmark your website should be aiming for<\/strong>.<\/p>\n\n\n\n But saying that is the easy part. The more useful question is what that actually means on a real website. That is where POUR comes in.<\/p>\n\n\n\n If you keep coming across the term WCAG 2.2 AA<\/a>, it helps to know what it actually is. WCAG stands for Web Content Accessibility Guidelines<\/strong>. It is the main set of standards used to judge whether a website is accessible. It is not new either. The first version, WCAG 1.0, was introduced back in 1999. WCAG 2.0 followed in 2008, WCAG 2.1 came in 2018, and WCAG 2.2 was released in 2023.<\/p>\n\n\n\n That matters because it shows web accessibility is not a passing trend or a new box-ticking exercise. These standards have been around for decades and have evolved as websites have changed. Modern websites now rely far more on mobile devices, interactive forms, pop-ups, menus, videos, and dynamic content, so the guidance has had to grow with them. But the core idea has stayed the same throughout: websites should work for everyone, including disabled people.<\/p>\n\n\n\n At the centre of WCAG are four principles known as POUR<\/strong>. That stands for Perceivable, Operable, Understandable,<\/strong> and Robust<\/strong>. These are the foundations of web accessibility. Put simply, if a website is hard to see, hard to use, hard to follow, or badly built behind the scenes, there is a good chance some users will struggle or be blocked from using it altogether.<\/p>\n\n\n\n Perceivable<\/strong> means people need to be able to notice and take in the content on the page.<\/p>\n\n\n\n Take colour contrast<\/strong> as one example. If light grey text is placed on a white background, some people will struggle to read it. That could include people with low vision, colour blindness, or even someone trying to read the page outside in bright daylight. This matters because if text does not stand out clearly enough from the background, people may miss key information, strain their eyes, or give up reading altogether.<\/p>\n\n\n\n Another example is alt text<\/strong>. Alt text is a short written description added to an image so that someone using a screen reader can understand what that image is showing. For example, if a page includes a chart showing growth over time, a screen reader user needs some kind of description of what that chart is telling them. This matters because without it, some users may miss information that everyone else can see straight away.<\/p>\n\n\n\n Perceivable also covers things like captions on videos, transcripts for audio, and making sure text can be enlarged without the page becoming difficult to use. In simple terms, people need a fair chance to access the content, whatever way they are using the web.<\/p>\n\n\n\n Operable<\/strong> means people need to be able to use the website and move through it properly.<\/p>\n\n\n\n For example, some people do not use a mouse at all and move through a website using only their keyboard. They might use the tab key to jump from link to link, button to button, and form field to form field. If a menu only opens when someone hovers over it with a mouse, or a button cannot be reached by keyboard, that becomes a barrier. This matters because if someone cannot physically get to the parts of the site they need, the website is not really usable for them.<\/p>\n\n\n\n Another example is a visible focus state<\/strong>. When someone tabs through a page, there should be a clear sign showing where they are, such as an outline around a button or link. This matters because without that visible marker, keyboard users can quickly lose track of where they are on the page and struggle to move forward with confidence.<\/p>\n\n\n\n Operable also includes things like making buttons large enough to tap on mobile, avoiding interactions that rely on very precise movements, and making sure people can close pop-ups or complete actions without getting stuck. The aim is simple: people should be able to use the website, not fight with it.<\/p>\n\n\n\n Understandable<\/strong> means the website should be clear, predictable, and easy to follow.<\/p>\n\n\n\n Take a form as an example. If a field just says \u201cEnter details\u201d and then shows an error without explaining what has gone wrong, many users will get stuck. A better approach would be a clear label, a clear instruction, and an error message that explains exactly what needs fixing, such as \u201cPlease enter your email address in the correct format\u201d. This matters because people should not have to guess what a website wants them to do.<\/p>\n\n\n\n It also applies to navigation and layout. If a button says \u201cClick here\u201d with no context, or the menu suddenly changes from one page to the next, the experience becomes harder to learn and trust. Users should be able to move through a website knowing what to expect. That is especially important on pages like checkouts, booking journeys, or contact forms, where confusion can quickly lead to abandonment.<\/p>\n\n\n\n Robust<\/strong> means the website should be built in a way that different browsers, devices, and assistive technologies can understand properly.<\/p>\n\n\n\n For example, if a heading is styled to look big and bold but is not actually marked up as a heading in the code, a screen reader user may miss the page structure completely. Or if a button is built badly behind the scenes, assistive technology may not announce it as a button at all. This matters because accessibility is not only about what looks right on screen. The code underneath needs to make sense too, so the site works reliably with the tools people depend on.<\/p>\n\n\n\n That is why WCAG is about much more than a few obvious fixes. It is not just asking whether a website looks modern or passes a quick test. It is asking a bigger question: can people perceive the content, operate the interface, understand what is happening, and rely on the website to work with the tools they use?<\/p>\n\n\n\n Once you understand that, WCAG starts to feel much less like a technical acronym and much more like a practical framework for building websites that work better for real people.<\/p>\n\n\n\n For public sector organisations, web accessibility is not just best practice. There is a clear legal expectation to make websites and mobile apps accessible and to be open about where any barriers still exist.<\/p>\n\n\n\n In practice, that means public sector bodies are expected to:<\/p>\n\n\n\n The accessibility statement is a big part of this. It is not meant to be a vague policy page or a box-ticking exercise. It should explain how accessible the website currently is, where users may run into difficulty, what is being done about those issues, and who to contact if they need support or want to report a problem.<\/p>\n\n\n\n That matters because public sector websites often provide essential information and services. If someone cannot complete a form, access a document, understand a process, or find the information they need, the impact can be much bigger than a bit of inconvenience. In some cases, it can stop people from accessing support, exercising their rights, or using a service independently.<\/p>\n\n\n\n It is also worth saying that publishing a statement does not replace the need to fix problems. The expectation is not just to acknowledge accessibility barriers, but to identify them, prioritise them, and improve the service over time. In other words, the statement should reflect real accessibility work, not stand in for it.<\/p>\n\n\n\n Once you look at what the public sector is expected to do, the bigger point becomes clearer: accessibility is being treated as part of delivering a usable digital service, not an optional extra. And that is exactly why private sector organisations should be paying attention too.<\/p>\n\n\n\n It would be easy to read all of this and think web accessibility is mainly a public sector issue. It is not.<\/p>\n\n\n\n If you run a private sector business in the UK, accessibility is not something you can afford to ignore. The Equality Act 2010<\/a> means service providers have a legal duty to make reasonable adjustments for disabled people. So if your website makes it harder for someone to buy from you, enquire, book, or access important information, that is a serious issue.<\/p>\n\n\n\n For some businesses, there is another layer to think about too. If you sell certain products or services into the EU, the European Accessibility Act<\/a> may also be relevant. That is especially worth being aware of for larger organisations, as the exemption for service providers is aimed at microenterprises with fewer than 10 employees and annual turnover below \u20ac2 million.<\/p>\n\n\n\n Even putting the legal side to one side for a moment, the business case is pretty clear. Your website is often the first impression people get of your business. If the text is hard to read, the buttons are awkward to use, the forms are confusing, or key journeys break when someone uses a keyboard or screen reader, that affects more than a small group of people. It affects trust. It affects conversions. And it affects how many people can actually use your website properly.<\/p>\n\n\n\n That is why accessibility is not just about compliance. It is about reach, usability, and making sure more people can engage with your business online.<\/p>\n\n\n\n And this is usually where a few common assumptions start to creep in. Things like \u201cwe use a modern theme, so we\u2019re probably fine\u201d or \u201cwe added a plugin, so accessibility is covered\u201d. Unfortunately, it is rarely that simple.<\/p>\n\n\n\n This is usually where things start to go wrong.<\/p>\n\n\n\n Not because most businesses do not care. Usually, it is because they assume they are probably fine. They use a modern theme. They have added a plugin. They have run one automated check. Nothing looks obviously broken. So accessibility gets pushed down the list.<\/p>\n\n\n\n The problem is, those assumptions do not hold up particularly well.<\/p>\n\n\n\n One of the biggest is the plugin assumption.<\/strong> You have probably seen these before. They are often the little floating widgets sat in the corner of a website with an accessibility icon, or a toolbar that lets users change things like text size, contrast, spacing, or reading mode. On the surface, they can look reassuring. The trouble is, they do not fix the underlying website.<\/p>\n\n\n\n If a form field is missing a proper label, a button is coded badly, the keyboard journey is broken, or the page structure does not make sense to a screen reader, an overlay is not going to solve that. In some cases, it can actually make things worse. These tools can interfere with the assistive technology people are already using, which can make websites even harder to navigate. That is a big reason why they are viewed so poorly by many disabled users and accessibility practitioners. In WebAIM\u2019s survey of accessibility practitioners<\/a>, only 2.4%<\/strong> of respondents with disabilities rated overlays as very effective<\/strong>, while 72%<\/strong> rated them as not at all<\/strong> or not very effective<\/strong>.<\/p>\n\n\n\n Another weak assumption is that most websites are accessible by now.<\/strong> They are not. The latest WebAIM Million report<\/a> found that 95.9%<\/strong> of the top one million home pages had detectable WCAG failures. So if your website has never been properly reviewed, it is far safer to assume there are issues than to assume everything is in good shape.<\/p>\n\n\n\n And the issues being picked up are not obscure edge cases either. The same report found that 83.9%<\/strong> of home pages had low contrast text, 53.1%<\/strong> had missing alt text on images, and 51%<\/strong> had missing form labels. These are basic things. Yet they are still everywhere.<\/p>\n\n\n\n Then there is the automated testing assumption.<\/strong> Automated tools absolutely have their place. They are useful. They are fast. They can help catch some issues early. But they do not give you the full picture. The DWP Accessibility Manual<\/a> says a GDS audit found that, out of 142 known accessibility issues, the best automated tools only found around 30 to 40%<\/strong>. That is a big gap.<\/p>\n\n\n\n That matters because some of the most important accessibility issues need human judgement. An automated tool cannot fully tell you whether alt text is actually helpful, whether link text makes sense out of context, whether a keyboard journey feels logical, or whether a booking form becomes frustrating halfway through. A website can pass an automated scan and still be difficult to use in real life.<\/p>\n\n\n\n And finally, there is the audience assumption.<\/strong> Some businesses still think accessibility is only a priority if they know they have disabled customers. That does not really stack up. Around one in four people in the UK have a disability<\/a>. On top of that, the Click-Away Pound survey<\/a> found UK businesses were losing \u00a317.1 billion<\/strong> a year because disabled customers were leaving inaccessible websites. So this is not a niche issue. It affects a huge number of people, and it carries real commercial weight too.<\/p>\n\n\n\n That is why accessibility is not something you can measure by whether a site looks modern, has a floating widget, or passes one scan. Those things might make a website look covered. They do not tell you whether it actually works for people.<\/p>\n\n\n\n So a much better question is this: how do you get a clearer picture of what is really going on?<\/p>\n\n\n\n The best place to start is with an automated accessibility scan.<\/p>\n\n\n\n A good scan can quickly highlight obvious issues on the page, such as low contrast text, missing alt text, empty links, missing form labels, and other common accessibility problems. It is one of the quickest ways to get an initial picture of where barriers may exist and whether your site needs closer attention.<\/p>\n\n\n\n That is exactly why we built our automated accessibility checker<\/a>. It gives you a quick way to review a page, spot common issues, and get a clearer sense of how accessible your site is at a glance. It is built on the WAVE API, helping surface the kinds of issues that are often missed when a site is only reviewed visually.<\/p>\n\n\n\n For some websites, that first scan alone will already flag enough to show that improvements are needed. But if you want a deeper view of usability, accessibility, SEO, and performance together, our website scorecard<\/a> takes things further.<\/p>\n\n\n\n The important thing is not to rely on guesswork. Start with a scan, see what it reveals, and build from there.<\/p>\n\n\n\n So, where should you actually start?<\/p>\n\n\n\nSo, What\u2019s the UK Standard for Website Accessibility?<\/h2>\n\n\n\n
\n\t
What WCAG 2.2 AA Actually Means in Practice<\/h2>\n\n\n\n
What the Public Sector Is Expected to Do<\/h2>\n\n\n\n
\n\t
What This Means for Private Sector Organisations<\/h2>\n\n\n\n
Common Assumptions That Catch Businesses Out<\/h2>\n\n\n\n
How to Get a Clear Picture of Your Site<\/h2>\n\n\n\n
A Simple Plan You Can Act On<\/h2>\n\n\n\n