Keeping column headers in empty states

[thefirstartist]

Package

carbon-components

Browser

Chrome

Operating System

MacOS

Package version

V11

React version

V11

Automated testing tool and ruleset

n/a

Assistive technology

n/a

Description

In Carbon's Empty states page, it says "an empty state for a table would replace the table and the column headers and footer should not be present." The reason for hiding the column headers is to avoid "having a screen reader read the entire table before getting to the message that there is no content in the table."

Column headers are important for sighted users. It shows you what the platform could look like once you’ve input more of your data. This article even suggests that empty states should always be replaced with demo content. We can hide column headers from a screen reader and display it visually, use the aria-hidden attribute and set it to true.

WCAG 2.1 Violation

No response

CodeSandbox example

n/a

Steps to reproduce

n/a

Code of Conduct

• [X] I agree to follow this project's Code of Conduct
• [X] I checked the current issues for duplicate problems

[dakahn]

@carbon-design-system/design from a design perspective do we support a table with no data? Although I can see where @thefirstartist is coming from, having column headers with no underlying data seems potentially visually confusing, but i'll defer to yall

The UX of an empty table aside, if you're going to show non-screen reader users potentially actionable empty table -- screen reader users should hear it as well. Does that feel right @mbgower

[thefirstartist]

@dakahn We can hide column headers from a screen reader and display it visually by using the aria-hidden attribute and set it to true. We do that in our Empty state pattern in Carbon for IBM Products PAL.

[dakahn]

@thefirstartist right of course we can, its just that if the lack of data under the headers is part of the user flow and supposedly meant to prompt action then we shouldn't have screen reader users miss that prompt and potentially not even known theres a table on the page

So if a data table with no data is something we support then putting the empty table in the dom and having it read -- with i assume some customized aria-labelling -- "header 1, header 2...no data" gives all our users a consistent experience.

[thefirstartist]

@dakahn Yes, we don't want screen reader to miss any part of user flow that's why we are only hiding the column headers from screen reader, not the empty states inside the table. This ticket is about Carbon's suggestion to remove column headers totally and we beg to differ.

[mbgower]

I concur absolutely with @dakahn that you do not want to start using ARIA to hide meaningful information from a screen reader user that is available to others visually.

So what @thefirstartist suggests here would result in what i would have no problem designating a WCAG failure. If you hide the column headers from only your screen reader users, you are failing a few different requirements:

Yes, we don't want screen reader to miss any part of user flow that's why we are only hiding the column headers from screen reader, not the empty states inside the table.

In Carbon's empty state guidance cited, this is what it says:

As most empty state illustrations are considered decorative, they should be skipped by screen readers. A decorative image is one that does not serve any practical or informational purpose, and is included to fill a visual void.

The very fact @thefirstartist is arguing that the column headers are meaningful content makes clear he doens't consider it decorative. And to be clear, the above quote is about the illustration -- in this case a grey cube -- not the text under it.

@thefirstartist, I think you may be confusing the situation by citing that article on empty states. That article is about providing sample data (usually in a form) where someone is working through a user process.

When used correctly, demo content will vanish after you’ve replaced it with your real user data. At that point, it’s served its purpose, and it’s over to you to use the app however you please.

The scenario from which this arose is a search where the result is zero data, yet the results are preceded by a data table header (correctly programmed with column headers, etc). The message "no results " or similar usually appears below the table (not inside it).

So your comment "It shows you what the platform could look like once you’ve input more of your data" is not appropriate. It's not "more data". It's "any data".

I don't think you're suggesting populating a zero data result with mock or dummy data? That is the basic approach discussed in the article. I think we can agree that is likely a poor experience for everyone. That said, if you arrived at a design where it made sense to include sample data, we would obviously want that data to be available to all users.

This ticket is about Carbon's suggestion to remove column headers totally and we beg to differ.

@thefirstartist Could you please provide examples where you have an empty table with column headers that you think is necessary to a user's understanding?

[thefirstartist]

