accessibility
by affaan-mThe accessibility skill helps you design, implement, and audit accessible UI with WCAG 2.2 Level AA guidance for Web, iOS, and Android. Use it to map component roles, labels, states, focus behavior, and accessibility traits, with practical accessibility usage for UX Audit work and implementation reviews.
This skill scores 78/100, which means it is a solid listing candidate for Agent Skills Finder. Directory users get a clearly triggerable accessibility workflow for WCAG 2.2 AA design, implementation, and audit tasks, with enough operational guidance to be useful beyond a generic prompt, though it still lacks some adoption aids that would make install decisions easier.
- Explicit use cases for web, iOS, and Android accessibility work, including audits and implementation
- Good operational framing around WCAG 2.2, POUR, semantic mapping, focus management, and labeling/hints
- Substantive SKILL.md body with headings and stepwise workflow content, making it easier for agents to execute
- No install command or support files, so users must infer setup and integration from SKILL.md alone
- Repository evidence shows placeholder markers and no reference/resources layer, which limits trust for edge cases and deeper adoption
Overview of accessibility skill
What the accessibility skill does
The accessibility skill helps you design, implement, and audit accessible UI against WCAG 2.2 Level AA. It is aimed at turning product intent into concrete semantic choices: native elements, ARIA roles, labels, hints, focus behavior, and platform-specific accessibility traits for Web, iOS, and Android.
Who should install this accessibility skill
This accessibility skill is best for frontend engineers, design system teams, UX auditors, and product designers who need implementation-ready guidance rather than a generic accessibility checklist. It is especially useful when you are doing accessibility for UX Audit work and need to move from “this flow feels risky” to specific remediations.
What job it helps you complete
The real job-to-be-done is not just “make things compliant.” It is to map a component or flow to the accessibility tree correctly so assistive tech users get the right role, name, state, order, and interaction model. The skill emphasizes semantic mapping, focus management, labeling, and the POUR principles instead of broad policy summaries.
Why choose it over a normal prompt
A normal prompt often produces vague accessibility advice. This skill is more useful when you need structured reasoning such as: identify the component role first, prefer native semantics, then define labels, states, keyboard behavior, and focus treatment. That makes the accessibility usage more actionable for implementation reviews and audits.
How to Use accessibility skill
Install context and what to read first
Install the skill through your skills workflow, then open skills/accessibility/SKILL.md first. There are no extra scripts or reference files in this skill, so nearly all useful guidance is in that single document. Read these sections in order:
When to UseCore ConceptsHow It Works- the step about identifying the component role
This is a lightweight accessibility install: low setup friction, but you should expect to supply the missing product context yourself.
Inputs the accessibility skill needs
The accessibility skill works best when you provide:
- platform:
Web,iOS, orAndroid - component or flow: button, modal, form, tabs, menu, carousel, etc.
- user goal: what the user is trying to do
- current implementation: HTML, JSX, SwiftUI/UIKit, Jetpack Compose/View XML, or screenshots plus behavior notes
- constraints: design system limits, legacy markup, third-party widgets
- audit target: WCAG 2.2 AA, keyboard support, screen reader behavior, focus order, target size, or naming/state issues
Weak input: “Make this accessible.”
Strong input: “Audit this React modal for WCAG 2.2 AA. Check semantic role, accessible name, focus trap, escape behavior, initial focus, return focus, and screen reader announcement. Suggest corrected JSX.”
Turn a rough goal into a strong prompt
Use a prompt shape like this for better accessibility usage:
- Identify the UI role and whether a native element should replace the current one.
- Describe the expected accessibility tree.
- List required label, role, state, value, and hint information.
- Define keyboard and focus behavior.
- Flag WCAG 2.2 AA risks.
- Return corrected code plus a short audit summary.
Example:
“Use the accessibility skill to review this custom dropdown on Web. First decide whether it should be a native select, button + listbox, or another pattern. Then provide the expected ARIA, keyboard interactions, focus movement, visible focus requirements, target size concerns, and revised code.”
Suggested workflow for audits and implementation
For accessibility for UX Audit, start at flow level, then drill into components:
- name the task and failure risk
- identify each interactive element’s true role
- check native semantic alternatives first
- verify labels, names, values, and states
- review keyboard order and focus visibility
- test screen reader announcements conceptually
- request remediated code or specs
If you are implementing rather than auditing, ask the skill for acceptance criteria you can hand to engineering and QA, not just prose advice.
accessibility skill FAQ
Is this accessibility skill good for beginners?
Yes, if you already know basic UI building. The skill explains the core accessibility ideas plainly, but it is not a full beginner course on WCAG. It is better as guided implementation support than as your only learning resource.
Is it enough for an accessibility install decision?
Mostly yes. The skill has a clear scope, a concrete workflow, and practical technical focus. The main limitation is packaging depth: there are no companion examples, test scripts, or platform-specific reference files. If you want extensive reusable assets, this feels lean; if you want fast guidance, it is easy to adopt.
How is it different from a generic accessibility prompt?
The difference is framing. This accessibility guide centers role identification, semantic mapping, accessibility tree thinking, labels, and focus management. Generic prompts often skip straight to ARIA attributes, which can lead to overengineering or wrong patterns.
When should I not use this skill?
Do not rely on this accessibility skill alone for legal sign-off, complex assistive technology compatibility testing, or highly specialized native platform edge cases. It is strongest for design and code reasoning, not as a substitute for manual testing with real devices, screen readers, and keyboard-only workflows.
How to Improve accessibility skill
Give richer UI context, not just code snippets
The biggest quality lever is context. Include the user task, whether the control changes state or navigates, what appears visually, and what currently breaks. Accessibility recommendations depend on behavior, not markup alone. A div can represent several patterns; the skill performs better when you define the intended interaction.
Ask for pattern selection before asking for ARIA
A common failure mode is forcing ARIA onto the wrong component. Improve accessibility output by asking: “What pattern is this actually?” For example, request a decision between native button, link, disclosure, tab, dialog, or listbox before remediation. This often prevents unnecessary custom widgets.
Request output in implementation-ready sections
For stronger accessibility usage, ask for a structured response:
- issue found
- user impact
- WCAG 2.2 concern
- recommended semantic pattern
- exact code change
- test steps
That format is better for handoff to engineering, QA, or design system owners than a single essay response.
Iterate with real failure evidence
After the first pass, improve the accessibility skill’s output by feeding back specifics: screen reader announcement text, keyboard traps, missing visible focus, or touch target measurements. The skill becomes much more valuable when you use it as an iteration loop for UX audit findings instead of a one-shot compliance check.