Clarification on <th> contextual mapping

[rahimabdi]

I would propose adding some additional guidance on how <th> should be mapped that takes into account whether <th> is a child of <thead> (computes as role="columnheader") or <tbody> (computes as role="rowheader").

I'm unable to identify where this is explicitly stated in the HTML spec or ARIA in HTML.

Current <th> mappings in html-aam:

• 3.4.132 th (is not a column header, row header, column group header or row group header, and ancestor table element has table role)
• 3.4.133 th (is not a column header, row header, column group header or row group header, and ancestor table element has grid or treegrid role)
• 3.4.134 th (is a column header or column group header)
• 3.4.135 th (is a row header or row group header)

Relevant <th> role test in wpt/html-aam/table-roles.html and its results: https://wpt.fyi/results/html-aam/table-roles.html?label=experimental&label=master&aligned

[cookiecrook]

In addition to or instead of the el-th-in-row test, I think we should split that into a few more:

• el-th-in-thead-row (default columnheader?)
• el-th-in-non-thread-first-row (columnheader if layout table heuristic not triggered? maybe add table and cell borders to avoid the layout table heuristic?)
• el-th-in-non-thread-second-row (rowheader? ditto re: layout table heuristic)
• el-th-in-tbody-row (always rowheader?)
• el-th-in-tfoot-row (always rowheader?)

[cookiecrook]

Meant to add that label to the related WPT issue, not this one.

[cookiecrook]

WG update... @scottaohara FYI... We'll agenda+ once the other tests are written...

[JAWS-test]

I would propose adding some additional guidance on how th should be mapped that takes into account whether th is a child of thead (computes as role="columnheader") or tbody (computes as role="rowheader").

I would advise against this because it would destroy many tables in terms of accessibility. Many tables use th in the tbody in auto state for column headers. This is defined in the HTML spec. Your suggestion would turn the column headers into row headers and the tables would no longer work

[rahimabdi]

I would advise against this because it would destroy many tables in terms of accessibility. Many tables use th in the tbody in auto state for column headers. This is defined in the HTML spec. Your suggestion would turn the column headers into row headers and the tables would no longer work

Hello @JAWS-test!

If I'm understanding correctly, although <thead> should be where table columns are defined (excluding complex tables), authors still use <th> as descendants of <tbody> and would expect a default mapping of columnheader unless explicitly overridden via scope.

To clarify, I raised this issue to provide clarity on <th> mappings in various contexts from my observations in writing WPT tests and how browsers currently behave; from the display: contents WPT test, I'm observing that <th> in a <tbody> context maps to rowheader in several browsers despite the default auto value of scope. This may be a bug per your reasoning but I think guidance somewhere (if not in HTML spec) would be valuable.

As @cookiecrook noted above, additional testing would reveal how browsers currently treat <th> to provide more consistent cross-browser behavior expectations and non-ambiguity of table header mappings in general.

[JAWS-test]

authors still use as descendants of and would expect a default mapping of columnheader unless explicitly overridden via scope.

Partly correct. The HTML specification states:

A header cell anchored at the slot with coordinate (x, y) with width width and height height is said to be a column header if any of the following are true: ... the cell's scope attribute is in the auto state, and there are no data cells in any of the cells covering slots with y-coordinates y .. y+height-1.

and

A header cell anchored at the slot with coordinate (x, y) with width width and height height is said to be a row header if any of the following are true: ... the cell's scope attribute is in the auto state, the cell is not a column header, and there are no data cells in any of the cells covering slots with x-coordinates x .. x+width-1.

This seems to me to be a sufficient definition and no deviating definitions should be made. If you don't like this definition, you should open a ticket at whatwg. And if the browsers deviate from this, they are faulty and this should be reported to them so that they can correct the error