Row headers for data tables: visual and programmatic considerations

[mbgower]

Carbon does a great job of consistently implementing column headers by default on tables.

• Visually, the top row is always given emphasis with bold text and a grey fill
• Programmatically, the top row is always implemented as a set of TH elements with the scope attribute set to "col"

However, there is no mechanism for a designer to designate a row header nor an incorporated way for developers to implement that.

The problem:

1. Many tables (I would conjecture the majority) implemented in Carbon use the cells in the first column as row headers. In the above example, the cells in the Name column serve as context for each row's data
2. Because the row headers are not programmatically set, a screen reader is left without information to easily navigate. For example, with the properly set column headers, a user navigating horizontally across a table now hears the Column headers read before the cell contents ("Rule, Round Robin", "Status, starting", etc). However, a user navigating vertically between rows hears nothing except the cell contents ("Starting, "active", "disabled"). If they are going down the status column, they will need to navigate to the row header each time to confirm which load balancer has that status.
3. Because most teams do not understand this need, they are unaware of a problem.

Considerations:

• it is not difficult to implement a table header (TH) to behave as a row header
• because there is no visual cue that a table row exists, it is more likely to be overlooked as something to implement
• while the first column's data is often the row header, some tables do not have a cell in a row that serves as a header
• for others, the cell serving as the table header may not be in the first column

Suggested approach:

• research implemented tables to determine the rate of tables where there is an inferred row header, both in the first column or elsewhere
• where a row header exists, consider visually treating the first column's cells in the same way as the top row -- make the text bold, add a grey fill
• consider making the row header the DEFAULT state for tables; offer a variation of the table where there is no row header (the current version) as a variant. This last would result in a much more conscious decision by designers. Where they do not want an emphasis on the first row's data, they can choose a 'Table with now row header' variant
• document this in the Data Table component documentation

Advanced consideration:

• on a batch table, the first column is made up of checkboxes; the second column contains the row header
• the checkbox is basically unlabelled (in actuality, it has a meaningless generic label), so the row header also serves as a form of label; it may also be possible to make this row header programmatically its explicit label, or a description
• it is also feasible to visually emphasis the name column here, even though it is not the first column.

[joshblack]

One option on the development side is that we could add TableRowHeader as a built-in component to help out with this use-case. We can also offer up some guidance on the technical side for when this should be considered and used.

This could be used as a placeholder while we try and look at visual patterns that this component could use to distinguish the row header in the row.

[mbgower]

@laurenmrice @aagonzales just flagging that this discussion was created. If there is a better way of labelling this to ensure it doesn't die of neglect, let me know