This one needs people who use assistive technology. It can't be answered from the specification — it turns on what actually works: which screen reader, which version, what was announced, what you expected instead. If you use a screen reader, magnification, switch access or voice control day to day, you have the evidence this repo is missing.

You don't need to know the codebase and you don't need to propose a fix. Describing what happened when you tried something is a complete contribution here. Disagreement with the framing is equally welcome. What this repo adopts on this question will be shaped by the people who answer it.

Deliverable: a11y-signals.yml schema.

The schema is drafted with two worked examples. This issue concerns one field's semantics.

A project declaring review capacity is asserting something about its process, not its product. The documentation has to make that impossible to confuse. Get it wrong and the file becomes a liability shield — a project points at its declaration as evidence its software is accessible, which is the exact inversion of the intent.

Open questions:

• What is a project actually promising, in words a maintainer and a disabled user would both read the same way?
• What must the field explicitly disclaim?
• Should declaring capacity that does not materialise have any consequence, or is the file purely descriptive?