Skip to main content
Glama

a11y-toolkit: Rendered WCAG audit

a11y_audit_dom
Read-onlyIdempotent

Run a deep rendered WCAG 2.2 audit on JavaScript-heavy pages with local Playwright/Chromium, checking computed contrast, target size, focus indicators, and static accessibility issues.

Instructions

Deep RENDERED WCAG audit via local Playwright/Chromium: real computed text contrast against effective backgrounds with alpha compositing (1.4.3), pixel-sampled measurement of text over images/gradients (background captured with the text transparent), minimum target size 24×24 (2.5.8, new in WCAG 2.2), visible focus indicator heuristic (2.4.7), plus rendered versions of the static checks (alt, accessible names, labels, headings, lang/title, tabindex, aria-hidden, captions, tables). Findings include remediation. Requires playwright: pip install playwright && playwright install chromium. — Use instead of a11y_audit_url on JS-heavy pages; needs local Playwright. Returns JSON: {mode, url, score 0-100, findings [{criterion, severity, signal, issue, remediation}], summary, score_note} — same shape as the static audit.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "a11y_audit_dom"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesPage URL to load in Chromium (http/https or file:// for local fixtures)
langNoOutput language for findings and remediation (default en)
targetNoEN 301 549 target: web=9.x clauses (default), documents=10.x, software=11.x
browserNoBrowser engine (auto = detect the first available)
timeoutNopage load timeout seconds (45 default)
standardNoadd the EN 301 549 V4.1.1 (2026) clause to every finding plus a standard block
auth_stateNoPath to a Playwright storage_state JSON (exported session) to audit behind login — local file, never uploaded
color_schemeNoEmulate prefers-color-scheme: run the contrast pass in dark mode too — dark themes fail where light passes (nobody audits both)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv5.27.0
    • addedInput schema / properties / standard
      Added value: +{
      +  "description": "add the EN 301 549 V4.1.1 (2026) clause to every finding plus a standard block",
      +  "enum": [
      +    "en301549"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / target
      Added value: +{
      +  "description": "EN 301 549 target: web=9.x clauses (default), documents=10.x, software=11.x",
      +  "enum": [
      +    "web",
      +    "documents",
      +    "software"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changedv5.8.0
    • addedInput schema / properties / color_scheme
      Added value: +{
      +  "description": "Emulate prefers-color-scheme: run the contrast pass in dark mode too — dark themes fail where light passes (nobody audits both)",
      +  "enum": [
      +    "light",
      +    "dark"
      +  ],
      +  "type": "string"
      +}
  3. Changed1 schema field changedv5.6.0
    • removedInput schema / browser
      Removed value: -{
      -  "description": "Browser engine (auto = detect the first available)",
      -  "enum": [
      -    "auto",
      -    "chromium",
      -    "firefox",
      -    "webkit",
      -    "chrome",
      -    "msedge"
      -  ],
      -  "type": "string"
      -}
  4. Changed1 schema field changedv5.5.0
    • addedInput schema / properties / browser
      Added value: +{
      +  "description": "Browser engine (auto = detect the first available)",
      +  "enum": [
      +    "auto",
      +    "chromium",
      +    "firefox",
      +    "webkit",
      +    "chrome",
      +    "msedge"
      +  ],
      +  "type": "string"
      +}
  5. Changed4 schema fields changedv4.0.0
    • addedInput schema / browser
      Added value: +{
      +  "description": "Browser engine (auto = detect the first available)",
      +  "enum": [
      +    "auto",
      +    "chromium",
      +    "firefox",
      +    "webkit",
      +    "chrome",
      +    "msedge"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / auth_state
      Added value: +{
      +  "description": "Path to a Playwright storage_state JSON (exported session) to audit behind login — local file, never uploaded",
      +  "type": "string"
      +}
    • addedInput schema / properties / lang / description
      Added value: +"Output language for findings and remediation (default en)"
    • addedInput schema / properties / url / description
      Added value: +"Page URL to load in Chromium (http/https or file:// for local fixtures)"
  6. Addedv3.3.0

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds real context beyond them: the local Playwright + Chromium dependency with install commands, that auth_state is a local file that is never uploaded, and that the contrast pass can be run in dark mode. It also discloses the return shape (mode, url, score, findings with criterion/severity/signal/issue/remediation, summary) despite having no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then checks, then prerequisite, then alternative, then return shape — a sensible information hierarchy with no filler sentences. It is dense with nested parentheses and criterion numbers, which slightly slows parsing but every clause carries substantive information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an eight-parameter, dependency-bearing audit tool with no output schema, the description covers purpose, check scope, install prerequisite, privacy of auth_state, sibling routing, and the exact response shape. An agent has everything needed to decide to call it and to interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all eight parameters (including enums for lang, target, browser, standard, color_scheme) are already documented in structured form. The description explains the measurement methodology behind contrast and target size, but adds no parameter-level meaning beyond the schema and does not touch timeout, browser, target, or lang semantics. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Deep RENDERED WCAG audit') and enumerates exactly which checks are performed (1.4.3 contrast with alpha compositing, 2.5.8 target size, 2.4.7 focus, plus rendered static checks). It explicitly contrasts itself with the sibling a11y_audit_url, so an agent can distinguish the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternative and the selecting condition: 'Use instead of a11y_audit_url on JS-heavy pages; needs local Playwright.' That is a clear routing rule with a stated prerequisite. It stops short of stating the inverse case (static pages, or environments without Playwright, should use a11y_audit_url), so the exclusion is only half-covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.