Elite Audit

Elite Audit

UI/UX quality audit orchestrator. ~190 rules across 8 categories, prioritized CRITICAL → HIGH → MEDIUM. Failures trigger the relevant teaching skill for guided remediation.

Quick Reference

Audit Modes

Full Audit

All rules, CRITICAL → HIGH → MEDIUM. Use before launch.

Run every rule across all 8 categories. Start with CRITICAL blockers, then HIGH quality gates, then MEDIUM polish. A full audit covers ~190 checks and ensures the implementation meets elite standards end-to-end.

Quick Audit

CRITICAL rules only (~43 checks). Use for fast sanity check.

Covers the minimum bar: contrast, focus, touch targets, reduced motion, Core Web Vitals, GPU-only animations, viewport meta, visible labels, and design tokens. Takes minutes, not hours. Good for mid-sprint gut checks.

Focused Audit

Single category. Use for targeted review (e.g., "audit accessibility only").

Load only the relevant checklist section below and the matching reference file. Useful after making changes in one area — verify that category passes without re-running everything.

The Audit Loop

The audit follows a strict feedback cycle:

1. Check rules by priority (CRITICAL first)
2. For each failure → state the rule, cite the source, name the fix skill
3. Invoke the teaching skill for implementation guidance
4. Fix the issue
5. Re-check the failed rule
6. Continue until all CRITICAL and HIGH rules pass
7. MEDIUM rules are recommendations, not blockers

Important: Never skip straight to fixing. Always state the rule ID, the evidence of failure, and which skill provides the remediation pattern. This creates an auditable trail.

Quick Checklists

Condensed inline checklists for rapid scanning. Each item is binary pass/fail. For full rule details and implementation guidance, load the corresponding reference file.

Accessibility

• Text contrast >= 4.5:1 (large text >= 3:1)
• Focus indicator visible on all interactive elements (2px + 2px offset)
• Touch targets >= 44x44px with >= 8px spacing
• prefers-reduced-motion handled on every animation
• Meaningful images have descriptive alt text; decorative have alt=""
• Heading hierarchy sequential (h1 -> h2 -> h3, no skips)
• Color not the only means of conveying information
• Skip-to-content link is first focusable element

Performance

• LCP <= 2.5s, INP <= 200ms, CLS <= 0.1
• Only transform, opacity, filter animated (GPU-only)
• Initial JS < 100KB, CSS < 50KB (gzipped)
• Images use AVIF/WebP with explicit dimensions
• Below-fold content lazy loaded
• font-display: swap on all custom fonts
• gsap.context() used with revert() on cleanup

Animation

• Duration: 100-300ms micro, 300-500ms reveals, never >800ms
• Easing: ease-out for entering, ease-in for exiting, never linear for UI
• Exit animations 60-70% of enter duration
• Animations interruptible (no blocking user input)
• Scale feedback 0.95-1.05 on press (not larger)
• No opacity lingering below 0.2
• Modal animates from trigger source

Layout

• <meta name="viewport" content="width=device-width, initial-scale=1"> (no user-scalable=no)
• Mobile-first breakpoints (min-width, not max-width)
• 100dvh used instead of 100vh for full-screen sections
• Fixed elements reserve safe padding for content
• Body text max-width 65ch
• Safe areas respected (env(safe-area-inset-*))

Forms & Feedback

• Every input has a visible label (not placeholder-only)
• Errors appear below the field with cause + fix
• Focus moves to first error on submit failure
• Toast uses aria-live="polite", auto-dismisses 3-5s
• Destructive actions require confirmation dialog
• Disabled state: opacity 0.4 + cursor: not-allowed + semantic attribute
• Multi-step forms show progress indicator

Navigation

• Bottom nav <= 5 items with icon + text label
• Active state visually indicated (color, weight, or indicator)
• Back navigation predictable (preserves scroll/state)
• Modals not used for primary navigation flows
• Breadcrumbs for 3+ level hierarchies
• Focus moves to main content on route change

Typography & Color

• Type scale with consistent ratio (1.25 recommended)
• Fluid sizes via clamp() for headings
• Line-height 1.5+ for body text
• Semantic color tokens (not raw hex in components)
• font-variant-numeric: tabular-nums for data/prices

Brand Consistency

