name: frontend-production-quality description: Use before implementing UI changes or frontend PRs. Enforces TodoWrite with 18+ items. Triggers: "accessibility audit", "WCAG", "Lighthouse", "screen reader", "a11y", "NVDA", "VoiceOver", "keyboard navigation", "focus indicator". For "Core Web Vitals" in frontend/UI context, use this skill. For pure backend/API performance optimization, use performance-optimization instead. If thinking "WIP doesn't need this" - use it anyway.
Frontend Production Quality
MANDATORY FIRST STEP
CREATE TodoWrite with 3 sections (18+ items total):
- Accessibility (WCAG 2.1 AA): 8+ items
- Performance (Core Web Vitals): 6+ items
- Evidence Collection: 4+ items
Do not design, implement, or review until TodoWrite is created and verified.
WIP Code is NOT an Exception
🚨 CRITICAL: If thinking "I'll commit this now and finish accessibility before code review/merge/deploy" → STOP
- 80% of "I'll finish it later" items never get finished
- Code review often approves incomplete work under pressure
- "WIP" becomes "deployed" without completing deferred items
If you can't complete the work now:
git stash push -m "WIP: feature - needs accessibility verification"- Finish tomorrow
- Commit only when complete
Never commit incomplete work.
Emergency Protocol (10-minute minimum)
If production is down and rollback impossible:
Emergency Verification (10 min):
1. axe CLI accessibility scan (2 min)
2. Manual functional test + keyboard nav (3 min)
3. Lighthouse audit (2 min)
4. Visual inspection - contrast, focus indicators (3 min)
If ANY issues found: DO NOT DEPLOY. Fix first or rollback.
Post-deployment (within 24 hours): Full accessibility audit, Core Web Vitals measurement, incident ticket.
Verification Checkpoint
After creating TodoWrite, verify 3 random items pass this test:
For each item, ALL THREE must be YES:
- Has concrete numbers/thresholds? (LCP < 2.5s, 4.5:1 contrast, tab order 1-5)
- Names specific tools/technologies? (NVDA, WebAIM, Lighthouse,
<button>) - States measurable outcome? (NVDA announces 'Submit button', Lighthouse A11y = 100)
If any NO → revise items before proceeding.
TodoWrite Requirements
Accessibility (WCAG 2.1 AA) - 8+ items
- Semantic HTML:
<button>,<a>,<input>instead of<div onClick> - ARIA labels:
aria-label,aria-labelledbywhere semantic HTML insufficient - Keyboard navigation: All interactive elements via Tab/Shift+Tab. Document tab order.
- Focus indicators: 2px solid border, 3:1 contrast minimum
- Color contrast: 4.5:1 body text, 3:1 large text (WebAIM checker)
- Screen reader testing: NVDA (Windows) or VoiceOver (Mac)
- Heading hierarchy: h1 → h2 → h3, no skips, one h1 per page
- Form labels: Every
<input>has<label>oraria-label
Performance (Core Web Vitals) - 6+ items
- Baseline measurement: Current LCP, FID, CLS before changes
- LCP < 2.5s: Largest Contentful Paint
- FID < 100ms: First Input Delay
- CLS < 0.1: Cumulative Layout Shift
- Bundle size: Document impact, justify if >10KB increase
- Lazy loading: Images
loading="lazy", non-critical JS on-demand
Evidence Collection - 4+ items
- Lighthouse A11y = 100: Screenshot with URL, date
- Lighthouse Perf ≥ 90: Screenshot with Core Web Vitals
- Keyboard tab order: List order + focus indicator description
- Screen reader results: What NVDA/VoiceOver announced
Specificity Test
For EACH item, ask: "Could an engineer implement without clarifying questions?"
| ❌ Fails Test | ✅ Passes Test |
|---|---|
| "Check accessibility" | "Semantic HTML: Replace <div onClick> with <button>, verify NVDA announces 'button'" |
| "Test performance" | "Core Web Vitals: LCP < 2.5s on 3G throttle using Lighthouse" |
| "Test keyboard navigation" | "Tab order: 1. Email input, 2. Password input, 3. Submit button. Each has 2px solid #0056b3 focus border" |
Red Flags - STOP When You Think:
| Thought | Reality |
|---|---|
| "We'll add accessibility later" | 80% never added. Retrofit costs 3-5x more. |
| "Design is approved, just implement" | Design approval doesn't override WCAG 2.1 AA (legal requirement) |
| "Internal tooling, less critical" | ADA applies to employees |
| "It's just a commit, not deploy" | Commits become deploys. 80% of "later" never happens |
| "Code review will catch it" | YOU are the quality gate. Code review is backup. |
| "I'll finish before code review" | Finish before committing. |
Response Templates
"We'll Add Accessibility Later"
❌ BLOCKED: Cannot defer accessibility.
- 80% of "later" items never get added
- Retrofit costs 3-5x more
- ADA lawsuits cost $20K-100K+
Required to override:
- Specific retrofit date (not "later")
- Budget allocated (engineer-weeks)
- Risk acceptance signed by decision maker
Skipping Core Web Vitals
❌ BLOCKED: Cannot mark complete without measurement.
Required:
- Lighthouse audit (Perf ≥ 90, A11y = 100)
- Core Web Vitals on 3G: LCP < 2.5s, FID < 100ms, CLS < 0.1
- Bundle size documented
Takes 5 minutes. Not optional.
Final Self-Grading
Before claiming complete:
[ ] 18+ items across 3 sections (A11y 8+, Perf 6+, Evidence 4+)
[ ] 80%+ items have concrete numbers/thresholds
[ ] 80%+ items name specific tools
[ ] 100% items have measurable outcomes
[ ] Tested 3 random items - all passed specificity test
[ ] WCAG 2.1 AA criteria explicitly specified
[ ] Core Web Vitals targets specified
Score 7+/8: Ready to proceed
Score <7: Revise TodoWrite before implementation
Verification Checklist (Before Complete)
Accessibility:
- DevTools accessibility check (0 violations)
- Keyboard navigation entire feature
- Screen reader test (NVDA/VoiceOver)
- Color contrast verified (all text 4.5:1+)
Performance:
- Lighthouse: Performance ≥ 90, Accessibility = 100
- Core Web Vitals on 3G: LCP < 2.5s, FID < 100ms, CLS < 0.1
- Bundle size impact documented
Evidence:
- Lighthouse screenshots
- Keyboard tab order documented
- Screen reader announcements documented
Failure to provide evidence = work is not complete.