Meeting minutes
<janina> /join #rqtf
<janina> s/\/join #rqtf//
<Fredrik> present*
Agenda Review & Announcements
Gottfried: My session on overlay tools was cancelled due to too few submissions.
Proposal: Well-Known URI for A11y Issue Reporting -- Paul
<matatk> w3c/
PaulG: Reporting about accessibility problems.
… Available for humans and agents.
… AT can also do this.
… Reporting channel: URL, e.g. via <link>
<Fazio> Sounds like this spec meets the needs of "Find Help" from the COGA How To Make Content Usable to People with Cognitive and Learning Disabilitires Guide
PaulG: HTML form to fill out.
… One person willing to do a prototype for it.
… Internal data (on page, etc.) automatically filled out.
… AI could potentially fix it before a human reads it.
<marcelo> link to Paul's spec: https://
PaulG: Benefits: Faster fixes, less reporting and conversations, status tracking (get request on report)
… This is a draft. Please provide feedback
<Zakim> matatk, you wanted to talk about well-known vs discoverable; and Reporting API
<matatk> Well-known vs 'discoverable' - background: https://
matatk: ADAPT is working on well-known URIs. Like landmarks for regions.
… We were advised against it. Many websites are complex, multi-tenant, multi-target groups, etc.
… Need a conversation about the best way to do this
… I will put a link in to ADAPT
<matatk> Reporting API: https://
matatk: Also working on standard for accessibility metadata - relevant here
… Reporting API must adhere to privacy - important
… Webpages draw from multiple sources frequently.
… Webpages often are not static; might be meshups or overlays.
… I cann pass along Information from a previous discussion on discoverable destinations: Links vs. well-known.
PaulG: What mechanism works best for your organization/deployment, do it. There is not necessarily a one-size-fits-all.
… The idea came from reporting API. It is about browser and machine-to-machine. It is not designed for humans to report.
… For meshups, etc.: harder to pinpoint to problem. Payload could include screenshots and other information.
… One issue per request important.
… This is not an audit tool. This is for untrusted actors to report what they find as a barrier.
matatk: Please provide feedback on the tracking issue.
Fazio: Sounds very much like COGA How To Make Content Usable to People with Cognitive and Learning Disabilitires Guide
<matatk> https://
Fazio: Was published 6 years ago. Please have a look into it.
janina: I like this - first principles. This becomes more important as we get agents on the web.
… I have a hard time how to report on barriers, e.g. ZOOM
… This is predictable for users.
… ADAPT vs. this one: We can have two specs, but they must not clash.
… Reliable accessibility statement is relevant too
… Hope this will make it into WCAG 3
matatk: If it is hard to report, bugs will likely not be reported
stevef: JAWS had something like a reporting system in place - but now it is gone.
<Fredrik> tjaws accessibility reporting
Fredrik: There was a sales pitch for the ARC server - looks like now put to sleep
… It was basically just a web form
matatk: Commercial providers could hook into this. Choice of to whom it gets reported.
PaulG: I published this as RFC. The idea is not new. We have many convergent technologies right now.
… I don't care how we get there. But the time is ripe.
<Zakim> matatk, you wanted to ask about venue, harmonisation, how/where to contribute
matatk: IETF as venue. We could seek advice on this if you want.
… W3C spec on well-known URI for changing passwords.
… Maybe we could harmonise together with well-known URI...
<Fredrik> Fredrik In honour of Red Dwarf, how aout Discoverable Accessibility Missteps Messaging Integration Technology - where does that land in the Backronymicon?
matatk: Micro-formats wiki, get people to use it, then register as URL type.
<Fredrik> Fredrik: You could change "Discoverable" to "Defined".
matatk: You don't want to overwhelm people, but also collect as much Information as possible.
… Same reporting form on every webpage is a good think, but also a UX challenge.
c/thing/thing
PaulG: The discovery doc has an object describing the format of reporting (e.g. EARL, AC rules, ...)
<matatk> s/AC Rules/ACT Rules/
PaulG: The minimum is a human-written description of the problem
… Hope that early prototypes will clarify what is needed and implementable
janina: I don't see a clash between this and ADAPT. But good if Matthew checks with the community about the suitability of well-known for this.
… Could this be a template approach for other types of reporting (e.g. security, privacy, etc.)
Abhinav: Can you elaborate on discoverable destination?
matatk: Imagine the following workflow: You Experience a problem, press a button, fill in data on a form.
… But it is dependent on the page you are on.
Abhinav: To my understanding, the form is a well-known page on the Domain.
<chiace> I think a useful next step would be to map the end-to-end reporting journeys across different user scenarios
PaulG: User presses button - an extension may open. Header information may not be available to the extension.
… Opportunity for third parties to handle stuff on the server.
… Let's do all: Well-known AND discoverable
<PaulG> there is a flow diagram (sorry ascii art) here: AutoSponge/
<PaulG> but I agree more user journey info would help
matatk: Chiara had a good proposal in the chat.
<marcelo> I can help PaulG
<Abhinav> Abhinav: gottfried - You can find details at:
<Abhinav> 1) https://
<Zakim> matatk, you wanted to talk about next steps
matatk: We should think about the next steps in terms of registration as RFC, etc.
<chiace> I can help as well for UX/UI
matatk: We are adjourned.