R46 and R77 failing on th with role="rowheader"

[dan-tripp-siteimprove]

On my "base example" below, R46 and R77 are failing. I think that they should pass - that is, if I'm reading ARIA in HTML correctly, where it says "If the ancestor table element is exposed as a role=table, then columnheader, rowheader and cell are allowed..." Of course, next it says "... but NOT RECOMMENDED". At any rate:

<h2>Base example.  From customer page.  Cells in top row fail R46 and R77.</h2>
<table>
	<tbody>
		<tr>
			<th role="rowheader">a</th>
			<td>b</td>
			<td>c</td>
		</tr>
		<tr>
			<td colspan="3">d</td>
		</tr>
	</tbody>
</table>

<h2>Base example + bottom row removed.  Cells in top row pass R46 and R77.</h2>
<table>
	<tbody>
		<tr>
			<th role="rowheader">a</th>
			<td>b</td>
			<td>c</td>
		</tr>
		<!--
		<tr>
			<td colspan="3">d</td>
		</tr>
		-->
	</tbody>
</table>

<h2>Base example + bottom row given a th with scope="row".  Cells in top row pass R46 and R77.</h2>
<table>
	<tbody>
		<tr>
			<th role="rowheader">a</th>
			<td>b</td>
			<td>c</td>
		</tr>
		<tr>
			<th scope="row">d</th>
			<td>e</td>
			<td>f</td>
		</tr>
	</tbody>
</table>

<h2>Base example + bottom row colspan removed.  Cells in top row still fail R46 and R77.</h2>
<table>
	<tbody>
		<tr>
			<th role="rowheader">a</th>
			<td>b</td>
			<td>c</td>
		</tr>
		<tr>
			<td zzzcolspan="3">d</td>
		</tr>
	</tbody>
</table>

<h2>Base example + role="rowheader" replaced with scope="row".  Cells in top row pass R46 and R77.</h2>
<table>
	<tbody>
		<tr>
			<th zzzrole="rowheader" scope="row">a</th>
			<td>b</td>
			<td>c</td>
		</tr>
		<tr>
			<td colspan="3">d</td>
		</tr>
	</tbody>
</table>

[hiSandog]

This seems worth capturing as a narrow regression around R46 and R77 failing on th with role="rowheader". The report already points at a concrete failure mode; a test that covers the failing input and the expected behavior would help keep the fix from becoming a one-off patch.

[wittjeff]

Claude Fable offers:

Investigation of #1883
TLDR: I reproduced the report against alfa main and found the root cause. Alfa is faithfully implementing the HTML spec's header-assignment algorithm, which completely ignores ARIA roles — so the explicit role="rowheader" is used to decide the rule applies to the cell but never to decide whether it passes. By the letter of ACT rule d0f69e alfa's behavior is conforming, but it's a real-world false positive: Chrome exposes the cell as a rowheader (I verified via the CDP accessibility tree).

Root cause
Both R46 and R77 delegate header association to cell.headers from @siteimprove/alfa-table, which implements the HTML "algorithm for assigning header cells". The failing has no scope, so scope is auto, and the spec's definitions resolve it (table.ts:984-1039):

• Not a column header — its row contains data cells ("b", "c").
• Not a row header — its column contains a data cell: the colspan="3" td "d" covers slot (0,1), i.e. column 0.
  A header that is neither gets blocked in the scanning algorithm's step 9.4 and is assigned to nothing. Result (reproduced with a local vitest run): th "a" has no assigned cells → R46 fails; cells b/c/d have empty headers → R77 fails. The model output confirms it — every cell in the base example has headers: [].

This explains all five variants in the issue precisely. Note the colspan is a red herring — the "zzzcolspan" variant still fails because any data cell below the th in column 0 disqualifies it as an auto-scope row header. The variants that pass all remove the data cell from column 0 (delete the row, or make "d" a header) or bypass auto-scope entirely (scope="row").

The crux is an applicability/expectation asymmetry in R46: applicability selects the th using ARIA semantics (hasRole(device, "rowheader", "columnheader") — the explicit role is honored), but the expectation computes assignment through the HTML table model, which has no concept of ARIA. So the rule effectively says "you declared this a rowheader, therefore it must have assigned cells" and then computes assignment with an algorithm that doesn't know about the declaration.

Is it a bug?

• Per ACT rule d0f69e (which R46 implements): assignment is explicitly defined via HTML's "forming relationships between data cells and header cells", so alfa matches the ACT rule's letter. No ACT test case covers this shape.
• Per real browsers/AT: Chrome's accessibility tree exposes "a" as rowheader (verified headlessly), and screen readers derive row-header association from the explicit role and position — so users do get the header. The issue author's reading of ARIA in HTML is correct: the role is allowed (though NOT RECOMMENDED) on a th inside a native table.

So: technically ACT-conforming, but a false positive in practice — the page's real fix is scope="row", yet failing conforming markup that AT handles fine is hard to defend to customers.

Fix options, if a PR is wanted

1. Rules-level (recommended): In R46's expectation, treat a th with an explicit rowheader/columnheader role as if it had row/column scope — i.e. pass if a cell/gridcell exists in the row(s)/column(s) it spans. Mirror in R77: a data cell counts as headed if its row contains a perceivable explicit rowheader (or its column an explicit columnheader). Only these two rules consume cell.headers, so the blast radius is small.
2. Table-model level: Teach isRowHeader/isColumHeader to read the role attribute. Smaller diff, but alfa-table currently has no ARIA dependency and is a deliberately pure HTML-spec implementation — mixing layers there feels wrong.
3. By-design close: point to ACT d0f69e and recommend scope="row". Defensible, but leaves the false positive.