Tables: no method to define row or column header cells (th)

[joedolson]

For data tables, it's important for accessibility to be able to identify table row and column headings. Since most tables inserted in a post should be inserted to display data, it should be the default assumption that there's at least one row and one column heading. Right now, the default code does not add any headings or scope and I can't see a method to specify headings. E.g. <th scope="row"> or <th scope="col">.

It's also not possible (as far as I can see) to create <thead> or <tfoot> elements.

[jwold]

@joedolson just to clarify you're saying it's not possible to create a thead or tfoot from the visual part of the Gutenberg editor, right? (as far as I can tell you can add it into the Text editor part: https://cloudup.com/cKU5volw1Z6)

[joedolson]

Yes, I mean in the visual part.

[jwold]

@joedolson here's a wireframe I've been playing with:

When you click to start typing in the table, you'll see two new buttons above it: Add Header Row and Add Header Column. Clicking each button will add/remove the header row/column.

Is this what you were imagining? Any suggestions?

[joedolson]

That's definitely moving in the right direction. I do think that the default content for a table should include some kind of heading, since a properly semantic table should always have headers. Is this imagined to insert an additional row/column, or would it change the characteristic of the currently selected row/column?

[jwold]

1. I was imagining that this would change the characteristics of the currently selected row/column. Kind of like this: https://v.usetapes.com/gJtWgZOimi

2. Are there any other buttons that you think should be added?

[afercia]

I'm a bit concerned users will start using tables for columns layout. I think WordPress doesn't want to encourage this practice, as it would mean going back to what the Web was 20 years ago. Would it be an option to add some warning or instructions?

[joedolson]

I think that providing a method to build a valid, accessible table should override that concern. I'm not sure that the editor itself is the right place for doing that kind of education. If the default implementation of a table included a header row, and was modeled more like a data table than for layout, then it would be better. But from a technical standpoint, I think that the accessibility issues from having an invalid data table are greater than those from using a layout table.

[jasmussen]

I'm a bit concerned users will start using tables for columns layout. I think WordPress doesn't want to encourage this practice, as it would mean going back to what the Web was 20 years ago. Would it be an option to add some warning or instructions?

I think if we don't offer — in the UI — a way to adjust padding, margins or borders (so you can hide them), it will look very much like a table and probably discourage this. The argument would be that the theme should style the table regardless.

[anna-harrison]

We are working on table improvements in TinyMCE that will address this issue (amongst others)
cc/ @spocke @EphoxJames

[BoardJames]

To be clear we're waiting on an internal Ephox project to share the table handling code from our other JS editor so this is likely a month out.

[joedolson]

Thanks for the updates!

[mtias]

@afercia I think at the very least the "block description" that shows in the inserter should explain what tables are meant for.

[androb]

"Snooker" has been open-sourced and is being actively worked on at:
https://github.com/ephox/snooker

[jeffpaul]

This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs.

[afercia]

Not sure this is just a design issue. Ideally, Gutenberg, and WordPress, should provide tools to help users produce semantic and accessible content. WordPress aims to be a semantic publishing platform.

Tables are tricky because content authors tend to abuse them. Ideally, tables should be used to represent data. However, the HTML recommendation doesn't prohibit to use them for layout.

These two different use cases require different markup. How can Gutenberg help users to produce good, semantic, and accessible content? Should Gutenberg explicitly discourage the usage of tables for layout purposes? Or should allow it? If so, should there be two different block types: "Table for data" and "Table for layout"? Any news about table improvements in TinyMCE mentioned above?

For reference, some quotes form the current HTML recommendation: https://www.w3.org/TR/html5/tabular-data.html

The table element represents data with more than one dimension, in the form of a table.
Tables should not be used as layout aids.
If a table is to be used for layout it must be marked with the attribute role="presentation" for a user agent to properly represent the table to an assistive technology and to properly convey the intent of the author to tools that wish to extract tabular data from the document.
User agents, especially those that do table analysis on arbitrary content, are encouraged to find heuristics to determine which tables actually contain data and which are merely being used for layout. This specification does not define a precise heuristic, but the following are suggested as possible indicators: (see the list of possible indicators)

[afercia]

See also #3504 for thead, tbody, tfoot.

[reedcodes]

Accessibility is an important priority for the projects my team is working on. Our content editors do have legitimate reasons for including data tables on their websites, and we would like to make the editor experience a good one for them; this also means limiting the source HTML code they would need to edit in order to make a table more accessible.

In addition to adding thead or tfoot, and <th scope="col" or <th scope="row">, another feature that could help with accessibility is caption. Again, there is no way to add this other than going into the source HTML; using options in the visual editor is preferred.

[afercia]

I'd say Gutenberg should also ensure the Table block gets used exclusively for data table. I'm afraid users will end up using it for layout purposes and that's something that, in my opinion, Gutenberg shouldn't allow.

[mtias]

The best way in which we can guide this is by not allowing nested blocks in table cells. Only regular rich text and the tokens that come with it (mentions, inline images, etc).

[afercia]

That would be great 🙂Also, mentioning it in the block inspector could be beneficial, perhaps. The current description implies that but I'd consider to make it more explicit. Right now, it says:
Insert a table -- perfect for sharing charts and data.

[afercia]

Discussed during today's a11y bug-scrub. A first simple step could be adding two new commands to the Table menu:

• transform into column header
• transform into row header

However, should these commands also try to validate a proper table HTML? What if users try to use one of them in a cell in the middle of the table?

[hedgefield]

Then we force it onto the first cell in that row/column I'd say.

[karmatosed]

I think a solid step is just to have a default header out of the box similar to how pages does:

There is an option to 'turn off' headers but it's something you have to turn off - thus encouraging better accessibility by default.

I think it could also be interesting to have this a setting for columns/row but that's a debate point to have 1 or 2 switches.

[karmatosed]

Noting we have one large issue to 'fix' tables and including this there, so closing here. #6923

[marvinpoo]

First of all:
So, is there a way to add table headers & footers to tables through the visual editor or not? I think this should be a standard configuration.

I'd say Gutenberg should also ensure the Table block gets used exclusively for data table. I'm afraid users will end up using it for layout purposes and that's something that, in my opinion, Gutenberg shouldn't allow.

This is not our problem. And it should never be as this is about the editor and not about your concern people are being dumb. This editor is supposed to work. It is not your decision what people should use a table for or what not. I have never seen any of my clients using the editor to design their website. And even if, it's their website and I just can tell them not to do. But this surely is NOT a reason to disable a friggin standard function.

[strarsis]

Also table headers + footers can be made position: sticky; which is also awesome for long tables.

[cngodles]

Not sure if this is relevant, but the UI of this could use improvement. I could not figure out how to enable this option until I found this issue. Otherwise, it works great.