Reporting API - Monitor Accessibility Failures?

In a recent spec review the Reporting API spec was raised,
https://www.w3.org/TR/reporting/

The Reporting API defines methods for browsers to report back to a "home"
backend potentially significant communication failure modes such as an
expired certificate that occur in-browser, client-side at the "edge".
The API is implemented in HTTP headers, in order to be available to a
user-agent at a low level, perhaps even reporting on failures that prevent
a page from being rendered.

The spec is a bit dry and hard to parse. Its use of HTTP headers make it
more robust, but still -- at least for this reader -- harder to understand.

Maud Nalpas wrote a tidy explainer here. https://web.dev/reporting-api/

*Some errors only occur in production. You won't see them locally or during
development because real users, real networks, and real devices change the
game. The Reporting API helps catch some of these errors⏤such as security
violations or deprecated and soon-to-be-deprecated API calls⏤across your
site, and transmits them to an endpoint you've specified. It lets you
declare what you'd like to monitor via HTTP headers, and is operated by the
browser.*


The spec is built to be somewhat privacy preserving.

If the industry would class inaccessibility as a type of communication
failure mode, particularly as it relates to third party apps and dynamic
experiences common on e-commerce websites that only instantiate and become
active in an end-user's browser, then such accessibility monitoring and
reporting could fall in scope of this API. This is an application that
likely was not envisioned by the spec's authors.

If this is an interesting direction for APA, I would next speak with an SP
using this API to ensure that I understand it.

- Lionel






Lionel Wolberger
COO, UserWay Inc.
lionel@userway.org
UserWay.org <http://userway.org/>
<https://userway.org>[image: text]