Template Overview

Digital interfaces must remain fully accessible to users relying on screen readers, keyboard-only navigation, and custom display scaling. The Accessibility Usability Audit Record provides a rigorous evaluation log that tracks WCAG 2.2 conformance, assistive technology test paths, focus traps, and remediation roadmaps in plain Markdown.

Markdown Template Structure

Copy the block below or click Download .md File to add this template directly to your personal vault:

---
title: "Accessibility Audit: [Product / Feature Flow]"
date: [YYYY-MM-DD]
auditor: "[[Auditor Name]]"
standard_target: "WCAG 2.2 Level AA"
assistive_tech_tested: ["macOS VoiceOver", "Keyboard Only", "High Contrast Mode"]
overall_compliance: "Pass / Partial / Fail"
critical_defects: 0
tags: [accessibility, a11y, wcag, usability, audit]
---

# Accessibility Usability Audit — [Product / Feature Flow]

## 1. Audit Scope & Assistive Tech Environment
- **Evaluated Workflows:** Account onboarding, template selection, audio recording, and note export.
- **Operating System & Browser:** macOS Sequoia 15.1, Safari 18.0, VoiceOver enabled.
- **Hardware Setup:** Apple Silicon Mac with built-in keyboard and trackpad.

## 2. WCAG 2.2 Level AA Compliance Checklist
| WCAG Criterion | Description | Status | Evidence / Observation |
|---|---|---|---|
| **1.1.1 Non-text Content** | Alt text for informative images | Pass | All icons include descriptive aria-labels |
| **1.4.3 Contrast (Minimum)** | Text contrast ratio >= 4.5:1 | Pass | Body text ratio measured at 7.8:1 |
| **2.1.1 Keyboard** | All interactive elements operable | Partial | Focus trap detected in modal close button |
| **2.4.7 Focus Visible** | Clear visual focus ring present | Pass | 2px solid cyan focus outline across all buttons |
| **4.1.2 Name, Role, Value** | Correct ARIA roles on custom inputs | Pass | Tab components implement standard ARIA tablist |

## 3. Discovered Accessibility Defects
### Defect A11Y-01: Focus Trap in Template Download Modal
- **WCAG Guideline:** 2.1.2 No Keyboard Trap (Level A)
- **Severity:** **Critical**
- **Observed Behavior:** Pressing Tab within the download dialog cycles into background elements rather than staying within the active dialog.
- **Expected Behavior:** Focus must be trapped inside the modal until dismissed via Escape or close button.
- **Remediation:** Implement standard `focus-trap` library or native HTML `<dialog>` element.

## 4. Screen Reader (VoiceOver) Traversal Notes
- VoiceOver correctly announces heading hierarchy from H1 through H3.
- Audio wave visualization lacks aria-live announcement when recording starts; add `aria-live="polite"` status message.

## 5. Remediation Plan & Prioritization
> [!IMPORTANT] Remediation Priority
> Defect A11Y-01 must be patched before release tag v1.4.0 to prevent blocking keyboard-dependent users.

## 6. Action Items
- [ ] Refactor modal dialog to native HTML `<dialog>` with proper inert attribute.
- [ ] Retest VoiceOver flow with blind accessibility consultant.

Filled Real-World Example

Here is a realistic example demonstrating how this template captures actual deliberations:

---
title: "Accessibility Audit: Templates Gallery"
date: 2026-10-08
auditor: "[[Priya Patel]]"
standard_target: "WCAG 2.2 Level AA"
assistive_tech_tested: ["macOS VoiceOver", "Full Keyboard Access"]
overall_compliance: "Pass"
critical_defects: 0
tags: [accessibility, a11y, templates]
---

# Accessibility Usability Audit — Templates Gallery

## 1. Audit Summary
Priya Patel audited the Templates Gallery page using macOS VoiceOver and Full Keyboard Access. All 12 category chips and 240 template cards were tested for keyboard navigation, tab order, and color contrast.

## 2. Key Findings
All category filter chips respond properly to keyboard Enter/Space, and the live search input includes an explicit label. Color contrast across both light and dark themes exceeds 7.2:1 for all textual elements.

When to Use and When to Avoid

When to Use

  • Use during pre-launch engineering audits to guarantee compliance with WCAG 2.2 AA.
  • Use when testing with screen reader users or assistive tech hardware.
  • Use to create clear, prioritized bug tickets for frontend developers.

When to Avoid

  • Avoid using as a substitute for live user testing with people with disabilities.
  • Avoid using for purely back-end database architectural reviews.

On-Device AI Integration

Summarize your recording in Oyma with this local instruction:

Analyze the accessibility audit notes:
1. Extract all discovered defects and group them by WCAG 2.2 criterion and severity.
2. Outline specific frontend code remediation suggestions (e.g., aria attributes, focus management).
3. Generate a prioritized Markdown punch list for the engineering sprint.

Your data remains securely on your Mac with zero cloud exposure.

Frequently Asked Questions

What accessibility standards does this audit template track?

The template aligns with WCAG 2.2 Level AA guidelines, focusing on keyboard operability, screen reader semantics, focus indicators, and touch target sizing.

Who should conduct this audit?

Accessibility engineers, product designers, and usability researchers testing with native assistive technology users (VoiceOver, NVDA, switch controls).

How are accessibility bugs categorized?

Bugs are triaged by severity: Critical (blocks task completion), High (causes major delay), Medium (workaround available), and Low (minor cosmetic).