Re: Reporting API - Monitor Accessibility Failures?

Dear Fredrik:

Lionel's email, attached here, reminds me you and I have an open action
relating to http headers. I know you've sent me email on the topic
already, but Lionel's spec review seems relevant. I expect we will want
more conversation on how relevant.

Meanwhile, we should get an understanding of what's currently required
of http headers. Can you find those links? I'm sure IETF has a current
version released, but also another under development. It's mainly thos
two we need to look at.

Thanks,

Janina

Lionel Wolberger writes:
> 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]

-- 

Janina Sajka (she/her/hers)
https://linkedin.com/in/jsajka

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Co-Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

Received on Sunday, 15 May 2022 17:49:22 UTC