react-table-library VS aria-practices

Wow I have to read this! For a freelance client of mine, I have open sourced React Table Library [0] with the focus on tree operations. They are handling a folder/file tree structure of 100 thousands nodes where it is possible to move folders/files, clone them, lazy load them on a top and nested level, etc. And all of it in the same table structure.

After I finished the project, I kinda knew why Google Drive only allows to display and modify on the same hierarchical level. There are so many constraints that you have to consider when implementing this in a nested view with many nodes.

[0] https://react-table-library.com/

I'll use React Table Library for the UI, but this pattern can work with most other tables or datagrids in a very similar way.

Maybe give https://react-table-library.com/ a try :)

Perhaps react-table-library with its Chakra UI integration is worth a try!

Ah okay. Yes, I didn't link those yet. But essentially you can find all the features on the Features section over here https://react-table-library.com/

https://tanstack.com/table/v8 https://react-table-library.com/

You could give react-table-library a shot :) The table cells are fully in your control, so you could just use an input field in them.

Check out this table's tree feature: https://react-table-library.com/

If someone is looking for a fully-featured table library that can use either Chakra or Mantine as theme, check out this library.

W3C Aria Practices

I should apologize off-the-bat for not digging in too deeply, but how does this handle keyboard and screenreader accessibility?

W3C has some in-depth list of expected keyboard interactions, though I'm not sure how complete they are:

https://w3c.github.io/aria-practices/#TreeView

https://w3c.github.io/aria-practices/examples/treeview/treev...

I ask because I've tried to implement a [TreeGrid](https://w3c.github.io/aria-practices/#treegrid) myself before and... it's a lot of work. I'd love an accessible, keyboard-friendly React tree :).

Yep I totally agree with this.

There are however a bunch of ARIA tags & best practices etc (https://w3c.github.io/aria-practices/) that exist to make popups and dialogs (and other things e.g. tree views or "email-inbox-style" "treegrids" etc) accessible (if implemented correctly).

I am conflicted about these - it is nice that there are ARIA tags for this, but it would also be nice if browsers "understood" aria tags and added some default behaviors (e.g. keyboard navigation). As it is, ARIA tags are essentially "pointless" to anyone who doesn't use an assistive technology, and so non-assitive-technology users nor developers benefit from using ARIA tags so they are often forgotten. If the browsers saw that there was an A11y-tree that matched a treeview or a treegrid, it would be really really nice if they applied some default common keyboard navigation implementation, rather than do nothing and leave it up to the developer to decide what keys do what on each and every site. .... Or on the other hand, is that too prescriptive and should we give developers and UX designers more leeway to design something better, rather than rely on browser-enforced defaults? I guess we are happy with browser defaults for basic inputs, but would we be for a treegrid?

The ARIA practices GitHub is a good resource to see where certain patterns fall short.