Verify that accessibility fixes resolve identified issues by re-running tests and checking against acceptance criteria. Use this skill after fixes have been generated to confirm they work correctly. Uses a11y-tester for runtime re-testing and magentaa11y-mcp for acceptance criteria verification. Part of the a11y-orchestrator workflow.
Installation
Details
Usage
After installing, this skill will be available to your AI coding assistant.
Verify installation:
npx agent-skills-cli listSkill Instructions
name: a11y-validator description: Verify that accessibility fixes resolve identified issues by re-running tests and checking against acceptance criteria. Use this skill after fixes have been generated to confirm they work correctly. Uses a11y-tester for runtime re-testing and magentaa11y-mcp for acceptance criteria verification. Part of the a11y-orchestrator workflow.
Accessibility Validator
Confirms that generated fixes resolve accessibility issues.
Validation Workflow
- Apply fixes to the code
- Re-run tests to check if issues are resolved
- Check acceptance criteria — query
magentaa11y-mcp:get_web_component("button")→ Returns acceptance criteriaget_component_gherkin("button")→ Returns Gherkin test syntax
- Categorize results as fixed, needs-manual, or still-failing
Re-Testing Process
For Runtime Issues (from a11y-tester)
Re-run the a11y-tester skill on the modified code:
- Serve or load the updated HTML
- Execute axe-core scan
- Compare violations to original list
- Mark resolved issues as fixed
Issue is fixed when:
- axe-core no longer reports the violation
- The specific element/selector passes
For Static Issues (from web-standards)
Re-apply the web-standards skill analysis:
- Parse the updated code
- Run the same checks that found the issue
- Verify the problematic pattern is resolved
Issue is fixed when:
- The anti-pattern is no longer present
- Proper semantic/ARIA structure exists
Acceptance Criteria Verification
Query magentaa11y-mcp for component acceptance criteria:
get_web_component("button")→ Returns full acceptance criteriaget_component_gherkin("button")→ Returns Gherkin test syntaxget_component_developer_notes("button")→ Returns implementation notes
For each fix, verify it meets the documented acceptance criteria:
Example: Button Fix Validation
From magentaa11y-mcp button criteria, verify:
- Has accessible name (visible text or aria-label)
- Role is "button" (native or ARIA)
- Keyboard operable (Enter/Space activates)
- Focus visible when focused
- State communicated if applicable (pressed, expanded)
Example: Form Input Fix Validation
From magentaa11y-mcp text-input criteria, verify:
- Label programmatically associated
- Required state communicated
- Error messages associated via aria-describedby
- Input purpose identifiable
Example: Link Fix Validation
From magentaa11y-mcp link criteria, verify:
- Has accessible name
- Role is "link"
- Keyboard operable (Enter activates)
- Purpose clear from link text or context
Result Categories
✅ Fixed
Issue confirmed resolved:
- Automated test passes
- Acceptance criteria met
- No regression introduced
### Issue #N: [Description]
**Status:** ✅ Fixed
**Verification:** axe-core passes / static check passes
**Criteria Met:** [List from magentaa11y-mcp]
⚠️ Needs Manual Review
Cannot automatically verify:
- Visual verification required (contrast, focus style)
- Content quality check needed (alt text appropriateness)
- Complex interaction testing required
- User judgment needed
### Issue #N: [Description]
**Status:** ⚠️ Needs Manual Review
**Reason:** [Why automated verification isn't possible]
**Manual Check:** [What human should verify]
**Guidance:** Query magentaa11y-mcp for component pattern
❌ Still Failing
Fix did not resolve the issue:
- Automated test still fails
- Pattern still detected
- Different approach needed
### Issue #N: [Description]
**Status:** ❌ Still Failing
**Reason:** [Why fix didn't work]
**Suggestion:** [Alternative approach to try]
Validation Checklist by Issue Type
Accessible Name Issues
- Element now has accessible name
- Name is meaningful and descriptive
- Name matches visible label (if applicable)
Semantic Structure Issues
- Correct HTML element used
- No redundant ARIA
- Proper nesting maintained
Keyboard Issues
- Element is focusable
- Expected keys work (Enter, Space, Escape, Arrows)
- Focus order logical
- Focus visible
Form Issues
- All inputs labeled
- Errors associated with inputs
- Required fields indicated
- Instructions associated
Landmark Issues
- Required landmarks present
- No duplicate main landmarks
- Landmarks properly labeled if multiple
Image Issues
- Alt attribute present
- Alt content appropriate (descriptive or empty)
- Decorative images marked correctly
Evidence Expectations (Make Validation Actionable)
For each “✅ Fixed” issue, include at least one of:
- The before/after axe rule status (rule id + instance count)
- The selector / snippet that was previously failing and now passes
- Any manual verification note required for final confidence (e.g., focus visibility, reflow)
Output Format
## Validation Results
**Total Issues:** X
**Fixed:** Y
**Needs Manual Review:** Z
**Still Failing:** W
### Fixed Issues
| Issue | Description | Verification Method |
|-------|-------------|---------------------|
| #1 | Missing button name | axe-core: button-name passes |
| #2 | Skipped heading | Static: h1→h2→h3 present |
### Needs Manual Review
| Issue | Description | Manual Check Required |
|-------|-------------|-----------------------|
| #3 | Image alt text | Verify alt describes image content |
| #4 | Focus visibility | Verify focus ring meets 3:1 contrast |
### Still Failing
| Issue | Description | Reason | Next Step |
|-------|-------------|--------|-----------|
| #5 | Complex table | Headers not properly associated | Review table structure |
Regression Checks
After validation, verify no new issues introduced:
- Run full axe-core scan on modified code
- Compare total violation count
- Flag any new issues not in original list
WCAG 2.2-Focused Regression Checks (Often Manual)
Even if axe-core is clean, explicitly verify or flag for manual review:
- Focus Not Obscured (Minimum) (2.4.11 AA): focused control remains visible with sticky headers/footers, banners, dialogs
- Dragging Movements (2.5.7 AA): drag-and-drop has an alternative (keyboard/buttons)
- Target Size (Minimum) (2.5.8 AA): small icon buttons/controls meet 24×24 CSS px or have an equivalent exception rationale
- Accessible Authentication (Minimum) (3.3.8 AA): login supports password managers; no cognition-only “puzzles” without alternatives
## Regression Check
**New Issues Found:** X
| New Issue | Description | Introduced By |
|-----------|-------------|---------------|
| ... | ... | Fix for Issue #N |
Quick Reference
| Validation Type | Tool/Resource | Pass Criteria |
|---|---|---|
| axe violations | a11y-tester skill | Violation no longer reported |
| Static patterns | web-standards skill | Anti-pattern removed |
| Acceptance criteria | magentaa11y-mcp | All criteria checked |
| Visual checks | Manual | Human verification |
More by joe-watkins
View allFormat accessibility violations into standardized, JIRA-ready issue reports using the accessibility-issues-template-mcp. Use this skill when users want to write accessibility issues, format axe-core violations as tickets, create accessibility bug reports, generate issue templates from test results, or convert violations to standardized formats. Triggers on requests like "write issues for these violations", "format as JIRA tickets", "create accessibility bug reports", or "generate issue from axe results".
Foundational accessibility patterns and requirements for AI-generated web code. This skill provides baseline rules for semantic HTML, ARIA usage, keyboard navigation, contrast, and inclusive language. Load this skill first before any accessibility analysis, remediation, or validation work. Other a11y skills (web-standards, a11y-remediator, a11y-validator, a11y-tester) build upon these fundamentals.
Generate accessibility fixes for identified issues using MCP servers for component patterns (magentaa11y-mcp), ARIA guidance (aria-mcp), WCAG criteria (wcag-mcp), and user impact (a11y-personas-mcp). Use this skill when you have a list of accessibility issues and need to produce corrected code with full context. Part of the a11y-orchestrator workflow.
Static HTML/CSS/ARIA analysis without requiring a browser. Use this skill when analyzing code for semantic HTML issues, ARIA validity, landmark structure, heading hierarchy, form labeling, or any accessibility problems detectable from source code. Queries aria-mcp for ARIA rules and wcag-mcp for success criteria mapping. Part of the a11y-orchestrator workflow.
