If you have ever opened the official WCAG documentation and closed the tab thirty seconds later, you are in good company. The guidelines are written by standards experts for standards experts, and they read like a legal contract. But the underlying ideas are simple, and most of the fixes a small business website needs take minutes rather than months.

This is web accessibility guidelines explained the way a site owner needs to hear it: what each conformance level really asks of you, which criteria matter most in practice, and how to check your own pages without hiring a consultant.

What WCAG actually is (and what it is not)

WCAG stands for Web Content Accessibility Guidelines. It is published by the W3C’s Web Accessibility Initiative (WAI) and it defines how to make web content usable by people with disabilities: blind and low-vision users, deaf and hard-of-hearing users, people with motor impairments, and people with cognitive or learning differences.

A few clarifications that save a lot of confusion:

• WCAG is a technical standard, not a law. Laws reference it. In the United States, the ADA and Section 508 point to WCAG. In Europe, the European Accessibility Act and EN 301 549 do the same. So while WCAG itself is voluntary, the obligation it creates through those laws usually is not.
• The current stable version is WCAG 2.2, which became a W3C Recommendation in October 2023 and remains the version regulators and auditors work with today. WCAG 3.0 is still a working draft and is not something you should be building to right now.
• WCAG 2.2 is backwards compatible. If you meet 2.2, you meet 2.1 and 2.0. Nothing was removed except one criterion (4.1.1 Parsing, now obsolete).
• An “accessibility widget” is not conformance. Overlay tools that add a floating accessibility icon do not fix the underlying HTML. Courts and advocacy groups have repeatedly said so.

The four principles: POUR

Every single WCAG criterion sits under one of four principles. If you remember nothing else from this article, remember these, because they let you reason about accessibility problems you have never seen before.

Principle	Plain English meaning	Typical failure
Perceivable	Users must be able to sense the content, through sight, sound or touch.	An image of your price list with no text alternative.
Operable	Users must be able to work the controls and navigate.	A dropdown menu that only opens on mouse hover.
Understandable	Content and interface behaviour must make sense.	A form that rejects your submission without saying why.
Robust	Content must work with assistive technology, now and later.	A custom checkbox built from a <div> that screen readers cannot identify.

Under those four principles sit 13 guidelines, and under those sit the success criteria: the testable statements that are actually graded. WCAG 2.2 has 87 of them, split across three conformance levels.

Levels A, AA and AAA: the honest comparison

The single most common misunderstanding: the levels are not “good, better, best” versions of the same requirements. They are three tiers of difficulty and impact. Level A criteria remove absolute barriers. Level AA removes significant barriers. Level AAA adds enhancements that are sometimes impossible for certain content types.

Level	Criteria count (2.2)	What it means in practice	Who targets it
A	32	The floor. Without these, some users simply cannot use the page at all.	Nobody should stop here, but it is the minimum defensible baseline.
AA	24 more (56 total)	The real-world target. Colour contrast, resizing, focus visibility, consistent navigation.	Almost every law and procurement contract references Level AA.
AAA	31 more (87 total)	Enhanced access: sign language for video, 7:1 contrast, reading-level limits.	Specialist sites. The W3C itself says AAA is not required for whole sites.

The practical takeaway: aim for WCAG 2.2 Level AA. That is the number your legal team, your enterprise clients and your public-sector tenders will ask for. Cherry-pick AAA items that are cheap for you (for example, 2.4.9 link purpose from link text alone is mostly a copywriting discipline).

One criterion, three levels: colour contrast

Contrast is the clearest illustration of how the levels stack, so it is worth walking through properly.

• Level A: no contrast requirement at all. Yes, really. Grey-on-grey text passes Level A.
• Level AA (1.4.3): body text needs a contrast ratio of at least 4.5:1 against its background. Large text (18pt / 24px, or 14pt / 18.66px bold) needs 3:1. Interface components and meaningful graphics need 3:1 under 1.4.11.
• Level AAA (1.4.6): body text jumps to 7:1, large text to 4.5:1.

Real numbers help. That popular light grey #999999 on white gives 2.85:1, which fails AA for body copy. Darken it to #767676 and you get 4.54:1, which passes. The visual change is subtle. The compliance change is total. The team at userway.org reached a similar conclusion.

How to check it yourself: open your page in Chrome or Edge, right-click a piece of text, choose Inspect, and click the small colour swatch next to the color property. The browser shows the contrast ratio and flags AA and AAA pass or fail directly.

The criteria that break most small business sites

After auditing a lot of SME websites, the same handful of failures come up again and again. Fix these and you will have resolved the majority of your real-world barriers.

1. Images without meaningful alt text (1.1.1, Level A)

