Headers in tables

[Reinmar]

While reading the spec I noticed that the table must either have a <thead> or <tr> > <th> to represent its heading.

But what about tables in which you don't want to have a header? While reading about tables in MacOS High Sierra I found this for instance:

Such a table LGTM. I think that it shouldn't also create a11y issues. But anyway, it has no header. Should an editor prevent creating such a table?

Another thing is tables with cells using scope=row. Aren't they suppose to use <th> elements as well? In such a case, the first cell of each row would be a <th>, making such a table incorrect according to the spec.

[Reinmar]

And one more thing – we need to decide whether the editor will create <thead> elements or simple <tr> with <th>s inside. The latter is simpler to implement because we don't have to consider splitting the table into multiple pieces. The table will always have the same structures, regardless of the number of rows which act as headers and regardless of whether it's the kind of table which has a first column as a row. Would that be fine if we avoided using the <thead> element? Or would that be a worse solution for some reason?

[Comandeer]

But what about tables in which you don't want to have a header?

Well, TBH .visuallyhidden.

I think that it shouldn't also create a11y issues.

But it creates. When user is inside table with properly added headings, then their names are read when navigating to particular cell, e.g. if the second column had name "Growth time", then user, navigating to the cell in this column would hear "Growth time, 10-12 weeks". It's much more informative than "10-12 weeks" alone. What's more adding headings also to row would give even more information about the info context.

Another thing is tables with cells using scope=row. Aren't they suppose to use elements as well?

Yes, they are. Apparently spec needs to be updated.

[Reinmar]

Well, TBH .visuallyhidden.

But that assumes that the header will be filled, just invisible. In reality, I'm afraid that many times people won't bother to fill that content. This is the typical "ease of creation" vs "a11y" problem. We'll need to figure out whether we should enforce that there's at least one header col/row.

[Comandeer]

We could change

The <table> SHOULD have a header placed inside <thead> element. If the <thead> element is not present, the first row of the table MUST represent the header. The header MUST contain a row with headings for each column, represented by <tr> element with <th> elements inside.

to:

The <table> SHOULD have a header placed inside <thead> element. The header, if present, MUST contain a row with headings for each column, represented by <tr> element with <th> elements inside. If the <thead> element is not present, the first row of the table SHOULD represent the header.

But honestly I'm not 100% happy with suche change.

[brunoais]

@Reinmar What prevents you from just hidding the header using CSS?

[Reinmar]

This is meant to be a recommendation for how a basic set of RTE features should be implemented. I'm not worried about the content itself because the end-developer may hide whatever he/she doesn't like. The problem occurs earlier – once the RTE user cannot change the first table row into a normal row. That user cannot hide anything using CSS.

Anyway, in CKEditor 5 we implemented tables in a way which lets you have tables without header rows/cols. I think that it's unrealistic to expect that all RTEs will force the existence of headers.

[itmaybejj]

One thing that would help most use cases is changing the default! CKEditor creates a table without headers by default, so only savvy users add a header row/column. This should be flipped: create tables with headers by default, so that users who want to make inaccessible tables have to affirmatively make a bad choice to remove them.

...And then ideally throw some sort of warning on the remove headers option.

[mgifford]

Just want to echo @itmaybejj point. An author may or may not want headers for their tables, however the default solution should be one that is the most accessible. It shouldn't take more work to make a table accessible, it should be understood to be the normal thing.

EDIT: Also worth pointing to the We4Authors Cluster study on tables https://accessibilitycluster.com/main-results/table-creator

and this W3C example for how tables should look https://www.w3.org/WAI/tutorials/tables/