Add an accessibility key

[lsmith77]

Public bodies must make the software they deploy accessible: in the EU through the Web Accessibility Directive, the procurement directive (Art. 42) and the European Accessibility Act, with EN 301 549 as the standard; in the US through Section 508. A buyer looking at open source software therefore asks early: how accessible is it, and how do we know?

publiccode.yml cannot answer that. The Italian conforme/lineeGuidaDesign is deprecated, and supports can name a standard, but not the level reached or where the evidence is.

Proposal

An optional top-level accessibility key, holding a summary and pointers to the evidence:

accessibility:
  standard: EN-301-549   # met or failed clause by clause
  version: V3.2.1
  conformance: partial   # out of the box: full | partial | none
  wcag:                  # WCAG version, and the level met out of the box
    version: "2.1"
    level: A
  configuration:         # WCAG level reachable with documented changes
    level: AA
    reference: docs/a11y/configuration.md
  reports:               # ACR/VPAT, one per part where parts differ
    - url: docs/a11y/public-ui.openacr.yaml
  statement: ACCESSIBILITY.md
  issueQueue: https://example.com/italia/medusa/issues?label=accessibility
  maintainerContact: accessibility@example.org
  endorsed:              # accessibility work outside this repository
    - url: https://example.com/acme/medusa-accessible-theme

Rules:

• If the key is present, it gives a standard with its version and conformance, a wcag version and level, or both. Standards such as EN 301 549 have no levels; only WCAG does.
• conformance and wcag.level are the out-of-the-box claim. configuration gives the WCAG level reachable by changing settings, themes or plugins, and links to what that costs.
• The detail per part and per criterion, the review date and the software version evaluated live in the reports. They describe the product before procurement. An evaluation of a live service belongs to the deploying organisation; a project's own evaluation of its reference installation may go in reports. Where parts differ, the summary gives the lowest WCAG level, with conformance: partial; where a report disagrees with the summary, catalogs show the report.
• endorsed points to themes, plugins or distributions the project vouches for, each with its own publiccode.yml and its own claim. The core's claim describes the core alone. As for mirrors (Add a mirrors key #391), authors remove entries they no longer trust, and catalogs show who makes each claim.
• maintainerContact may be a role address, unlike maintenance/contacts.

This is the same split as for security, where the file points at the SBOM. OpenACR is an existing machine-readable report format, though it lacks a product identifier and a neutral, maintained home.

Questions:

• Should the file carry a claim at all, or only point to reports?
• Would extending supports with a version and a WCAG level be enough?
• Is configuration too much for a first version?
• Is endorsed the right name?

Further reading

• Accessibility: a summary in publiccode.yml, the detail in conformance reports: the rationale, the requirements for a report format, and OpenACR assessed against them.

Assessment, meaning who checked a claim and how catalogs show that, is left for a separate issue.

[mgifford]

There are different types of Accessibility Conformance Reports for different things. See GSA/openacr#180

Also, now there are also statements in code like https://mgifford.github.io/ACCESSIBILITY.md

OpenACR is geared at procurement. WCAG-EM was recently updated, but still geared at existing sites.

https://github.com/GSA/openacr
https://github.com/GSA/openacr-editor (currently tied to https://acreditor.section508.gov )

The ACR Repository is coming soon https://www.section508.gov/tools/

[lsmith77]

I made some corrections based on the feedback by @mgifford