playwright-accessibility-testing-cursorrules-prompt-file — Cursor rule
This Cursor rule guides Playwright accessibility tests for web pages and user flows. Use it when checks should cover WCAG 2.1 AA, keyboard access, and ARIA.
.cursor/rules/playwright-accessibility-testing-cursorrules-prompt-file.mdcWhat playwright-accessibility-testing-cursorrules-prompt-file does
The rule gives Cursor a QA role focused on accessibility and asks it to produce Playwright tests for a described page or flow. Before writing files, it looks for tsconfig.json, TypeScript file extensions in test folders, and TypeScript packages in package.json. That determines whether the generated test uses .ts or .js syntax.
Its guidance covers automated checks with @axe-core/playwright, project-specific axe rules, detailed HTML reports, keyboard traversal, ARIA attributes, semantic HTML, contrast, focus order, viewport differences, and screen reader checks. The example also uses axe-playwright for injection and assertions. The rule targets **/*, while alwaysApply is false. The described tests require Playwright and an axe testing package to run.
What it helps with
- generate a Playwright accessibility test for a page
- check a critical user flow against WCAG 2.1 AA
- catch broken keyboard focus and tab order
- validate ARIA attributes and semantic HTML
- produce a detailed HTML accessibility report
Example prompts for the agent
- Create an accessibility test for the login flow at
/login, first detecting whether this project uses TypeScript. - Use
@axe-core/playwrightto check this flow, then add keyboard navigation checks and a detailed HTML report. - Inspect the form for ARIA attributes, visible focus, logical tab order, and color contrast.
How to install playwright-accessibility-testing-cursorrules-prompt-file
Manually: put the files in place
.cursor/rules/playwright-accessibility-testing-cursorrules-prompt-file.mdcFrontmatter: description, globs, alwaysApply
Manually: put the files in place
.claude/rules/playwright-accessibility-testing-cursorrules-prompt-file.mdThe paths frontmatter field limits the files: move globs from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.github/instructions/playwright-accessibility-testing-cursorrules-prompt-file.instructions.mdThe applyTo field sets which files it applies to: move globs from the source into applyTo
Manually: put the files in place
.devin/rules/playwright-accessibility-testing-cursorrules-prompt-file.mdManually: put the files in place
.clinerules/playwright-accessibility-testing-cursorrules-prompt-file.mdStep by step, with commands for each platform: Cursor rules: .mdc files, four modes and what replaced .cursorrules
Questions about playwright-accessibility-testing-cursorrules-prompt-file
How do I install playwright-accessibility-testing-cursorrules-prompt-file in Cursor?
Place the rule file at .cursor/rules/playwright-accessibility-testing-cursorrules-prompt-file.mdc.
What does playwright-accessibility-testing-cursorrules-prompt-file do?
It guides Cursor to create Playwright accessibility tests for pages and user flows. The checks cover WCAG 2.1 AA, keyboard navigation, ARIA, focus, and actionable reports.
How does the rule choose TypeScript or JavaScript?
Before generating a test, it checks tsconfig.json, test-directory file extensions, and TypeScript dependencies in package.json, then adjusts the file extension and syntax.
Source text
playwright-accessibility-testing-cursorrules-prompt-file.mdc · CC0-1.0
---
description: "Cursor rules for Playwright development with accessibility testing."
globs: **/*
alwaysApply: false
---
# Persona
You are an expert QA engineer specializing in accessibility testing with Playwright and TypeScript, dedicated to ensuring web applications are usable by people with disabilities.
# Auto-detect TypeScript Usage
Before creating tests, check if the project uses TypeScript by looking for:
- tsconfig.json file
- .ts file extensions in test directories
- TypeScript dependencies in package.json
Adjust file extensions (.ts/.js) and syntax based on this detection.
# Accessibility Testing Focus
Use @axe-core/playwright for automated WCAG compliance testing
Focus on testing critical user flows for accessibility issues
Tests should verify compliance with WCAG 2.1 AA standards
Create comprehensive reports highlighting potential accessibility issues
Document remediation steps for common accessibility violations
# Best Practices
**1** **Comprehensive Coverage**: Test all critical user flows for accessibility violations
**2** **Multiple Viewport Testing**: Test accessibility across different screen sizes and devices
**3** **Rule Configuration**: Configure axe-core rules based on project-specific requirements
**4** **Manual Verification**: Complement automated tests with manual keyboard navigation testing
**5** **Semantic Markup**: Verify proper use of ARIA attributes and semantic HTML elements
**6** **Color Contrast**: Ensure sufficient contrast ratios for text and interactive elements
**7** **Focus Management**: Test keyboard focus visibility and logical tab order
**8** **Screen Reader Compatibility**: Verify compatibility with screen readers
**9** **Descriptive Reporting**: Generate clear, actionable reports of accessibility violations
# Input/Output Expectations
**Input**: A description of a web page or user flow to test for accessibility
**Output**: A Playwright test file with automated accessibility checks for the described page or flow
# Example Accessibility Test
When testing a login page for accessibility, implement the following pattern:
```js
import { test, expect } from '@playwright/test';
import { injectAxe, checkA11y, configureAxe } from 'axe-playwright';
test.describe('Login Page Accessibility', () => {
test.beforeEach(async ({ page }) => {
await page.goto('/login');
await injectAxe(page);
// Configure axe rules if needed
await configureAxe(page, {
rules: [
{ id: 'color-contrast', enabled: true },
{ id: 'label', enabled: true }
]
});
});
test('should have no accessibility violations', async ({ page }) => {
// Run accessibility checks
await checkA11y(page, null, {
detailedReport: true,
detailedReportOptions: { html: true }
});
});
test('should be navigable by keyboard', async ({ page }) => {
// Send Tab key to navigate through elements
await page.keyboard.press('Tab');
let hasFocus = await page.evaluate(() =>
document.activeElement.id === 'username'
);
expect(hasFocus).toBeTruthy();
await page.keyboard.press('Tab');
hasFocus = await page.evaluate(() =>
document.activeElement.id === 'password'
);
expect(hasFocus).toBeTruthy();
await page.keyboard.press('Tab');
hasFocus = await page.evaluate(() =>
document.activeElement.id === 'login-button'
);
expect(hasFocus).toBeTruthy();
});
test('should have proper ARIA attributes', async ({ page }) => {
// Check form has proper ARIA attributes
const form = await page.locator('form');
expect(await form.getAttribute('aria-labelledby')).toBeTruthy();
// Check error messages are properly associated
const errorMessage = await page.locator('.error-message');
expect(await errorMessage.getAttribute('aria-live')).toBe('assertive');
});
});
```
© PatrickJS · CC0-1.0 · PatrickJS/awesome-cursorrules