Accessibility Analyzer

Analyze accessibility from real user sessions — keyboard navigation patterns, focus traps, missing labels, and a11y regressions. Complement automated audits with evidence from actual users.

When to Use

• "Are keyboard-only users able to navigate our checkout?"
• "Did the redesign break accessibility for screen reader users?"
• "Find sessions where users tabbed through the page — did they get stuck?"
• "Are our form labels working for assistive technology?"
• "Validate WCAG compliance from real session data"
• "Show me sessions where users struggled with focus order"

Mental Model

Automated a11y tools (Axe, Lighthouse) catch ~30% of accessibility issues. Real user sessions catch the rest — focus traps, keyboard dead ends, unlabeled interactive elements, content that changes without announcement.

Fullstory captures all DOM interactions. By looking at how users interact with your site without a mouse, you can identify where the experience breaks.

For visual checks, follow session-review: open with fullstory:review-open, pass its client_id to fullstory:review-snapshot at the target timestamp, and always call fullstory:review-close, including on errors. Delegate repeated captures to session-replay.

Workflow

Step 1: Identify a11y-relevant sessions

Build segments for users likely relying on assistive technology:

fullstory:build_segment("users who navigated using only keyboard (tab key usage, no mouse clicks)")
fullstory:build_segment("users who used form fields extensively (screen reader users fill forms via keyboard)")

Or filter sessions by interaction patterns:

fullstory:get_sessions(
  event="keydown",      # keyboard interactions
  exclude_event="click", # no mouse clicks = likely keyboard-only
  limit=10
)

Step 2: Audit keyboard navigation

For each keyboard-navigated session, use session-context agent: "What was the user's tab order? Did they tab through elements in a logical sequence? Did they get trapped in any element (modal, form, menu)? Were there dead tab stops where nothing was focused?"

Common keyboard issues:

• Focus trap: User tabs into a modal/dropdown and can't tab out
• Skip link missing: User tabs through 50 nav items before reaching content
• Focus not visible: Element receives focus but no focus ring — user doesn't know where they are
• Tab order illogical: Focus jumps from header to footer, skipping main content

Step 3: Check form accessibility

For form-heavy pages, check:

fullstory:build_metric(
  query="users who interacted with /signup form using keyboard only",
  output_type="single_number"
)

With review-snapshot, check:

• Are all form fields reachable via Tab?
• Do labels associate with inputs (clicking label focuses the input)?
• Are error messages announced (do they have aria-describedby or role="alert")?
• Are required fields indicated both visually AND programmatically (aria-required)?

Step 4: Check for focus-order regressions

After a UI deploy, compare keyboard navigation before/after:

fullstory:build_metric(query="sessions with keyboard navigation on /checkout", output_type="trend")
fullstory:compute_metric(metric_id, time_range="last_14_days")
→ look for a change in navigation patterns at the deploy timestamp

If users start spending more time tabbing or rage-clicking after deploy, something broke in the focus order.

Step 5: Simple checks from session screenshots

Use review-snapshot to visually verify at key interaction points:

• Focus indicator visible on the active element?
• Color contrast sufficient for the active element?
• Text readable without zooming on mobile?
• Interactive elements have clear affordance (looks clickable)?

Step 6: Report

## Accessibility Audit — /checkout (last 30 days)

### Keyboard Navigation
- 142 sessions with keyboard-only navigation (estimated)
- Primary issue: Focus trap in promo code modal — 12 sessions show users tabbing repeatedly inside the modal without escape
- Tab order: Logical (Header → Shipping → Payment → Submit) ✅

### Form Accessibility
- All 8 form fields reachable via Tab ✅
- 3 fields missing explicit <label> associations: Promo Code, Gift Card, CVV 🔴
- Error messages not associated with fields (no aria-describedby) — screen reader users won't hear them 🔴
- Required fields visually indicated (red asterisk) but no aria-required ✅?

### Regressions
- No a11y regressions detected since Jul 15 deploy ✅

### WCAG Impact
| Issue | WCAG Criterion | Severity | Affected Users |
|-------|---------------|----------|---------------|
| Focus trap in modal | 2.1.2 No Keyboard Trap | High | 12 sessions (8%) |
| Missing form labels | 1.3.1 Info and Relationships | High | All keyboard users |
| Error announcement | 4.1.3 Status Messages | Medium | All form users |

### Recommendations
1. Add Escape key handler to promo code modal (WCAG 2.1.2)
2. Add explicit <label for="..."> to Promo Code, Gift Card, CVV fields
3. Add aria-describedby linking error messages to their fields

Common A11y Issues Detectable in Sessions

Guidelines

• Fullstory can't directly detect screen reader usage — infer from keyboard-only interaction patterns. Be transparent about this limitation.
• Automated tools catch code-level issues. Your job is to find interaction-level issues that only appear in real usage.
• A single focus trap affecting 12 sessions out of 142 is an 8% failure rate — that's high enough to fail WCAG 2.1.2 conformance.
• Don't claim WCAG compliance or non-compliance. You're providing evidence, not a certification.
• Always cross-reference with the mobile-analyzer — many mobile a11y issues overlap (touch targets, zoom, text size).
• After any UI deploy, run a quick keyboard audit on the changed pages. Focus-order regressions are the most common deploy-caused a11y bug.