Website Accessibility Questions Commonly Asked

When Tim Berners-Lee created the World Wide Web, universality was one of its founding ideas. As he put it, “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

That principle is still fundamental today. The web helps people find information, compare services, contact businesses, book appointments, make purchases and complete everyday tasks. So the question is simple: can people actually use your website? Can they read the content? Can they move around the page? Can they complete a form, find your contact details or understand what to do next?

For the majority of websites, there are still a lot of issues. The 2026 WebAIM Million report found that 95.9% of the top one million home pages had detectable accessibility failures.

For many business and website owners, this information may be new. For others, the thought of making a website accessible may have felt overwhelming, technical or simply not like a priority at the time.

That is why it helps to bring the conversation back to the basics. What was the web originally meant to achieve? What do people expect from a website today? What do UK web accessibility standards actually mean? And what should you be thinking about when planning or improving your own site?

This article answers some of the most common website accessibility questions, with a focus on what they mean for business and website owners.

What is website accessibility?

Website accessibility means designing and building a website so more people can use it, including disabled people. Some people cannot see the screen, or cannot see it clearly. Some cannot hear audio. Some cannot use a mouse and rely on a keyboard or voice instead. Some find long or unclear pages hard to follow.

Over 1 billion people worldwide are disabled, around 15% of the population.

It also covers everyday situations most of us hit at some point: a cracked screen, bright sunlight on a phone, a slow connection, or a noisy room with no headphones.

A good way to think about it is the question from earlier: can people read your content, move around the page, and finish what they came to do? If that is true for a wide range of people, your site is in good shape. If parts of it only work for someone using a mouse, with sharp eyesight, on a fast connection, your website probably isn’t accessible.

The reality is that most designers and developers do not consider any of this. That is why nearly 96% of website home pages fail basic accessibility checks, according to the 2026 WebAIM Million report.

Is website accessibility a legal requirement in the UK?

For public sector organisations, yes. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 require their websites and apps to meet WCAG 2.2 AA and to publish an accessibility statement.

For private businesses, web accessibility is covered by the Equality Act 2010, which requires service providers to make “reasonable adjustments” for disabled people, both online and offline. If your website is not accessible, you may not be meeting that duty.

Some UK businesses that sell services into the EU also have to meet the European Accessibility Act. Whether it applies depends on the business, and our guide to the EAA explains the different scenarios.

Across all of these, the benchmark is WCAG 2.2 AA. Our guide to UK accessibility standards explains what that means in practice.

What are website accessibility standards?

Website accessibility standards are the technical guidelines a website is measured against. They define what an accessible site needs to do, so accessibility can be tested rather than guessed at.

The main one is the Web Content Accessibility Guidelines (WCAG), used worldwide as the benchmark that audits and testing tools measure against.

Many laws point to WCAG as their technical benchmark too. In the UK that includes the public sector accessibility regulations, and around the world it underpins laws such as the Americans with Disabilities Act (ADA) and Section 508 in the US, and the European Accessibility Act across the EU.

Most websites should be working to WCAG 2.2 at Level AA.

What is WCAG?

WCAG stands for the Web Content Accessibility Guidelines. It is the international standard for web accessibility, published by the World Wide Web Consortium (W3C), the body that sets the technical standards for the web.

WCAG is built around four principles: content should be perceivable, operable, understandable, and robust, known together as POUR. Under those principles sit a set of testable success criteria, and each criterion is graded at one of three levels: A, AA, or AAA.

The versions

WCAG has been updated over the years as the web has changed:

• WCAG 1.0 (1999): the original guidelines, now outdated.
• WCAG 2.0 (2008): a full rewrite built to apply to any web technology, and still the foundation of everything since.
• WCAG 2.1 (2018): added criteria for mobile, touch, low vision, and some cognitive needs.
• WCAG 2.2 (2023): the current version, adding criteria such as larger touch targets, clearer focus indicators, and simpler authentication.
• WCAG 3.0: an early draft for the future. It uses a different structure and scoring system, but it is years from being finished and is not one to build to yet.

Each version builds on the last, so a site that meets WCAG 2.2 also meets 2.1 and 2.0.