@mbgower We currently have two PALs governed by DSAG and both of them keep the column headers in empty states: Empty state in Table in IBM Cloud PAL Empty state in Table in CD&AI PAL

Since Carbon suggests to remove the table header to avoid having a screen reader read the entire table before getting to the message, we are just wondering if there's a way keeping the column headers and addressing Carbon's concern at the same time. It's important for our users to see the headers in an empty state.

[mbgower]

@thefirstartist, just so we're clear, this is a best practice for empty states, not a requirement. As well, I want to emphasize that including the column headers for a blank table does not constitute an accessibility failure, per se, as far as I can tell looking at your images.

I would like to point out a few things and ask a few questions to better understand your intent and the actual interaction, and maybe arrive at something that reduces what is not a great experience for some users.

My first question would be, in what context would you be using an empty state? This almost looks like an authoring tool usage. If that's the case, this really doesn't align with primary scenario we're trying to address (search results displayed in tabular form with no records). Once I understand the context better, I may be able to offer ideas you might want to consider.

For now, I'll just describe what happens if this was an interaction where the user is in a process where they're interacting with data and get zero records back:

1. Assuming the filter is active and this table has sortable column headers, a user using a screen reader is going to be forced to tab 5 times to get through the controls above the column header and then tab 5 more times (or whatever number of columns are exposed) to get past the first row and discover that the table has no information, at which time they're going to have to go back at least those 10 tabs to do whatever action is prescribed for them to populate the table.
2. A low vision user using magnification will also have to work past additional information (likely with their mouse) until they discover the table isn't populated and find the empty state information.
3. Mobile users, I'm assuming, are going to have a mild irritant of having to scroll past the column headers to reach a similar finding.

If the column headers themselves are an important piece of information for all users, retaining it makes sense, and the above is the way all these users will consume that information. Obviously you are in a better position than me to weigh the importance of the table headers in your design against the quality of the experience for some users.

We're been discussing table design at Carbon Accessibility Guild calls lately, and amongst other things have had cursory discussions about table row tallies being exposed persistently. If that ever gets off the ground, some kind of "0 records returned" message near the top of the interaction might help all users more rapidly understand the results of a search or filter. (There is obviously a benefit to sighted users on a table with pagination as well, since they can't tell how many records beyond the displayed page have been filtered.)

Again, no idea if that is relevant to your use case or not.

[thefirstartist]

@mbgower Empty states used mainly for the OOTB experience. When users run our products for the first time, they will see quite a few empty tables without data. For example, the Connections table posted above has no data when user visits the page for the first time. It's important to show the column headers. I agree that column headers are not important for search results displayed in tabular form with no records. But we'd like to offer a consistent experience for our users. it seems Carbon suggests to remove column headers for all cases. The image from Carbon shows a "No data" empty state, not a "No results found" (with a magnifying glass icon) empty state. I'm afraid that might not be ideal for the OOTB experience.

[mbgower]

Empty states used mainly for the OOTB experience

Assuming OOTB is "out of the box" :)

I agree that column headers are not important for search results displayed in tabular form with no records. But we'd like to offer a consistent experience for our users.

But if the use case is different, then why strive for that consistency? You've made a case that you want the context of the 'future' table presentation for your new user experience. But if the use situation is presenting search results, and as you say a zero result is not important to display in tabular form, it's a different use case. Why make it appear the same?

I'm also curious to find out if you think a "# results" status message displayed somewhere near the table header would negatively affect your use case. Realize it's a vague question, but trying to understand if this is a potential path forward that applies in both use cases.

[thefirstartist]

@mbgower It's not important but it's nice to have the column headers even when there are no records found in a search. So in our use cases, it's required to have column headers in no data and nice-to-have in no search results. Since Carbon suggests to remove the column headers regardless due to accessibility reason, we'd like to know if there's a way to address that concern but keeping the column headers.

[mbgower]

we'd like to know if there's a way to address that concern but keeping the column headers.

I've suggested one (expose the results above the table) and you haven't responded back about that. Do you have any thoughts?

I'm afraid that might not be ideal for the OOTB experience.

