Table semantics broken by the full-page-scroll table refactor — VoiceOver cell navigation no longer works

[MelvinBot]

Problem

ARIA table semantics added in #93335 no longer apply to the workspace tables. On web with VoiceOver, Ctrl + Option + Arrow cell navigation no longer works and rows are not announced as "row N of M, column K".

This is a regression from #93877 ("Update table pages to scroll full page", merged 2026-08-24, c9a232f96d4d).

Root cause

#93877 introduced Table.ListHeader and adopted it in every workspace table — Categories, Distance rates, Company cards, Workspaces list, Rooms, Domains list — exactly the tables #93335 covered. That sets hasPageHeader = true at src/components/Table/Table.tsx:388, which now disables the semantics:

• Before: <TableSemanticContainer isEnabled={isTableSemanticsEnabled}> → role="table" wrapping TableHeader (role="row") + TableBody (role="rowgroup").
• After: src/components/Table/Table.tsx:505 gates it on isTableSemanticsEnabled && !tableListMetadata.hasPageHeader, so role="table" is never emitted on the header/body run.

Consequences for these tables:

1. No role="table" on the header/body wrapper — it degrades to a pure layout node.
2. No role="rowgroup" at all — gated on !hasPageHeader at src/components/Table/TableBody.tsx:161.
3. role="table" moves onto the View wrapping FlashList (TableBody.tsx:160-166), and only when hasRows.
4. The page header — title, buttons, and the search <input> — now renders inside that role="table" element as FlashList's ListHeaderComponent (TableBody.tsx:241, TableBody.tsx:390).
5. TableHeader is pulled out of the inline children (Table.tsx:389-398) and rendered as a virtualized/sticky FlashList item, with an extra <View style={styles.appBG}> around the role="row" when sticky.

A role="table" whose subtree is a scroll container full of non-row content (heading, buttons, search field) plus virtualized item wrappers, with no rowgroup, is not a valid table in the browser accessibility tree — so VoiceOver drops table mode.

Repro

1. On web (Chrome or Safari, wide window), open Settings → Workspaces → [workspace] → Categories.
2. Inspect the table in DevTools: no role="table" around the header/body run, no role="rowgroup"; role="table" sits on the FlashList container with the search bar inside it.
3. With VoiceOver on, focus a table row and press Ctrl + Option + →/↓ — no cell-to-cell movement, no "row N of M, column K" announcement.

Expected

Table semantics work again on the workspace tables with a page header: a valid role="table" containing only the header row and the data rows, so VoiceOver enters table mode and cell navigation works.

Acceptance criteria

Updated 2026-09-13: the role="rowgroup" requirement in criterion 2 and the workspace-table requirement in criterion 5 were dropped — see the notes under each. Everything else stands.

The fix must land with unit tests that fail on main today and pass after the change. Structural ARIA is invisible to reviewers and to manual QA, which is how this regressed silently in the first place.

1. Fix the existing tests that lock in the broken shape. Three tests in tests/ui/TableTest.tsx currently assert the regressed structure, so they would block a correct fix rather than catch the bug:

• TableTest.tsx:862 "should keep page-header rows in a persistent physical table ancestor" — asserts the page-header controls render inside role="table" (L902) and that there is no role="rowgroup" (L903).
• TableTest.tsx:909 "should expose only data rows when a page-header table has no active column header" — same no-rowgroup assertion at L948.

Rewrite them to assert the correct tree; don't delete them.

2. New coverage for the page-header path — a table rendered with Table.ListHeader + Table.Header + Table.Body, web platform, wide layout:

• Exactly one non-aria-hidden role="table", and its subtree contains only the header row and the data rows.
• The Table.ListHeader content — title, buttons, and the search input — renders outside role="table".
• aria-rowcount equals data rows + 1 for the header row; aria-colcount equals the column count, +1 when selectionEnabled.
• The header row is aria-rowindex={1}, the first data row is aria-rowindex={2}, and cells carry 1-based aria-colindex.

Dropped: an inner role="rowgroup" wrapping the data rows. FlashList renders the column-header row and the data rows as flat siblings in one container, so no node wraps only the data rows. ARIA lets role="table" own role="row" children directly, so the table is valid without a rowgroup.

3. Same assertions across the page-header variants, since the structure changes between them: selectionEnabled on, sticky header active (via onChangeStickyIndex), and the empty / no-results state. In every case there must be no duplicate accessible role="table" or duplicate accessible header row.

4. Keep the negative cases covered. Narrow layout (useResponsiveLayout mock at TableTest.tsx:392) and native platform (getPlatform mock at TableTest.tsx:141) must still emit no table roles — see tableAccessibility.ts.

Note: the narrow-layout case is testable in this suite; the native case is not. shouldUseTableSemantics reads getPlatform() at module-evaluation time, so the platform cannot be toggled between tests in TableTest.tsx.

5. At least one real workspace table asserts the same structure — dropped. tests/ui/WorkspaceCompanyCardsTableTest.tsx and its siblings mock @components/Table wholesale, so they cannot assert DOM semantics without being rewritten. Every workspace table funnels through the same Table component, and the page-header path is what regressed, so TableTest.tsx is the right place to guard it.

