What Is Web Accessibility? Why WCAG Standards Matter for Your Website

Web accessibility decides whether people with visual, hearing, motor or cognitive differences can actually use your website. In this guide I cover the WCAG 2.2 levels, what the European Accessibility Act means for companies selling into the EU, the testing tools I use and the mistakes I see most often. This is not legal advice. Instead, it is what I have learned as a designer and consultant since 2012.

What is web accessibility?

Web accessibility is the practice of designing and building websites so that everyone, including people with disabilities, can perceive, operate, understand and rely on them. A screen reader user, a keyboard-only user and a visitor with low vision should all be able to complete the same task with the same ease.

I suggest you read that definition broadly. Accessibility is not only about permanent disability. For example, someone reading a phone in bright sunlight cannot see low-contrast text. Likewise, a person with a broken arm has to browse one-handed. Also, an ageing customer base struggles with small text and tiny buttons. In short, accessible design also covers temporary and situational limits.

In my projects I treat it as a quality standard, not an add-on. An accessible page is usually a better coded, more clearly written and easier to use page. That is why the work pays off well beyond compliance.

What is WCAG and who publishes it?

WCAG stands for Web Content Accessibility Guidelines. It is the international standard published by the Web Accessibility Initiative (WAI) at the W3C. The current version is WCAG 2.2. It first became a W3C Recommendation in October 2023, and you can read the current text on the official W3C WCAG 2.2 page.

The standard rests on four principles, known by the acronym POUR:

• Perceivable: Information must reach every visitor. For instance, images need a text alternative.
• Operable: Every function must work with a keyboard. Visitors also need enough time.
• Understandable: Text and interface behaviour must be predictable. Error messages must say how to fix the problem.
• Robust: Code must work reliably with assistive technologies such as screen readers.

In practice, each principle holds guidelines, and each guideline holds testable success criteria. So WCAG is not a vague statement of intent. It is a list of items you can check one by one. As a result, it moves the "is this accessible?" debate onto measurable ground.

What is the difference between levels A, AA and AAA?

WCAG sorts its success criteria into three conformance levels. Level A covers the basics. If you miss these, some users cannot use the site at all. Next, level AA removes the most common barriers. Finally, level AAA is the highest level, and it is not achievable for every type of content.

In practice, the target is almost always AA. The European standard EN 301 549 also builds on WCAG AA criteria for web content. Therefore I tell clients this: do not chase AAA across the whole site. Meet AA fully and move towards AAA where it makes sense.

What changed in WCAG 2.2?

WCAG 2.2 added nine new success criteria on top of version 2.1. It also marked the old 4.1.1 Parsing criterion as obsolete and removed it. Specifically, most of the new criteria deal with mobile use, focus visibility and login flows.

• 2.4.11 Focus Not Obscured (AA): A focused element must not disappear completely behind a sticky header or cookie banner.
• 2.5.7 Dragging Movements (AA): Anything done by dragging needs a single-pointer alternative.
• 2.5.8 Target Size (AA): Click targets must be at least 24 by 24 CSS pixels or have enough spacing.
• 3.2.6 Consistent Help (A): Help links or contact details must stay in the same place across pages.
• 3.3.7 Redundant Entry (A): Do not ask users for the same information twice in one process.
• 3.3.8 Accessible Authentication (AA): Login must not depend on puzzles or memory. Allow password managers and pasting.

The remaining three (2.4.12, 2.4.13 and 3.3.9) sit at level AAA. I often see sites with cookie banners and sticky menus fail 2.4.11. So check focus states during design, not after launch.

Why does the European Accessibility Act matter outside the EU?

The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025. It sets accessibility requirements for products and services offered to consumers in the EU. For example, these include e-commerce, banking, electronic communications, e-books and passenger transport ticketing. You can read the full text on EUR-Lex.

It matters outside the EU because the deciding factor is where the consumer is, not where the company is based. For example, if you run an online shop that sells directly to customers in Germany, national law there (the BFSG) may apply to you. The directive exempts microenterprises that provide services. Specifically, that means fewer than 10 staff and an annual turnover or balance sheet total of no more than 2 million euros.

