Frontend · How to use a skill

audit-accessibility-and-performance

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.

Version 1.0 · Updated 2026-10-31

View raw SKILL.md

curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/audit-accessibility-and-performance/raw' -o ~/'.claude/skills/audit-accessibility-and-performance/SKILL.md'

curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/audit-accessibility-and-performance/raw' -o '.cursor/skills/audit-accessibility-and-performance/SKILL.md'

curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/audit-accessibility-and-performance/raw' -o '.agents/skills/audit-accessibility-and-performance/SKILL.md'

{
  "mcpServers": {
    "theskillvault": {
      "url": "https://theskillvault.ai/mcp"
    }
  }
}

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".

1. 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.
2. 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."

Licence: CC BY 4.0. Attribution when you reuse it: From TheSkillVault, https://theskillvault.ai, CC BY 4.0