Website Accessibility: A Practical Guide to WCAG 2.2 and Barrier-Free Design

Introduction

Around one in four adults in the EU lives with some form of disability. For many of them, the question of whether they can use your website is not a minor inconvenience — it is the difference between completing a task independently or not at all.

Accessibility has also become a legal baseline. The European Accessibility Act (EAA) applies to a wide range of digital products and services from June 2025. But even for teams not yet subject to regulation, the practical case is hard to dispute: better structure, better SEO, broader reach, and fewer frustrated users.

This guide covers what website accessibility means in practice — five specific barriers your site may already have, how the WCAG 2.2 framework maps to real decisions, and a checklist you can use to prioritize the work.

Five barriers your website may already be creating

The majority of accessibility problems on the web fall into a short list of recurring patterns. These are the five barriers that exclude the largest number of users.

1. Text that is difficult or impossible to read

Low contrast, small font sizes, and overly complex language compound each other. A user with moderate visual impairment may be able to cope with one of these problems — rarely all three.

The practical baseline: body text should render at 15–16 px minimum, with a contrast ratio of at least 4.5:1 against its background (the WCAG AA threshold). For large text (18 px or bold 14 px and above), the threshold drops to 3:1. Tools like WebAIM’s contrast checker let you verify any colour pair in seconds.

Plain language is harder to test automatically, but it matters significantly for users with cognitive disabilities or lower literacy. Short sentences, active voice, and avoiding unexplained jargon all help.

2. Images with no text alternative

A user running a screen reader encounters an image and hears nothing — or worse, a raw file name like img_20240312_banner_v3.jpg read aloud verbatim.

The fix is alt text: a short, accurate description of what the image shows and, where relevant, what it communicates. Decorative images that add no meaning should carry an empty alt="" attribute so screen readers skip them entirely. Images of text are a particular problem — the text content should appear in the document itself rather than be embedded in a graphic.

This is one of the fastest fixes in accessibility and one of the most consistently overlooked. Every image on your site should either have descriptive alt text or be explicitly marked decorative.

3. Video and audio with no captions or transcripts

A user who is deaf or hard of hearing cannot access audio-only content. A user with cognitive or attention difficulties may process a written transcript far more effectively than audio narration. Captions — synchronised text that appears during video playback — address the first group. Full transcripts available separately address both.

For marketing content, product demos, and webinars, captions are now broadly expected. Automated captioning is available in most video hosting platforms and has improved substantially, but auto-generated captions for technical terms and product names still require review before publishing.

4. Keyboard traps and inaccessible navigation

Not all users interact with a website using a mouse. Users with motor impairments, screen reader users, and keyboard-preference users all navigate via Tab, Enter, and arrow keys. A site operable only with a pointer device excludes a significant portion of that group.

Keyboard accessibility has concrete requirements: every interactive element — links, buttons, form fields, dropdowns, dialogs — must be reachable via Tab; the current focus position must be visually indicated at all times; modals must not create traps; and the focus order must follow a logical sequence that matches the visual layout.

Testing this requires five minutes and no tools: put your mouse aside and navigate your site using only Tab, Shift+Tab, Enter, and arrow keys. If you get stuck, cannot see where you are, or cannot activate elements, you have keyboard accessibility issues.

5. Forms and CAPTCHAs that create insurmountable barriers

Forms are where the stakes of accessibility are highest. Contact pages, login flows, registration screens, and checkout pages are functional — a user who cannot complete a form cannot achieve the goal they came for.

Traditional image-based CAPTCHAs are among the most documented accessibility problems in web design. Identifying distorted letters or selecting images containing specific objects is explicitly problematic for users with visual impairments, users with cognitive disabilities, and screen reader users. Audio alternatives help — but they present their own difficulties for users with hearing impairments, and the audio versions of widely-used CAPTCHAs are frequently difficult even for users without impairments.

WCAG 2.2 addresses this directly. Success Criterion 3.3.8 (Accessible Authentication) explicitly requires that authentication processes do not rely solely on cognitive function tests — a category that includes puzzle-solving CAPTCHAs.

The practical solution is to move away from challenge-based CAPTCHAs entirely. TrustCaptcha runs bot detection invisibly in the background while a user fills in a form — no puzzle to solve, no image to interpret, nothing to click. Verification runs during normal interaction, so it does not interrupt the form flow for any user. This approach aligns with WCAG 2.2 SC 3.3.8 and removes one of the most common active barriers from the flows where users most need to succeed.

