---
name: audit-accessibility-and-performance
description: Runs a pre-launch quality pass on a website, with WCAG 2.2 AA quick checks (alt text, headings, labels, keyboard, focus, contrast) and Core Web Vitals fixes, checked with Lighthouse. Use when the user wants their site accessible, faster, a Lighthouse audit, or a quality check before launch.
license: CC-BY-4.0
metadata:
  category: frontend
  tags: "accessibility,performance,quality,website"
  author: johnny-bravo
  version: "1.0"
  updated: "2026-10-31"
  status: published
---

# Audit accessibility and performance

## When to use
- A site is built and you want it usable by everyone (keyboard, screen readers, low vision) and fast on a phone before it goes live.
- Lighthouse shows low scores, or the site feels slow.
- This is a quick, practical pass, not a formal WCAG conformance audit.

## Handoff
- Reads: the running site (`npm run build && npm start`) and its source.
- Writes: fixes in the code, plus `docs/quality-report.md` with the before and after scores, what was fixed and what is left.

## Steps
1. Baseline: in Chrome, open the production build (not `npm run dev`, which is slower and unminified), DevTools → Lighthouse → Mobile, categories Performance, Accessibility, Best practices, SEO. Run it on the home page and one inner page. Note the scores in `docs/quality-report.md`.
2. Images: every meaningful image has `alt` that says what it shows or does; decorative images use `alt=""`. Use `next/image` with `width`/`height` (or `fill` with a sized parent) so nothing jumps.
3. Structure: one `<h1>` per page, headings in order (no jumping from h2 to h4), landmarks (`<header>`, `<nav>`, `<main>`, `<footer>`), `<html lang>` set, and a working skip link.
4. Forms: every input has a visible `<label>`; errors are text next to the field (linked with `aria-describedby`), not colour alone.
5. Keyboard: unplug the mouse. Tab through each page: every link, button and field is reachable in a sensible order, the focus ring is clearly visible (don't remove `outline` without a replacement), the menu opens and closes, and nothing traps focus. Sticky headers must not hide the focused element.
6. Contrast: text at least 4.5:1 against its background (3:1 for large text and for icons, borders and focus rings that matter). Check the brand colours from the theme step; adjust the token, not each component.
7. Targets and motion: buttons and links at least 24×24 CSS pixels (44×44 is friendlier on mobile); respect `prefers-reduced-motion` for animations.
8. Core Web Vitals targets (good, at the 75th percentile of visits): LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less.
   - LCP: give the hero `next/image` `loading="eager"` or `fetchPriority="high"` (Next.js 16 replaced the old `priority` prop with `preload`), size it correctly, and serve modern formats (Next.js does this).
   - CLS: reserve space for images, embeds and fonts; use `next/font` instead of a font `<link>`.
   - INP: keep client components small; move work out of click handlers; avoid heavy third-party scripts, or load them with `next/script` `strategy="lazyOnload"`.
9. Re-run Lighthouse, then a screen reader smoke test (VoiceOver on Mac or iPhone, NVDA on Windows, TalkBack on Android): the page title, headings and form labels should all be read out sensibly.
10. Write `docs/quality-report.md`: scores before and after, each fix, and anything left with a reason.

## Gotchas
- A Lighthouse accessibility score of 100 does not mean accessible: automated tools catch only some problems. Steps 5 and 9 are the ones that find the rest.
- Lab scores vary run to run; compare medians of 3 runs. Real-user field data appears later in Search Console or Vercel Speed Insights.
- Don't add ARIA to fix what native HTML does already (`<button>` beats `<div role="button">`).
- Placeholder text is not a label.
- Autoplaying video in the hero usually costs both LCP and accessibility; use a poster image.

## References
- W3C WAI, Easy Checks: https://www.w3.org/WAI/test-evaluate/preliminary/
- WCAG 2.2 quick reference: https://www.w3.org/WAI/WCAG22/quickref/
- web.dev, Web Vitals: https://web.dev/articles/vitals

## Credits
Topic coverage informed by addyosmani/web-quality-skills (https://github.com/addyosmani/web-quality-skills, MIT © 2026 Addy Osmani). The text here is our own.

## Example prompt
"Run a Lighthouse audit on my site before launch and fix the accessibility and speed problems it finds."
