Skip to main content :::
:::

What Is WCAG? A Practical Guide to Web Accessibility Guidelines

WCAG is the most widely used international guidance for evaluating web accessibility. Learn what WCAG A, AA, and AAA mean, how WCAG 2.1 and 2.2 differ, and how teams can check common issues across product, design, QA, and engineering workflows.


Key Takeaways

  • WCAG stands for Web Content Accessibility Guidelines.
  • It is not a single tool or an automated scan report. It is a set of international guidelines for making web content easier to perceive, operate, understand, and use with assistive technologies.
  • Most product teams start with WCAG 2.1 or 2.2 Level AA as a practical accessibility target.

A plain-language way to understand WCAG

If you are working on web accessibility, think of WCAG as a shared language. It helps product, design, engineering, QA, and site owners decide whether a website can actually be used by people in different situations.

WCAG is not only an engineering checklist. It affects button design, error messages, form labels, content structure, keyboard interaction, and whether users can complete tasks without unnecessary barriers.

What does WCAG mean?

WCAG is developed by the W3C Web Accessibility Initiative. It organizes requirements for web content, interactive components, forms, images, video, keyboard operation, and assistive technology support into testable success criteria.

In practice, WCAG is used as the foundation for web accessibility testing, accessibility audits, procurement requirements, and internal product quality standards.

Who needs to understand WCAG?

Product managers need WCAG because accessibility issues can become abandoned flows, support costs, and acceptance risks. Designers need WCAG because contrast, focus states, touch targets, error messages, and information hierarchy affect accessibility before code is written.

Frontend engineers and QA teams need WCAG because many issues appear in component states, keyboard behavior, ARIA, form validation, dynamic content, and real browser flows. Site owners need the basics so they can interpret audits, claims, and remediation work.

The four WCAG principles: POUR

WCAG groups its requirements under four principles: Perceivable, Operable, Understandable, and Robust, often shortened to POUR.

Perceivable means information should not rely on a single sense. Operable means users should be able to interact without a mouse. Understandable means labels, instructions, errors, and flows should be clear. Robust means content should work reliably with browsers and assistive technologies.

WCAG is not only an engineering issue

Some WCAG issues can be fixed in code, such as missing form labels, incorrect ARIA, focus order problems, or keyboard traps. Many others come from content and design: vague link text, unclear errors, weak alt text, or color being the only cue.

A mature accessibility workflow connects design review, content review, frontend implementation, automated checks, manual review, and QA acceptance instead of treating accessibility as a last-minute cleanup task.

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

WCAG success criteria are grouped into three conformance levels: A, AA, and AAA. Level A is the baseline. Level AA is the practical target most organizations use. Level AAA is stricter and is not always realistic for every type of content.

For most product teams, WCAG 2.1 AA or WCAG 2.2 AA is the right starting point because it covers common issues such as keyboard access, color contrast, form errors, headings, alt text, and focus visibility.

A practical WCAG checklist

You do not need to start by reading the full specification. Use these questions to find common risks, then turn the findings into issues that can be fixed and retested.

  • Do images have useful alt text?
  • Can every interactive control be used with a keyboard?
  • Is keyboard focus clearly visible?
  • Do form fields have labels, instructions, and error messages?
  • Does text have enough contrast against its background?
  • Do headings communicate the content structure?
  • Does link text explain its purpose?
  • Can dynamic content be understood by screen readers?

How are WCAG 2.1 and WCAG 2.2 different?

WCAG 2.2 extends WCAG 2.1 with additional success criteria around focus appearance, dragging movements, target size, and accessible authentication. In short, it reflects more of the interaction problems found in modern web interfaces.

If your team is starting a new accessibility process, use WCAG 2.2 as the reference. If your current process is based on WCAG 2.1 AA, you can progressively add the newer WCAG 2.2 checks.

How do you check whether a website meets WCAG?

WCAG cannot be fully checked with automation alone. Automated scans are useful for issues such as missing alt text, form labels, ARIA errors, and detectable contrast failures. Human review is still needed for keyboard flow, meaningful error messages, reading order, and task completion.

A reliable workflow starts with browser-based scanning, then adds keyboard testing, screen reader checks, zoom review, color simulation, and task-based QA. The final step is turning findings into issues developers can fix and retest.

How WCAG relates to DevCheck

Accesserty DevCheck is not legal advice, and a scan is not a full compliance guarantee. Its role is to help PMs, design, QA, engineering, content, and operations roles find WCAG-related risks faster inside the browser, including local pages, staging sites, authenticated flows, interactive states, and PDF structure signals.

In practice, DevCheck can be the first layer of a WCAG improvement workflow: identify clear, reproducible, fixable issues, then combine that with manual testing for a more complete accessibility review.

Frequently Asked Questions

Is WCAG a law?

WCAG itself is a technical guideline from W3C, not a law by itself. However, many laws, procurement rules, and organizational policies reference WCAG, commonly targeting WCAG 2.1 AA or WCAG 2.2 AA.

Does passing an automated scan mean a site meets WCAG?

No. Automated tools only check part of WCAG. Keyboard operation, screen reader experience, form guidance, content context, and real task flows still require human review.

Should a website target WCAG 2.1 or WCAG 2.2?

New projects should generally reference WCAG 2.2. Existing programs based on WCAG 2.1 AA can keep that baseline and progressively add the new WCAG 2.2 success criteria.

Related Pages

References