The rule is not “every image needs alt text”. The rule is every image needs an appropriate text alternative, and sometimes the appropriate alternative is nothing.

• Informative image: describe the information. A photo of your storefront becomes alt="Itimap office entrance on Rue Neuve".
• Functional image (a linked logo or icon button): describe the destination or action, not the picture. A magnifying glass icon in a search button gets alt="Search", not alt="magnifying glass".
• Decorative image: use an empty alt, alt="". This tells the screen reader to skip it. Leaving the attribute off entirely makes some screen readers read out the file name, which is how users end up hearing “IMG underscore 4 4 8 2 final v 3 dot jpg”.
• Text inside an image: the alt must contain that same text. Better yet, stop putting text in images.

Quick test: turn off images in your browser, or use a browser extension that reveals alt text. Read the page. Does it still make sense?

2. Keyboard navigation traps and invisible focus (2.1.1, 2.1.2, 2.4.7)

Plenty of people never touch a mouse: screen reader users, people with tremors, people recovering from an injury. WCAG requires that everything you can do with a mouse can be done with a keyboard.

The three-minute audit that every site owner should run at least once:

1. Load your homepage and put your mouse away.
2. Press Tab repeatedly. Can you always see where you are? If the highlight ring disappears, someone has written outline: none in the CSS. That is a straight Level AA failure of 2.4.7 Focus Visible.
3. Does the focus order follow the visual reading order, or does it jump around unpredictably?
4. Open your navigation menu with Enter or Space. Hover-only dropdowns fail here.
5. Open a modal or cookie banner. Can you close it with Escape and Tab back out? If focus is stuck inside forever, that is a keyboard trap (2.1.2, Level A).
6. Fill in and submit your contact form using only the keyboard. Then do the same with your checkout if you have one.

WCAG 2.2 also added 2.4.11 Focus Not Obscured (Minimum, AA): when an element receives focus, it must not be completely hidden by a sticky header, chat bubble or cookie bar. Sticky headers are the usual culprit.

3. Form fields with no labels (1.3.1, 3.3.2)

Placeholder text is not a label. It vanishes the moment someone starts typing, it usually fails contrast, and many screen readers treat it inconsistently. Every input needs a real <label> with a for attribute matching the input’s id. If your design cannot accommodate a visible label, use aria-label, but a visible label is better for everyone, including users with memory or attention difficulties.

Related, and often overlooked: 3.3.1 Error Identification requires that errors are described in text. A red border alone fails, because a colourblind user or a screen reader user gets no information from it. A comparable breakdown sits on ada.gov.

4. Headings used for styling instead of structure (1.3.1, 2.4.6)

Screen reader users navigate by jumping between headings, the same way sighted users skim. If you picked <h4> because it looked the right size, you broke that navigation. One <h1> per page, then <h2> for main sections, <h3> for subsections, no skipped levels. Style with CSS, not by choosing a different tag. This one happens to help your SEO too.

5. Link text that says nothing (2.4.4, Level A)

“Click here”, “read more” and “learn more” repeated fifteen times give a screen reader user a link list that is completely useless. Write links that describe their destination: “read our 2026 pricing guide” rather than “read more”.

6. Video with no captions (1.2.2, Level A)

Prerecorded video with audio needs captions at Level A. Auto-generated captions on YouTube are a starting point, not a finish line: you need to edit them for names, jargon and punctuation. Level AA adds audio description for visual information that is not conveyed in the soundtrack.

7. Text that cannot be resized or reflowed (1.4.4, 1.4.10)

Users must be able to zoom text to 200% without losing content or function, and your page must reflow into a single column at the equivalent of 320 CSS pixels wide without a horizontal scrollbar. Test it: zoom your browser to 400% and see what breaks. Fixed pixel heights on containers are the usual reason things get clipped.

What WCAG 2.2 added, and why it matters to you

WCAG 2.2 introduced nine new success criteria. These are the ones that most often catch out otherwise-decent sites:

Criterion	Level	What it asks for
2.4.11 Focus Not Obscured (Minimum)	AA	Focused elements must not be entirely hidden by sticky UI.
2.5.7 Dragging Movements	AA	Anything that needs dragging (sliders, sortable lists) needs a single-pointer alternative such as buttons.
2.5.8 Target Size (Minimum)	AA	Clickable targets at least 24 by 24 CSS pixels, or adequately spaced. Tiny social icons often fail.
3.2.6 Consistent Help	A	If you offer contact or help links, keep them in the same relative place on every page.
3.3.7 Redundant Entry	A	Do not make users retype information they already gave you in the same process.
3.3.8 Accessible Authentication (Minimum)	AA	No cognitive test (puzzle CAPTCHA, remembering a password with no paste allowed) without an alternative.

