Practical accessibility auditing: tools & workflow

Web accessibility is no longer optional—it’s a legal requirement, a moral imperative, and a business opportunity. With the European Accessibility Act (EAA) now in full effect and similar legislation spreading globally, organizations must ensure their WordPress websites meet WCAG 2.2 standards. This comprehensive guide provides a practical, step-by-step workflow for auditing WordPress sites, combining automated testing tools with essential manual testing techniques.

---

Why Accessibility Auditing Matters in 2026

The digital landscape has fundamentally shifted. In 2026, accessibility compliance isn’t just about avoiding lawsuits—it’s about reaching the 1.3 billion people worldwide living with disabilities. For WordPress site owners, this represents both a challenge and an opportunity.

Legal Requirements and Deadlines

The European Accessibility Act (EAA), which came into force in June 2025, mandates that all public sector websites and mobile applications must meet WCAG 2.2 Level AA standards. Private sector companies providing essential services—banking, transportation, e-commerce, and telecommunications—face similar requirements. Non-compliance can result in fines up to €100,000 in some EU member states.

In the United States, the Department of Justice has strengthened ADA Title II and III enforcement, with web accessibility lawsuits reaching record numbers in 2025. The UK maintains its Public Sector Bodies Accessibility Regulations, while Canada enforces the Accessible Canada Act.

Business Benefits Beyond Compliance

Accessibility auditing delivers measurable business value:

• Expanded Market Reach: Accessible websites serve 15-20% more users, including aging populations and temporary disability scenarios
• Improved SEO: Many accessibility practices directly enhance search engine optimization, from semantic HTML to alt text optimization
• Reduced Maintenance Costs: Accessible code is typically cleaner, better structured, and easier to maintain
• Enhanced Brand Reputation: Demonstrating accessibility commitment builds trust with customers and stakeholders

The WordPress Context

WordPress powers over 43% of the web, making it a critical platform for accessibility. While the WordPress core has made significant accessibility improvements, themes and plugins often introduce barriers. A systematic auditing workflow is essential for identifying and remediating these issues.

---

Understanding WCAG 2.2: The Foundation of Accessibility Auditing

Before diving into tools and workflows, auditors must understand the Web Content Accessibility Guidelines (WCAG) 2.2 framework. Released in October 2023, WCAG 2.2 builds upon previous versions with nine new success criteria focused on cognitive and motor accessibility.

The Four Principles of Accessibility

WCAG 2.2 organizes accessibility requirements around four foundational principles, commonly remembered by the acronym POUR:

1. Perceivable

Information and user interface components must be presentable to users in ways they can perceive. This principle covers:

• Text alternatives for non-text content (images, videos, audio)
• Captions and transcripts for multimedia
• Color contrast and text resizing capabilities
• Content that doesn’t rely solely on sensory characteristics

2. Operable

User interface components and navigation must be operable by all users. Key requirements include:

• Full keyboard accessibility
• Sufficient time limits with ability to extend
• Seizure and physical reaction prevention
• Clear navigation and wayfinding

3. Understandable

Information and the operation of user interface must be understandable:

• Readable and understandable text content
• Predictable functionality and navigation
• Input assistance and error prevention
• Consistent identification and labeling

4. Robust

Content must be robust enough to work with current and future assistive technologies:

• Valid, well-formed HTML
• Compatible with assistive technologies
• Progressive enhancement principles
• Standards-compliant markup

WCAG 2.2 Compliance Levels

WCAG 2.2 defines three levels of conformance, each building upon the previous:

Level	Description	Typical Use Case
A	Minimum accessibility requirements; addresses the most critical barriers	Basic compliance, rarely sufficient alone
AA	Industry standard; addresses major accessibility barriers	Required by most legislation (EAA, ADA, AODA)
AAA	Enhanced accessibility; the highest level of conformance	Specialized applications, aspirational target

Most legal requirements mandate WCAG 2.2 Level AA compliance. This article focuses on achieving and maintaining Level AA conformance.

New in WCAG 2.2

WCAG 2.2 introduces nine new success criteria that auditors must understand:

• 2.4.11 Focus Not Obscured (AA): Focus indicators must not be hidden by other content
• 2.4.12 Focus Not Obscured (Enhanced) (AAA): Stricter requirements for focus visibility
• 2.4.13 Focus Appearance (AAA): Specific requirements for focus indicator size and contrast
• 2.5.7 Dragging Movements (AA): Alternatives to dragging for pointer input
• 2.5.8 Target Size (Minimum) (AA): Minimum 24×24 CSS pixel target size
• 3.2.6 Consistent Help (A): Help mechanisms in consistent locations
• 3.3.7 Redundant Entry (A): Avoid requiring information already entered
• 3.3.8 Accessible Authentication (Minimum) (AA): Cognitive function tests not required for authentication
• 3.3.9 Accessible Authentication (Enhanced) (AAA): No cognitive function tests with alternatives

---

Automated Testing Tools: Your First Line of Defense

Automated accessibility testing tools provide rapid, scalable detection of common issues. While they catch only approximately 30% of accessibility barriers, they’re essential for establishing baseline compliance and catching regressions.

Browser Extensions for Immediate Feedback

axe DevTools

Developed by Deque Systems, axe DevTools is the industry standard for browser-based accessibility testing. The free browser extension provides:

• Zero False Positives: axe is designed to only report issues it can verify, minimizing noise
• WCAG 2.2 Coverage: Comprehensive support for all WCAG 2.2 success criteria
• Intelligent Testing: Distinguishes between “needs review” and definite violations
• Integration Ready: Results can be exported for documentation

