| name | frontend-performance-accessibility |
| description | Use when improving frontend performance, Lighthouse, web-vitals, or a11y. |
Frontend Performance Accessibility
Performance Checks
Use Lighthouse for page-level performance and best-practice validation:
make lighthouse-desktop
make lighthouse-mobile
Use web-vitals for runtime signals when adding instrumentation.
Accessibility Checks
- Figma design is the source of truth. Before modifying UI, verify the
design spec first. Accessibility guidance applies on top of the design,
not instead of it. Do not invent UI from a11y requirements alone.
- Prefer semantic MUI components and native controls.
- Use accessible names for buttons, links, fields, dialogs, and icons.
- Keep form errors connected to their fields.
- Use Playwright role and label locators to preserve accessibility coverage.
- Check keyboard interaction for menus, dialogs, forms, and route changes.
Rendering Rules
- Avoid layout shifts from dynamic labels, counters, and loading states.
- Keep heavy computation out of render paths.
- Memoize only when measurement or code shape shows repeated cost.
- Preserve readable contrast and focus states.
Verification
make test-unit-client
make test-e2e
make test-visual
make lighthouse-desktop
make lighthouse-mobile
Run the subset that matches the change, then finish with make format followed
by make lint.
Related Guides
Before applying this skill, confirm the active task against
../AI-AGENT-GUIDE.md and
../SKILL-DECISION-GUIDE.md so every relevant
skill is consulted.
Line Length Disclosure
Before presenting changes, check changed text files for lines longer than 100 characters.
If any exist, tell the user each path:line and measured character count.
Treat this as disclosure, not failure, unless a project gate fails.
Supporting Files