The levels

The three conformance levels describe how far a site goes:

• A is the minimum. Without it, some people are blocked from the content altogether.
• AA is the level almost everyone should aim for. It covers the most common and significant issues, and it is the level named by most laws, including in the UK.
• AAA is the highest level. It is not expected across a whole site, and the W3C does not recommend it as a blanket target because not all content can meet it.

In practice, WCAG 2.2 at Level AA is the benchmark for most websites.

What are the most common accessibility issues on websites?

The same six issues have topped the WebAIM Million report for seven years running. Together they make up 96% of all the errors it detects.

• Low contrast text (83.9% of home pages): text too pale against its background, so people with low vision, colour blindness, or anyone in bright sunlight struggles to read it.
• Missing alt text (53.1%): images with no text description, so screen reader users miss whatever the image is showing.
• Missing form labels (51%): fields with no label attached to them, so it is unclear what goes where, especially for screen reader users.
• Empty links (46.3%): links with no readable text, so a screen reader announces a link but not where it leads.
• Empty buttons (30.6%): buttons with nothing a screen reader can read out, so their purpose is left to guesswork.
• Missing document language (13.5%): no language set in the code, so screen readers may pronounce the page wrongly.

While these are the most common, and in a lot of cases the most simple to fix on an individual basis, often when grouped on a larger site and built into a brand’s brand guidelines they can be incredibly difficult to fix retrospectively. There are also other common issues that automated tools tend to miss, like a site not working properly with a keyboard, which can fundamentally block access for someone, for example someone with limited dexterity in their hands, or a site not working with screen readers, the software that reads a page aloud for blind and partially sighted people.

How do I test my website for accessibility?

To get a complete picture of your website’s accessibility, you need a mix of automated and manual testing.

Start with an automated scan. A few options, depending on how much detail you want:

• Squee accessibility checker: a detailed automated scan, explained in plain, non-technical language.
• WAVE: a Chrome plugin that marks issues directly on the page, so you can see exactly where each problem is.
• axe DevTools: code-level testing, aimed at developers.
• Lighthouse: a simple top-level overview built into Chrome, though the least detailed of these.

An automated scan can only give you around 30 to 40% of the full picture, so never rely on one alone. For example, an automated scan cannot:

• check whether you can navigate the site with a keyboard
• confirm the site is coded correctly for someone using a screen reader
• check whether the page still works when zoomed in

For everything an automated scan misses, you need manual testing against WCAG 2.2 AA. That is what our accessibility audits cover, from a quick healthcheck, to an audit, to a full audit of the whole site.

Can automated accessibility tools find every issue?

No. Automated tools are useful for a first pass, but they only catch a fraction of what WCAG covers. A GDS audit reported in the DWP Accessibility Manual found that the best automated tools detected only 30 to 40% of 142 known accessibility issues.

Much of accessibility needs human judgement. A tool can tell you an image has no alt text, but not whether the alt text that is there actually describes the image. It cannot tell you whether link text makes sense out of context, whether the keyboard order follows the page in a logical way, or whether a form is usable from start to finish.

So an automated scan is a good starting point, not a verdict. To know a site really works, it has to be tested by a person using the same tools and techniques disabled people rely on.

How do I make website content more accessible?

Accessibility does not just fall on the developer or the technical team. Everyone involved with a website has a responsibility for it, and like SEO, it is an ongoing process rather than a one-off job. A site can be built to WCAG 2.2 AA and drift out of it within months if nobody thinks about the content being added.

If you are a content editor, writer, or anyone publishing to the site, this is what to check as you go:

