Clarify use case for aria-selected for 'grid' role descendants

[turjmner8]

Issue Description

When dealing with something like selection states in a 'grid' role element, aria-selected='true' can be set on both, 'row' role elements and 'gridcell' elements. For a grid supporting single or multiple cell selection, it makes sense to set aria-selected on the cells themselves.

For row selection concepts, to me it seems like the spec implies that the 'row' elements would have aria-selected of true/false, but that is not actually specified as far as I can tell, and some screen readers don't seem to convey that information.

For column selection concepts, it is much less clear, especially if only single selection is allowed (with aria-multiselectable set to false on the 'grid' itself). If a column was going to be marked as selected, it seems like the only viable way of doing that would be to mark every cell in the logical column as selected, though that would seem to run contrary to multiple selection not being allowed. It is also not as clear in that case what elements aria-selected='false' would be required / expected to be set on for non-selected columns (just the 'columnheader' role elements, or all cells?)

I have tested a number of combinations of aria-selected being set on different role elements, and I don't seem to be able to find a consistent way of representing row and column selection, but I'm not sure what combination is really expected or should be expected.

If the current aria-selected concept is not quite capable of handling these concepts without introducing ambiguity as to what is actually selected / selectable in a 'grid' element, would it be possible to look into introducing more specific aria attributes to help clarify? Potentially aria-column-selected, aria-row-selected, etc...

Thanks for any clarifications here.

Link to the version of the specification or documentation you were looking at at.

Link to documentation:

https://www.w3.org/TR/wai-aria-1.2/#aria-selected

https://www.w3.org/TR/wai-aria-1.2/#aria-multiselectable

https://www.w3.org/TR/wai-aria-1.2/#row

https://www.w3.org/TR/wai-aria-1.2/#gridcell

https://www.w3.org/TR/wai-aria-1.2/#columnheader

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)?

Yes

[scottaohara]

again, this PR might help with at least some aspects of this issue - #2390

[spectranaut]

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

[turjmner8]

So my thoughts behind this is that there are valid use cases where interactions with grids involve only being able to select rows, columns, or individual cells. There are also cases where interactions with grids can involve selecting any combination of those things, not necessarily just cells or just rows.

For visual users, this is very apparent based on background color or border changes that can clearly apply to all cells in the row or column, or just the cell interacted with.

For unsighted users though, the markup available for selection state is just on the cell element (or potentially the row element), but does not convey anything about other related cell selection state updates. Even with just aria-selected being available on row and cell elements today, it doesn't seem like screen readers distinguish between the 2 locations much if at all, and at a minimum it would be potentially helpful to clarify the intent here. If the row element was not required anymore due to the desire to have less restrictive DOM setups though (my other suggestion: #2402), then it would be even harder for a non-sighted user to know if they just selected a row vs a cell vs a column even with that distinction.

[smhigley]

@turjmner8 could you clarify what question you have, or what changes are being suggested, to the ARIA spec? While you've raised some interesting examples (e.g. designing screen reader UX for column selection), they seem more like authoring UX decisions rather than spec-related issues.

If the question is why aria-selected is supported on role=row elements, the answer is because keyboard navigation patterns in treegrids and occasionally grids can send focus to those elements. When up/down arrow keyboard navigation moves focus between rows rather than only gridcells, the selectable row element itself must expose aria-selected for it to be conveyed to screen reader users making use of that scripted navigation pattern. The same consideration does not exist for columns because, just by the nature of how the DOM works, there is no column element that could gain keyboard focus or be reached by the screen reader's virtual cursor.

In cases where the row element has aria-selected, authors may choose to also set aria-selected on gridcells, both because keyboard navigation should also set focus to those elements, and because built-in screen reader table navigation commands will move the virtual cursor directly to cells.

The question of whether to expose column selection on only column headers or on body cells as well is interesting, but should probably be decided on a case-by-case basis depending on the specifics of your grid's features and information hierarchy (and also ideally based on direct feedback from screen reader users on your specific UX). The goal of ARIA is more to support all valid UX patterns rather than to dictate how something like column selection must be designed.

Does that roughly address what you were asking? If not, could you provide specific examples showing the use case or cases you would like ARIA to support, that it does not currently cover?

[turjmner8]

Thanks for the information - that is helpful!

In cases where the row element has aria-selected, authors may choose to also set aria-selected on gridcells, both because keyboard navigation should also set focus to those elements, and because built-in screen reader table navigation commands will move the virtual cursor directly to cells.

Specifically, my main question is for a 'grid' role implementation that allows users to select only rows (never individual cells themselves), what is the expected aria-selected markup for the various row and cell elements? No matter which I choose (only the 'row', only the 'gridcell' elements in the row, or all of the above), it seems that various screen readers like JAWs and NVDA don't seem to act as I'd expect, and it was unclear to me if that concept is really supported by the existing spec. If it is, I'm curious which combination I should move forward with and look to file bugs on screen readers that have issues with it. Otherwise, if it is not really supported, I think it would be very useful to include updates to the spec to help clarify selection concepts between rows and cells for these common UX behaviors.

And then more of a secondary thought, if it really is the 'row' element as I kind of thought was being implied in the spec, how might that translate to a grid that allows only for column selections but not individual cells since there is no 'column' element? The various Grid implementations I am working on can have 1 or more types of these selections enabled at any given time (rows, columns, or individual cells) depending on the use case for the given page, and it didn't seem like just the 'gridcell' and 'row' element support for aria-selected really allows for screen readers to distinguish between what is selected in these cases.

Thanks again for the help here.