React Table Component Deprecation Discussion

[jack-ryan-nava-pbc]

Building off of the work that the eminent @zarahzachz has done in this RFC, we at the Design System are looking to deprecate the React-based Table component.

The current motivations are:

1. The current API does not offer much beyond using HTML
2. The current API can be confusing, and that confusion can in lead to non-ideal implementations

The goal of this discussion is two fold:

1. Build awareness of our intent to deprecate this component
2. Learn from our community of product teams to provide examples and guidance that better serve their needs

Timeline for deprecation:
We don't have one at the moment. We no immediate plans to remove the React-based Table component. However we are beginning to offer more thorough guidance on creating tables in the hopes that folks will begin to migrate to using our CSS and HTML patterns.

What are we doing instead?
Providing guidance and examples for teams so they can better implement accessible tables. A first round of additional guidance is located here.

What do we need from you?
Your feedback! We'd love to hear how you are using the Table component now, or if you aren't, why? We'd also love any feedback or requests for additional guidance or feature requests.

Thank you!

[maggiewachs]

I think it's a great idea to reassess whether a component makes sense here. 🎉

For table documentation/guidance, I think what you have is a really good starting point. Some things to consider regarding accessibility:

• Include an example of a table that scrolls. Stacking table cells on mobile screens works well for simpler tables, but it can get complicated for tables with many columns. I think it would help to include an accessible scrolling table example to show how more complex tables can be presented at varying viewport widths.
• Downplay use cases that are less accessible, like multi-header tables. They're fairly infrequently used/needed in WECMS sites, too, so I'm curious to know how often this pattern is used across the board? If it needs to stay, I think guidance should include a caveat that they are generally less accessible, and that additions like headers attributes are necessary.
• Use actual (or close to actual) content in examples. Referring to the multi-header table again — if that structure really is necessary, it would help to see an example where a multi-header table is the best formatting option. The current example (household members) would be more accessible in a list, paragraphs, or simple table with multiple lines of text in cells.