Skip to main content
Glama
Sign In
a11y-toolkit

a11y-toolkit

by kinti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

a11y-toolkit: Form error testing

a11y_forms
Destructive

Submits invalid data to test/staging forms and judges the post-submit DOM for WCAG 3.3.1/3.3.3 error identification, field association, and suggestions.

Instructions

Form error testing (3.3.1 Error Identification, 3.3.3 Error Suggestion) — the guided flow no competitor automates: fills every validatable field with INVALID data, really submits, and judges the post-submit DOM — are errors identified in text and associated with the field (aria-invalid + aria-describedby, error summary, role=alert), or does the form swallow them? Native browser validation counts as identification (unless the form has novalidate); forms that navigate on submit are honestly noted as not measurable in-page. Requires local Playwright. Returns JSON: per-field error judgments {field, submitted_value_class, error_identified, announced, suggestion_present} plus an overall 3.3.1/3.3.3 verdict. Use on test/staging forms, or forms you own: invalid data is REALLY submitted. Do not run against production forms that trigger real emails, orders or leads.

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_forms"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesPage URL with the form(s) to test
langNoOutput language (en default)
timeoutNoPage load timeout seconds (45 default)
auth_stateNoPath to a Playwright storage_state JSON to test forms behind login

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
-}
  2. Addedv4.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that invalid data is REALLY submitted (matching destructiveHint/openWorldHint), that local Playwright is required, what gets checked in the DOM (aria-invalid, aria-describedby, role=alert), and what is not measurable. The safety-critical warning about production forms is exactly the kind of context annotations alone cannot convey.

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?

Purpose is front-loaded in the first clause, followed by mechanism, requirements, return shape and the safety caveat. It is information-dense but somewhat long and parenthetical, trading some readability for thoroughness.

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 a complex, destructive, output-bearing tool with no output schema, the description covers the mechanism, the return JSON shape, the prerequisites (local Playwright), the edge cases and the safety constraint. Nothing an agent needs to invoke it safely and correctly is missing.

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 each parameter (url, lang, timeout, auth_state) is already documented in the schema. The description adds behavioral context rather than parameter-level detail — it implies forms behind login (auth_state) are supported but doesn't enrich the parameter syntax beyond the schema. Baseline 3 is appropriate.

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+resource: it fills validatable fields with invalid data, really submits, and judges the post-submit DOM for WCAG 3.3.1/3.3.3 error identification and suggestion. This is clearly distinguishable from sibling audit tools like a11y_audit_url or a11y_audit_dom because it is the only one that actively submits a form and reads the resulting DOM.

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

Usage Guidelines5/5

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

Gives explicit when-to-use (test/staging forms or forms you own) and when-not-to-use (do not run against production forms that trigger real emails, orders or leads). It also defines edge-case handling: native browser validation counts unless the form has novalidate, and forms that navigate on submit are honestly marked as not measurable in-page.

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

Deploy Server

Other Tools