lwc-accessibility
Installation
SKILL.md
Use this skill when a Lightning Web Component looks correct visually but may fail for keyboard users or assistive technology. The highest-value move in LWC accessibility work is usually to remove custom interaction code and return to accessible base components, then handle the few remaining focus and labeling gaps deliberately.
Before Starting
Gather this context before working on anything in this domain:
- Which parts of the UI are interactive: buttons, menus, tabs, dialogs, inline actions, or custom pickers?
- Is the component built mostly from
lightning-*base components, SLDS blueprint markup, or custom HTML? - Where should focus move after the user opens a modal, triggers validation errors, saves, or cancels?
Core Concepts
Accessibility in LWC is easiest when the component stays close to platform primitives. Salesforce base components already carry keyboard behavior, labeling support, and SLDS-aligned semantics. The farther a team moves toward clickable div elements, custom focus logic, and manual ARIA, the more likely it is to recreate a solved problem badly.