DEV Community

IAAP Audit
IAAP Audit

Posted on • Originally published at iaapaudit.com

WCAG 2.2 Success Criteria for Developers

A developer-friendly guide to WCAG 2.2 success criteria, including POUR, A/AA/AAA levels, common failures, audit evidence, and retesting.

WCAG success criteria become much less abstract when you read them as user-facing requirements.

They describe what your interface needs to support so people can use it with different abilities, devices, browsers, and assistive technologies.

Think in POUR

WCAG groups requirements under four principles:

  • Perceivable: users can access the information.
  • Operable: users can use the controls.
  • Understandable: users can understand the content and errors.
  • Robust: the interface works with assistive technology.

Most accessibility bugs fall cleanly into one of these areas.

Common developer-facing failures

You will often see criteria fail through implementation details such as:

  • button behavior recreated with a div.
  • Missing form labels.
  • Error messages not connected to fields.
  • Low contrast text.
  • Focus hidden by sticky headers.
  • Modals that do not manage focus.
  • Custom widgets with wrong roles or states.
  • Status messages that screen readers never receive.

The fix is usually more practical than the criterion name suggests.

What WCAG 2.2 adds

WCAG 2.2 adds checks that matter in modern apps:

  • Focus Not Obscured.
  • Dragging Movements.
  • Target Size Minimum.
  • Consistent Help.
  • Redundant Entry.
  • Accessible Authentication.

If you own a design system, review these at the component level.

How to write audit issues well

A good WCAG issue should be reproducible.

Include:

  • URL or screen.
  • Component.
  • Steps to reproduce.
  • Expected behavior.
  • Actual behavior.
  • User impact.
  • Criterion and level.
  • Suggested fix.
  • Retest status.

This turns WCAG from a label into an engineering task.

Do not rely only on automation

Automated tools help, but they cannot fully test keyboard flow, screen reader meaning, focus order, authentication experience, or real task completion.

Use tools for coverage. Use manual testing for confidence.

Conclusion

WCAG 2.2 success criteria are not separate from product quality. They are product requirements for accessible interaction.

Learn the intent, map issues clearly, and retest the user journey after fixes.

Read the original guide on IAAP Audit: https://iaapaudit.com/blog/wcag-2-2-success-criteria-plain-english

Top comments (0)