Should aria-selected be allowed on row, columnheader, or rowheader in table?

[zcorpan]

aria-selected is defined as

Indicates the current "selected" state of various widgets.

https://w3c.github.io/aria/#aria-selected

aria-selected is a supported state for row.

row is allowed in table.

A table is not a widget.

Does this make sense? It seems to me that, if you can select rows in a table, it should be a widget, and thus use the grid role.

cc @spectranaut

[joanmarie]

Answer: No.

[joanmarie]

To be clear, my "Answer: No" is to the issue summary (should aria-selected be allowed on row in table?). What you say in the opening report does indeed "make sense." 😄

[mcking65]

Expanding scope of this issue because columnheader and rowheader are also allowed in table and should not be selectable in that context.

[mcking65]

Essentially, this is another side effect of the ontology where we have a widget branch and a structure branch. In some cases like table and grid, we have elements that are structurally identical but one is static and the other is interactive. The ontology is inconsistent for required owned elements. For instance, we have cell and gridcell to distinguish the differences between static cells and interactive cells. We do not have analogous distinctions for row, columnheader, or rowheader.

Consider nested lists and trees. We have 100% separation in the ontology. If you want an interactive hierarchical list, you use tree, with groups of treeitem elements nested in treeitem elements. And, if you want nested static lists, you use list elements nested in listitem elements. Since we do not have a concept of control patterns, this is probably how table and grid should be.

As it is we use hacks that can be confusing and make the spec complex. For instance, we opted to make separator a widget only if it is focusable. We could do something similar for row, columnheader, and rowheader, making it a widget only if it is in the grid context.

[joanmarie]

Consensus from TPAC: Make the necessary changes in the spec. We shouldn't need to make any changes elsewhere (APG or Core-AAM). In addition, we don't anticipate needing testing, etc. because this will fall under the category of "handling authoring errors" which is all user agents SHOULD statements.

[zcorpan]

In addition, we don't anticipate needing testing, etc. because this will fall under the category of "handling authoring errors" which is all user agents SHOULD statements.

Hmm, is that a policy ARIA has? If so, I disagree with it; I think it's important to achieve interoperability for error handling.

[jnurthen]

@zcorpan thanks for the comment.
Looking at the spec in more detail I find
"User agents MUST ignore non-global states and properties used on an element without a role supporting the state or property; either defined as an explicit WAI-ARIA role, or as defined by the host language WAI-ARIA semantic matching an appropriate WAI-ARIA role."
So it does seem that according to the spec text we should require that an invalid attribute is not exposed to the a11y API.