RE: Well-Known URI for Accessibility Issue Reporting

Hi Paul,

Thanks for the detailed response!

The legacy site scenario for well-known URI coexistence is a fair point. For sites where injecting <link> elements on every page is difficult, a single JSON file at a well-known URI is clearly easier to deploy. Having both paths available, with <link> taking precedence when present, seems like the right balance. It gives modern CMS-driven sites the sub-site scoping and author control benefits of Discoverable Destinations, while keeping the door open for legacy systems.

The one POST per issue rationale is compelling. The points about atomic issues mapping cleanly to ticketing systems, keeping evidence correlated with the right issue all make practical sense from an operator's perspective. The framing that this is a reporting mechanism for untrusted reporters, not an audit ingestion pipeline is an important distinction.

@m.atkinson@samsung.com<mailto:m.atkinson@samsung.com>: Paul raises a valid point about legacy sites where adding <link> elements to every page is impractical. Should we consider recognizing well-known URIs as an optional fallback mechanism in Discoverable Destinations? The <link> approach should remain the primary and recommended path, and when both are present, <link> should take precedence. This would make Discoverable Destinations more practical for a wider range of sites without compromising the sub-site scoping and author control benefits we chose <link> for. We had already considered Well-Known URLs and Linksets as centralized alternatives, so this would not be much deviation.

Thanks,
Abhinav Kumar


From: Paul Grenier <pgrenier@gmail.com>
Sent: 06 April 2026 22:14
To: Kumar, Abhinav <abhina.kumar@sap.com>
Cc: m.atkinson@samsung.com; WAI Adapt Task Force <public-adapt@w3.org>
Subject: Re: Well-Known URI for Accessibility Issue Reporting

Abhinav,

Thank you for taking the time to read the proposal and your thoughtful comments.

The subsite scenario is an important use case and I can see the wisdom in making Link headers and tags the primary discovery mechanism. However, the reasons for .well-known to exist in tandem with Discoverable Destinations, in my mind, is just as compelling. Consider legacy services and sites (or really any system resistant to change). The engineering needed to inject Link headers for every request or inject tags on every page could be much greater than adding a single JSON file to the domain. Especially for vendor-supplied reporting capabilities. Resources spent on integration of Discoverable Destinations would be better spent on remediation.

I agree, I should address the Reporting API in well-known's spec. They're very different in approach and scope but can co-exist.

The original design was for multiple issues. But one POST per report was intentional. I'll try to explain all of the reasons that went into that decision, but I may forget some:

  *   Protecting the operator from malicious or burdensome payloads
  *   Scoping issues in a way that would be better understood and processed by (potentially AI-automated) systems on the operator's side
  *   Ease of mapping issues to internal ticketing systems and assignment to disparate teams (also makes the accessibility coordinator's job easier)
  *   Easily referenceable issues for grouping and categorizing on the operator's side
  *   Clearer reporting for user tracking of what's done, what's planned, and what won't be fixed without "throwing away the whole report" for one wont-fix issue
  *   Evidence became needlessly complex with multiple issues. It became difficult to correlate which issue had which evidence since evidence wasn't part of the original formats. Mixing evidence types also got complicated. Keeping the schema simpler required one-POST-per-issue.
  *   Easier reproducibility for operators. If one part of a multi-issue report became stale from a code/content change, the entire report may become difficult to reproduce. Atomic issues controls for collateral "damage" from a system change.
The goal of this spec is NOT to support an audit. I assume audits are performed by operators or government regulators and they have their own reporting systems. This is expected by the operator and the auditor won't get rate limited or denied authorization. Accessibility-reporting is open to untrusted reporters and is not planned. It needs to do one thing well and not become a burden or attack vector for operators to worry about.

Again, thank you for the comments and ideas.

Sincerely,
--
Paul Grenier


On Mon, Apr 6, 2026 at 9:37 AM Kumar, Abhinav <abhina.kumar@sap.com<mailto:abhina.kumar@sap.com>> wrote:
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<mailto:m.atkinson@samsung.com> <m.atkinson@samsung.com<mailto:m.atkinson@samsung.com>>
Sent: 02 April 2026 03:10
To: 'WAI Adapt Task Force' <public-adapt@w3.org<mailto:public-adapt@w3.org>>; pgrenier@gmail.com<mailto: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<https://www.w3.org/events/meetings/b3d3fb17-9637-4fae-a68a-39f8f9a6719a/202>

60408T100000/>