Meeting minutes
Introduction, Any Updates?
matatk: COGA is planning an update to
… Making Content Useable
… this is significant as it is a source of use cases and personas for us in Adapt TF
gb, status
<gb> matatk, the delay is 15, issues are on, names are on, full issues are printed 10 at a time; and the repository is w3c/
matatk: There are Actions and PRs on the Adapt repo, let's add that to the agenda so that we can clear them in a more timely manner
Well Known Destination
Lionel_Wolberger_: Many discussions active on Github, let's look there.
https://
#231
<gb> Action 231 Follow up on "Well-known URL[s]" (on matatk)
#259
<gb> Issue 259 [not found]
Lionel_Wolberger_: Looking at Discussion #259, https://
… Schema for automated accessibility reports
ACTION: matatk: Report that gb doesn't work with GitHub Discussions
<gb> Created action #260
matatk: Schema would end up being addressed under 'Reporting API' workstreams
… it is not intrinsic to Well Known Destination
matatk: We do expect that a Well Known Destination could redirect and provide either human-readable or machine-readable results. This is relevant for accessibility statement, report a problem, and other possible destinations.
Abhinav: Why is an accessibility report considered separate from accessibility metadata?
matatk: One use case: I want to know what this site's accessibility statement/policy is
… I can imagine that this page has aspects that are machine readable, e.g. what ATs are supported
… Another use case: I want to report an accessibility problem
… this would use Reporting API, which would require some browser support
… one scenario: a bug report
… another scenario: an automated accessibility test could be uploaded via the Reporting API
… (This could be taken up by Accessibility at the Edge Community Group)
Abhinav: I see accessibility metadata as comprehensive. It should enable access to (*) report a bug (*) find information on accessibility
… so why can't this be part of Well Known Destination, both proposals to be handled together?
… it will be cognitive overload if we end up defining multiple Well Known Destinations for Accessibility
… one end point will be very powerful, which can then enable access to the other destinations
matatk: +1 to that
… But Reporting API is still different to this
… it's not accessed from a particular page
… and it requires that the server have a 'listener' for the Reporting API
Lionel_Wolberger_: Reminder, the reporting API is here https://
Lionel_Wolberger_: I closed three discussion issues that related to the above.
Wee took up Discussion #256, https://
<gb> Issue 256 [not found]
<Lionel_Wolberger_> s/wee/we
Abhinav: Question in 256 is about ensuring the accessibility statement is translated into the user's language, regardless as to whether they got there via the well-known URL or directly.
matatk: Aha - the answer is we _hope_ (and need to check!) that the localization system will work just the same as usual - the well-known URL is just a redirect, so it should be transparent, but we need to check that it does work like that.