Overview

Accessibility agents validate WCAG-oriented behavior including keyboard navigation, focus order, color contrast thresholds, ARIA semantics, and screen-reader-critical flows. They complement manual audits by scanning generated UI paths after each substantive frontend change.

Enable agents per organization in Automation → AI Agents. Human review applies to generated output before release-critical use.

Who should read this

QA engineers, SREs, platform teams, and developers operating Zof Console and APIs.

Prerequisites

Organization administrator approval to enable agent category
Staging or approved test environment reachable from execution plane
Requirement linkage for audit-oriented teams (recommended)

When to use this workflow

Pre-release audit of checkout and account settings
Regression after component library upgrades
Compliance evidence collection for public-sector releases

Step-by-step procedure

Enable in Console

Automation → AI Agents → Accessibility category → Enable for organization.

Confirm policy pack allows accessibility agents for target applications.

Target application surfaces

Select web targets with authenticated staging URLs.

Attach critical pages: login, checkout, profile, admin settings.

Review generated cases

Quality → Cases → filter by accessibility agent label.

Human review required before blocking production on findings alone.

Key concepts

accessibility validation scope: Keyboard-only navigation for primary workflows; Focus visibility and skip-link behavior; Form labels, roles, and live-region announcements; Color contrast on interactive states (hover, disabled, error).
Check 1: Keyboard-only navigation for primary workflows
Check 2: Focus visibility and skip-link behavior
Check 3: Form labels, roles, and live-region announcements

Best practices

Pair automated scans with manual assistive-technology spot checks
Scope agents to user-facing flows, not every static marketing page
Track accessibility regressions in Test Health separate from functional noise