Whether you are in scope depends on your sector, sales model and target countries. For a firm answer, speak to a lawyer. My technical advice is simpler. If you sell into the EU, plan your site against WCAG 2.2 AA. If you run several languages, combine these checks with the structure I describe in my multilingual website SEO guide.

Why is web accessibility important for your business?

Web accessibility matters because visitors who cannot use your site cannot buy, fill in a form or contact you. People with disabilities, older users and people with temporary limits are not a small group. According to the World Health Organization, around 1.3 billion people, about one in six worldwide, experience significant disability.

The commercial picture is clear. A form field without a label is an empty box for a screen reader user. Likewise, a menu that will not open with a keyboard is a locked door. Consequently, every accessibility bug is a lost sale in disguise.

Moreover, accessibility fixes improve the experience for everyone. Better contrast, larger tap targets and clearer error messages help all visitors. If you fight a high bounce rate, you will notice that many checks in my guide on reducing bounce rate overlap with accessibility work.

What are the most common web accessibility errors?

The most common errors are surprisingly basic. The WebAIM Million report scans one million home pages every year. Above all, its 2026 edition found detectable WCAG failures on 95.9% of home pages, with an average of 56.1 errors per page.

1. Low contrast text: 83.9% of pages.
2. Missing alternative text for images: 53.1%.
3. Missing form input labels: 51%.
4. Empty links: 46.3%.
5. Empty buttons: 30.6%.
6. Missing document language: 13.5%.

The report notes that 96% of all detected errors fall into these six categories. In other words, you can improve your site noticeably without a large budget. However, keep one thing in mind. Automated scans catch only part of the problems.

How do you check colour contrast?

Colour contrast is the luminance ratio between text colour and background colour. WCAG AA requires at least 4.5:1 for normal text and 3:1 for large text. In addition, non-text elements such as icons, form borders and focus rings also need 3:1.

The problem I see most is light grey body text and white text on a brand colour. Orange, yellow and light green brand colours often fail 4.5:1 with white text. You do not have to change your brand colour. Instead, reserve a darker shade of it for text.

You can check contrast in a few ways. Chrome DevTools shows the ratio in the colour picker when you inspect text. When building a palette, pick shades with the HTML colour codes tool and then measure the ratio. Also, never rely on colour alone. When a field turns red on error, add an icon or text as well. If you are reworking your corporate palette, the cleanest place to solve this is inside a brand identity project.

Why is keyboard access so critical?

Keyboard access is critical because screen reader users, people with motor disabilities and many power users navigate without a mouse. Every link, button, menu and form field must be reachable with the Tab key. Also, each one must work with Enter or the space bar.

Here is a simple test. Put the mouse aside and try to send your contact form, starting from the home page. Look for answers to these questions:

• Can you always see which element has focus, or has CSS removed the focus ring?
• Does the focus order follow the visual order of the page?
• Do dropdowns and dialogs open with the keyboard and close with Esc?
• When a modal opens, does focus stay inside and return afterwards?
• Is there a "skip to content" link at the top?

Most clients who run this test find at least one trap within five minutes. Usually the cause is a clickable div or a focus outline removed for looks. Therefore using real button and link elements solves most issues from the start.

How should you write alt text for images?

Alt text is the text equivalent that an image offers to screen readers, and to browsers when the image fails to load. Good alt text states the purpose of the image in context. So it does not just describe pixels.

These are the rules I follow:

• For informative images, state the content, such as "diagram of the four steps in our quote process".
• For linked images, state the destination, such as "Home" or "Go to cart".
• For decorative images, leave the alt attribute empty (alt="") so screen readers skip them.
• Do not start with "image of" or "photo of". The screen reader already says that.
• Do not stuff keywords. Alt text is not an SEO box.

Charts and infographics need more than short alt text. In those cases, give a summary of the data as text or a table next to the image. If you have thousands of product images, start with a template. After that, fix your best sellers by hand first.

How do you design an accessible form?

