useSortBy should toggle`aria-sort` on column headers and relevant demos should encourage a11y best practices

Describe the bug (required)

1. useSortBy should leverage the aria-sort attribute which describes the current sort direction for a particular column to screen reader only users
2. The demo for useSortBy is not keyboard accessible - fortunately this can be overcome easily via manually leveraging column.toggleSortBy! Since this library is fairly popular, it would be good to encourage best practices where possible.

Provide an example via Codesandbox! (required) Codesandbox Demo <-- here is a demo demonstrating the lack of aria-sort on the <th> elements with a keyboard accessible implementation using column.toggleSortBy

Steps To Reproduce (required)

1. Go to the linked demo in the documentation for useSortBy
2. Try to control the sorting using a keyboard only - unfortunately you can’t due to some HTML semantics problems
3. When clicking on a <th> to sort, inspect the DOM for the aria-sort attribute - it isn’t set at all.

Expected behavior (Recommended) Here is a great demo of how this should work from a reliable source: https://dequeuniversity.com/library/aria/table-sortable

1. All sortable <th> elements have a nested <button> inside to make them keyboard accessible
2. All sortable <th> elements have a valid aria-sort attribute (but only if they are sortable!)
3. Note they do not have the title attribute that is currently provided by useSortBy - this shouldn’t be necessary with the aria-sort attribute in place.

Screenshots N/A

Desktop (please complete the following information):

• OS: macOS Big Sur
• Browser: All browsers
• Version: 7.6.3

Smartphone (please complete the following information):

N/A

Additional context Seriously, thanks to all of the maintainers for your work. The headless approach this library takes serves the React community well.

Depending on the complexity of the code, I could potentially jump in and help out with this one. The aria-sort problem in particular seems like low-hanging fruit. Updating a CodeSandbox demo should be quite easy as well, though I’m not sure of the best way to go about doing that in this case.

[tannerlinsley]

I’m happy to accept any PRs for better aria attrs!

[esetnik]

I suppose it depends on what “headless” means exactly! For some headless libraries (React ARIA, Downshift, Radix) they are all about adding the right HTML attributes for handling state changes (including ARIA). Is this library only concerned with data? If it’s concerned at all with producing the right HTML to reflect table state, then ARIA attributes should be part of the mix I would think.

I agree. And most devs don’t know too much about aria and often don’t have the business justification to bother supporting it. In my opinion it should be baked in whenever possible. If adding too many properties by default was a concern there could be some configuration one could set to decide whether or not to generate aria attributes.