That last one bites a lot of sites: blocking paste in password fields is now an accessibility failure, because it prevents password manager use.

A realistic self-audit checklist

You will not reach full conformance in an afternoon, but you can eliminate most user-facing barriers. Work through this in order.

1. Run an automated scan. Use the free axe DevTools extension, WAVE, or Lighthouse’s accessibility audit in Chrome. Be aware that automated tools reliably catch only around a third of issues.
2. Do the keyboard walkthrough described above on your five most important pages: home, main service or product page, contact, checkout or booking, and one blog post.
3. Check contrast on body text, buttons, link colours, placeholder text and any text sitting on top of an image.
4. Review your images. Every one in your CMS media library used on a page needs an intentional alt decision.
5. Inspect your heading outline. A browser extension like HeadingsMap shows it in seconds.
6. Test with a screen reader. VoiceOver is built into macOS and iOS, Narrator into Windows, and NVDA is free. Half an hour of fumbling teaches you more than any checklist.
7. Zoom to 400% and check nothing is clipped or overlapping.
8. Confirm your page language is declared: <html lang="en">. It is one attribute and it changes screen reader pronunciation entirely (3.1.1, Level A).
9. Write an accessibility statement describing your conformance target, known issues and a contact route for problems. In several jurisdictions this is mandatory, and everywhere it is good faith evidence.

Where the legal picture stands in 2026

Two developments make this less theoretical than it was a couple of years ago:

• The European Accessibility Act obligations became applicable in June 2025 for a wide range of consumer-facing digital products and services, including e-commerce, banking, transport ticketing and e-books. The technical benchmark used across the EU is EN 301 549, which incorporates WCAG Level AA.
• In the United States, the DOJ’s rule under ADA Title II set WCAG 2.1 Level AA for state and local government web content, with compliance deadlines arriving in 2026 and 2027 depending on population size. Private-sector ADA web litigation continues to run at thousands of filings a year, and WCAG AA remains the de facto standard courts reference.

None of that requires panic. It does mean that “we did not know” stopped being a usable answer some time ago.

Frequently asked questions

What are the four Web Content Accessibility Guidelines?

People usually mean the four principles: perceivable, operable, understandable and robust (POUR). Content must be sensed, controls must be usable, information and behaviour must make sense, and the code must work with assistive technologies. All 87 success criteria in WCAG 2.2 sit under one of these four. Related reading: Understanding WCAG 2.2.

Which WCAG level do I need for my website?

WCAG 2.2 Level AA. It is what accessibility legislation, public procurement and enterprise vendor reviews reference around the world. Level A alone leaves obvious barriers in place, and full Level AAA is not achievable for all content types.

Is WCAG legally required?

WCAG itself is a voluntary technical standard, but it is written into binding law in many places: Section 508 and ADA regulations in the US, EN 301 549 and the European Accessibility Act in the EU, AODA in Ontario, and equivalents elsewhere. If you sell to consumers or to the public sector, treat AA as required.

What contrast ratio do I need?

For Level AA: 4.5:1 for normal body text, 3:1 for large text (24px or 18.66px bold and above), and 3:1 for user interface components and meaningful graphics. Level AAA raises body text to 7:1. Pure decoration and disabled controls are exempt.

Do automated accessibility checkers make my site compliant?

No. Tools like axe, WAVE and Lighthouse are excellent at catching missing alt attributes, unlabelled inputs and contrast failures, but they cannot judge whether your alt text is meaningful, whether your focus order makes sense or whether a video’s captions are accurate. Plan on automated scanning plus manual keyboard and screen reader testing.

Should I use WCAG 2.2 or wait for WCAG 3.0?

Build to WCAG 2.2 now. WCAG 3.0 is still an early working draft with a different conformance model and no confirmed publication date, and it is expected to remain a draft for years. Work done for 2.2 Level AA will not be wasted.

How much does accessibility remediation cost?

It depends almost entirely on how your site was built. A small brochure site on a well-coded theme can often reach Level AA with a few days of focused work on contrast, labels, headings and focus styles. Custom applications with bespoke widgets, data tables and PDFs are a different project. Fixing accessibility during a redesign is dramatically cheaper than retrofitting later.

The short version

WCAG is not really about legal risk, though the legal risk is real. It is about the fact that roughly one in six people worldwide lives with a significant disability, and a site that locks them out is losing customers silently. Start with the keyboard test and the contrast check this week. Both are free, both take minutes, and between them they will surface more genuine barriers than any compliance badge ever will.

If you would like a hand mapping your site against WCAG 2.2 Level AA, or you want a prioritised remediation plan rather than a 200-page scan report, get in touch with our team.