An accessible form gives every field a visible label that is linked in code, reports errors clearly and works fully with a keyboard. WebAIM data shows unlabelled fields on half of all home pages. As a result, forms are likely where many conversions quietly leak away.

These are the fixes I make most often:

1. Do not use placeholder text as a label. It disappears as soon as someone types.
2. Link each label to its field with a matching for and id.
3. Show error messages as text next to the field and explain how to fix them.
4. Mark required fields in words, not only with an asterisk.
5. Use the autocomplete attribute for name, email and phone.
6. Do not ask for the same data again in a later step. WCAG 2.2 now treats this as its own criterion.

I cover the structure of lead forms in my guide on booking, quote and demo form design. Combine it with this list, and you will get more submissions with fewer errors.

Why do heading structure and semantic HTML matter?

Screen reader users rarely listen to a page from top to bottom. Instead, they jump between headings to find what they need. So your heading hierarchy works as a table of contents for them. H2 follows H1, and H3 sits under H2. Never pick a heading level for its font size.

The same logic applies to other semantic elements. Mark navigation with nav, main content with main and the footer with footer. Assistive technology then recognises the regions of the page. In addition, a lang attribute on the html element lets screen readers use the correct language and pronunciation. The WebAIM report found that this one line is missing on 13.5% of pages.

This structure also supports SEO. A clean heading hierarchy and meaningful HTML help search engines understand your content too. I collected the other technical basics in my technical SEO tips article.

When should you use ARIA attributes?

ARIA is a set of attributes that give assistive technology extra information where HTML alone falls short. For example, you can name an icon-only search button with aria-label="Search". Likewise, you can report whether a dropdown is open with aria-expanded.

However, the first rule in the W3C's own guidance is clear. If a native HTML element does the job, do not use ARIA. A real button element brings keyboard support, focus and role information for free. If you add role="button" to a div, you must script all of that yourself. Wrong ARIA can be worse than no ARIA, because it gives screen readers false information.

In short, treat ARIA as a last resort, not a patch kit. Solve the problem with semantic HTML first. Add ARIA only when needed, then listen to the result with a screen reader.

Do accessibility overlay widgets solve the problem?

The short answer is no. Overlays are tools you add with one line of code. They show an accessibility menu with buttons for larger text or higher contrast. Also, they are often sold with a "one-click compliance" promise.

The real problems, however, live in the code. A layer on top cannot reliably fix an unlabelled field, a menu that ignores the keyboard or a broken focus order. Many screen reader users have also tuned their own assistive technology already. An overlay can clash with those settings. The W3C WAI team also stresses that automated tools alone cannot determine conformance.

That is why I recommend spending the overlay budget on fixing real issues in the source code. If your site already has an overlay, test what sits underneath before you remove it. You will usually find errors the widget never touched.

How do you test web accessibility?

You test web accessibility on three layers: automated scans, manual checks and testing with real users. Automated tools are fast, but they cannot measure every WCAG criterion. For example, they can see that alt text exists, but not whether it is correct.

For a first look, the accessibility score in Lighthouse is a good start. I explain how to read it in my Lighthouse performance test guide. Still, a score of 100 does not mean the site is accessible. It only means it passed the checks a machine can run.

How does web accessibility affect SEO?

Google has not announced web accessibility as a direct ranking factor. Even so, the overlap with SEO is strong. Alt text gives context in image search. A clear heading structure helps search engines understand content. Likewise, descriptive link text tells both screen readers and crawlers what the target page is about.

Accessibility fixes also improve user behaviour. Readable text, clear buttons and simple forms help visitors stay and finish their task. On mobile, rules such as the 24 by 24 pixel target size tie in directly with the issues you find in a mobile-friendly test.

For this reason, I build accessibility into SEO projects as well. Heading hierarchy, alt text, link text and the language attribute are already on my technical audit list. The same fix then serves both search visibility and user experience. I discuss this balance further in my article on SEO and UX.

What should you watch for with video and audio?

