From 5d1e8d256deea2a31a8b840c4966a44a972e54b1 Mon Sep 17 00:00:00 2001 From: Matthew Tylee Atkinson Date: Tue, 21 Nov 2023 10:29:59 +0000 Subject: [PATCH] Add first draft explainers for two more specs --- explainers/accessibility-meta.md | 66 ++++++++++++++++++ explainers/accessibility-reporting.md | 97 +++++++++++++++++++++++++++ 2 files changed, 163 insertions(+) create mode 100644 explainers/accessibility-meta.md create mode 100644 explainers/accessibility-reporting.md diff --git a/explainers/accessibility-meta.md b/explainers/accessibility-meta.md new file mode 100644 index 0000000..3f7a046 --- /dev/null +++ b/explainers/accessibility-meta.md @@ -0,0 +1,66 @@ +# Accessibility statement schema and metadata + +## Authors + +- Matthew Tylee Atkinson (@matatk), Samsung Electronics + +## Introduction + +Accessibility statements provide detailed information from a site developer about: + +* Which assistive technologies they support. +* Known issues. +* Plans for further accessibility improvements. +* Contact details so that visitors can request help, or report problems. + +This spec provides a standard schema for providing this information, with the following goals. + +## Motivating Use Cases + +* Improved consistency of accessibility statements across sites. + - This will make the statements more useful for humans. +* Make the statements machine readable. + +> **TODO:** Prediction: machine readability may give some organisations concerns (as it makes researching easier). + +## Non-goals + +* Specifying the _location_ (URI) of the accessibility statement. This is the subject of a separate specification. +* Providing the means for accessibility reporting, in the following ways. Both of these are covered by a separate specification. + - Providing the means for accessibility test results to be automatically, semi-automatically, or manually reported. + - Providing the means for people to report difficulties they are having on a given page. + +> **TODO:** Link to the other specs/explainers. + +## User research + +> **TODO** + +## Schema for accessibility statements + +> **TODO** + +This section will detail: + +* What types of information can go into an accessibility statement. +* How each is to be identified and encoded. + +## Key scenarios + +> **TODO** + +## Detailed design discussion + +> **TODO** + +## Considered alternatives + +> **TODO** + +## Stakeholder Feedback / Opposition + +> **TODO** + +## References & acknowledgements + +> **TODO** \ No newline at end of file diff --git a/explainers/accessibility-reporting.md b/explainers/accessibility-reporting.md new file mode 100644 index 0000000..19ccf20 --- /dev/null +++ b/explainers/accessibility-reporting.md @@ -0,0 +1,97 @@ +# Accessibility reporting: use cases, endpoints, and schema + +## Authors + +- Matthew Tylee Atkinson (@matatk), Samsung Electronics + +## Introduction + +> **TODO** + +This work builds on the [Reporting API](https://www.w3.org/TR/reporting-1/). + +## Motivating Use Cases + +* Providing the means for accessibility test results to be automatically, semi-automatically, or manually reported. +* Providing the means for people to report difficulties they are having on a given page. + +> **Note:** It is anticipated that using infrastructure such as the Reporting API will be particularly helpful in situations where pages are comprised of content obtained from multiple sources, because the reporting can be done "at the edge" where this content is combined. +> +> To be useful, though, this will require organisations to be able to reproduce (or at least approximate) the assembled content, based on the information provided by the report. + +## Non-goals + +* Specifying the location (URI) of the accessibility statement. This is the subject of a separate specification. +* Specifying the schema of the machine-readable accessibility statement. This is the subject of a separate specification. + +> **TODO:** Link to the other specs/explainers. + +## User research + +> **TODO** + +## Accessibility reporting mechanisms + +### Reporting endpoint for accessibility results + +> **TODO** + +We will standardise an endpiont to be used for accessibility reporting—or possibly two endpoints: + +* A reporting endpoint for (automatic, semi-automatic) inspection tooling. +* A reporting endpoint for issues that a user reports (manually, or with assistance from a tool that may include attachments, like screengrabs) when they encounter an error. + +### Schema for automated accessibility reports + +> **TODO** + +We will standardise a schema to be used by automated accessibilty tooling. + +Challenges include: + +* Scoping (Just WCAG, or also best practices—in which case, how should they be flagged?) +* Identifying the part of the page that is affected. +* Attachments. +* Units. + +We will probably find help with this via the [Accessibility Conformance Testing (ACT)](https://www.w3.org/WAI/standards-guidelines/act/). + +### Schema for accessibility barriers affecting users + +> **TODO** + +We will standardise a schema for providing reports from users. + +## Key scenarios + +### An automated accessibility scanner + +> **TODO** + +### Manual in-browser accessibility inspection tools + +> **TODO** + +### A site visitor experiencing barriers + +> **TODO** + +## Detailed design discussion + +> **TODO** + +## Considered alternatives + +> **TODO** + +## Stakeholder Feedback / Opposition + +> **TODO** + +## References & acknowledgements + +> **TODO** + +* [Research Questions TF: Use cases for the Reporting API](https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/Reporting_API_Use_Cases) +* [Accessibility Conformance Testing (ACT)](https://www.w3.org/WAI/standards-guidelines/act/) +* [Reporting API](https://www.w3.org/TR/reporting-1/) \ No newline at end of file