The aria-rowindex attribute being permitted on cells seems like a footgun

[bathos]

1. The aria-rowindex attribute is permitted on elements with the roles cell, row, columnheader, gridcell, and rowheader.

2. In the case of role row, it’s explained well what the meaning of aria-rowindex is.

3. Regarding the rest, the spec says “Authors MAY also place aria-rowindex on all of the children or owned elements of each row.”

4. Also regarding the rest, statements are made like “Authors MUST ensure elements with role gridcell are contained in, or owned by, an element with the role row.”

I think this is pretty confusing for two reasons.

First, I don’t think it’s stated that if aria-rowindex is present on a role=cell (etc) element that the indicated index must be the same as the explicit or implicit index of the required ancestor/owner row-roled element. However it seems like it must be, right? If not, it’s not explained what would happen. Assuming it does need to be, then, it’s unclear what purpose there would be to adding the attribute to anything other than a row-roled element.

The bigger issue is that I think this sets up a misuse booby-trap for devs. If you look up aria-rowindex, you’ll learn that it’s legal on cells — and there’s a chance that’s exactly what you were hoping to find, because a natural question is “can I use aria-rowindex on my gridcells to communicate position instead of having row-roled element parents?”

The answer is no, but to learn that you have to look at the definitions of the roles, not the attribute, so it’s easy to mistake ‘permitted on gridcell’ for yes. This is significant because the requirement for row elements is no longer as obvious as it once was. Due to CSS grid layout, the requirement for rows makes grid-related JS, HTML and CSS all more complex than they would otherwise need to be, which is why I think a lot of people will be looking up this property to check if it’s a valid alternative.

In other words:

• it seems confusing because it appears pointless
• it seems dangerous because at a glance it looks like aria-rowindex does provide a solution to the unusability of CSS grid for styling ... grids.

My suggestion would be to include a note in the aria-rowindex definition that explains that it isn’t a valid alternative to having row-roled elements. But it’s also possible I’m misunderstanding something significant here, since it seems pretty odd for an attribute to be explicitly permitted on elements where it would seemingly never do anything.

[JAWS-test]

I think aria-rowindex is allowed on gridcell and cell because aria-colindex can usually only be located at cell or gridcell

To allow aria-rowindex at cell, gridcell etc. has the advantage that then aria-rowindex and aria-colindex can be at the same element.

[bathos]

I agree that that would be advantageous if aria-rowindex and aria-colindex were both sufficient for establishing rows and columns. The issue is that row, unlike column, actually does require an element with the row role, and that row will have a specific rowindex, whether implicit or explicit. It’s left undefined what occurs if the aria-rowindex stated on a cell is different from the rowindex of its row, but as far as I can tell it would always be an error. That means aria-rowindex on a cell can only (a) be redundant or (b) be an error or maybe (c) lead to undefined behavior.

[JAWS-test]

I think the specification is a bit imprecise here because it does not say whether it is allowed to assign an aria-rowindex only on the cell and not on the row:

Authors SHOULD place aria-rowindex on each row. Authors MAY also place aria-rowindex on all of the children or owned elements of each row.

If allowed, it would not be redundant. If it's not allowed, it would be redundant or faulty

[jnurthen]

@aleventhal is this still in scope for 1.3?

[pkra]

From @scottaohara on #1853 (comment)

note to self: need to run some tests for current support for aria-rowindex on cells and what gets exposed, if anything.