Video and audio are out of reach for deaf visitors without captions or a transcript. WCAG asks for captions on prerecorded video at level A. At level AA it also asks for audio description of important visual information. Also, live video needs captions at level AA.

The problem I see most is auto-generated captions. That said, they are a useful start. Yet they often get brand names, technical terms and numbers wrong. So review captions before you publish. Also make sure the video makes sense without sound, since many people watch muted on mobile.

• Give autoplay video a pause button and start it muted.
• Add a transcript to podcasts and audio content.
• Test that player controls work with a keyboard.

I look at the conversion side in my article on how website video affects conversion rate. Accessible video carries those gains to a wider audience.

Why are motion, animation and time limits risky?

For some visitors, moving content is not just distracting but physically unpleasant. Large parallax or scroll effects can trigger dizziness in people with vestibular disorders. WCAG also limits content that flashes more than three times per second at level A because of seizure risk.

Auto-rotating sliders cause problems as well. WCAG requires a way to pause, stop or hide automatic motion that lasts more than five seconds. So if you use a slider, add a visible pause button. Supporting the prefers-reduced-motion media query in CSS takes only a few lines, and it respects the user's system setting.

Time limits fall into the same group. If a session is about to expire on a checkout or a long application form, warn the user and let them extend it. Otherwise a slow typist or an assistive technology user loses their data before finishing.

What is an accessibility statement, and do you need one?

An accessibility statement is a page that explains which standard your site follows, lists known gaps and gives visitors a way to report problems. For example, public sector sites in the EU must publish one. For in-scope private services, it is expected practice. The W3C WAI offers a free generator to help you write it.

I recommend including these points:

• The standard and level you target, for example WCAG 2.2 AA.
• The date and method of the last review.
• Known limitations and the planned fix date.
• An email address and phone number for visitors who hit a barrier.

An honest statement builds more trust than a claim of full compliance. Do not write it and forget it, though. Update the date and the list of gaps after every major release.

When should accessibility be planned?

The cheapest moment is the start of design. When the colour palette, type scale, component library and form templates are accessible, every later page inherits that base. Otherwise, fixing things after launch means repeating the same work page by page.

This is how I build accessibility into a project:

1. During discovery, I write the target level, usually WCAG 2.2 AA, into the proposal and contract.
2. In design, I define contrast, focus states and tap targets at component level.
3. Then, in development, I use semantic HTML and real button and link elements.
4. In testing, I run an automated scan, a keyboard test and at least one screen reader pass.
5. After launch, I leave the content team a short guide on alt text and headings.

The last step matters, because content added later often breaks accessibility more than design does. When you request a design quote, ask whether accessibility is included and at which level. It is worth adding that question to my UI/UX services checklist.

How long does it take to make an existing site accessible?

It depends on the size of the site, the theme and where the errors come from. If most errors come from a shared template, such as the menu, header, footer or form component, one fix improves hundreds of pages at once. If the errors sit in content, for example thousands of images without alt text, the work takes longer.

Here is a starting range from my field experience, not a guarantee. On a single-template corporate site with 20 to 30 pages, core AA fixes can usually be done within a few weeks. On a custom e-commerce site with many components, the same work can stretch over several months. And when an off-the-shelf theme has deep structural issues, rebuilding can make more sense than patching.

I always start by prioritising. First come the flows that earn money, such as checkout, contact and quote forms. Then come templates, and finally content. That way you see a measurable difference in the first weeks. On the e-commerce side we handle these flows together within e-commerce consulting.

Where should you start with web accessibility?

You do not need a big project to start today. This short sequence gives the highest impact for the least effort on most sites:

• Run Lighthouse on your home page, one product or service page and your contact page.
• Put the mouse aside and run a keyboard test on those three pages.
• Next, replace failing colours with darker shades.
• Fix labels and error messages in your forms.
• Add the correct lang value to the html element.
• Give your content team a written alt text rule.

In short, web accessibility is not a one-off project. It is part of maintaining your site. In my own web design projects, WCAG 2.2 AA is part of the plan from day one. If you would like to review your current site together, write to me via the contact page. We measure first, then prioritise.