What is WCAG 2.2? A Plain-English Guide for Business Owners

Last updated: July 2026 Reading time: approximately 8 minutes No technical background needed

If you've been told your website needs to meet "WCAG 2.2 AA" and you have no idea what that means, you're not alone. The name alone puts most people off. But the ideas behind it are actually simple - and understanding them will help you make sense of any accessibility audit you receive.

This guide explains WCAG 2.2 in plain English, with no assumptions about your technical knowledge. By the end, you'll understand what the standard requires, why it exists, and what it means for your website.

What is WCAG?

WCAG stands for Web Content Accessibility Guidelines. It is the international standard for making websites accessible to people with disabilities. It was created by the W3C - the organisation that sets standards for how the web works worldwide - and it is updated periodically as technology and user needs evolve.

Version 2.2, published in 2023, is the current version. It is the version referenced in the European Accessibility Act and therefore the version your Irish business needs to comply with.

Think of WCAG 2.2 as a checklist of requirements that, when met, means your website can be used by people with a wide range of disabilities - including people who are blind, have low vision, are deaf or hard of hearing, have motor impairments that prevent them using a mouse, or have cognitive conditions that affect how they process information.

Worth knowing: Around 1 in 4 people in Ireland has a disability that affects how they use the web. That is a significant portion of your potential customers - not a niche group.

Why does it matter for my business?

WCAG 2.2 AA is the technical standard at the heart of the European Accessibility Act (EAA), which became enforceable in Ireland on 28 June 2025. If your website does not meet WCAG 2.2 AA, it does not meet the EAA - and non-compliance is a criminal offence under Irish law, with fines of up to €60,000 and personal liability for directors.

But beyond the legal obligation, there are practical business reasons to care:

  • Accessible websites rank better in search engines - Google's crawlers benefit from the same clear structure that helps assistive technology users
  • They convert better on mobile, because the same improvements that help disabled users (larger tap targets, clear form labels, readable text) improve the experience for everyone
  • They reduce the risk of losing customers who hit barriers and simply leave

Accessibility is not just compliance. It is good web practice that happens to also be a legal requirement.

For more on the EAA and what it means for Irish businesses, see our full guide: The European Accessibility Act: A Complete Guide for Irish Businesses.

The four POUR principles

WCAG 2.2 is built around four core principles. Everything in the standard flows from these four ideas. The principles are remembered using the acronym POUR:

P - PerceivableCan everyone sense what's on the page?
O - OperableCan everyone use and navigate the site?
U - UnderstandableCan everyone make sense of it?
R - RobustDoes it work with assistive technology?

Let's look at each one in plain English.

Principle 1

Perceivable

Can everyone on your website actually see or hear the content, regardless of disability?

Real-world analogy Think of a printed menu versus a menu that's also read aloud. A person who is blind can't read the printed version - but if the same information is available as audio, they can access it. Perceivable means your website's information is available in a form every user can access.

Many websites present information in ways that only work if you can see them perfectly. A photo with no description is invisible to a screen reader. A graph where meaning is conveyed only by colour is useless to someone who is colour-blind. A video with no subtitles excludes deaf users.

What this means for your website:

  • Every image needs a text description (called "alt text") that explains what the image shows
  • Videos need subtitles or a transcript
  • Text must have enough contrast against its background to be readable - light grey text on a white background is a very common fail
  • Don't rely on colour alone to show something - for example, don't make required form fields red with no other indicator
  • Content must still make sense if a user turns off images or styles
Principle 2

Operable

Can everyone navigate and use your website, even without a mouse?

Real-world analogy A building with only stairs excludes wheelchair users. The same building with a ramp works for everyone - wheelchair users, people with prams, delivery drivers with trolleys. Operable means your website works for users who navigate differently, not just those with a standard mouse and keyboard.

Many people with disabilities don't use a mouse. Someone with a motor impairment may navigate entirely by keyboard. Someone with a visual impairment may use a screen reader that reads each element in sequence. A person with limited hand movement may use voice control or a single switch device.

If your website relies on hovering, clicking, or dragging - and only those things - it excludes a significant number of users.

What this means for your website:

  • Every button, link, and form field must be reachable and usable using only a keyboard (Tab, Enter, arrow keys)
  • There must be a visible indicator showing which element is currently focused as a user tabs through the page
  • Buttons and links must be large enough to tap accurately on a touchscreen - tiny icons or closely packed links are a common fail on mobile
  • If content moves, flashes, or auto-plays, users must be able to pause or stop it
  • Drop-down menus must work without a mouse
  • If something times out (like a shopping cart), users must be warned and given a way to extend the time
Principle 3

Understandable

Can everyone make sense of your content and know how to use your site?

