Make the trainer usable with a screen reader

[RCheesley]

Make the trainer genuinely usable with a screen reader. This is the part of
accessibility that automated tooling cannot check, so it needs its own issue and
manual testing.

Axe already runs against every view in both themes in CI. Axe cannot see any of
what follows.

The problem this solves

A typing trainer is close to the worst case for a live region. Announcing every
keystroke produces a firehose that makes the app unusable; announcing nothing
leaves a screen reader user with no idea where they are.

Acceptance criteria

• Individual keystrokes are not announced.
• The current word is announced when it changes.
• Errors are announced.
• The end-of-drill result is announced once.
• Progress uses a polite live region; the result uses assertive. Not the
  reverse.
• The drill surface has an accessible name, and a description stating the next
  key, the finger and the row.
• Nothing about progress, error state or key state is conveyed by colour alone.
• prefers-reduced-motion: reduce removes every transition and any
  celebratory animation.

Manual testing required

Tested with at least VoiceOver on macOS and NVDA on Windows. The checklist in
docs/accessibility.md is the acceptance criteria; tick it off in the pull
request and say which assistive technology and version you used.

Tests this unblocks

• End-to-end: announces the current word and the result, but not every
  keystroke. That test can only check the regions and their politeness, not
  whether the result is actually usable. The manual pass is the real test.

Help wanted

If you use a screen reader and would be willing to try this, that feedback is
worth more than anything the tooling can tell us.

[RCheesley]

Depends on #6, since the drill surface is what needs announcing.

[RCheesley]

Where this is up to, and what we are asking for

Partial work in #20. Deliberately not closing this issue.

Done, and asserted automatically

The mechanical half was largely built with the drill surface in #6, and is checked on every commit — axe against every view in both themes, plus specific assertions that:

• individual keystrokes are not announced — the current word is announced when it changes, and nothing fires per keypress;
• errors name the key that was expected and the finger that owns it, not just the letter;
• the result is announced once, assertively; progress is polite;
• the drill surface has an accessible name and a description naming the next key, its finger and its row;
• the next key is named in words before it is highlighted in colour;
• Escape releases keyboard capture, and Tab then moves through the page normally;
• a whole drill can be completed without touching the mouse;
• nothing is conveyed by colour alone — severity bands are words, marks carry decoration as well as ink.

Fixed in #20

A repeated identical announcement was silent. A live region only speaks when its contents change, so setting it to the string it already holds does nothing. Mistyping the same key twice in a row announced once. announceInto now toggles a trailing space so a repeat is always a real change.

Applied to the progress views. The drill surface adopts it as soon as #8 lands — it is being edited there in parallel.

Suspected, from reading the code rather than from listening

Confirming or dismissing any of these is useful:

1. Whitespace-only changes. The fix above assumes every screen reader treats a trailing-space difference as a change. That is the documented technique, but it is a guess until somebody hears it.
2. No region is aria-atomic. Multi-part messages may be announced in fragments.
3. Five polite regions can speak — capture state, drill progress, current lesson, load status, progress status. If two change together the order is the screen reader's choice. We do not know if this piles up in practice.
4. The next-key description changes while the surface holds focus. It is referenced by aria-describedby, and screen readers vary a lot in whether they re-read a description that changes underneath them.

What we actually need

docs/screen-reader-testing.md — a twenty-minute script that assumes no knowledge of the codebase. It links the reference layout so you can do it without owning a Glove80.

A typing trainer is close to the worst case for a live region: announce every keystroke and it is an unusable firehose, announce nothing and you have no idea where you are. We think we are on the right side of that line. We have not heard it.

The questions no test can answer:

• Is announcing the current word the right granularity, or is it too much, or not enough?
• Is the result comprehensible heard rather than seen — words per minute, accuracy, stars?
• Does the escape hint arrive in time to help somebody who feels trapped?
• Does the weak-key report — grouped by finger and row, which is the whole point of this project — read sensibly aloud?
• The board diagram is aria-hidden on the claim that everything it shows is also in text. Is that claim true?

If you use a screen reader and are willing to spend twenty minutes on this, please say what you found here — including the parts that were fine. Knowing which announcements already work is as useful as knowing which do not.