Ultimately, you believe your use case is more important than the recommended best practice. On the other hand, some of your comments, such as the above one, suggest you haven't performed any user testing to confirm removing the table headers is an inferior experience, or to what degree. Once you have that information, you can make one of those tough design decisions.

But your decision doesn't make it the right best practice for everyone. There are reasons people decide to make something more difficult to use for some users because of their main objective for a larger user group. That doesn't mean Carbon should alter its best practice, IMO.

As noted, I think there may be a way out of this by focusing on surfacing the table records to all users above the table. I'd like to hear your thoughts on that.

[mbgower]

BTW, if "searching and filtering are disabled", you may want to consider the iteration where the filter input is not expanded.

[dakahn]

adjusted some tags since this is less of an issue ticket and more of a proposed guidance change

[thefirstartist]

@mbgower By "results," did you mean "search results"? Placing the results above the table near the header doesn't address our concern about the first-time user experience. When empty state appears inside the table without any data, There's no "results" to show. As mentioned, this ticket is more about the first-time users' No data experience. shall we keep the column headers or hide them. For example, when a user first visit this Data requests page, we are showing "No data" empty state with the column headers. This gives the user a preview what data will be included in the table.

[aagonzales]

Jumping in here, as previously stated the Carbon pattern guidelines around removing/skipping headers in empty state tables is a best practice but not a requirement. If the DSAG and Cloud have user testing and a strong opinion that they should be shown then they are allowed to do that in the context of their products and document that decision in their PAL as a purposeful deviation. However, Carbon still sees it as a best practice for the reasons mentioned above and will keep it as such in our guidance.

That said I think some good points have been made. If Cloud and Carbon for IBM Product feel like the table headers are important enough to be visually shown then they should also be read out by screen-readers. You should not be creating different experiences based on the information delivery system. If its important context for one type of user than its important context for all users.

You simply must weigh the option of what is the main purpose of the empty state and what does a user need to complete their task.

[aagonzales]

Also if Cloud or Carbon for IBM P would like to submit a documentation update for use-cases when a product might want to keep the table headers in and what the benefits that has over skipping the headers (visually or otherwise) then we would be glad to review it and update the pattern docs to include it so there is less of a deviation from the system.

[thefirstartist]

Thanks @aagonzales. Yes, I'll discuss in DSAG and decide if we can provide doc or user research report to support our decision in keeping the column headers in an empty data table.

[mbgower]

One last point I'll suggest for this, @thefirstartist. In your last image, the context is more explicit than your prior examples. Here you offer 2 buttons to make a New data request. I'd still argue that the design is 'burying the lead' with the information "You don't have any data requests yet" stuck at the bottom of the page, but at least you have the primary action near the top. All users are left with the first interaction point in the main content being the New data request button. That is approaching a more equitable design.

I suggest you also think about stripping out the Filter by and filter inputs (which I think it is difficult to argue are doing anything more than cluttering a design with no data; there's even an iteration of the data table that hides it behind a search button).

[mbgower]

@thefirstartist on the call today, I was asked to provide an example of how info might be exposed before the table. Here's a very lo fi example of what your page might look like. Here's what I did:

• hid the search function (not really any point when there are no records; you could also just disable..)
• added a "0 requests" piece of information to the left of the action button

That's your new user use case. The same approach could also be employed in the very different use case where we're dealing with search results. Again, very lo fi, but hopefully @aagonzales and @jeanservaas understand where I'm going with this

[thefirstartist]

@mbgower I like them a lot. Thank you for putting them together so quickly. The only thing I might suggest is to left-align "0 requests" with the header but I'll leave the visual details to @aagonzales .

[sstrubberg]

Next steps: Take the mockups that @mbgower made above and iterate on them to make a Pattern that consumers can follow for empty states.

[mjabbink]

It sounds to me like you’re on the UX/accessibility issues. So I’ll note that centered typography needs to be updated, and hopefully, the team can update the single straight quote to a proper apostrophe.

Yikes

————————————————————