Installation and Basic Usage:

1. Install the axe DevTools extension from the Chrome Web Store or Firefox Add-ons
2. Navigate to the page you want to test
3. Open browser DevTools (F12) and select the “axe DevTools” tab
4. Click “Scan all of my page” for a comprehensive analysis
5. Review results categorized by severity: Critical, Serious, Moderate, Minor

Interpreting axe Results:

Critical: Blocks assistive technology users completely
  Example: Missing form labels, empty buttons

Serious: Causes significant barriers for some users
  Example: Insufficient color contrast, missing alt text

Moderate: Causes frustration or slower task completion
  Example: Ambiguous link text, skipped heading levels

Minor: Minor inconvenience or best practice violation
  Example: Redundant alternative text, redundant links

WAVE (Web Accessibility Evaluation Tool)

WAVE, developed by WebAIM, offers a visual approach to accessibility testing:

• Visual Overlays: Issues are highlighted directly on the page
• Icons and Indicators: Color-coded icons show error types at a glance
• No Registration Required: Completely free, no account needed
• Side Panel Details: Detailed explanations alongside visual indicators

Using WAVE Effectively:

1. Install the WAVE browser extension or use the online version at wave.webaim.org
2. Click the WAVE icon to activate evaluation
3. Review the summary panel showing errors, alerts, features, structural elements, and ARIA
4. Click any icon on the page to see detailed information
5. Use the “Reference” tab to understand WCAG requirements

Accessibility Insights for Web

Microsoft’s Accessibility Insights provides two testing modes:

• FastPass: Quick automated checks (2 minutes)
• Assessment: Comprehensive manual testing guided workflow (30+ minutes)

The tool is particularly valuable for teams already using Microsoft development tools and integrates well with Azure DevOps.

WordPress-Specific Accessibility Plugins

WP Accessibility

WP Accessibility addresses common WordPress accessibility issues without requiring code changes:

Features:

• Removes target attributes from links (prevents unexpected new windows)
• Adds skip links for keyboard navigation
• Forces alt attributes on images (with fallback handling)
• Adds labels to standard WordPress forms
• Provides toolbar with font size and contrast controls

Configuration Best Practices:

// Recommended WP Accessibility settings for audit preparation
// Settings → WP Accessibility

// Enable: Add skip links to your theme
// Enable: Add landmark roles to HTML5 structural elements
// Enable: Force alt attributes on images
// Enable: Add post titles to "read more" links
// Disable: Remove title attributes (can conflict with some themes)

Accessibility Checker by Equalize Digital

This plugin provides real-time accessibility checking within the WordPress admin:

• Editor Integration: Scans content as you create it
• Frontend Scanning: Checks published pages from visitor perspective
• Detailed Reports: Shows exact code causing issues
• Bulk Scanning: Audit entire sites automatically

Pro Version Features:

• Full-site automated scanning
• PDF report generation
• Issue prioritization
• Remediation guidance

One Click Accessibility

A lightweight plugin for quick accessibility improvements:

• Skip to content link
• Outline focus for keyboard navigation
• Font resizing controls
• Grayscale mode for testing
• Light and high contrast modes

CI/CD Integration for Continuous Accessibility

Automated accessibility testing should be part of your continuous integration pipeline to prevent regressions.

axe-core with GitHub Actions

# .github/workflows/accessibility.yml
name: Accessibility Tests

on: [push, pull_request]

jobs:
  accessibility:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm install @axe-core/cli http-server

      - name: Build site
        run: npm run build

      - name: Start server
        run: npx http-server ./dist -p 8080 &

      - name: Run axe accessibility tests
        run: |
          npx axe http://localhost:8080 \
            --tags wcag2a,wcag2aa,wcag22aa \
            --exit

Pa11y for Automated Scanning

Pa11y is a command-line tool that can be integrated into any CI/CD pipeline:

# Install Pa11y
npm install -g pa11y

# Run accessibility test on a single page
pa11y https://example.com --standard WCAG2AA

# Run with actions (click elements, wait for content)
pally https://example.com --actions "click element #menu-toggle"

# Generate JSON report for CI integration
pa11y https://example.com --reporter json --standard WCAG2AA > accessibility-report.json

Lighthouse CI for Performance and Accessibility

Google’s Lighthouse CI can track accessibility scores over time:

// lighthouserc.json
{
  "ci": {
    "collect": {
      "url": [
        "http://localhost:8080/",
        "http://localhost:8080/about/",
        "http://localhost:8080/contact/"
      ],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:accessibility": ["error", {"minScore": 0.9}]
      }
    }
  }
}

Automated vs. Manual Testing Comparison

Aspect	Automated Testing	Manual Testing
Coverage	~30% of WCAG criteria	~100% with proper methodology
Speed	Minutes for entire site	Hours for comprehensive audit
Cost	Low (tools are often free)	Higher (requires expertise)
Consistency	Highly reproducible	Depends on tester skill
False Positives	Minimal with quality tools	None
False Negatives	Significant (misses ~70%)	Minimal with thorough testing
Best For	Baseline compliance, regression prevention	Comprehensive audits, legal compliance
Frequency	Every deployment	Quarterly or major releases

---

Manual Testing Workflow: The Critical 70%

Automated tools miss the majority of accessibility barriers. Manual testing with assistive technologies and structured methodologies is essential for true compliance.

Keyboard Navigation Testing

Keyboard accessibility is the foundation of web accessibility. If users can’t navigate and operate your site with only a keyboard, many assistive technologies won’t work.

The Keyboard Testing Protocol

Step 1: Basic Navigation

1. Disconnect your mouse or disable your trackpad
2. Press Tab to move through interactive elements (links, buttons, form fields)
3. Press Shift+Tab to move backward
4. Use Enter to activate links and buttons
5. Use Space to activate buttons and checkboxes
6. Use Arrow keys for radio buttons, selects, and custom widgets

Step 2: Focus Visibility Testing

Verify that focus indicators are clearly visible:

/* Ensure focus indicators are visible */
/* WCAG 2.2 requires focus indicators to be at least 2px thick */

/* Good: Clear focus indicator */
a:focus,
button:focus,
input:focus {
  outline: 3px solid #0056b3;
  outline-offset: 2px;
}

/* Bad: No focus indicator or insufficient contrast */
a:focus {
  outline: none; /* Removes focus indicator entirely */
}

Step 3: Logical Tab Order

Tab order should follow the visual reading order (typically left-to-right, top-to-bottom). Check for:

• Tab traps (can’t Tab away from an element)
• Skipped elements that should be focusable
• Illogical jumps in focus order
• Hidden elements receiving focus

Step 4: Interactive Element Testing

Test all interactive components:

Element	Keyboard Operation	Expected Behavior
Links	Tab, Enter	Navigate to target
Buttons	Tab, Enter, Space	Activate action
Checkboxes	Tab, Space	Toggle selection
Radio buttons	Tab, Arrow keys	Change selection within group
Select dropdowns	Tab, Arrow keys, Enter/Space	Open and select options
Modal dialogs	Tab (trapped), Escape	Focus trapped, close on Escape
Accordion	Tab, Enter/Space, Arrow keys	Expand/collapse panels
Tabs	Tab, Arrow keys, Enter	Switch between tab panels

Common Keyboard Issues in WordPress

Issue: Missing focus styles in themes

/* Fix: Add visible focus styles to your theme */
/* Add to style.css or customizer additional CSS */

*:focus {
  outline: 2px solid #007cba;
  outline-offset: 2px;
}

/* Enhanced focus for high contrast */
@media (prefers-contrast: high) {
  *:focus {
    outline: 3px solid currentColor;
    outline-offset: 3px;
  }
}

Issue: Custom dropdowns not keyboard accessible

<!-- Bad: Custom dropdown without keyboard support -->
<div class="dropdown">
  <span class="dropdown-trigger">Menu</span>
  <div class="dropdown-content">
    <a href="#">Item 1</a>
    <a href="#">Item 2</a>
  </div>
</div>

<!-- Good: Accessible dropdown with ARIA -->
<div class="dropdown">
  <button
    class="dropdown-trigger"
    aria-expanded="false"
    aria-haspopup="true"
    id="menu-button"
  >
    Menu
  </button>
  <div
    class="dropdown-content"
    role="menu"
    aria-labelledby="menu-button"
    hidden
  >
    <a href="#" role="menuitem">Item 1</a>
    <a href="#" role="menuitem">Item 2</a>
  </div>
</div>

Screen Reader Testing

Screen readers convert visual content to audio or braille. Testing with screen readers reveals issues automated tools cannot detect.

Screen Reader Options

Screen Reader	Platform	Cost	Best For
NVDA	Windows	Free	Primary Windows testing, most popular
JAWS	Windows	Paid ($95/year)	Enterprise compliance testing
VoiceOver	macOS/iOS	Built-in	Apple ecosystem testing
TalkBack	Android	Built-in	Mobile Android testing
Narrator	Windows	Built-in	Quick Windows testing

NVDA Testing Workflow

NVDA (NonVisual Desktop Access) is the most widely used screen reader and essential for Windows accessibility testing.

Installation:

1. Download from nvaccess.org
2. Run the installer (portable version available)
3. Launch with Ctrl+Alt+N

Essential NVDA Commands for Testing:

Basic Navigation:
- Tab: Move to next focusable element
- Shift+Tab: Move to previous focusable element
- H: Next heading
- 1-6: Next heading level 1-6
- L: Next list
- I: Next list item
- T: Next table
- F: Next form field
- G: Next graphic
- D: Next landmark

Reading Commands:
- Insert+Down Arrow: Start reading continuously
- Ctrl: Stop reading
- Insert+Up Arrow: Read current line
- Insert+Tab: Read current focus

Mode Switching:
- Insert+Space: Toggle between browse and focus modes

What to Listen For:

1. Meaningful announcements: Does the screen reader convey the purpose of each element?
2. Context: Are form fields properly labeled?
3. Structure: Are headings announced with their levels?
4. State changes: Are dynamic updates announced (live regions)?
5. Navigation: Can you navigate by headings, landmarks, and lists?

VoiceOver Testing on macOS

VoiceOver is built into macOS and essential for testing Apple devices.

Enabling VoiceOver:

• Press Cmd+F5 (or triple-click Touch ID on newer Macs)
• Or: System Settings → Accessibility → VoiceOver

Essential VoiceOver Commands:

Basic Navigation:
- Cmd+F5: Toggle VoiceOver
- Ctrl+Option+Right/Left Arrow: Navigate to next/previous item
- Ctrl+Option+Shift+Down Arrow: Enter/interact with element
- Ctrl+Option+Shift+Up Arrow: Exit element

Web Navigation:
- Ctrl+Option+Cmd+H: Next heading
- Ctrl+Option+Cmd+L: Next link
- Ctrl+Option+Cmd+J: Next form control
- Ctrl+Option+Cmd+T: Next table

Reading:
- Ctrl+Option+A: Start reading
- Ctrl: Stop reading

Mobile Screen Reader Testing

Mobile accessibility is critical as mobile traffic continues to grow.

iOS VoiceOver Testing:

1. Settings → Accessibility → VoiceOver → Toggle On
2. Use single finger swipe right to navigate
3. Double-tap to activate
4. Three-finger swipe to scroll

Android TalkBack Testing:

1. Settings → Accessibility → TalkBack → Toggle On
2. Use single finger swipe right to navigate
3. Double-tap to activate
4. Two-finger swipe to scroll

Color Contrast Verification

WCAG 2.2 requires specific contrast ratios for text and UI components.

Contrast Requirements

Content Type	Level A	Level AA	Level AAA
Normal text (<18pt or <14pt bold)	3:1	4.5:1	7:1
Large text (≥18pt or ≥14pt bold)	3:1	3:1	4.5:1
UI Components & Graphics	3:1	3:1	3:1
Focus indicators (WCAG 2.2)	3:1	3:1	4.5:1

Testing Tools

Browser DevTools:

Modern browsers include contrast checking in DevTools:

1. Right-click element → Inspect
2. In Styles panel, click color swatch
3. Check contrast ratio displayed
4. Look for green checkmark (passes) or warning icon (fails)

WebAIM Contrast Checker:

WebAIM’s online tool provides detailed analysis:

1. Visit webaim.org/resources/contrastchecker/
2. Enter foreground and background colors
3. Review pass/fail status for each level
4. Use the lightness slider to find passing alternatives

Sim Daltonism:

Test how your site appears to users with color vision deficiencies:

• macOS: Available on the App Store
• Windows: ColorVeil or similar tools
• Online: Colorblindly browser extension

Common Contrast Issues in WordPress

Issue: Light gray text on white backgrounds

/* Bad: Insufficient contrast */
.text-muted {
  color: #999999; /* 2.8:1 contrast - FAILS WCAG AA */
}

/* Good: Sufficient contrast */
.text-muted {
}

Issue: Placeholder text contrast

/* Bad: Default placeholder often fails */
::placeholder {
}

/* Good: Darker placeholder */
::placeholder {
}

Focus Management Testing

WCAG 2.2 places increased emphasis on focus visibility and management.

Focus Not Obscured (2.4.11)

When a UI component receives keyboard focus, the component must not be entirely hidden by author-created content.

Testing Procedure:

1. Navigate through the page using Tab
2. Verify focused elements are fully visible
3. Check for sticky headers/footers that might obscure focus
4. Test modals and overlays for focus trapping

Common Issue: Sticky Headers Hiding Focus

/* Problem: Sticky header covers focused elements */
.header-sticky {
  position: fixed;
  top: 0;
  height: 80px;
}

/* Solution: Scroll padding for fixed headers */
html {
  scroll-padding-top: 100px; /* Header height + buffer */
}

/* Or use :target offset for anchor links */
:target {
  scroll-margin-top: 100px;
}

Focus Appearance (2.4.13 - AAA)

While AAA level, understanding focus appearance helps create better experiences:

/* Enhanced focus indicator meeting AAA guidelines */
:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 2px;
  border-radius: 2px;
}

/* Minimum area: 48×48 CSS pixels */
.focus-enhanced:focus-visible {
  box-shadow: 0 0 0 2px white, 0 0 0 4px currentColor;
}

---

Common WordPress Accessibility Issues and Fixes

WordPress sites share common accessibility patterns. Understanding these accelerates auditing and remediation.

Issue 1: Missing or Inadequate Alternative Text

The Problem:

Images without alt text or with meaningless filenames as alt text.

Detection:

• Automated tools flag missing alt attributes
• Screen readers announce “image” or filename

The Fix:

<!-- Bad: Missing alt text -->
<img src="photo.jpg">

<!-- Bad: Meaningless alt text -->
<img src="photo.jpg" alt="photo">

<!-- Good: Descriptive alt text -->
<img src="wordpress-dashboard.jpg" alt="WordPress admin dashboard showing the block editor with a paragraph block selected">

<!-- Good: Decorative image with empty alt -->
<img src="decorative-border.png" alt="">

WordPress Implementation:

// Enforce alt text in WordPress media library
function enforce_alt_text($response, $attachment, $meta) {
  if (empty($response['alt'])) {
    $response['alt'] = ''; // Mark as decorative by default
  }
  return $response;
}
add_filter('wp_prepare_attachment_for_js', 'enforce_alt_text', 10, 3);

// Add alt text reminder in admin
function alt_text_admin_notice() {
  $screen = get_current_screen();
  if ($screen && $screen->id === 'attachment') {
    echo '<div class="notice notice-warning">
      <p><strong>Accessibility Reminder:</strong> Please add descriptive alt text or mark as decorative.</p>
    </div>';
  }
}
add_action('admin_notices', 'alt_text_admin_notice');

Issue 2: Improper Heading Structure

The Problem:

Skipped heading levels, using headings for styling, or missing H1.

Detection:

• axe flags skipped heading levels
• WAVE shows heading outline
• Screen reader users navigate by headings

The Fix:

<!-- Bad: Skipped levels and styling misuse -->
<h1>Page Title</h1>
<h4>Section Heading</h4> <!-- Skipped h2, h3 -->
<h2 style="font-size: 14px;">Small Text</h2> <!-- Using h2 for styling -->

<!-- Good: Logical heading hierarchy -->
<h1>Page Title</h1>
  <h2>Main Section</h2>
    <h3>Subsection</h3>
    <h3>Another Subsection</h3>
  <h2>Another Main Section</h2>

WordPress Block Editor Fix:

// Restrict heading levels in block editor
function restrict_heading_levels($settings) {
  $settings['allowedBlockTypes'] = array(
    'core/paragraph',
    'core/heading',
    'core/list',
    // ... other allowed blocks
  );
  return $settings;
}

// Or use CSS to visually indicate heading level
function admin_heading_styles() {
  echo '<style>
    h1.wp-block-heading { border-left: 4px solid #007cba; padding-left: 8px; }
    h2.wp-block-heading { border-left: 4px solid #00a0d2; padding-left: 8px; }
    h3.wp-block-heading { border-left: 4px solid #46b450; padding-left: 8px; }
  </style>';
}
add_action('admin_head', 'admin_heading_styles');

Issue 3: Form Labels and Error Messages

The Problem:

Unlabeled form fields, missing error associations, or unclear error messages.

Detection:

• axe flags form fields without labels
• Screen readers don’t announce field purpose
• Error messages aren’t programmatically associated

The Fix:

<!-- Bad: No label association -->
<input type="email" placeholder="Enter your email">

<!-- Bad: Placeholder as label -->
<input type="email" placeholder="Email Address">

<!-- Good: Explicit label with for attribute -->
<label for="email">Email Address <span aria-label="required">*</span></label>
<input type="email" id="email" name="email" required aria-required="true">

<!-- Good: Error message programmatically associated -->
<label for="email">Email Address *</label>
<input
  type="email"
  id="email"
  name="email"
  required
  aria-required="true"
  aria-invalid="true"
  aria-describedby="email-error"
>
<span id="email-error" class="error" role="alert">
  Please enter a valid email address (e.g., name@example.com)
</span>

WordPress Contact Form 7 Enhancement:

// Add ARIA attributes to Contact Form 7
add_filter('wpcf7_form_elements', function($content) {
  // Add aria-required to required fields
  $content = preg_replace(
    '/<input[^>]*class="[^"]*wpcf7-validates-as-required[^"]*"[^>]*>/',
    '$0 aria-required="true"',
    $content
  );
  return $content;
});

Issue 4: Keyboard-Inaccessible Custom Components

The Problem:

Custom dropdowns, tabs, and modals that only work with mouse.

The Fix:

// Accessible Tab Component
class AccessibleTabs {
  constructor(container) {
    this.container = container;
    this.tabs = Array.from(container.querySelectorAll('[role="tab"]'));
    this.panels = Array.from(container.querySelectorAll('[role="tabpanel"]'));

    this.tabs.forEach((tab, index) => {
      tab.addEventListener('click', () => this.selectTab(index));
      tab.addEventListener('keydown', (e) => this.handleKeydown(e, index));
    });
  }

  handleKeydown(event, index) {
    let newIndex;

    switch(event.key) {
      case 'ArrowRight':
        newIndex = (index + 1) % this.tabs.length;
        break;
      case 'ArrowLeft':
        newIndex = (index - 1 + this.tabs.length) % this.tabs.length;
        break;
      case 'Home':
        newIndex = 0;
        break;
      case 'End':
        newIndex = this.tabs.length - 1;
        break;
      default:
        return;
    }

    event.preventDefault();
    this.tabs[newIndex].focus();
    this.selectTab(newIndex);
  }

  selectTab(index) {
    this.tabs.forEach((tab, i) => {
      const isSelected = i === index;
      tab.setAttribute('aria-selected', isSelected);
      tab.setAttribute('tabindex', isSelected ? '0' : '-1');
      this.panels[i].hidden = !isSelected;
    });
  }
}

// Initialize
document.querySelectorAll('[role="tablist"]').forEach(tabs => {
  new AccessibleTabs(tabs);
});

<!-- Accessible Tab Markup -->
<div class="tabs">
  <div role="tablist" aria-label="Product Information">
    <button
      role="tab"
      aria-selected="true"
      aria-controls="panel-1"
      id="tab-1"
      tabindex="0"
    >
      Description
    </button>
    <button
      role="tab"
      aria-selected="false"
      aria-controls="panel-2"
      id="tab-2"
      tabindex="-1"
    >
      Specifications
    </button>
  </div>

  <div
    role="tabpanel"
    id="panel-1"
    aria-labelledby="tab-1"
  >
    Product description content...
  </div>

  <div
    role="tabpanel"
    id="panel-2"
    aria-labelledby="tab-2"
    hidden
  >
    Technical specifications...
  </div>
</div>

Issue 5: Missing Skip Links

The Problem:

Users navigating by keyboard must tab through all navigation items to reach main content.

The Fix:

<!-- Skip Link Implementation -->
<body>
  <a href="#main-content" class="skip-link">
    Skip to main content
  </a>

  <nav><!-- Navigation items --></nav>

  <main id="main-content" tabindex="-1">
    <!-- Main content -->
  </main>
</body>

/* Skip Link Styling */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 16px;
  z-index: 100;
  text-decoration: none;
}

.skip-link:focus {
  top: 0;
}

WordPress Implementation:

// Add skip link in header.php (before any other content)
function add_skip_link() {
  echo '<a href="#main-content" class="skip-link">' .
       esc_html__('Skip to main content', 'textdomain') .
       '</a>';
}
add_action('wp_body_open', 'add_skip_link');

// Ensure main content area has ID
echo '<main id="main-content" tabindex="-1">';

Issue 6: Inaccessible Modal Dialogs

The Problem:

Modals that don’t trap focus, close on Escape, or return focus to trigger.

The Fix:

// Accessible Modal Component
class AccessibleModal {
  constructor(trigger, modal) {
    this.trigger = trigger;
    this.modal = modal;
    this.focusableElements = 'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])';
    this.firstFocusable = null;
    this.lastFocusable = null;
    this.previousFocus = null;

    trigger.addEventListener('click', () => this.open());
    modal.querySelector('.modal-close').addEventListener('click', () => this.close());
    modal.addEventListener('keydown', (e) => this.handleKeydown(e));
  }

  open() {
    this.previousFocus = document.activeElement;
    this.modal.hidden = false;
    this.modal.setAttribute('aria-modal', 'true');

    const focusable = this.modal.querySelectorAll(this.focusableElements);
    this.firstFocusable = focusable[0];
    this.lastFocusable = focusable[focusable.length - 1];

    this.firstFocusable.focus();
    document.body.style.overflow = 'hidden';
  }

  close() {
    this.modal.hidden = true;
    this.modal.removeAttribute('aria-modal');
    document.body.style.overflow = '';
    this.previousFocus.focus();
  }

  handleKeydown(event) {
    if (event.key === 'Escape') {
      this.close();
    }

    if (event.key === 'Tab') {
      if (event.shiftKey && document.activeElement === this.firstFocusable) {
        event.preventDefault();
        this.lastFocusable.focus();
      } else if (!event.shiftKey && document.activeElement === this.lastFocusable) {
        event.preventDefault();
        this.firstFocusable.focus();
      }
    }
  }
}

<!-- Accessible Modal Markup -->
<button aria-haspopup="dialog" aria-controls="modal-1" id="modal-trigger">
  Open Modal
</button>

<div
  role="dialog"
  aria-modal="true"
  aria-labelledby="modal-title"
  id="modal-1"
  hidden
>
  <h2 id="modal-title">Modal Title</h2>
  <p>Modal content...</p>
  <button class="modal-close" aria-label="Close modal">
    <span aria-hidden="true">&times;</span>
  </button>
</div>

---

Creating an Accessibility Audit Report

A well-structured audit report transforms findings into actionable remediation plans.

Report Structure

1. Executive Summary

• Overall compliance status (WCAG 2.2 Level AA)
• Critical issues count
• Risk assessment
• Recommended priority order

2. Methodology

• Tools used (axe, WAVE, screen readers)
• Pages tested (representative sample)
• Testing dates and environment

3. Detailed Findings

Organize by WCAG principle (Perceivable, Operable, Understandable, Robust) or by severity.

Finding Template:

### Issue: [Brief Description]
**WCAG Criterion:** [e.g., 1.1.1 Non-text Content (Level A)]
**Severity:** [Critical | Serious | Moderate | Minor]
**Location:** [URL and specific element]

**Description:**
Detailed explanation of the issue and its impact on users.

**Current Code:**
```html
<!-- Problematic code -->

Recommended Fix:

<!-- Corrected code -->

Testing Verification:

1. [Step to verify fix]
2. [Expected result]

**4. Remediation Roadmap**

| Priority | Issue | Estimated Effort | Owner | Target Date |
|----------|-------|------------------|-------|-------------|
| P0 | Missing form labels | 2 hours | Developer | Week 1 |
| P0 | Keyboard traps | 4 hours | Developer | Week 1 |
| P1 | Color contrast | 3 hours | Designer | Week 2 |
| P2 | Heading structure | 2 hours | Content | Week 3 |

### Automated Report Generation

**Using axe-core for Reports:**

```javascript
// generate-accessibility-report.js
const { axe } = require('@axe-core/webdriverjs');
const { Builder } = require('selenium-webdriver');
const fs = require('fs');

async function auditPage(url) {
  const driver = await new Builder().forBrowser('chrome').build();

  try {
    await driver.get(url);
    const results = await axe(driver).analyze();

    const report = {
      url,
      timestamp: new Date().toISOString(),
      violations: results.violations.map(v => ({
        id: v.id,
        impact: v.impact,
        description: v.description,
        help: v.help,
        helpUrl: v.helpUrl,
        nodes: v.nodes.length
      })),
      passes: results.passes.length,
      incomplete: results.incomplete.length,
      inapplicable: results.inapplicable.length
    };

    fs.writeFileSync(
      `audit-${Date.now()}.json`,
      JSON.stringify(report, null, 2)
    );

    return report;
  } finally {
    await driver.quit();
  }
}

// Audit multiple pages
const pages = [
  'https://example.com/',
  'https://example.com/about/',
  'https://example.com/contact/'
];

pages.forEach(url => auditPage(url));

Report Templates

Spreadsheet Template Columns:

1. Issue ID
2. WCAG Criterion
3. Level (A/AA/AAA)
4. Page/URL
5. Element Location
6. Issue Description
7. User Impact
8. Recommended Fix
9. Effort Estimate
10. Priority
11. Status
12. Notes

---

Remediation Workflow

Transforming audit findings into an accessible website requires systematic remediation.

Phase 1: Critical Issues (Week 1)

Focus on barriers that completely block users:

1. Missing form labels - Prevents form completion
2. Keyboard traps - Locks users in elements
3. Missing alt text on informative images - Blocks content understanding
4. Empty buttons/links - Prevents interaction

Daily Standup Questions:

• Which critical issues were resolved today?
• Are there any blockers preventing fixes?
• Have fixes been tested with keyboard and screen reader?

Phase 2: Serious Issues (Week 2-3)

Address significant barriers that cause frustration:

1. Color contrast failures
2. Skipped heading levels
3. Missing skip links
4. Improper ARIA usage

Phase 3: Moderate Issues (Week 4)

Polish the experience:

1. Redundant links
2. Ambiguous link text
3. Missing language attributes
4. PDF accessibility

Testing Verification Protocol

For each fix, verify with:

1. Automated re-test: Run axe on the specific page
2. Keyboard verification: Navigate to and interact with the element
3. Screen reader check: Confirm proper announcement
4. Visual inspection: Check focus indicators and contrast

Regression Prevention

Pre-commit Hooks:

// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "npm run test:accessibility"
    }
  },
  "scripts": {
    "test:accessibility": "axe http://localhost:3000 --exit"
  }
}