• Write in plain language. Short sentences, clear words, and acronyms explained the first time. This helps people with cognitive or learning disabilities, people reading in a second language, and anyone in a hurry.
• Use headings in order. Structure the page with real headings (Heading 1, then 2, then 3) rather than just bold text. Screen reader users rely on headings to move around a page.
• Write meaningful link text. A link should make sense on its own, so “read our accessibility guide” rather than “click here”. Screen reader users often jump from link to link, out of the surrounding text.
• Add alt text to images. Describe what an image shows or does, so someone using a screen reader gets the same information. Images that are purely decorative do not need it.
• Do not rely on colour alone. If colour is the only thing signalling meaning, for example a red word to flag an error, that meaning is lost for anyone who cannot see or distinguish the colour. Add a label, icon, or text as well.
• Caption and transcribe. Add captions to video and transcripts to audio, so the content reaches people who are deaf or hard of hearing.
• Give each page a clear title. A descriptive page title is the first thing a screen reader announces, and it helps everyone know which page they are on.

The W3C’s tips on writing for web accessibility cover these in more depth.

Does website accessibility help SEO?

Yes. Accessibility is not a direct ranking factor, but accessible websites and websites that rank well share the same foundations, because a search engine reads a page in much the same way a screen reader does: through the code, not the visuals.

The overlap runs right through WCAG:

• Semantic, well-structured code tells software what each part of a page is: navigation, headings, main content, and buttons. Screen readers use that structure to move around the page, and search engines use it to crawl, index, and understand the site.
• Alt text describes an image for screen reader users. Google’s own image SEO documentation calls alt text the most important attribute for helping it understand what an image shows.
• Headings in the correct order let screen reader users move around a page, and show search engines how the content is organised.
• Descriptive link text tells someone where a link leads before they follow it. “Click here” gives a screen reader user and a search engine the same problem: no context.
• Captions and transcripts make video and audio available to people who are deaf or hard of hearing, and turn that content into text search engines can index.
• Page speed matters for people on older devices and slower connections, and is part of Google’s ranking systems through Core Web Vitals.

The same applies to AI search tools, which rely on the same structure and text to understand a page and decide what to cite.

Accessibility alone will not move a site to the top of the results. The point is the overlap: fixing accessibility issues often fixes SEO issues at the same time.

Can an accessible website still look creative?

Yes, and it should improve the user experience rather than stifle creativity.

Accessibility does shape some design decisions. Colour combinations need enough contrast to be readable. Links need a visual cue beyond colour alone, usually an underline. Text needs to remain readable when enlarged up to 200%, with no content overlapping, disappearing, or being cut off. Anything interactive needs a visible focus state, so someone moving through the page with a keyboard can see where they are.

Those constraints rule out design patterns that make websites harder to use, like pale grey text on a white background, links that only appear on hover, or buttons too small to tap.

Bold layouts, strong colour, illustration, animation, and distinctive typography are all possible, and can create fantastic-looking, easy-to-use, and accessible websites.

Our 10 key principles of accessible web design cover this in more detail.

Should accessibility be considered during a website redesign?

Yes. A redesign is the best time to address accessibility, because every decision is already open. The colour palette, typography, components, templates, and content are all being chosen anyway, so accessibility can be built into each of them from the start, usually at no extra cost.

Retrofitting is where the cost sits. Fixing accessibility on a live site means auditing what is there, redesigning signed-off components, and reworking code and content across the whole site. A contrast failure caught at the design stage is a five-minute palette adjustment. The same failure caught after launch has already spread to every page.

If you are commissioning a website redesign, three things to put in the brief:

• Name the standard. Make WCAG 2.2 AA a requirement in the contract, not a nice-to-have.
• Ask how it will be tested. Automated scans cover less than half of WCAG, so ask what manual testing is included and when it happens.
• Agree who owns it after launch. Content added later can undo the work, so decide how new pages and posts will be checked.

What is the best first step to improve website accessibility?

Find out where your website stands. Run an automated check first: it takes a few minutes and flags the most common issues, like low contrast text, missing alt text, and missing form labels. Our free accessibility checker does this and explains the results in plain, non-technical language.

Off the back of the scan, you will have a better idea of the level of accessibility issues on your site. The next step is determining whether the site’s structure is good enough to fix the outstanding issues, or whether it would be more cost-effective, and ultimately a better experience, to start with a new build. That is judged case by case.

If you are not sure, and want to understand more about the accessibility of your site and your next options, get in touch with us at Squee. We are accessibility experts, with years of experience designing and developing simple and complex websites built with accessibility best practices and inclusive design principles.