a11y-toolkit

Overview Schema Source Related Servers Discussions Admin

a11y-toolkit: Accessibility statement (EAA/RD 1112)

a11y_generate_declaration

DestructiveIdempotent

Generate an accessible HTML accessibility statement for Spanish RD 1112/2018 or the European Accessibility Act, covering conformance status, feedback, complaints, and non-accessible content.

Instructions

Generates an Accessibility Statement in HTML: art. 10 RD 1112/2018 (Spanish public sector, framework="rd1112") or European Accessibility Act wording (Directive (EU) 2019/882 / Ley 11/2023, framework="eaa"; EN output uses Directive (EU) 2016/2102 / EAA wording). The generated document is itself accessible. Saves to output_path when given. — Legal statement generator; drive inaccessible_content from audit findings and a11y_evidence. Returns {html, summary} — the accessible legal statement; writes a file only when output_path is given.

Input Schema

Name	Required	Description
`url`	Yes	Website URL the statement covers
`lang`	No	Statement language (default en; es uses the Spanish legal wording)
`entity`	Yes	Legal entity name as it should appear in the statement
`method`	No	How conformance was evaluated (e.g. "self-evaluation: a11y-toolkit screening + manual review")
`status`	Yes	Compliance state: full \| partial \| not_conformant (plena \| parcial \| no_conforme, pre-5.11, still accepted as aliases)
`feedback`	No	Contact channel for accessibility feedback (email or URL)
`framework`	No	rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)
`complaints`	No	Claim/complaint procedure URL or address (legally required in several jurisdictions)
`output_path`	No	save the HTML here (optional)
`review_date`	No	ISO date of the next scheduled review
`evaluation_date`	No	ISO date of the last evaluation (YYYY-MM-DD)
`alternative_format`	No	Where to get the content in an alternative accessible format
`inaccessible_content`	No	Non-accessible content list: one string per item, ideally criterion + reason + alternative

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv5.14.0Oct 23, 2026

addedInput schema / properties / alternative_format

Added value: +{
+  "description": "Where to get the content in an alternative accessible format",
+  "type": "string"
+}

addedInput schema / properties / complaints

Added value: +{
+  "description": "Claim/complaint procedure URL or address (legally required in several jurisdictions)",
+  "type": "string"
+}

removedInput schema / properties / disponibilidad_alternativa

Removed value: -{
-  "description": "Where to get the content in an alternative accessible format",
-  "type": "string"
-}

changedInput schema / properties / entity / description

Previous value: -"Legal entity name as it should appear in the statement (company, body…)"New value: +"Legal entity name as it should appear in the statement"

addedInput schema / properties / evaluation_date

Added value: +{
+  "description": "ISO date of the last evaluation (YYYY-MM-DD)",
+  "type": "string"
+}

removedInput schema / properties / fecha_evaluacion

Removed value: -{
-  "description": "ISO date of the last evaluation (YYYY-MM-DD)",
-  "type": "string"
-}

changedInput schema / properties / framework / description

Previous value: -"Legal framework: rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)"New value: +"rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)"

addedInput schema / properties / method

Added value: +{
+  "description": "How conformance was evaluated (e.g. \"self-evaluation: a11y-toolkit screening + manual review\")",
+  "type": "string"
+}

removedInput schema / properties / metodo

Removed value: -{
-  "description": "How conformance was evaluated (e.g. \"self-evaluation: a11y-toolkit screening + manual review\")",
-  "type": "string"
-}

removedInput schema / properties / reclamacion

Removed value: -{
-  "description": "Claim/complaint procedure URL or address (legally required in several jurisdictions)",
-  "type": "string"
-}

changedInput schema / properties / status / description

Previous value: -"Compliance state: plena | parcial | no_conforme (parcial is the honest default when findings exist)"New value: +"Compliance state: full | partial | not_conformant (plena | parcial | no_conforme, pre-5.11, still accepted as aliases)"

changedInput schema / properties / status / enum

Previous value: -[
-  "plena",
-  "parcial",
-  "no_conforme"
-]New value: +[
+  "full",
+  "partial",
+  "not_conformant"
+]

Changed11 schema fields changedv5.0.0Sep 23, 2026

removedInput schema / properties / contenido_no_accesible

