Ara — audits d'accessibilité RGAA

Re-authenticate against Ara using the credentials configured in this server's environment, and report the current authentication state. Takes no arguments on purpose: credentials must never be passed as tool arguments, because tool arguments transit through the model's context and are persisted in conversation transcripts. Configure them in the `env` block of your MCP client configuration: - ARA_AUTH_TOKEN — a pre-issued Bearer token (recommended) - ARA_USERNAME + ARA_PASSWORD — used to sign in automatically at startup Use this tool only when a call has failed with an expired-token error.

Create a new RGAA accessibility audit in Ara. Returns the audit with its editUniqueId (for editing) and consultUniqueId (for viewing the report). Audit types: - FULL: all 106 RGAA criteria - FAST: 25 criteria (audit rapide) - COMPLEMENTARY: 25 criteria (audit complémentaire) — disjoint from the rapid ones, the two methodologies together covering 50 Call list_rgaa_criteria to see exactly which criteria a type covers.

Soft-delete an audit. The audit itself returns HTTP 410 Gone for future requests, and disappears from the account's audit list. This cannot be undone from this server. IMPORTANT — deleting does NOT unpublish. If the audit was published, its report REMAINS publicly readable at its consultation URL after deletion, and it is then reachable from nowhere in the Ara interface, so it can no longer be edited or withdrawn. Verified against the live API. Do not present deletion to the user as a way to undo a publication.

Fully duplicate an existing audit (metadata, pages, RGAA results, example images). Returns a new audit with fresh IDs. The source audit is left untouched.

Export audit results in CSV format.

Retrieve a full audit by its editUniqueId. Returns all metadata, pages, environments, and notes.

Return the work plan for an audit type: which criteria can be settled by reading the HTML source, and which ones require the rendered page, keyboard navigation, the accessibility tree, or editorial judgement. Call this BEFORE starting an audit. It tells you which tools you will actually need — a browser, a keyboard pass, a screen reader — instead of discovering halfway through that half the criteria cannot be answered from markup. Criteria that need more than the source cannot be marked COMPLIANT or NOT_COMPLIANT by update_audit_results without declaring the matching evidence. This classification is guidance from this server, not a prescription of the RGAA.

Where an audit stands: how many criteria are evaluated on each page, and WHICH ONES ARE LEFT — as a compact list of ids. Use this instead of get_audit_results whenever the question is "what remains to be done". A FULL audit carries 106 criteria per page, transverse elements included: 212 results for a single page, close to a thousand on an eight-page sample. Pulling all of them back just to spot the gaps wastes the context you need for the audit itself. Also reports whether the audit can be published — Ara refuses publish_audit while a single criterion is still NOT_TESTED, and this is how you find that one.

Retrieve all criterion results for an audit. Returns an array of results, each with: - topic (1-13): RGAA topic number - criterium: criterion number within the topic - pageId: ID of the audited page - status: COMPLIANT | NOT_COMPLIANT | NOT_APPLICABLE | NOT_TESTED - compliantComment / notApplicableComment - notCompliantItems: the individual issues found, each with title, comment, userImpact (MINOR | MAJOR | BLOCKING) and quickWin On a FULL audit this returns 106 criteria per page — hundreds of entries. Filter by pageId or status rather than pulling everything, and call get_audit_progress when all you need is what is left to evaluate.

Get the full audit report (read-only). Includes accessibility rate, criteria counts, and result distributions by page and topic. Uses the consultUniqueId (not the editUniqueId).

Return the wording of a single RGAA 4.1 criterion AND its numbered tests — the checks an auditor actually performs to decide COMPLIANT / NOT_COMPLIANT / NOT_APPLICABLE. Call this before evaluating a criterion with update_audit_results: it is what turns "topic 6, criterium 1" into something you can actually assess. Also tells whether the criterion belongs to the rapid or complementary audit. The "verification" block says what is needed BEYOND the HTML source to settle the criterion — keyboard navigation, rendered page, accessibility tree, or editorial judgement — and how to go about it. When "sourceSuffit" is false, reading the markup is not enough: open the page. Source: the RGAA reference shipped with Ara, published by the DINUM under Licence Ouverte 2.0.

List RGAA 4.1 criteria as an index: topic number, topic name, criterion number and wording. Tests are NOT included — call get_rgaa_criterion for those. Use this to know what an audit actually covers before evaluating anything. Filter to keep the answer small: - auditType FAST — the 25 criteria of a rapid audit - auditType COMPLEMENTARY — the 25 complementary criteria (disjoint from the rapid ones) - auditType FULL, or no filter — all 106 - topic — restrict to one of the 13 topics Source: the RGAA reference shipped with Ara, published by the DINUM under Licence Ouverte 2.0.

Update only the notes field of an audit, without touching other metadata. The new content REPLACES the existing notes. Unlike criterion comments, this field is passed through as rich text: HTML is interpreted. Write &lt;th&gt; rather than <th> if you need to quote markup literally.

Mark an audit as published/completed. This makes the audit report and its accessibility statement PUBLICLY available at their consultation URL — confirm with the user before calling it. The audit must be fully filled in (all criteria evaluated) before publishing. Returns HTTP 409 if incomplete. IMPORTANT — publishing is effectively irreversible from here. There is no unpublish operation, and delete_audit does NOT withdraw a published report: it stays publicly readable while disappearing from the Ara interface. Make sure the user means to publish THIS audit, on THIS site, before calling it — publishing an audit about a third party puts a public accessibility statement about them under the auditor's name.

Full update of an audit's metadata (procedure info, auditor info, environments, tools, technologies, notes, etc.). This REPLACES the existing metadata: fetch the audit with get_audit first and resend the fields you want to keep.

Update criterion results for an audit. Send an array of result items. Each item targets one criterion on one page using (pageId, topic, criterium), and REPLACES the previous evaluation of that criterion. The topic/criterium must be a valid RGAA combination. Topics 1-13: 1. Images, 2. Cadres, 3. Couleurs, 4. Multimédia, 5. Tableaux, 6. Liens, 7. Scripts, 8. Éléments obligatoires, 9. Structuration, 10. Présentation, 11. Formulaires, 12. Navigation, 13. Consultation Status values: COMPLIANT, NOT_COMPLIANT, NOT_APPLICABLE, NOT_TESTED Working through a FULL audit: 106 criteria on every page, transverse elements included. Send them page by page, or topic by topic — not in one call. Between batches, call get_audit_progress to see what is left rather than re-reading every result. Before evaluating a criterion, call get_rgaa_criterion to read its wording and its tests: it is what lets you judge rather than guess. Comments are stored as rich text by Ara, so this server escapes < and > before sending: quote markup freely (<th>, <label for>, <video>) and it will survive as written. Do not pre-escape. Describing a non-compliance: the details live in notCompliantItems, one entry per issue found, each with its own title, comment, userImpact (MINOR | MAJOR | BLOCKING) and quickWin. The API requires this array on EVERY item — send [] when there is nothing to report. Ara counts an audit as having blocking issues by looking at the userImpact of these entries, not of the criterion.

Update the accessibility statement (déclaration d'accessibilité) for an audit, REPLACING the current statement fields. This also PUBLISHES the statement: after the call the audit carries a statementPublicationDate and the déclaration is available at its public consultation URL — confirm with the user before calling it. Publishing the statement is separate from publish_audit, which publishes the audit report.