Real-world analogy Imagine a contact form where every field is just labelled "Field 1", "Field 2", "Field 3". You'd have no idea what to type where. Understandable means your website communicates clearly - users always know what they're looking at, what they need to do, and what went wrong if something doesn't work.

This principle is about clarity - for everyone, but especially for people with cognitive disabilities, learning differences like dyslexia, or users who are not fluent in English.

What this means for your website:

  • Every form field must have a clear label - "Email address", not just a placeholder that disappears when you start typing
  • Error messages must explain specifically what went wrong and how to fix it - "Invalid input" is useless; "Please enter a valid email address, for example name@company.ie" is helpful
  • Navigation must be consistent across pages - the same menu in the same place every time
  • The language of the page must be set correctly in the code (so a screen reader reads it in the right accent)
  • Avoid jargon where plain language works - though this applies to the substance of what you write, not just accessibility
Principle 4

Robust

Does your website work properly with the assistive technology your users rely on?

Real-world analogy Think of a standard electrical socket versus a proprietary one that only works with one brand's plug. A robust socket works with any compatible device. Robust means your website is built in a standard way that any assistive technology - screen readers, voice control software, braille displays - can reliably read and interact with.

This principle is the most technical of the four, but the idea behind it is straightforward. Assistive technologies - the software and hardware that people with disabilities use to access the web - rely on your website being built according to recognised web standards. If your site is built in a non-standard way, these tools may misread it, skip content, or fail entirely.

You do not need to understand the technical details yourself. Your web developer does. What matters is that when you commission a website or make changes to an existing one, the people doing the work understand accessibility requirements - and that you verify compliance through an audit.

In practice, this means your site needs:

  • Correct use of headings so screen readers can navigate the page structure (a logical H1 → H2 → H3 hierarchy, not headings chosen for their visual size)
  • All interactive elements - buttons, links, form fields - properly labelled so screen readers can announce what they are
  • Correct page language set in the code
  • Status messages (like "Your form has been submitted") announced to screen readers, not just shown visually
  • No content that relies on JavaScript in a way that breaks when assistive technology is present

What does Level AA mean?

WCAG uses three levels of conformance: A, AA, and AAA. Think of them as bronze, silver, and gold.

Level What it means Required by EAA?
A The absolute minimum - removes the most severe barriers. A site that only meets Level A still has significant accessibility issues for many users. Not sufficient on its own
AA ✓ The mainstream standard. Covers a broad range of disabilities and use cases. This is what the European Accessibility Act requires. Yes - this is the legal requirement
AAA The highest level, covering more edge cases. Not always practical to achieve across an entire site, and not required by the EAA. No - this goes beyond legal requirements

When someone tells you your site needs to meet WCAG 2.2 AA, they mean: version 2.2 of the guidelines, at the Level AA standard. That is the legal requirement under the European Accessibility Act.

What does this look like in practice?

The gap between a site that passes WCAG 2.2 AA and one that doesn't is usually not dramatic to the eye. Most failures are invisible to someone browsing normally with a mouse - they only show up when a user relies on a screen reader, navigates by keyboard, or has difficulty perceiving low-contrast text.

Here are the most common failures we find on Irish SME websites, mapped to each POUR principle:

  • Perceivable: Images without alt text - a screen reader simply skips the image or reads the filename ("IMG_4523.jpg"). Low-contrast text - grey text on a white background that looks subtle but is unreadable for many users with low vision.
  • Operable: Navigation menus that only work with a mouse - hover-triggered dropdowns that collapse the moment you try to Tab into them. Contact and booking forms that can't be submitted by keyboard alone.
  • Understandable: Form fields with no visible label - just a grey placeholder text that disappears when you click the field. Error messages that say "Error" without explaining what the user needs to do.
  • Robust: Buttons built using a generic <div> tag rather than a proper <button> - they look like buttons but screen readers don't identify them as clickable. Missing heading structure - pages where all text looks visually organised but the underlying code has no headings at all.

None of these require a complete website redesign to fix. Most are specific, targeted changes that a web developer can implement from a clear brief - which is exactly what a good accessibility audit provides.

What should I do next?

Understanding WCAG 2.2 and the POUR principles is the first step. The next step is finding out whether your website actually meets the standard - and if not, what specifically needs to change.

The only reliable way to know is a proper accessibility audit. Free automated tools can spot some issues quickly, but they detect only around 30–40% of WCAG failures. The rest require manual testing by someone who understands how assistive technologies actually work in practice.

We offer a free homepage accessibility check delivered within one business day. It will tell you whether your site has obvious WCAG 2.2 AA failures, what they are, and how serious they are. No commitment, no credit card.