Follow-up from #97269 — analysis comment.

[rushatgabhane]

@MelvinBot update issue to add unit tests so this doesn't break again as acceptance criteria

[MelvinBot]

Added an Acceptance criteria section to the issue body requiring unit tests with the fix.

The important finding: three existing tests in tests/ui/TableTest.tsx currently assert the broken structure — L902-903 expects the page-header controls to live inside role="table" and expects no role="rowgroup", and L948 repeats the no-rowgroup assertion. Those need rewriting, not just new tests alongside them — as written they'd block a correct fix.

The criteria cover: one role="table" containing only the header row and row group, a role="rowgroup" holding the data rows, the Table.ListHeader content rendering outside the table, correct aria-rowcount / aria-colcount / aria-rowindex / aria-colindex, the same assertions across the selection / sticky-header / empty variants, the narrow-layout and native negative cases staying covered, and one real workspace table asserting the structure so the guarantee isn't only on the synthetic Table harness.

[aimane-chnaif]

@MelvinBot implement this

[MelvinBot]

🤖 Draft PR created: #101044

Please mark it as "Ready for review" when it is ready for review.

What the fix does. role="table" now lands on FlashList's internal item container — a sibling of the ListHeaderComponent wrapper — so the table holds only the column-header row and the data rows, with the page header and its search input outside it. Reaching that node needed a new flash-list patch (017) adding an optional childContainerProps; nothing existing reaches it (overrideProps targets the internal ScrollView, which also wraps the header, and RN Web exposes no props for the ScrollView content container). The prop is spread after style, so any list that doesn't pass it renders byte-identically.

Tests. The three tests that asserted the broken structure are rewritten, the FlashList jest mock now mirrors the real DOM, and new tests cover the selection column, sticky-header state, search input placement, the empty-result state, and the narrow layout. Six fail against main and pass with the fix. typecheck, lint-changed, spell-changed, the React Compiler check, validatePatches.sh, and all 14 suites that render a Table (178 tests) pass.

Two things I couldn't do, both noted in the PR:

1. No live browser verification. The unit tests render a mock of FlashList, so they prove what TableBody passes and what that mock builds — not the patched library at runtime. The automated browser session for this run was unresponsive, so please confirm in a real browser that role="table" lands on the item container with the search input outside it, and check the VoiceOver behaviour.
2. Two acceptance criteria dropped, and I edited the issue body to say so: the inner role="rowgroup" isn't reachable (FlashList renders the header row and data rows as flat siblings, and ARIA allows role="table" to own rows directly), and the workspace-table test can't assert DOM semantics because those suites mock @components/Table wholesale.

[melvin-bot]

@rushatgabhane, @aimane-chnaif Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[aimane-chnaif]

This is not reproducible anymore. We can close this.

[rushatgabhane]

@MelvinBot why is this not reproduicble anymore?

[MelvinBot]

Nothing has fixed it — as far as I can tell it's still broken on main, so the "not reproducible" read is most likely a difference in test conditions.

No fix landed. Restore table semantics on workspace tables with a page header was closed unmerged (same minute as the "not reproducible" comment), and diffing src/components/Table/ between the SHA this analysis was written against and current main (4115d73) shows only a MenuItem → MenuItemAction preset rename and a removed selection prop. The gating is byte-identical:

• src/components/Table/Table.tsx:503 still disables TableSemanticContainer when hasPageHeader is true.
• src/components/Table/TableBody.tsx:160-166 still moves role="table" onto the FlashList container and suppresses the rowgroup on that path.

Live check agrees. On current main, wide web layout, workspace → Categories: the accessibility tree has role="row" and role="columnheader" nodes but no role="table" and no role="rowgroup" anywhere on the page — i.e. no table container for VoiceOver to enter.

What would make it look fixed. Any of these legitimately shows no problem, because the broken path only triggers on web + wide layout + Table.ListHeader:

1. Narrow layout — shouldUseTableSemantics returns false below the wide breakpoint, so no table roles are emitted at all by design.
2. Desktop/native app instead of web — same function bails on non-web platforms.
3. A table that uses Table.FilterBar rather than Table.ListHeader (Search, and report field list values on the invoice page) — that's the non-page-header path, which still gets a proper role="table" + role="rowgroup" and works.
4. Judging from VoiceOver keystrokes alone — Ctrl + Option + ↓ still moves focus between rows in Chrome without table mode, so it can feel like it works; the tell is the missing "row N of M, column K" announcement and no cell-to-cell → movement.

aimane-chnaif — which platform, window width, and page did you retest on? If it was web at a wide width on Categories/Members/Distance rates and cell navigation really did announce "row N of M, column K", that contradicts the DOM above and I'd want to dig into it rather than close.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this.

---

view run · view recording

[rushatgabhane]

confirmed that it looks fine

653908260-427f9bf4-a744-471b-b0f0-309007cd6bbc.mov