Removed value: -{
-  "description": "Non-accessible content list: one string per item, ideally criterion + reason + alternative",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

removedInput schema / properties / entidad

Removed value: -{
-  "description": "Legal entity name as it should appear in the statement (company, body…)",
-  "type": "string"
-}

addedInput schema / properties / entity

Added value: +{
+  "description": "Legal entity name as it should appear in the statement (company, body…)",
+  "type": "string"
+}

removedInput schema / properties / estado

Removed value: -{
-  "description": "Compliance state: plena | parcial | no_conforme (parcial is the honest default when findings exist)",
-  "enum": [
-    "plena",
-    "parcial",
-    "no_conforme"
-  ],
-  "type": "string"
-}

removedInput schema / properties / fecha_revision

Removed value: -{
-  "description": "ISO date of the next scheduled review",
-  "type": "string"
-}

addedInput schema / properties / framework

Added value: +{
+  "description": "Legal framework: rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)",
+  "enum": [
+    "rd1112",
+    "eaa"
+  ],
+  "type": "string"
+}

addedInput schema / properties / inaccessible_content

Added value: +{
+  "description": "Non-accessible content list: one string per item, ideally criterion + reason + alternative",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

removedInput schema / properties / marco

Removed value: -{
-  "description": "Legal framework: rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)",
-  "enum": [
-    "rd1112",
-    "eaa"
-  ],
-  "type": "string"
-}

addedInput schema / properties / review_date

Added value: +{
+  "description": "ISO date of the next scheduled review",
+  "type": "string"
+}

addedInput schema / properties / status

Added value: +{
+  "description": "Compliance state: plena | parcial | no_conforme (parcial is the honest default when findings exist)",
+  "enum": [
+    "plena",
+    "parcial",
+    "no_conforme"
+  ],
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "entidad",
-  "url",
-  "estado"
-]New value: +[
+  "entity",
+  "url",
+  "status"
+]

Changed12 schema fields changedv4.0.0Sep 22, 2026

addedInput schema / properties / contenido_no_accesible / description

Added value: +"Non-accessible content list: one string per item, ideally criterion + reason + alternative"

addedInput schema / properties / disponibilidad_alternativa / description

Added value: +"Where to get the content in an alternative accessible format"

addedInput schema / properties / entidad / description

Added value: +"Legal entity name as it should appear in the statement (company, body…)"

addedInput schema / properties / estado / description

Added value: +"Compliance state: plena | parcial | no_conforme (parcial is the honest default when findings exist)"

addedInput schema / properties / fecha_evaluacion / description

Added value: +"ISO date of the last evaluation (YYYY-MM-DD)"

addedInput schema / properties / fecha_revision / description
```
Added value: +"ISO date of the next scheduled review"
```

addedInput schema / properties / feedback / description

Added value: +"Contact channel for accessibility feedback (email or URL)"

addedInput schema / properties / lang / description

Added value: +"Statement language (default en; es uses the Spanish legal wording)"

addedInput schema / properties / marco / description

Added value: +"Legal framework: rd1112 (Spanish public sector, art. 10) or eaa (European Accessibility Act / private sector)"

addedInput schema / properties / metodo / description

Added value: +"How conformance was evaluated (e.g. \"self-evaluation: a11y-toolkit screening + manual review\")"

addedInput schema / properties / reclamacion / description

Added value: +"Claim/complaint procedure URL or address (legally required in several jurisdictions)"

addedInput schema / properties / url / description

Added value: +"Website URL the statement covers"

Changed2 schema fields changedv3.3.0Sep 13, 2026

removedInput schema / properties / lang / description

Removed value: -"Idioma de la declaración (es por defecto; en = Directive (EU) 2016/2102 / EAA wording)"

changedInput schema / properties / output_path / description

Previous value: -"Guarda el HTML en esta ruta (opcional)"New value: +"save the HTML here (optional)"

First observedv2.3.0Aug 23, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare destructiveHint=true and idempotentHint=true, which could alarm an agent given this is a document generator; the description resolves that by stating a file is written only when output_path is given, and that it returns {html, summary}. It also notes the generated document is itself accessible, a non-obvious quality guarantee. It doesn't say whether an existing file at output_path is overwritten.

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 verb and the framework fork in the first clause, and the emitter-style tagline at the end is useful rather than filler. It is dense with parenthetical legal citations, which costs a little readability but each clause carries information.

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

Completeness4/5

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

For a 13-parameter generator with no output schema, the description supplies the return shape ({html, summary}), the conditional side effect, and the legal/input sourcing guidance. What's missing is minor: overwrite semantics for output_path and how status/partial maps into the generated text.

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 coverage is 100%, so all 13 parameters are already documented, and the description mostly restates them (framework values, output_path behavior, lang). It adds light legal context — EN wording falls under Directive (EU) 2016/2102 / EAA — but gives no guidance on the required triple (entity/url/status) or how status interacts with inaccessible_content. 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 artifact — generates an Accessibility Statement in HTML — and pins down the two legal frameworks (rd1112 vs eaa) with the exact directives behind each. The trailing tagline 'Legal statement generator' separates it from the sibling audit tools and from a11y_generate_vpat without the agent needing to open a 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?

Gives concrete workflow guidance: populate inaccessible_content from audit findings and a11y_evidence, and pick framework=rd1112 for Spanish public sector vs eaa for private sector. It stops short of naming an explicit alternative for when a different statement format (e.g. VPAT) is wanted, so no exclusion rule is stated.

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

a11y-toolkit: Accessibility statement (EAA/RD 1112)

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools