### Vector graphics (Draft): text and accessibility, §5 of `wai.graphics.vector`

- **[graphics-vector](extensions/graphics-vector.md) §5 is written.** A payload carries
  its words beside its glyphs, and this revision says what a sink computes from them and
  what it owes the viewer:
  - **The projection and the transcript, byte for byte (§5.4).** A block's active set is
    the union of the effective windows of the runs and paths that draw it, cut to the
    document's window, sorted, with windows that overlap or touch merged. The projection
    at a frame is every block active at the frame's tick, in reading order; the
    transcript is every block with its active set. Both are JSON with a fixed member
    order and exactly three string escapes. A block's `purpose` is written as the byte
    carried, an unregistered code included; `mode` is in every node; a ruby link is
    written as the base block's index with the range's start and length; `decorative`
    blocks are in neither. Opacity, position and clips do not enter either value. A
    payload's *text record* is its transcript and every frame's projection at every
    listed rate, one value a line: text-equivalence is byte equality of it.
  - **Encoder rules (§5.1, §5.3)** that a verifier checks and a sink does not: one base
    direction for a block, one joining sequence in one run, vertical text and its
    `mode`, Normalization Form C, every byte of a string in exactly one cluster, no
    zero-glyph cluster for a visible character, and no colour glyphs.
  - **The purpose vocabulary (§5.2),** with how each purpose is exposed and whether it is
    announced by default.
  - **Exposure (§5.5).** A presenting sink exposes the current projection to the
    platform's accessibility interface, updates it when the projection changes, inserts
    strings as text and never as markup, and keeps within stated announcement limits.
    What assistive technology then says is not claimed.
  - **Whether the words match the glyphs (§5.6):** the chain from a parent font to an
    outline set, from a text block to glyph IDs, and from glyphs to the overlay layer;
    what an authoring receipt records; and what the chain does not reach.
  - **Captions under the viewer's control (§5.7).** Captions travel as timed text. A
    sink that cannot read the platform's caption preferences does not draw `caption` or
    `subtitle` items, and a frame it draws without them is not the published frame.
- **`wai-vector`: the text layer.** `wai_vector::text` computes `text_hash`, block
  identities, effective windows, active sets, the projection, the transcript and the
  text record, in a sink's build, and a verifier's check of the cluster rule. The tool
  gains `wai-vector a11y` (the text record, the transcript, or one frame's projection)
  and `wai-vector text` (the text digests and each block as a reviewer reads it). The
  corpus-seeded fuzz holds the text layer of every payload it accepts: the transcript
  is JSON that gives back each tag and string, and a projection lists exactly the
  blocks the frame procedure draws at that tick.
- **`vector-conformance`: the `a11y` group.** Each payload's expected file states the
  SHA-256 of its text record, and the record is committed beside it, so every fabric leg
  recomputes it: the worked example of §5.4, windows and a fade to nothing, a
  `decorative` block, text alternatives of paths, reading groups, ruby over part of a
  base, registered and unregistered purposes, merged and clipped intervals, windows cut
  by enclosing groups, the three writing modes, four rates over one document, strings
  that take each escape and strings that take none, and a payload with no text. The
  `canonical` and `refusals` groups gain text-block cases: an ungrouped block between
  groups, ruby links to a later block and ranges that end inside a character or at the
  string's end, and pairs that pin where `TEXTS` sits in the record pass and that the
  text-block rules come before any outline set is read.

