agentleFS
mejbaurbaharmejbaurbahar/fagun/skills/accessibility-testing/SKILL.md

accessibility-testing

Skill1 starsChanged 4 months agoMITView on GitHub

Use when auditing a web app for accessibility (a11y) — WCAG compliance, screen reader compatibility, keyboard navigation, color contrast, and semantic HTML/ARIA correctness.

9 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use compliance-testing, analytics-tracking-testing and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • petrkindlmannSkill

    compliance-testing

    Test for regulatory compliance: GDPR/CMP consent verification, Google Consent Mode v2, Global Privacy Control (GPC), CCPA/US state opt-out, EU AI Act Article 50 transparency, Better Ads Standards, and cookie-inventory auditing. Covers automated consent-flow testing, policy-based script blocking before consent, and cookie drift detection. Use when: "GDPR test," "compliance," "CMP test," "cookie consent," "consent mode," "CCPA," "GPC," "AI Act," "Better Ads," "privacy banner." Not for: WCAG/axe-core test authoring — use accessibility-testing. Not for: OWASP/vuln scanning — use security-testing. Not for: evaluating your LLM feature's quality or safety — use ai-system-testing. Related: accessibility-testing, security-testing, ai-system-testing, ci-cd-integration.

    Also in 4 projects that use this

  • petrkindlmannSkill

    analytics-tracking-testing

    Validate that analytics and marketing tracking fire CORRECTLY: GA4/GTM dataLayer events, Meta/TikTok/LinkedIn pixels, and ad-tech tags. Covers building a tracking plan as the contract, intercepting collect-endpoint beacons and dataLayer.push in Playwright, asserting event name + params + values + timing + de-duplication, Consent Mode v2 gating, CI regression gating, and news-media events (article-view, scroll-depth, paywall). Use when: "test analytics tracking," "GA4 event test," "verify the pixel fires," "dataLayer test," "tracking plan," "Meta Pixel dedup," "scroll-depth tracking test," "gate tracking in CI." Not for: whether tracking is ALLOWED to fire under consent law (GDPR/CMP) — that is compliance-testing; this skill checks the data is CORRECT. SEO meta tags / structured data — out of scope. Related: compliance-testing, playwright-automation, api-testing, qa-project-context.

    Also in 3 projects that use this

  • testified-ossSkill

    exploratory-testing

    Guide exploratory testing sessions including charter creation, session-based testing, heuristics application, and finding documentation. Use when planning exploratory testing, conducting test sessions, or documenting discoveries.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Forms: every input has a programmatically associated <label>, required fields are announced as required (not just visually marked with an …

    line 20

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Accessibility Testing

Baseline: WCAG 2.1/2.2 AA

Most legal/compliance requirements target AA. Structure the audit around the four POUR principles:

  • Perceivable — alt text on images, captions on video, sufficient color contrast, content not conveyed by color alone.
  • Operable — full keyboard operability, no keyboard traps, visible focus indicators, skip-to-content link, no seizure-inducing flashing.
  • Understandable — clear labels, consistent navigation, error messages that say how to fix the problem (not just "invalid input").
  • Robust — valid semantic HTML, correct ARIA usage (or none — wrong ARIA is worse than no ARIA), works across assistive tech.

Practical audit pass

  1. Automated scan first (fast, catches ~30-40% of issues): axe-core via browser extension, or Lighthouse's accessibility category (lighthouse_audit in Chrome DevTools MCP covers this).
  2. Keyboard-only pass: unplug the mouse mentally — Tab through the entire page. Every interactive element must be reachable, in a logical order, with a visible focus ring. Modals must trap focus while open and return it on close. Nothing should require a mouse-only gesture (hover-only menus, drag-and-drop with no keyboard alternative).
  3. Screen reader spot-check: VoiceOver on macOS (Cmd+F5) for at least the primary flow — does it announce meaningful labels, form errors, and dynamic content changes (aria-live regions)? Icon-only buttons must have accessible names.
  4. Color contrast: 4.5:1 for normal text, 3:1 for large text/UI components (AA). Check via browser DevTools contrast checker, not eyeballing.
  5. Forms: every input has a programmatically associated <label>, required fields are announced as required (not just visually marked with an asterisk), errors are associated with their field via aria-describedby.
  6. Zoom/reflow: page usable at 200% browser zoom without horizontal scroll or clipped content.

Common real bugs to specifically hunt for

  • <div onclick> instead of <button> — not keyboard-focusable, no accessible role.
  • Images with alt="" on content images (decorative-only pattern misapplied) vs. missing alt entirely on meaningful images.
  • Custom dropdowns/modals built without ARIA roles/states (role="dialog", aria-modal, aria-expanded) — screen readers can't tell they exist.
  • Placeholder text used as the only label — disappears on focus, not a real label.
  • Low-contrast disabled-looking buttons that are actually clickable, or vice versa.

Reporting

File via [[bug-reporting]], citing the specific WCAG success criterion violated (e.g. "1.4.3 Contrast (Minimum)") — this makes severity/priority unambiguous and ties directly to compliance requirements when they apply.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.