w3.org states elements with role='gridcell' should be owned by an element with role='row'

[MarkFalconbridge]

https://www.w3.org/TR/wai-aria-1.1/#grid states that elements with role='gridcell' should be owned by an element with role='row'.

With the current implementation of FixedSizedGrid or VariableSizedGrid I don't think this is possible as there aren't any elements surrounding a row of cells once rendered in the DOM.

Is this something that could be added so that full aria support becomes possible?

[bvaughn]

Grouping grid cells into rows is not something I'm interested in doing. Adding the overhead of additional DOM element wrappers to performance sensitive areas like grid doesn't feel like a worthwhile tradeoff.

Is there a different aria role that would be better suited to the current DOM structure?

[MarkFalconbridge]

Unfortunately not, I've definitely got a grid of data to present and according to that spec, elements with role gridcell, columnheader, or rowheader are owned by elements with role row, which are in turn owned by an element with role rowgroup, or grid. What this means in practice is that users who use assistive technologies may not get a full picture of how the data in the grid is structured.

[thielium]

I can second that this is an issue for my team.

The only way I know how to fulfill this requirement now is using React.Children to traverse the items passed into the inner element and using the items' props to group them into rows. Performance cost aside, there are problems with this approach, one being that it's not very idiomatic to have props travel up from the children into the parent like that.

I have an idea I'm not yet happy with that explores exposing a rendering mechanism for such purposes. It solves accessibility challenges, but it only partially enables sticky row / column handling, which I sort of feel like is in the same category as this (i.e. cell decoration and grouping). I also am sympathetic to not wanting to expose too much of the inner workings to prevent the API from getting cluttered.

But I'm very interested in this particular issue's resolution. I don't want to be pedantic, but the language in the spec that @MarkFalconbridge linked to is actually a little more forceful (emphasis not added):

Authors MUST ensure elements with role gridcell, columnheader, or rowheader are owned by elements with role row, which are in turn owned by an element with role rowgroup, or grid.

Beyond just wrapping things with a role="row", things like headers are pretty tough to achieve without some fine-grained controls.

Happy to help on this one, if you find a solution but don't find the time, @bvaugh.

[bvaughn]

Realistically, I don't think I'll invest time in this issue any time soon. I may even prefer to remove the current role entirely rather than add wrapping layers. I think a lot of existing advanced usage of innerElementType might be broken by such a change, and there are performance implications, implications on things like sticky rows/cols, etc.

[thielium]

Definitely respect the zero sum game of open source time management.

Would you be interested in PRs that are:

• Not breaking changes;
• Expose the ability to add wrapping, but don't put the burden on react-window?

[bvaughn]

I'd love to review ideas, yes. Can't promise to land them, but it would be helpful for discussion.

[nahumzs]

Wondering if #218 has any plans to happen. Lacking screen reader accessibility is totally a deal-breaker for me and my company. Sad that we invested some time with this library to realize this is not possible to be used in a production environment where accessibility is required.

Maybe adding a note on the readme file would help to be aware of the lack of accessibility support for this specific scenario?

I think for this specific case https://bvaughn.github.io/react-virtualized/#/components/Table is a solid alternative.

By the way, thank you for the amazing work @bvaughn