Should the 'row' role really be necessary for parents of 'gridcell' and other cell role elements?

[turjmner8]

Discussed in #2128

^{Originally posted by turjmner8 February 22, 2024}
In general, would it be possible to remove the requirement for role 'gridcell' elements to be contained within role 'row' elements in a future spec? Newer DOM approaches like CSS grid are available to simplify the construction of grid structures that do not really support having a row-like element wrap all the given 'cell' elements of a logical row. Additionally, it's not quite clear to me how someone would be able to construct a 'row' role compliant grid for cases where cells span multiple rows without using TR elements, which introduces other sizing issues that do not exist when using more modern DIV / CSS strategies.

It seems like aria-rowindex, aria-colindex, etc... on 'gridcell' role elements themselves should be enough to convey what logical row and column a given 'gridcell' element belongs to even if its parent was a 'grid' role element rather than an additional 'row' role element.

I may be missing some nuance here, but the only thing that seems a little unclear would be not being able to set aria-selected on the containing 'row' element if row selection is supported. In general, it also feels like selections when dealing with tables/grids could also benefit from some enhancements though (how to tell if a row vs column vs individual cell is selected for example). Specifying aria-selected on 'row' role elements vs 'gridcell' role elements does not seem to make much of a difference in current screen reader impls (NVDA, JAWS, voiceover, etc...)

Thanks for any feedback / info here.

[turjmner8]

I'm wondering if there could be any additional input on this for future consideration. There was some feedback in the discussion I posted initially, though not much activity after that.

Developing higher complexity grid implementations is very difficult to make accessible with the current DOM restrictions that enforce a containing 'row' element for all cells in a logical row. In addition to the comments above, I have requirements where visible row header cells also need their own horizontally scrollable region, and that is impossible to implement in a 'grid' role due to all cells within a given logical row needing to be children of a single 'row' element.

[scottaohara]

re-posting the related issues that this touches on - #1138 and my issue that we closed as duplicate #1853

another related issue to consider with this #1386

and this PR might actually counter balance the mentioned gap of not being able to select a row of cells - if a row were not to exist - #2390

All that said - is setting a row to display: contents also a way to mitigate an issues between needing to use a role=row and wanting more styling flexibility with CSS's grid layout? My understanding is that it could help here... but i also admittedly have avoided using that display value due to previous a11y issues

[turjmner8]

All that said - is setting a row to display: contents also a way to mitigate an issues between needing to use a role=row and wanting more styling flexibility with CSS's grid layout? My understanding is that it could help here... but i also admittedly have avoided using that display value due to previous a11y issues

Oh, that is an interesting idea - I can certainly try out some proof of concepts in that area and will report back on how it goes.

[turjmner8]

Sorry for the accidental close - reopened

[nickygencs17]

+1 on this

[turjmner8]

At least for my preliminary testing, using display:contents seems to help quite a bit. I still can't get a scenario to work where something like a set of rowheader columns have there own scrollable region, but I am able to move forward with a single scrollable CSS grid implementation so far.

I think it would be still be helpful to not require 'row' elements if there is additional markup that could be introduced to simplify the DOM structure and enable more complex scrollable regions in its place.

[scottaohara]

thanks for checking that out @turjmner8. too bad it didn't solve all the use cases you were looking for. but with that said, would you be at liberty to share some examples / reduced test cases with us for what it is you're trying to create? we talked about this a bit in the ARIA working group today, and there was interest in the idea - but people wanted some use cases to check out so they could understand it better.

[spectranaut]

Discussed briefly in today's meeting: https://www.w3.org/2025/01/16-aria-minutes.html#58d7

[turjmner8]

thanks for checking that out @turjmner8. too bad it didn't solve all the use cases you were looking for. but with that said, would you be at liberty to share some examples / reduced test cases with us for what it is you're trying to create? we talked about this a bit in the ARIA working group today, and there was interest in the idea - but people wanted some use cases to check out so they could understand it better.

Sure, would be happy to write up a rough codepen of the type of layout - not sure it will have all of the actual keyboard support it eventually will, but at least the simplest core scrolling regions that I am looking to find support for. Thanks!

[turjmner8]

Some rough samples - feel free to let me know if anything looks off with them or there are more questions / concerns.

In the first demo below, the individual cells do not have containing 'row' role elements, but have aria-colindex and aria-rowindex set on them to convey their logical rows and columns. This allows the individual cells to be part of a simple CSS grid layout that can utilize sticky positioning for column and row headers as well, and is an example of what I am hoping can become a valid 'grid' role implementation with the requested change.

https://codepen.io/turjmner8/pen/azojNxV

In order to achieve an acc-compliant grid today, using the display:contents suggestions, this next demo shows the same basic grid with additional 'row' role elements. These extra elements don't really cause much of an issue for this simple case, but do have a negative impact on rendering performance of larger grids by a noticeable amount without really adding any new information or functionality when compared to the first demo.

https://codepen.io/turjmner8/pen/QwLBpOx

Finally, the last demo below shows a more complex grid setup where there are multiple row headers that are rendered within their own horizontally scrollable region separate from the rest of the grid body. This is an additional requirement I am working with that I don't believe is achievable with a valid 'grid' role implementation due to the 'row' role requirement. The row headers themselves need to be children of a different scrollable region than the rest of the logical row's cells, but also need to share 'row' element ancestors. The aria markup I've included follows the same pattern as my first demo, where all of the cells (header and non-header) specify aria-rowindex and aria-colindex, which should be enough to convey the logical grid structure.

https://codepen.io/turjmner8/pen/ogvMZdx

[JAWS-test]

I checked the first example with Firefox: Firefox only recognises the grid, not the gridcell roles. This means that table navigation is not possible at all with NVDA.
Chrome, on the other hand, recognises grid and gridcell, but all gridcells are in one row due to the lack of role=row, so that NVDA outputs 32 columns in one row during table navigation.

[scottaohara]

@JAWS-test the point of the demos weren’t that we thought they would work, but we wanted to see what was trying to be achieved

Thanks @turjmner8. This will give the group something to mull over.