Guide · Agent skill
How to use the ARIA Attribute Validator agent skill
Updated · written with AI from the project's own documentation and checked against our catalogue data
The aria-valid-attr skill is a set of instructions that teaches an AI agent to review HTML and interactive components for ARIA attributes that are misspelled, do not exist, or are not defined by the WAI-ARIA standard. This guide explains what the skill makes the agent do, how to install it, how to trigger it with plain requests, and what to watch for. By the end you will be able to add the skill to Claude and ask for a focused ARIA check of your markup.
Quick start
- 1Download the ZIP. Get the aria-valid-attr ZIP file from the source page on this site.
- 2Unzip into a skills folder. Unzip it into ~/.claude/skills/ for personal use, or into .claude/skills/ inside a project.
- 3Or upload in the Claude apps. If you use the Claude apps, upload the ZIP under Settings → Capabilities → Skills.
- 4Make a review request. Ask in plain words for an ARIA check of your HTML or component, and include the markup.
- 5Read the findings. Check each flagged attribute, role, or label the agent names against the WAI-ARIA standard.
- 6Verify the fix. Apply the corrected attribute names and confirm them with a browser accessibility tool.
What does the aria-valid-attr skill make the agent do?
ARIA attributes are the accessibility labels that browsers pass to screen readers. If an attribute is misspelled or not part of the WAI-ARIA standard, browsers and screen readers ignore it, and users who depend on assistive technology may not get the information the attribute was meant to provide.
When this skill is installed, the agent reviews rendered HTML and interactive components for those invalid attribute names. It checks native HTML semantics first, then looks at keyboard behaviour, focus flow, and accessible names, and explains how to verify fixes with browser accessibility tools.
- Flags misspelled aria-* attributes, such as aria-labeledby instead of aria-labelledby
- Flags non-existent aria-* attributes
- Checks that roles and states are standard-defined so screen readers can interpret them
- Explains how valid attributes communicate element state to users
How do you install the aria-valid-attr skill?
Download the ZIP file for the skill from the source page on this site. Then choose one of the two installation options below. Both put the skill's files in place so an agent can read them.
Option 1 is a personal install: unzip the download into ~/.claude/skills/ so the skill is available across your projects. Option 2 is a project install: unzip it into the .claude/skills/ folder inside a specific project so it is only available there.
If you use the Claude apps instead, you can upload the ZIP under Settings → Capabilities → Skills.
- Personal: unzip into ~/.claude/skills/
- Project: unzip into .claude/skills/ in your project folder
- Claude apps: upload the ZIP under Settings → Capabilities → Skills
What files does the skill contain?
The skill folder is small. SKILL.md holds the main instructions and the metadata that describes when the skill applies. It covers the check, the fix, the explanation, and the code review steps.
references/rule.md holds the fuller detail, including an HTML code example that shows a valid attribute, a misspelled one, and a non-existent one. The main file points to it for framework-specific guidance.
- SKILL.md: main instructions and description
- references/rule.md: examples and rationale
How do you trigger the skill with natural requests?
The skill's description tells the agent to use it when reviewing rendered HTML, interactive components, or design-system patterns for valid ARIA attributes. You do not need a special command. Ask for an accessibility review of your markup in plain words and mention ARIA or screen readers so the request matches the skill's purpose.
Include the markup or component in your request, or point the agent to the file. The more specific the request, the more useful the review.
- Check this component for invalid ARIA attributes.
- Review this HTML for misspelled aria-* attributes before we release.
- Look at this menu button and tell me if any ARIA attributes are wrong or not in the WAI-ARIA spec.
- Audit our design-system dropdown markup for valid ARIA usage.
<div aria-labeledby="header">...</div>What does an example review look like?
Given the markup above, a useful review points out that aria-labeledby is misspelled and should be aria-labelledby. The fix is to replace the attribute name with the standard one, then confirm the result with a browser accessibility tool.
The reference example also shows a non-existent attribute, aria-required-type, which does not exist in the WAI-ARIA standard. A correct button example uses aria-expanded and aria-controls, which are valid attributes.
- Misspelled: aria-labeledby, should be aria-labelledby
- Non-existent: aria-required-type
- Valid: aria-expanded and aria-controls on a button
<button aria-expanded="false" aria-controls="menu">
Menu
</button>What does the skill need, and is it safe to run?
The skill lists no required tools or prerequisites. It does not run scripts and does not use the network, so it only reads the material you give it and the files in the skill folder.
The skill guides review from markup only. It cannot run screen readers, so it does not replace testing with real assistive technology.
- Requirements: none listed
- Runs scripts: no
- Uses network: no
- Licence: MIT
What are the limits and tips for better results?
This is a checklist-style review guide, not an automated scanner. Results depend on the markup you share and the reviewing agent's reading of it. For repeatable checks in a build pipeline, a dedicated linter is more reliable.
For best results, share the rendered HTML rather than only source fragments, since the skill reviews rendered output. Ask for the exact element, role, label, and focus behaviour to be named, and then verify each fix in a browser accessibility tool.
- Share rendered HTML, not just fragments, when you can
- Ask the agent to name the exact element and attribute
- Verify each fix with browser accessibility tooling
- Use a linter such as axe or eslint-plugin-jsx-a11y for automated CI checks
What people use it for
- Catching a misspelled aria-labelledby before a component ships
- Reviewing a button or menu for valid aria-expanded and aria-controls usage
- Checking design-system patterns so teams use consistent, valid ARIA attributes
- Giving designers or QA staff a plain-language accessibility check of markup
Frequently asked questions
How do I install the aria-valid-attr skill?
Download the ZIP from the source page, then unzip it into ~/.claude/skills/ for personal use or into .claude/skills/ inside a project. In the Claude apps, you can upload the ZIP under Settings → Capabilities → Skills.
Does the aria-valid-attr skill require anything else to run?
The skill lists no requirements. It does not run scripts and does not use the network, so it only works from the files and the material you provide.
Is the aria-valid-attr skill free?
The skill is licensed under MIT. Check the licence file in the source repository for the full terms.
Can this skill replace an automated accessibility linter?
No. It is a checklist-style review guide, not an automated scanner. For repeatable checks in CI, a dedicated linter such as axe or eslint-plugin-jsx-a11y is more reliable.
Does the skill test with screen readers?
No. It guides review from the markup and cannot run screen readers, so it does not replace testing with real assistive technology.
What is the difference between aria-labelledby and aria-labeledby?
aria-labelledby is the correct WAI-ARIA attribute. aria-labeledby is a misspelling, and browsers ignore it, so the element may not get the accessible name you intended.
New agent skills, repos and AI tools — every week
The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.
Our verdict
Use this skill if you want an AI agent to give a plain-language, checklist-style review of ARIA attribute names and usage in your markup before release. Pick a dedicated linter such as axe or eslint-plugin-jsx-a11y if you need automated, repeatable checks in CI, and use real assistive technology for a full accessibility audit.
Download the skill