Visual Regression Testing:

Include accessibility-specific visual tests:

// accessibility-visual.test.js
describe('Focus indicators', () => {
  it('should show visible focus on buttons', async () => {
    await page.goto('http://localhost:3000');
    await page.keyboard.press('Tab');

    const screenshot = await page.screenshot();
    expect(screenshot).toMatchImageSnapshot();
  });
});

---

FAQ: Practical Accessibility Auditing

What is the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 builds upon WCAG 2.1 with nine new success criteria focusing on cognitive and motor accessibility. Key additions include Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), and Accessible Authentication (3.3.8). WCAG 2.2 also deprecates success criterion 4.1.1 Parsing, as modern browsers and assistive technologies have improved parsing reliability.

How often should I conduct accessibility audits?

For active websites, conduct automated scans with every deployment and comprehensive manual audits quarterly or with major releases. After significant updates—theme changes, plugin additions, or content migrations—perform targeted audits of affected areas. Public sector organizations under EAA should maintain continuous monitoring.

Can I achieve WCAG compliance using only automated tools?

No. Automated tools catch approximately 30% of WCAG criteria, primarily those that can be programmatically verified like missing alt text or color contrast ratios. Manual testing with keyboard navigation and screen readers is essential for evaluating cognitive accessibility, meaningful alternative text, and complex interaction patterns.

