RE: Well-Known URI for Accessibility Issue Reporting

Hi All,

Thanks for sharing the spec. I have gone through the "Well-Known URI for Accessibility Issue Reporting" specification on high level and here is my understanding:

What I understand from the spec:
The spec defines a discovery document at /.well-known/accessibility-reporting where sites advertise how to report accessibility issues. It includes a JSON discovery document, a full REST API (POST/GET/PUT/DELETE), and a structured report schema that supports human reporters, automated tools, and AI agents.

The report schema covers element identification through multiple locator strategies, accessibility tree snapshots modeled on AXNode, an extensible rule vocabulary system using JSON-LD, impact severity levels, and attachments (screenshots, DOM snapshots etc).

It's substantial and well thought out work.

Some context on what we've been doing in Adapt Task Force:
I want to share some background that may be useful. The WAI-Adapt Task Force has been working on Discoverable Destinations (https://github.com/w3c/adapt/blob/main/explainers/discoverable-destinations.md), which is a mechanism for sites to advertise common page types like help, login, accessibility statement, and so on, so that user agents and AI agents can reliably find them.

Accessibility reporting, with discovery via well-known URL, was originally part of this same scope. We had two early explainers scoped for it

  *   Accessibility statement schema: https://github.com/w3c/adapt/blob/main/explainers/accessibility-meta.md
  *   Accessibility reporting endpoints and schema: https://github.com/w3c/adapt/blob/main/explainers/accessibility-reporting.md

We deferred reporting in the first phase to focus on the destination list sourced from the COGA Task Force, which includes accessibility-statement. Reporting is planned for a subsequent phase. So, the core idea of a standardized way to report accessibility issues to site operators has been on the roadmap for a while.

We also have an explainer on how Discoverable Destinations work with agentic AI systems: https://github.com/w3c/adapt/blob/main/explainers/navigation-and-content-tools-for-agents-using-discoverable-destinations.md, covering MCP/WebMCP integration, Semantic Web Tools, ARIA landmark navigation, and LLM orchestration patterns etc. The AI agent scenarios described in your spec is on similar lines.

On the Well-Known URI approach
One thing I wanted to flag is that we started with well-known URIs for Discoverable Destinations and moved away from them to <link> elements with rel values. Two reasons led to that decision:

  1.  Well-known URIs are origin-scoped, which means you cannot demarcate sub-sites. A hotel site with separate restaurant and gym micro-sites cannot have different endpoints per sub-site.
  2.  Well-known URIs are managed separately from page content, making them harder for regular content authors to maintain. <link> elements live in page markup and are naturally handled by CMS systems.

This is documented in the "Alternatives Considered" section of our Discoverable Destinations explainer. The current thought process is that accessibility-reporting would be added as a Discoverable Destination type, may be discovered via <link rel="accessibility-reporting">, on similar lines as accessibility-statement works today.

I notice your spec already supports this path in section 3.4 (Link-Based Discovery), which is great. It might be worth considering making that the primary discovery mechanism rather than the well-known URI, so that it fits well with "Discoverable Destinations".

What your spec does that we haven't
To be candid, our reporting explainer is still in preliminary stage. Your spec has done the great work on things we identified but hadn't solved yet:

  *   The report schema with element locators, accessibility tree snapshots, and the extensible rule vocabulary system etc.
  *   The full report lifecycle (submit, receipt, status tracking, amend, retract).
  *   Accessibility tree snapshots as structured evidence for what the reporter actually observed is a nice approach.

A few thoughts

  *   Our reporting explainer originally envisioned building on the W3C Reporting API (https://www.w3.org/TR/reporting-1/) for automated browser-based reporting. Your spec uses a custom REST API, which is better suited for explicit user and agent submissions. It might be worth discussing the Reporting API somewhere and the trade-offs between the two approaches.
  *   The one report per POST constraint could be challenging for automated scanners generating dozens of findings per audit. Have you considered batch submission?
  *   The JSON-LD @context system is powerful, but given that the complexity most operators will simply ignore it, a simpler format might lower the barrier for adoption.

Next steps
I think there's a natural fit between what your spec provides (the reporting protocol, report schema, and lifecycle API) and what Discoverable Destinations is building toward (the discovery layer for finding endpoints like accessibility statements and, in the next phase, accessibility reporting). IMO, we should discuss how these pieces could work together.

Thanks and Regards

Abhinav Kumar
Development Architect, BPM

SAP Labs India Pvt. Ltd, 138, Export Promotion Industrial Park, Whitefield, Bangalore 560 066, India
abhina.kumar@sap.com<mailto:abhina.kumar@sap.com>

Mandatory Disclosure Statement: www.sap.com/impressum<http://www.sap.com/impressum>

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise
confidential information. If you have received this e-mail in error, you are hereby
notified that any review, copying, or distribution of it is strictly prohibited. Please inform
us immediately and destroy the original transmittal. Thank you for your cooperation.






-----Original Message-----
From: m.atkinson@samsung.com <m.atkinson@samsung.com>
Sent: 02 April 2026 03:10
To: 'WAI Adapt Task Force' <public-adapt@w3.org>; pgrenier@gmail.com
Subject: Well-Known URI for Accessibility Issue Reporting



Dear Adapt TF colleagues,



Please join us on the main APA WG call on Wednesday the 8th [1] (full agenda

forthcoming) to discuss Paul's proposal.



APA will be reviewing this proposal (your input is welcome, as APA members);

you can find a link to the proposal, and our review discussion thread here:

<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fa11y-tracking%2Fissues%2F312&data=05%7C02%7Cabhina.kumar%40sap.com%7C2c7f182f97494bb5116a08de90374e6a%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C639106764386924639%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=92VSfk0QcI7RpFUjRa%2FmmwLWZtXbDN37Lg2ZT0h0LTA%3D&reserved=0<https://github.com/w3c/a11y-tracking/issues/312>>



We look forward to the discussion with Paul!



Best regards,





Matthew



[1]

<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2Fevents%2Fmeetings%2Fb3d3fb17-9637-4fae-a68a-39f8f9a6719a%2F202&data=05%7C02%7Cabhina.kumar%40sap.com%7C2c7f182f97494bb5116a08de90374e6a%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C639106764386950974%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EOjp4fL6tndJ9yXUKW8QS7WiokOQT0RoQaDtVHtHMm8%3D&reserved=0

60408T100000/>