Q17 of 24 · Accessibility

How do you plan and execute a full manual accessibility audit of a web application?

AccessibilitySenioraccessibilityauditmanual-testingwcagprocesssenior

Short answer

Short answer: A structured audit covers page structure (headings, landmarks, reading order), keyboard access, screen reader walkthrough on the target platform, colour contrast, images and media, forms and error handling, dynamic content, and motion. Document each issue against its WCAG success criterion, severity, and recommended fix.

Detail

A manual accessibility audit is systematic, not exploratory. Plan it as a test suite with explicit coverage areas, then execute each one in order.

Coverage areas and how to test each:

  1. Page structure: check heading hierarchy (h1 → h2 → h3, no skips), landmark regions (main, nav, header, footer present), and reading order (does the content make sense in DOM order without CSS?). Tools: screen reader in document navigation mode, DevTools outline.

  2. Keyboard access: navigate the entire page by keyboard only. Every interactive element reachable? Tab order logical? No traps? Focus always visible? (See keyboard navigation testing for the full process.)

  3. Screen reader walkthrough: navigate the page with the appropriate SR/browser pair. Verify announcements, image alt text, form labels, error messages, dynamic content, state changes.

  4. Colour contrast: scan all text and UI components against their backgrounds. Use Colour Contrast Analyser or browser DevTools. Don't forget large text (3:1 threshold), UI components (3:1 threshold), and focus indicators.

  5. Images and media: every non-decorative image has meaningful alt text; decorative images are marked alt=""; videos have captions; audio has transcripts.

  6. Forms: every input labelled, required fields indicated, errors associated and descriptive.

  7. Dynamic content: live regions announce updates; focus is managed correctly on page changes; modals trap and return focus.

  8. Motion: animations respect prefers-reduced-motion; no content flashes more than 3 times per second.

Documentation: record each issue with: the WCAG success criterion it violates, the severity (critical/high/medium/low based on user impact), the specific element and location, and a recommended fix. Use a spreadsheet or JIRA with a custom accessibility issue type.

// WHAT INTERVIEWERS LOOK FOR

Systematic coverage of all areas (not just what axe checks). Maps findings to WCAG success criteria. Mentions the output format (documented issues with criterion and severity).