Confusion about how "assigned" headings work with ARIA [d0f69e]

[WilcoFiers]

I was looking over the Table header cell has assigned cells rule to share it with AG, but looking over it again I'm not so sure this is ready. The main issue is of this rule using HTML's "assigned headings" definition.

First up, this rule assumed aria-owns isn't used to create structure in the tree. The application relies on the flat tree rather than the accessibility tree to decide whether a headercell is in a table/grid.

The assigned headings algorithm itself assumed its only ever applied to th / td elements inside a table element. It too doesn't account for aria-owns. It uses scope and headers attributes as though those are supported (which they may not be on an element with an explicit role).

It may very well be that the HTML 5 algorithm with some modifications can be made to work for tables built with ARIA, but someone would actually need to do that. Right now the rule as written would for example allow the headers attribute to be used on <div role="cell">, which doesn't seem right. Nor do I think the rule should ignore the possibility of people using aria-owns inside tables.

[Jym77]

Yep, this has been a problem for some time, see #1971.

[dd8]

There are various interop issues with assigning headers - see "Header calculation" in blog article below. There's also a design problem with the HTML headers attribute - Accessibility APIs expose ColumnHeaders and RowHeaders properties but the headers attribute has no way to indicate which IDs are row headers and which are column headers.

https://www.powermapper.com/blog/table-headers-and-scope/

[Jym77]

Decision:

• restrict the rule to HTML tables, possibly continuing on #1971.
• @WilcoFiers to reach out to ARIA group to ask how ARIA tables are supposed to work and assign headers.