Web dashboard: rollup tiles associate their number and label by reading-order proximity only, with no programmatic relationship #3031

The web dashboard's fleet rollup tiles associate each number with its label by reading-order proximity only — no programmatic relationship. It is a page-wide property of the .rollup num/label pattern, not a property of any one tile, which is why it is filed here rather than fixed inside the PR that surfaced it.

Measured, not inferred

Against fc7e3f09fb (#3027), on the Deadlocks (recent) tile and its new coverage sub-line:

• The sub-line text is in the accessibility tree — generic "read 0 of 12 servers" — and in the correct reading order. Flat browse order reads … "0", "Deadlocks (recent)", "read 0 of 12 servers". It is not hover-only and not unavailable.
• Meaning is carried by text, not colour. The yellow is redundant, so there is no WCAG 1.4.1 failure.
• role=null, aria-label=null, aria-describedby=null, tabIndex=-1. Association is proximity alone — arguably a 1.3.1 concern, and arguably only because the reading order happens to be right.

Why this is page-wide rather than one tile's problem

The Blocking tile beside it associates its own 0 with its label by the identical proximity-only pattern. Every .rollup tile does. So a fix applied to one tile would make that tile the odd one out and leave the pattern intact everywhere else — which is the argument for doing it once, at the helper, rather than at a call site.

Worth stating plainly: #3027 did not lower the page's bar. It added a sub-line that follows the existing convention. This issue is about the convention.

One residual that is genuinely hover-only, and is a different shape

The rendered coverage note — 169 characters, on title of a non-interactive div — is sighted-only. It is absent from the accessibility tree as a description, and a title on a non-interactive element is not reliably announced.

That is the real availability gap, as distinct from the association gap above.

Shape of a fix

A stable id on the sub-line plus aria-describedby on the number, giving "0, read 0 of 12 servers". Applied at the tile helper so every rollup tile inherits it rather than one.

Do not attach the long note to aria-describedby. 169 characters announced on every pass over the number is worse than the hover-only status quo — the short coverage fact is the right accessible carrier, and the note is not. That call was made deliberately when the sub-line was built and should not be reversed by someone tidying up.

Not verified

Light mode and high-contrast rendering were not tested. The accessibility-tree readings above were taken against a stubbed /api/fleet, not a live Darling service — the field names were cross-checked against real serializer output, but no end-to-end request was made. No assistive technology was driven; the tree was read programmatically rather than with a screen reader.

Provenance note, because it matters for how this is read

An earlier summary of this finding — mine — described the coverage figure as "available rather than visible," implying it was missing from the accessibility tree. That was wrong, and in the direction that wastes a reviewer's time: someone hunting an availability failure on the figure will not find one. The lane that raised it measured its own claim and corrected it downward, which is how the narrower and accurate version above exists.