Someone in a meeting says "we need to be WCAG compliant," and everyone nods along without quite knowing what that means. If that sounds familiar, you're not alone. WCAG comes up constantly in digital product conversations, yet it's rarely explained in plain terms.
This guide walks through what WCAG 2.2 actually is, assuming no prior knowledge. Whether you're a designer, developer, product manager, or business owner hearing this term for the first time, this is a good place to start.
What is WCAG, exactly?
WCAG stands for Web Content Accessibility Guidelines. It's a set of standards published by the W3C (World Wide Web Consortium), the same organization behind technical web standards like HTML and CSS.
The core idea is straightforward: WCAG exists to make websites and apps usable by everyone, including people with visual, auditory, motor, or cognitive disabilities. Without this kind of guidance, design and engineering decisions that seem minor can completely block some users from doing simple things on your site, like filling out a form, reading important information, or completing a transaction.
WCAG has gone through several versions since it first launched in 2008: WCAG 2.0, then WCAG 2.1 in 2018, and the current version, WCAG 2.2, which became an official W3C Recommendation in October 2023. Each new version adds requirements on top of the previous one without removing or changing what came before, so if your site already meets WCAG 2.1, you're already most of the way to WCAG 2.2.
Why WCAG 2.2 matters right now
There are two practical reasons to pay attention to WCAG 2.2 now rather than later.
First, it's the current international benchmark. Accessibility regulations in multiple countries reference WCAG directly as the technical standard, including the European Accessibility Act in the EU. If your organization serves international markets, or plans to, understanding WCAG 2.2 isn't optional anymore.
Second, if you're based in Indonesia, there's a local angle worth knowing too. Law No. 8 of 2016 on Persons with Disabilities, which ratified the Convention on the Rights of Persons with Disabilities (CRPD), mandates accessibility across all areas of life, including access to information. On the technical side, Indonesia's Ministry of Communication and Digital Affairs has also been developing digital accessibility guidance that references ISO 40500, which is essentially WCAG published as an international ISO standard. There's no regulation yet that explicitly mandates WCAG 2.2 in Indonesia specifically, but the policy direction is clearly heading that way.
The four core principles (POUR)
Part of what makes WCAG feel overwhelming is the sheer number of individual success criteria. But all of them trace back to four core principles, often remembered by the acronym POUR:
Perceivable — information needs to be presented in ways that reach different senses. The most common example: images need alt text so screen reader users still know what they depict, and videos need captions for people who can't hear the audio.
Operable — every function on a site needs to work without relying solely on a mouse or touchscreen; keyboard-only navigation has to work too. This matters for people with motor disabilities who can't use a mouse with precision, and for anyone relying on assistive technology in general.
Understandable — language and behavior on a site need to be clear and consistent. A form error message, for example, should explain exactly what went wrong and how to fix it, not just flash a red box with no explanation.
Robust — content needs to work correctly with a wide range of technologies, including assistive technology like screen readers, both today and as those technologies evolve. This usually comes down to writing code that follows HTML standards properly.
Every individual success criterion in WCAG, from the simplest to the most technical, ultimately falls under one of these four principles.
Conformance levels: A, AA, and AAA
WCAG also organizes its success criteria into three levels: A, AA, and AAA.
Level A covers the most basic requirements. If a site fails Level A, there's usually a fundamental barrier preventing some users from accessing the content at all.
Level AA is the most commonly targeted level, both by organizations and by regulations around the world. When someone says "we need to be WCAG compliant" without specifying a level, they almost always mean AA.
Level AAA is the strictest level, and it's generally not required across the board, since some of its criteria are difficult to apply to every type of content. The W3C itself describes AAA as something to aim for rather than a blanket requirement.
For most organizations, WCAG 2.2 Level AA is the realistic and most widely adopted target.
What's new in WCAG 2.2
WCAG 2.2 adds nine new success criteria on top of WCAG 2.1, and removes one older criterion that's now considered obsolete (it dealt with HTML parsing issues that modern browsers already handle reliably). Everything from 2.1 still applies in 2.2 — this is an addition, not a replacement.
A few of the new criteria worth knowing about:
- Minimum target size — clickable elements on touchscreens should meet a minimum size, so people with limited fine motor control don't accidentally tap the wrong, too-small, too-close-together element.
- Focus not obscured — when someone navigates with a keyboard, the currently focused element shouldn't be partially hidden behind something else, like a sticky header or a pop-up.
- Consistent help — if a page offers help, contact info, or live chat, its location should stay consistent across pages, so users don't have to hunt for it every time they navigate somewhere new.
- Accessible authentication — login flows shouldn't rely on a difficult cognitive task, like memorizing and retyping a visual CAPTCHA, as the only way to verify someone's identity. These additions specifically target gaps that WCAG 2.1 left unaddressed, particularly for users with cognitive disabilities, low vision, and motor impairments on touch devices.
How to start applying it
If this feels like a lot, that's normal. You don't need to master all 86 success criteria in WCAG 2.2 before taking your first step. A few practical things you can check right now:
Start with the basics: does every image on your site have meaningful alt text? Can your entire site be navigated using only a keyboard, with no mouse at all? Is there enough contrast between your text and its background to read comfortably?
It also helps to learn from resources built specifically for beginners. We maintain two free ones: Aksesibel.id, which covers the fundamentals of digital accessibility in Indonesian, and PanduanWCAG.com, which breaks down each WCAG criterion individually in plain Indonesian.
Automated testing tools like axe DevTools or Lighthouse are a reasonable starting point for catching obvious issues, but it's worth knowing their limits: automated tools can only detect a portion of WCAG's full set of criteria. The rest still requires manual testing, including hands-on testing with assistive technology like screen readers.
When it's time to bring in outside help
Plenty of organizations start with good intentions and then run out of time or resources to actually follow through. That's understandable — WCAG 2.2 covers a lot of ground.
If you want a clearer picture of where your organization currently stands before deciding on next steps, we offer a free Accessibility Maturity Assessment that takes about 10-15 minutes. It maps your organization's accessibility maturity across seven dimensions, based on an official W3C framework.
If you already know you need a deeper look at a specific product, our accessibility audit service can help identify concrete barriers in your website or app, along with recommendations your team can act on right away.
WCAG looks intimidating from the outside, but the goal behind it is simple: building digital products that work for more people. Just understanding the four core principles already puts you ahead of most people nodding along in that meeting.