• Design tokens defined (not magic values)
• Spacing follows 4/8px scale
• One primary CTA per screen
• SVG icons (never emoji)
• Consistent icon stroke width and style
• hover/pressed/disabled states visually distinct

Remediation Map

When a rule fails, invoke the corresponding teaching skill. The skill provides implementation patterns, code examples, and verification steps.

How to Use the Remediation Map

1. Identify the failed rule's category from the quick checklists above
2. Find the matching row in the remediation map
3. Load the teaching skill (e.g., /skill:elite-accessibility)
4. Navigate to the key reference file within that skill
5. Follow the implementation pattern to fix the issue
6. Re-run the specific check to verify the fix

Testing Tools

Quick reference of tools to verify audit rules. Use these to gather evidence for pass/fail decisions.

Contrast

• WebAIM Contrast Checker — paste foreground/background colors, get WCAG ratio
• DevTools CSS Overview — Chrome > More Tools > CSS Overview > Colors tab shows all contrast issues
• axe DevTools — automated contrast scanning across the entire page

Performance

• Lighthouse — DevTools > Lighthouse tab, or npx lighthouse <url> --view
• DevTools Performance panel — record interactions, check for long tasks and layout shifts
• WebPageTest — multi-device, multi-location real-world performance testing
• npx unlighthouse — audit every page on the site in one run

Animation

• DevTools Rendering — enable Paint Flashing to see repaints (red = bad)
• DevTools FPS meter — Rendering > Frame Rendering Stats for live FPS overlay
• DevTools Animations panel — inspect timeline, duration, easing of running animations
• DevTools Layers panel — verify animated elements are on their own compositor layer

Accessibility

• axe DevTools — browser extension, catches ~57% of WCAG issues automatically
• WAVE — visual overlay showing errors, alerts, and structural elements
• VoiceOver (macOS) — manual screen reader testing, Cmd+F5 to toggle
• NVDA (Windows) — free screen reader for Windows testing
• Accessibility Insights — Microsoft tool with tab-stop visualization

Layout

• DevTools Device Toolbar — responsive mode with device presets
• DevTools device emulation — test notch/safe-area behavior on iOS/Android frames
• BrowserStack / LambdaTest — real device testing across OS and browser combinations

Bundle

• npx vite-bundle-visualizer — treemap of Vite output bundles
• source-map-explorer — npx source-map-explorer dist/assets/*.js
• bundlephobia.com — check npm package sizes before adding dependencies
• Import Cost (VS Code extension) — inline size display for imports

Audit Report Format

When reporting audit results, use this structure:

## Audit Report — [Project Name]
**Mode**: Full / Quick / Focused ([category])
**Date**: YYYY-MM-DD

### CRITICAL ([X] passed / [Y] total)
- PASS: [rule description]
- FAIL: [rule description] → Fix: [skill name] > [reference file]

### HIGH ([X] passed / [Y] total)
- PASS: [rule description]
- FAIL: [rule description] → Fix: [skill name] > [reference file]

### MEDIUM ([X] passed / [Y] total)
- PASS: [rule description]
- REC: [rule description] → Suggested: [skill name] > [reference file]

### Verdict
- CRITICAL: [all pass / N failures — BLOCKED]
- HIGH: [all pass / N failures — needs work]
- MEDIUM: [X recommendations]
- Ship: YES / NO

CRITICAL failures block deployment. HIGH failures should be resolved but are not hard blockers for staging. MEDIUM items are recommendations for polish.

Common Audit Patterns

Pattern: Post-Build Audit

After completing a feature or page build:

1. Run Quick Audit (CRITICAL only) to catch blockers immediately
2. Fix any CRITICAL failures using the remediation map
3. Run Full Audit before requesting review
4. Document findings in the audit report format above

Pattern: PR Review Audit

When reviewing a pull request:

1. Run Focused Audit on the categories touched by the PR
2. Check that no existing passing rules have regressed
3. Flag new CRITICAL/HIGH failures as blocking review comments
4. Flag MEDIUM items as non-blocking suggestions

Pattern: Pre-Launch Audit

Before deploying to production:

1. Run Full Audit across all categories
2. Verify all CRITICAL rules pass (use pre-launch-checklist.md)
3. Verify all HIGH rules pass
4. Document any accepted MEDIUM exceptions with rationale
5. Final verdict: Ship YES requires zero CRITICAL and zero HIGH failures