Data table persistent sort indicator and other considerations

[mbgower]

As discussed, the sorting controls on data tables are non-persistent. A sortable table is indistinguishable from a non-sortable table until a user hovers (or place focus there).
Yet most tables have a default sort view, and this could be exposed to show which row is sorted and in ascending or descending order. The sort controls for other column headers can still be exposed on focus or hover (it arguably helps); with the persistent sort indicator, these cell-specific sort options do not need to be persistent.

Other data table considerations discussed in the following Word document. https://ibm.box.com/s/b68e43xg8hwxkzvoa2e68yaf7qa8g4me

[mbgower]

@laurenmrice and @aagonzales at one point during datatable discussions involving @mjabbink I believe there was a general feeling that datatables have a sorted column in almost every case, and that Carbon could make its default datatable show the currently sorted column by default. There could still be a way of having a table implemented that didn't have a sorted column by default, and those would be the only ones that would not have a persistent visual indicator of which column was currently sorted.

This came up again as a result of a post on #accessibility-at-ibm. Any updates on this?

[jnm2377]

@mbgower the box link you shared is not working for me, I think it might be private or expired. Is the issue here basically just trying to find a way to better indicate what column a user is sorting by? Maybe we can talk about this in the next CAG call.

[mbgower]

@jnm2377 I've updated the link. Should work for you now https://ibm.box.com/s/b68e43xg8hwxkzvoa2e68yaf7qa8g4me

The basic thing is that there is no visual indication of whether a table is sortable or not until you start interacting with it. Which means the designer must annotate that on every single wireframe, or just assume the dev will pick correctly.
If the default Carbon implementation is to have a column sorted automatically, it 'solves' this annotation problem, and also creates a better experience overall, arguably. Or, as a less dramatic fallback, have a persistent indicator that a table is sortable.

[mbgower]

Note that Visible Controls did not make it into WCAG 2.2 as a new requirement, so my comments about those considerations, although still valid for improved user experience, would not represent an actual failure.

[mbgower]

Some of the discussion from a CAG call on this topic:

• sounds like a good area for some research. what percentage of table implementations use sorting? Of those, how many have a default sort order?
• if there isn't a default sort, but the table is sortable, how do you have a persistent indicator?
  • all columns could have the unsorted indicator
  • the first column could have the unsorted indicator
  • you could introduce an icon somewhere not on a specific column to indicate 'sortable'
• what if there are only a couple of sortable columns, or one? How is that shown?
  • suggested having the sortable columns show the up/down arrow indicator for unsorted (but sortable)
• is there ever a situation where compound sorts can take place?
  • Group understanding is that Carbon does not allow
• Iliad: a lot of times you don't want sorting, but those are usually small tables; big tables usually have sorting
• as implemented by storybook, sorting seems to be holistical (if sortable, all columns are sortable) but TJ thinks there is a way of just putting it on specific columns
• at the moment, there is no guidance on annotations for sorting (other than what we put on the accessibility tab) and no variations in Figma assets between sortable and non-sortable
• if we wanted to move to a sortable table as the default, we'd need to do a break-release; otherwise, would roll out to all Carbon users!
• the default one likely doesn't have because there are a lot of things that go on top of the default, and they might involve sorting
• with a tri-state sort, if you unsort the table the icon won't show up

[mbgower]

@laurenmrice I've put up my summary of the discussion.
Key take away from today's CAG call on this topic, from Mike's perspective: it is worth putting in some design effort now to explore a persistent indicator for sortable tables.

I'm also curious to know what happens with sortable tables in a mobile environment? How does someone even discover they are sortable when they cannot hover? A persistent indicator would also address this.

[grahamharper]

Just adding a +1 to this discussion as this issue, which I'm currently thinking about, led me here:

I'm also curious to know what happens with sortable tables in a mobile environment? How does someone even discover they are sortable when they cannot hover? A persistent indicator would also address this.

The answer is, a touch user won't have a way to know the columns are sortable (unless they actually attempt to sort by tapping on the column header, which they are unlikely to do as their is no affordance). This in my view is the priority issue to solve here.

Also, there won't always be a default sort based on one of the columns e.g. a search interface where the results are based on something like a complex "best match" algorithm.