agency-accessibility-auditor

Audits web interfaces against WCAG 2.2 criteria using automated scans and assistive technology testing.

Updated Jul 27, 2026
One-click install
npx skills add https://github.com/imMamdouhaboammar/Mimera --skill agency-accessibility-auditor-immamdouhaboammar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: agency-accessibility-auditor
Source: https://github.com/imMamdouhaboammar/Mimera/tree/main/.agents/skills/testing-accessibility-auditor
Command: npx skills add https://github.com/imMamdouhaboammar/Mimera --skill agency-accessibility-auditor-immamdouhaboammar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Interfaces often pass automated accessibility scans while remaining unusable for screen reader and keyboard-only users, leaving teams unaware of the roughly 70% of barriers that automation cannot detect. ## Core Features & Use Cases - WCAG 2.2 Auditing: Evaluates interfaces against all four POUR principles with specific success criterion references and severity classifications from Critical to Minor. - Assistive Technology Testing: Verifies screen reader compatibility (VoiceOver, NVDA, JAWS), keyboard-only navigation, zoom at 200%/400%, and reduced motion or high contrast modes. - Actionable Remediation Reports: Produces structured audit reports with evidence, code-level fixes, and prioritized remediation plans. - Use Case: Before launching a new checkout flow, run a full audit to catch a keyboard trap in the date picker and missing form labels, then receive concrete ARIA and semantic HTML fixes with WCAG criterion references. ## Quick Start Audit this page for WCAG 2.2 AA conformance, including keyboard navigation and screen reader testing, and report every issue with severity and fixes.

Frequently Asked Questions about agency-accessibility-auditor

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

FAQPage Schema
How do I audit a website for WCAG 2.2 accessibility compliance?

Run automated scans with axe-core and Lighthouse first, then manually test with a screen reader and keyboard-only navigation. Document each issue with its WCAG criterion number, severity, and a concrete code fix.

What accessibility issues do automated tools like axe-core miss?

Automated tools catch roughly 30% of issues. They miss focus order problems, illogical reading order, ARIA misuse in custom components, unannounced dynamic content, and cognitive barriers like unclear error recovery.

Does a high Lighthouse accessibility score mean my site is accessible?

No. A green Lighthouse score only reflects automated checks and does not verify screen reader behavior, keyboard traps, or focus management. Manual assistive technology testing is required for genuine conformance.

How do I test keyboard navigation for custom components like modals and tabs?

Verify Tab reaches all interactive elements, Escape closes modals and returns focus to the trigger, and arrow keys move within tab lists and menus. Check against WAI-ARIA Authoring Practices patterns for each widget.

When should accessibility testing happen in the development process?

Accessibility should be checked at every phase, not just before launch. Integrate axe-core into CI/CD pipelines, add accessibility acceptance criteria to user stories, and audit component libraries before implementation.