What WCAG 2.2 actually requires

The Web Content Accessibility Guidelines (WCAG) are the international standard for web content accessibility. Published by the W3C, they form the basis for most national and EU-level legal accessibility requirements. The current version is WCAG 2.2, published in October 2023.

WCAG is organized around four principles: content must be Perceivable, Operable, Understandable, and Robust — often written as POUR. Each principle breaks into guidelines, which break into testable success criteria.

The conformance levels determine what “compliant” means in practice:

• Level A — the minimum. Failing Level A criteria creates serious barriers for assistive technology users.
• Level AA — the legal target for most jurisdictions, including EU accessibility requirements. This is what “WCAG compliance” typically means.
• Level AAA — the highest level, not required by law and often impractical for entire sites, but achievable for specific high-priority components.

WCAG 2.2 added nine new success criteria compared to WCAG 2.1. The most significant additions cover focus appearance (making keyboard focus states more visible), accessible authentication (directly affecting how CAPTCHAs and login flows are designed), and drag-and-drop interaction alternatives. WCAG 2.2 is backwards compatible — meeting 2.2 AA automatically satisfies all 2.1 AA criteria, with one removed exception (4.1.1 Parsing, deprecated in 2.2).

For most business websites, achieving WCAG 2.2 Level AA is the appropriate and legally relevant goal.

An accessibility checklist you can use today

This is a practical starting point organized by area, not an exhaustive audit. Work through it from the top.

Text and visual presentation

• Body text renders at 15 px or larger
• Contrast ratio is at least 4.5:1 for body text, 3:1 for large text
• Text can be resized to 200% in the browser without loss of content or function
• No content is presented as text inside an image (except logos and decorative graphics)
• Language and reading level is appropriate for your target audience

Images and media

• Every meaningful image has accurate alt text
• Decorative images carry alt=""
• Videos have accurate, synchronized captions
• Audio-only content has a written transcript

Keyboard and navigation

• All interactive elements are reachable and operable via keyboard alone
• Focus indicator is clearly visible at all times
• No keyboard traps exist in modals, dialogs, or custom components
• A skip navigation link appears at the top of each page
• Tab order matches the visual reading sequence

Forms and authentication

• Form labels are programmatically associated with their inputs via for/id or aria-labelledby
• Error messages identify which field failed and explain how to correct it
• No enforced time limits on form completion unless adjustable
• No CAPTCHA that requires solving an image puzzle or an audio challenge
• Authentication flows do not require cognitive function tests (WCAG 2.2 SC 3.3.8)

Structure and semantics

• Headings follow a logical hierarchy without skipped levels
• Landmark regions are used (header, nav, main, footer)
• Each page has a descriptive and unique <title> element
• Links use descriptive anchor text, not “click here” or “read more”
• Tables define headers with <th> and appropriate scope attributes

How to prioritize if you are starting from zero

A full accessibility audit of a mature site can return hundreds of issues. The most effective approach when starting without prior accessibility work is to sequence the effort by impact and effort rather than trying to resolve everything at once.

First two weeks: Fix the highest-impact, lowest-effort items. This almost always means image alt text, contrast failures, and missing form label associations. Run your site through Lighthouse (built into Chrome DevTools) or the WAVE browser extension and resolve everything flagged as an error — not a warning, an error. These are automated catches that represent hard failures.

Next month: Address keyboard navigation and focus management. This requires manual testing and often involves working with a developer on interactive components — modals, dropdowns, custom form controls — that automated tools evaluate incompletely. Replace any puzzle-based CAPTCHA during this phase; it is a high-impact change with straightforward technical implementation.

Ongoing: Structural and content accessibility — heading hierarchy, reading level, captions on new video content — becomes part of your production process rather than a one-time remediation effort.

Getting to a WCAG 2.2 AA baseline for a typical business website takes two to four weeks of focused development work, more for sites with complex interactive components or large content archives.

Conclusion

Accessibility is not a one-time audit or a compliance checkbox. It is a continuous quality standard — and the bar set by WCAG 2.2 Level AA is both achievable and increasingly expected. The five barriers described here account for the vast majority of the problems that exclude users from functioning websites. Most of them are faster to fix than teams expect.

One of the fastest improvements you can make to form accessibility is replacing a puzzle-based CAPTCHA with a solution designed for invisible, barrier-free verification. 👉 Try TrustCaptcha free — WCAG 2.2 aligned, EU hosting included on every plan.