What screen reader should I use for testing?

NVDA is the most widely used screen reader and is free, making it the best starting point for Windows testing. For comprehensive compliance testing, also test with JAWS (the enterprise standard) and VoiceOver (built into macOS and iOS). Mobile testing requires TalkBack on Android and VoiceOver on iOS.

How do I handle third-party plugins that aren’t accessible?

First, contact the plugin developer with specific accessibility issues—many are responsive to feedback. If the plugin is essential and cannot be replaced, consider:

1. Adding accessibility wrappers in your theme
2. Using alternative input methods
3. Providing accessible alternatives for critical functionality
4. Documenting known issues for users

For non-essential plugins, seek accessible alternatives from the WordPress Accessibility Team’s plugin recommendations.

What’s the minimum team size needed for accessibility auditing?

A single developer can conduct basic audits using automated tools. However, comprehensive audits benefit from diverse perspectives:

• Developer: Fixes code-level issues
• Designer: Addresses color, contrast, and visual hierarchy
• Content Editor: Ensures meaningful alt text and heading structure
• User Tester with Disabilities: Provides real-world validation

For small teams, consider engaging external accessibility consultants for annual comprehensive audits.

How do I prioritize accessibility issues?

Prioritize by user impact and effort:

1. P0 - Critical: Blocks users completely (missing labels, keyboard traps)
2. P1 - Serious: Significant barriers (contrast failures, missing skip links)
3. P2 - Moderate: Causes frustration (ambiguous links, heading skips)
4. P3 - Minor: Best practice violations (redundant links, minor ARIA issues)

Within each priority, address issues affecting the most pages first.

Are there legal risks for non-compliant WordPress websites?

Yes. In the European Union, the European Accessibility Act mandates WCAG 2.2 Level AA compliance for public sector websites and essential services, with penalties varying by member state (up to €100,000 in some jurisdictions). In the United States, ADA Title III lawsuits against websites have increased significantly, with settlements typically ranging from $10,000 to $100,000 plus remediation costs. Beyond legal risk, inaccessible websites exclude 15-20% of potential users.

How do I test accessibility on a staging site?

Accessibility testing on staging environments follows the same process as production:

1. Ensure staging accurately reflects production (content, plugins, theme)
2. Use browser extensions (axe, WAVE) on staging URLs
3. Test with screen readers against staging
4. Include accessibility tests in your CI/CD pipeline for staging deployments
5. Document staging-specific configurations that might differ from production

What WordPress themes are most accessible?

The WordPress Accessibility Team maintains a list of accessibility-ready themes that meet basic accessibility standards. Popular options include:

• Twenty Twenty-Four (WordPress default)
• Astra (with accessibility features enabled)
• GeneratePress
• Genesis Framework child themes

Always verify accessibility claims with your own testing, as theme updates can introduce regressions.

---

Related Resources

For more comprehensive WordPress optimization and development guidance, explore these related articles:

• Semantic SEO for WordPress: The Complete 2026 Guide - Learn how accessibility improvements enhance your SEO strategy
• WordPress Contact Forms: The Ultimate Guide for 2026 - Ensure your forms meet WCAG standards
• How to Update URLs in the WordPress Database When Moving to a New Domain - Maintain accessibility during site migrations

---

