WCAG 2.2 Success Criteria Explained: Developer Implementation Guide

Web Content Accessibility Guidelines (WCAG) 2.2 contains 87 success criteria organized under four principles. For developers implementing accessibility, understanding what each criterion requires—and how to achieve it in code—is essential. This guide provides developer-focused explanations with practical implementation techniques.

Understanding WCAG Structure

Principles (4)

1. Perceivable: Users must be able to perceive content
2. Operable: Users must be able to operate the interface
3. Understandable: Content must be understandable
4. Robust: Content must work with assistive technologies

Conformance Levels

Level A: Essential accessibility (30 criteria) Level AA: Standard compliance target (20 additional criteria) Level AAA: Enhanced accessibility (28 additional criteria)

Most legal requirements reference Level AA, requiring 50 success criteria.

New in WCAG 2.2

WCAG 2.2 added 9 new success criteria:

2.4.11 Focus Not Obscured (Minimum) — AA

Requirement: Focused elements are not entirely hidden by other content.

Implementation:

/* Account for sticky headers */
:focus {
  scroll-margin-top: 80px;
}

/* Ensure fixed elements don't cover focus */
.sticky-header {
  position: sticky;
  top: 0;
}

main:focus-within {
  scroll-padding-top: 100px;
}

2.4.12 Focus Not Obscured (Enhanced) — AAA

Requirement: No part of focused element is hidden.

More stringent than 2.4.11—entire element must be visible.

2.4.13 Focus Appearance — AAA

Requirement: Focus indicator has minimum size and contrast.

*:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

2.5.7 Dragging Movements — AA

Requirement: Drag operations have single-pointer alternatives.

Implementation:

<!-- Draggable list with button alternatives -->
<ul class="sortable">
  <li>
    Item 1
    <button aria-label="Move up">↑</button>
    <button aria-label="Move down">↓</button>
  </li>
</ul>

<!-- Slider with increment buttons -->
<input type="range" id="volume">
<button aria-label="Decrease">-</button>
<button aria-label="Increase">+</button>

2.5.8 Target Size (Minimum) — AA

Requirement: Targets at least 24×24 CSS pixels.

Implementation:

button, a, input[type="checkbox"], input[type="radio"] {
  min-width: 24px;
  min-height: 24px;
}

/* Spacing for adjacent small targets */
.icon-button {
  padding: 8px;
  margin: 4px;
}

3.2.6 Consistent Help — A

Requirement: Help mechanisms appear in consistent locations.

Implementation:

• Place help links in same position across pages
• Use consistent labeling
• Keep contact info in predictable location

3.3.7 Redundant Entry — A

Requirement: Previously entered info auto-populated.

Implementation:

<!-- Multi-step form remembers data -->
<input type="email" id="email" autocomplete="email">

<!-- Or provide selection from previous entries -->
<select id="shipping">
  <option value="new">Enter new address</option>
  <option value="saved1">123 Main St...</option>
</select>

3.3.8 Accessible Authentication (Minimum) — AA

Requirement: No cognitive tests required for authentication.

Implementation:

• Allow password managers (don't block paste)
• Provide copy/paste for verification codes
• Don't require CAPTCHA transcription
• Offer alternative authentication

<!-- Allow paste in password fields -->
<input type="password" id="password">
<!-- Don't add onpaste="return false" -->

3.3.9 Accessible Authentication (Enhanced) — AAA

More stringent—no object recognition or personal content recognition required.

Key Success Criteria Deep Dive

1.1.1 Non-text Content (A)

Developer implementation:

<!-- Informative images -->
<img src="chart.png" alt="Sales increased 25% from Q1 to Q4">

<!-- Decorative images -->
<img src="divider.png" alt="" role="presentation">

<!-- Functional images -->
<button>
  <img src="search.svg" alt="Search">
</button>

<!-- Complex images -->
<figure>
  <img src="diagram.png" alt="System architecture overview"
       aria-describedby="diagram-desc">
  <figcaption id="diagram-desc">
    Detailed description of the architecture...
  </figcaption>
</figure>

1.3.1 Info and Relationships (A)

Developer implementation:

<!-- Proper heading hierarchy -->
<h1>Page Title</h1>
  <h2>Section</h2>
    <h3>Subsection</h3>

<!-- Proper lists -->
<ul>
  <li>Item one</li>
  <li>Item two</li>
</ul>

<!-- Proper tables -->
<table>
  <caption>Quarterly Sales</caption>
  <thead>
    <tr>
      <th scope="col">Quarter</th>
      <th scope="col">Sales</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Q1</th>
      <td>$50,000</td>
    </tr>
  </tbody>
</table>

<!-- Proper form labels -->
<label for="email">Email</label>
<input type="email" id="email">

2.1.1 Keyboard (A)

Developer implementation:

// Custom interactive element
const customButton = document.querySelector('.custom-button');

customButton.setAttribute('tabindex', '0');
customButton.setAttribute('role', 'button');

customButton.addEventListener('keydown', (e) => {
  if (e.key === 'Enter' || e.key === ' ') {
    e.preventDefault();
    handleClick();
  }
});

2.4.7 Focus Visible (AA)

Developer implementation:

/* Never remove focus without replacement */
/* Bad: */
*:focus { outline: none; }

/* Good: */
*:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

/* Custom focus for specific elements */
.button:focus-visible {
  outline: none;
  box-shadow: 0 0 0 3px #fff, 0 0 0 5px #0066cc;
}

4.1.2 Name, Role, Value (A)

Developer implementation:

<!-- Custom checkbox -->
<div role="checkbox"
     tabindex="0"
     aria-checked="false"
     aria-labelledby="checkbox-label">
  <span id="checkbox-label">Accept terms</span>
</div>

<!-- Expandable section -->
<button aria-expanded="false" aria-controls="section1">
  Show details
</button>
<div id="section1" hidden>
  Details content...
</div>

<!-- Tab interface -->
<div role="tablist">
  <button role="tab" aria-selected="true" aria-controls="panel1">Tab 1</button>
  <button role="tab" aria-selected="false" aria-controls="panel2">Tab 2</button>
</div>
<div role="tabpanel" id="panel1">Content 1</div>
<div role="tabpanel" id="panel2" hidden>Content 2</div>

Testing Success Criteria

Automated Testing

Detects approximately 30-40% of issues:

• Missing alt attributes
• Color contrast
• Missing form labels
• Invalid ARIA

Manual Testing Required

• Content quality (alt text meaningfulness)
• Keyboard navigation logic
• Focus order appropriateness
• Screen reader experience

Taking Action

Understanding WCAG success criteria at the implementation level enables developers to build accessible products from the start. Use this guide as a reference when implementing features and reviewing code.

Schedule a TestParty demo and get a 14-day compliance implementation plan.

Related Resources

• WCAG 2.2 Level AA Checklist
• WCAG 2.2 vs 2.1 Comparison
• ARIA Labels Guide
• Keyboard Navigation Testing