Content
View differences
Updated by Alexander Coles about 8 hours ago
### Decision needed
#DREAM-942 cannot start until the team decides how accessible row positions (`aria-rowindex` / `aria-rowcount`) are counted while a relation or children column is expanded. Relation occurrences and repeated occurrences of one work package under several owners are not described by the query results, and how many of them precede a page depends on which relation columns the request names and which owners are expanded. Expansion state is client-side and session-wide (`wp-view-relation-columns.service.ts`).
### Options
1. **The server counts every occurrence for the named relation columns, regardless of expansion.** Positions exist whether or not an owner is expanded; collapsed owners keep their slots (stable gaps, as decided for groups and hierarchies on 2026-10-24). Stateless API, positions never shift on expand or collapse, consistent with the shipped model. Cost: a relation count per named column over the whole query on every collection request, and `aria-rowcount` includes rows that may never be rendered.
2. **The request carries the expansion state; the server counts only expanded occurrences.** Counts match what the user can reach and the query stays cheap. Cost: every expand or collapse changes every later position and needs a refetch or a client-side recount; cross-page consistency depends on sending the same state with every page; the state leaks into URLs or request bodies.
3. **Keep withdrawing positions while a relation or children column is expanded (today's behaviour) and ship 18.0 without #DREAM-942.** No fabrication; an acceptance-criteria exception that needs recorded NVDA/VoiceOver results and feature-owner acceptance before it is chosen for 18.0; fabrication, spec-compliant, nothing to build before the 2026-11-11 feature freeze. Cost: assistive-technology users lose positions and counts whenever they expand a relation column; must be recorded as an accepted gap in #DREAM-846 and re-checked in #DREAM-897.
4. **Frontend-only when the page holds the complete result set** (count rendered occurrences, withdraw otherwise). Covers single-page queries only; a partial form of 1 or 2 rather than an alternative.
### Recommendation for discussion
Option 3 for 18.0, recorded explicitly. Decide between 1 and 2 after #DREAM-897 shows whether positions with expanded relation columns matter to screen-reader users. If they do, option 1 for consistency with stable gaps, provided the count query cost is acceptable on large queries.
### Resolution criteria
- A recorded choice with reasons, plus the accepted-gap note in #DREAM-846 if option 3 is chosen for 18.0.
- For options 1 and 2: the occurrence key shape (owner, relation type, target) and how a work package repeated under two owners is numbered.
- #DREAM-942's scope item 1 replaced by a reference to this decision.
#DREAM-942 cannot start until the team decides how accessible row positions (`aria-rowindex` / `aria-rowcount`) are counted while a relation or children column is expanded. Relation occurrences and repeated occurrences of one work package under several owners are not described by the query results, and how many of them precede a page depends on which relation columns the request names and which owners are expanded. Expansion state is client-side and session-wide (`wp-view-relation-columns.service.ts`).
### Options
1. **The server counts every occurrence for the named relation columns, regardless of expansion.** Positions exist whether or not an owner is expanded; collapsed owners keep their slots (stable gaps, as decided for groups and hierarchies on 2026-10-24). Stateless API, positions never shift on expand or collapse, consistent with the shipped model. Cost: a relation count per named column over the whole query on every collection request, and `aria-rowcount` includes rows that may never be rendered.
2. **The request carries the expansion state; the server counts only expanded occurrences.** Counts match what the user can reach and the query stays cheap. Cost: every expand or collapse changes every later position and needs a refetch or a client-side recount; cross-page consistency depends on sending the same state with every page; the state leaks into URLs or request bodies.
3. **Keep withdrawing positions while a relation or children column is expanded (today's behaviour) and ship 18.0 without #DREAM-942.** No fabrication; an acceptance-criteria exception that needs recorded NVDA/VoiceOver results and feature-owner acceptance before it is chosen for 18.0;
4. **Frontend-only when the page holds the complete result set** (count rendered occurrences, withdraw otherwise). Covers single-page queries only; a partial form of 1 or 2 rather than an alternative.
### Recommendation for discussion
Option 3 for 18.0, recorded explicitly. Decide between 1 and 2 after #DREAM-897 shows whether positions with expanded relation columns matter to screen-reader users. If they do, option 1 for consistency with stable gaps, provided the count query cost is acceptable on large queries.
### Resolution criteria
- A recorded choice with reasons, plus the accepted-gap note in #DREAM-846 if option 3 is chosen for 18.0.
- For options 1 and 2: the occurrence key shape (owner, relation type, target) and how a work package repeated under two owners is numbered.
- #DREAM-942's scope item 1 replaced by a reference to this decision.