LLM-Friendly Structured Data

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Practical Accessibility Auditing: Tools & Workflow for WordPress",
  "description": "A comprehensive guide to auditing WordPress sites for WCAG 2.2 compliance using automated tools and manual testing techniques.",
  "author": {
    "@type": "Organization",
    "name": "WPPoland",
    "url": "https://wppoland.com"
  },
  "publisher": {
    "@type": "Organization",
    "name": "WPPoland",
    "logo": {
      "@type": "ImageObject",
      "url": "https://wppoland.com/logo.png"
    }
  },
  "datePublished": "2026-01-29",
  "dateModified": "2026-01-29",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://wppoland.com/blog/practical-accessibility-auditing-workflow"
  },
  "about": {
    "@type": "Thing",
    "name": "Web Accessibility Auditing",
    "sameAs": "https://www.w3.org/WAI/standards-guidelines/wcag/"
  },
  "teaches": [
    "WCAG 2.2 compliance testing",
    "Automated accessibility testing with axe and WAVE",
    "Manual testing with screen readers",
    "Keyboard navigation testing",
    "WordPress accessibility remediation"
  ],
  "proficiencyLevel": "Intermediate",
  "dependencies": "WordPress, Modern web browser, Screen reader software"
}

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "How to Conduct a WCAG 2.2 Accessibility Audit on WordPress",
  "description": "Step-by-step workflow for auditing WordPress websites for accessibility compliance",
  "totalTime": "PT4H",
  "supply": [
    "Web browser (Chrome, Firefox, or Edge)",
    "axe DevTools browser extension",
    "WAVE browser extension",
    "Screen reader (NVDA, JAWS, or VoiceOver)"
  ],
  "tool": [
    {
      "@type": "HowToTool",
      "name": "axe DevTools"
    },
    {
      "@type": "HowToTool",
      "name": "WAVE Evaluation Tool"
    },
    {
      "@type": "HowToTool",
      "name": "NVDA Screen Reader"
    }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Run Automated Tests",
      "text": "Install axe DevTools and WAVE browser extensions. Scan all key pages including homepage, contact page, and content templates. Document all violations by severity level.",
      "url": "https://wppoland.com/blog/practical-accessibility-auditing-workflow#automated-testing-tools"
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Test Keyboard Navigation",
      "text": "Disconnect your mouse and navigate the entire site using only Tab, Shift+Tab, Enter, Space, and Arrow keys. Verify all interactive elements are reachable and operable.",
      "url": "https://wppoland.com/blog/practical-accessibility-auditing-workflow#keyboard-navigation-testing"
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Conduct Screen Reader Testing",
      "text": "Test with NVDA (Windows) or VoiceOver (macOS). Navigate by headings, landmarks, and form fields. Verify all content is properly announced and navigation is logical.",
      "url": "https://wppoland.com/blog/practical-accessibility-auditing-workflow#screen-reader-testing"
    },
    {
      "@type": "HowToStep",
      "position": 4,
      "name": "Verify Color Contrast",
      "text": "Use browser DevTools or WebAIM Contrast Checker to verify all text meets WCAG 2.2 contrast requirements (4.5:1 for normal text, 3:1 for large text).",
      "url": "https://wppoland.com/blog/practical-accessibility-auditing-workflow#color-contrast-verification"
    },
    {
      "@type": "HowToStep",
      "position": 5,
      "name": "Document and Prioritize Findings",
      "text": "Create a comprehensive report organizing issues by WCAG principle and severity. Develop a remediation roadmap with timelines and responsible parties.",
      "url": "https://wppoland.com/blog/practical-accessibility-auditing-workflow#creating-an-accessibility-audit-report"
    },
    {
      "@type": "HowToStep",
      "position": 6,
      "name": "Remediate and Verify Fixes",
      "text": "Fix critical issues first, followed by serious and moderate issues. Verify each fix with automated tools, keyboard testing, and screen reader confirmation.",
      "url": "https://wppoland.com/blog/practical-accessibility-auditing-workflow#remediation-workflow"
    }
  ]
}

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the difference between WCAG 2.1 and WCAG 2.2?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "WCAG 2.2 builds upon WCAG 2.1 with nine new success criteria focusing on cognitive and motor accessibility. Key additions include Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), and Accessible Authentication (3.3.8). WCAG 2.2 also deprecates success criterion 4.1.1 Parsing."
      }
    },
    {
      "@type": "Question",
      "name": "How often should I conduct accessibility audits?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "For active websites, conduct automated scans with every deployment and comprehensive manual audits quarterly or with major releases. After significant updates—theme changes, plugin additions, or content migrations—perform targeted audits of affected areas."
      }
    },
    {
      "@type": "Question",
      "name": "Can I achieve WCAG compliance using only automated tools?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Automated tools catch approximately 30% of WCAG criteria, primarily those that can be programmatically verified. Manual testing with keyboard navigation and screen readers is essential for evaluating cognitive accessibility, meaningful alternative text, and complex interaction patterns."
      }
    },
    {
      "@type": "Question",
      "name": "What screen reader should I use for testing?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "NVDA is the most widely used screen reader and is free, making it the best starting point for Windows testing. For comprehensive compliance testing, also test with JAWS (the enterprise standard) and VoiceOver (built into macOS and iOS)."
      }
    },
    {
      "@type": "Question",
      "name": "Are there legal risks for non-compliant WordPress websites?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. In the European Union, the European Accessibility Act mandates WCAG 2.2 Level AA compliance for public sector websites and essential services, with penalties varying by member state (up to €100,000 in some jurisdictions). In the United States, ADA Title III lawsuits have increased significantly."
      }
    }
  ]
}