.agents/skills/axe-core/SKILL.md
axe-core - accessibility testing engine for automated WCAG compliance checks. USE WHEN: user mentions "axe", "automated accessibility testing", "a11y tests", asks about "integrating accessibility checks", "CI/CD accessibility", "Playwright accessibility", "Jest accessibility", "Vitest axe" DO NOT USE FOR: manual accessibility audits - use `wcag` skill instead
npx skillsauth add d-subrahmanyam/deno-fresh-microservices axe-coreInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
wcag skill for understanding guidelines and manual testingwcag skill for ARIA authoring practicesDeep Knowledge: Use
mcp__documentation__fetch_docswith technology:axe-corefor comprehensive documentation on rules, configuration, and integrations.
npm install -D @axe-core/react # For React
npm install -D axe-core # Core library
import React from 'react';
import ReactDOM from 'react-dom/client';
if (process.env.NODE_ENV !== 'production') {
import('@axe-core/react').then(axe => {
axe.default(React, ReactDOM, 1000);
});
}
import { axe, toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);
test('should have no accessibility violations', async () => {
const { container } = render(<MyComponent />);
const results = await axe(container);
expect(results).toHaveNoViolations();
});
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
test('should not have accessibility issues', async ({ page }) => {
await page.goto('/');
const accessibilityScanResults = await new AxeBuilder({ page }).analyze();
expect(accessibilityScanResults.violations).toEqual([]);
});
// With specific rules
test('should pass WCAG AA', async ({ page }) => {
await page.goto('/');
const results = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa'])
.analyze();
expect(results.violations).toEqual([]);
});
// cypress/support/commands.ts
import 'cypress-axe';
// In test
describe('Accessibility', () => {
it('has no violations', () => {
cy.visit('/');
cy.injectAxe();
cy.checkA11y();
});
});
import axe from 'axe-core';
async function checkAccessibility() {
const results = await axe.run();
if (results.violations.length > 0) {
console.log('Violations:', results.violations);
}
}
| Anti-Pattern | Why It's Wrong | Correct Approach |
|-------------|----------------|------------------|
| Running axe on empty/loading states | Tests incomplete DOM, false negatives | Wait for content to load before running axe |
| Ignoring all violations | Defeats purpose of automated testing | Fix violations or document exceptions with reasoning |
| Testing only homepage | Most accessibility issues in complex interactions | Test all critical user flows and components |
| Not configuring WCAG level | Tests against all rules, may be too strict | Set withTags(['wcag2a', 'wcag2aa']) for target level |
| Running axe synchronously in loops | Slow test execution | Use Promise.all() for parallel execution |
| Committing violations to CI | Prevents catching regressions | Fail builds on new violations |
| Testing hidden/inactive components | Axe tests invisible elements unnecessarily | Use exclude parameter for hidden sections |
| No baseline for legacy code | All violations block progress | Create baseline, track improvements incrementally |
| Issue | Diagnosis | Solution |
|-------|-----------|----------|
| axe finds no violations but page is inaccessible | Automated tools catch only ~30-40% of issues | Supplement with manual keyboard and screen reader testing |
| "No violations" but form has issues | axe doesn't test form logic/flow | Test form submission, error handling manually |
| Timeout in Playwright axe tests | Large/complex page takes too long | Increase timeout or analyze specific regions |
| False positive on custom component | axe rule doesn't understand pattern | Use disableRules or add proper ARIA to fix |
| Violations in third-party widgets | Can't modify external code | Document exceptions, contact vendor, or replace widget |
| Different results in different browsers | Browser-specific rendering differences | Run axe in multiple browsers, use cross-browser test suite |
| CI fails but local passes | Environment differences (timing, content) | Ensure consistent test data and wait conditions |
| Too many violations to fix at once | Legacy codebase with extensive issues | Create baseline, use --save flag to track improvements |
development
Guidelines for building high-performance APIs with Fastify and TypeScript, covering validation, Prisma integration, and testing best practices
development
FastAPI modern Python web framework. Covers routing, Pydantic models, dependency injection, and async support. Use when building Python APIs. USE WHEN: user mentions "fastapi", "pydantic", "async python api", "python rest api", asks about "dependency injection python", "python openapi", "python swagger", "async endpoints", "python api validation", "fastapi middleware" DO NOT USE FOR: Django apps - use `django` instead, Flask apps - use `flask` instead, synchronous Python APIs without type hints, GraphQL-only APIs
tools
FastAPI integration testing specialist. Covers synchronous TestClient, async httpx AsyncClient, dependency injection overrides, auth testing (JWT, OAuth2, API keys), WebSocket testing, file uploads, background tasks, middleware testing, and HTTP mocking with respx, responses, and pytest-httpserver. USE WHEN: user mentions "FastAPI test", "TestClient", "httpx async test", "dependency override test", "respx mock", asks about testing FastAPI endpoints, authentication in tests, or HTTP client mocking. DO NOT USE FOR: Django - use `pytest-django`; pytest internals - use `pytest`; Container infrastructure - use `testcontainers-python`
development
Expert in FastAPI Python development with best practices for APIs and async operations