noejunior792/accessibility-by-default
Overview
This skill treats accessibility as a baseline requirement, embedding WCAG 2.1/2.2 AA principles into every decision. It guides frontend engineers to build inclusive interfaces by default rather than as an afterthought. The goal is practical, testable behaviors that make apps perceivable, operable, understandable, and robust for real users.
How this skill works
The skill inspects markup, interaction patterns, focus management, state exposure, and progressive enhancement to ensure accessibility-first outcomes. It enforces semantic HTML, keyboard support, proper labeling, contrast, motion and preference respect, and ARIA only when necessary. It provides a clear review checklist and actionable fixes for issues found during development or code review.
When to use it
- When creating new UI components or pages so accessibility is present from first render.
- During code reviews to block regressions and surface concrete fixes.
- When refactoring legacy code to remove div-buttons, add labels, and restore keyboard behavior.
- Before release to validate contrast, keyboard flows, screen reader announcements, and motion preferences.
- When designing interactions to ensure alternatives for hover, gesture, and auto-advancing content.
Best practices
- Use native elements first: button, a, form controls, headings, lists and landmarks.
- Ensure every interactive item is keyboard operable and has visible focus and logical tab order.
- Label every control and image; provide accessible names for icon-only buttons and aria-hidden for decorative icons.
- Respect user preferences: prefers-reduced-motion, prefers-contrast, prefers-color-scheme; do not auto-advance content.
- Progressively enhance: core functionality must work without JavaScript; ARIA only when native semantics cannot express intent.
Example use cases
- Fix an icon-only delete button by adding an aria-label and hiding the icon from assistive tech.
- Convert clickable divs to native buttons to restore keyboard and screen reader behavior.
- Audit a modal to ensure focus traps correctly, focus returns on close, and announcements are made to screen readers.
- Add prefers-reduced-motion support and alternative navigation for infinite scroll.
- Report accessibility bugs with location, severity, impact, and a minimal code fix example.
FAQ
WCAG 2.1/2.2 Level AA is the baseline target for all guidance and decisions.
When should I use ARIA?
Use ARIA only when native HTML cannot express the required semantics; incorrect ARIA can harm accessibility.
How do I test accessibility quickly?
Start with keyboard-only navigation, a screen reader pass, contrast checks, zoom tests, and verifying motion and preference settings.