Replies: 3 comments 1 reply
-
I got kind of nerd-sniped by this idea and made a codepen: https://codepen.io/melsumner/pen/BabgZmp Does it accurately reflect what you're describing? |
Beta Was this translation helpful? Give feedback.
1 reply
-
related - #1138 and my issue that we closed as duplicate #1853 |
Beta Was this translation helpful? Give feedback.
0 replies
-
+1 on this. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions