Carbon: [Carbon 10: Data Table] Table heading in table body

[elizabethsjudd]

Detailed description

Describe in detail the issue you're having.

<th> should be used within the table body to denote the row's heading but it's styling is odd.

Is this issue related to a specific component?

Data Table

What did you expect to happen? What happened instead? What would you like to see changed?

Table row heading should align with the rest of the cells. Often they don't visually look different from other cells but are semantically important for screen reader users

What browser are you working in?

Chrome, FireFox, Safari

What version of the Carbon Design System are you using?

v10.0.0

What offering/product do you work on? Any pressing ship or release dates we should be aware of?

Watson Health Pattern & Asset Library (PAL)

Steps to reproduce the issue

1. Add a th as a cell within the tbody
2. View the table styles

Screenshot

[jnm2377]

@IBM/carbon-designers is this a pattern we're supporting? cc: @dakahn is this a requirement for a11y?

[elizabethsjudd]

For a11y the rows should have headers as well, other wise when the screen reader user is navigating through the table they won't have a clear understanding of what row they are on. Typically the styles look like a normal table cell as that's visually what most users are used to but semantically the markup should be using th elements.

[jeanservaas]

So @elizabethsjudd are you saying that adding the tag within the body to denote the row's heading is causing issues with the styling?

[jnm2377]

cc: @designertyler @aagonzales we don't have a mock up for th(header) within tbody as the row header instead of column header, so the styles right now just target all th's within table, we'd need to update that to target either th within thead and th within tbody and apply styles accordingly, but we'd need to come up with a design spec for what row headers styling would be.

[elizabethsjudd]

@jeanservaas yes. I'm trying to have a table that looks like a carbon style but use the proper semantic markup to denote the row heading. Without looking at the code what seems to be happening is the th element is not scoped to the thead so when i use it in the body it looks like a column header instead of a standard row cell.

@jnm2377 Personally I would make the "row header" styling a special class that is optional instead of scoping it to the th in the tbody. A lot of times the designs aren't in a way that they always want to call out which cell is the header so by default it should just look like any other row cell but then we could add a class that would allow us to style it as a "row header".

[jnm2377]

Right, but the th in tbody would still need to receive "default row cell" styles, so if we want both options, as in have the th look like all the other cells or look like a header, we'd have 2 selectors. Targeting the th would be used to apply the default styles, and the th with the special class would apply an optional "row header" look. @elizabethsjudd

[designertyler]

The way I'm understanding the request is only to have the header cells not inherit the darker header style when used in a column. Or is this request to have the option to do either (look like a header or normal row)?

If that's the case @jnm2377 I'd cut out this second part.

...as in have the th look like all the other cells or look like a header, ...

If that _is_ what we're aiming for, then we need to revisit the design specs since those darker grays may need a divider or something to help separate.

[elizabethsjudd]

@designertyler The request is to not have the headers in the table body look like the column styles and instead look like a standard tbody cell. If that bug was taken care, I would say this issue is fixed. The table in the screen shot should look like the tables on the Carbon website.

With that said, I don't think it's a bad practice to have the option to have a "row header" style but that does require additional work (design specs) and could be done as part of a separate issue IMO

[stale[bot]]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

[elizabethsjudd]

No Stale. We might have someone on our team be able to help with this but not sure when.