web-accessibility-auditor

Audit and implement WCAG 2.2 AA accessibility in HTML and UI components.

Updated Apr 13, 2026
One-click install
npx skills add https://github.com/JenilRevaliya/ARGUS --skill web-accessibility-auditor-jenilrevaliya
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: web-accessibility-auditor
Source: https://github.com/JenilRevaliya/ARGUS/tree/main/.agent/skills/web-accessibility-auditor
Command: npx skills add https://github.com/JenilRevaliya/ARGUS --skill web-accessibility-auditor-jenilrevaliya

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Frontend code often ships with accessibility defects—div-based buttons, missing form labels, broken keyboard navigation, and silent dynamic updates—that exclude screen reader and keyboard users and fail WCAG 2.2 AA compliance. ## Core Features & Use Cases - Semantic HTML Enforcement: Replaces div-soup markup with native elements like <button>, <nav>, and <dialog> that carry built-in keyboard and screen reader support. - ARIA & Focus Management: Applies correct ARIA states (aria-expanded, aria-invalid, aria-hidden), focus trapping in modals, and :focus-visible styling for keyboard users. - Forms & Live Regions: Ensures every input has an associated label, errors are announced via role="alert", and dynamic content updates use aria-live regions. - Use Case: When building a custom accordion or auditing a React component, use this Skill to verify keyboard operability, screen reader announcements, and WCAG 2.2 AA conformance before shipping. ## Quick Start Audit my login form component for WCAG accessibility issues and fix any keyboard navigation or label problems.

Frequently Asked Questions about web-accessibility-auditor

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make a custom modal accessible to screen readers?▼

Use the native `<dialog>` element with `showModal()`, which handles focus trapping automatically. Move focus into the modal on open, hide the background with `aria-hidden="true"`, support the Escape key, and return focus to the triggering button on close.

How to fix keyboard navigation accessibility in HTML?▼

Use native interactive elements like `<button>` and `<a>` instead of clickable divs, since they include built-in focus and Enter/Space key behavior. Never remove focus outlines globally; use `:focus-visible` to show outlines only for keyboard users.

When should I use ARIA attributes versus native HTML?▼

Prefer native HTML elements first, since they carry built-in semantics and keyboard support. Add ARIA only for custom widgets like accordions or tabs, using states such as `aria-expanded`, `aria-pressed`, and `aria-invalid` to communicate behavior to screen readers.

Does a placeholder attribute count as an accessible form label?▼

No, placeholder is not a label because it disappears when the user types, causing cognitive loss. Every input needs an associated `<label>` linked via `for`/`id` or implicit wrapping, with errors announced using `aria-describedby` and `role="alert"`.

Why are my dynamic content updates not announced by screen readers?▼

Content injected without a page reload is invisible to screen readers unless it uses a live region. Add `aria-live="polite"` for non-urgent updates like result counts, or `role="alert"` for errors that must interrupt the user immediately.