Revise the section for table markup

[AndersEkl]

There are additional markup that would be beneficial to add, for example header scope.

[jonaslil]

I agree. It would be good to mention explicitly the use of <th> for column and row headers, since this is the most important mark up for accessibility.

It is unclear to me why <tbody> is required - is it for styling purposes? It does not do anything for accessibility, as far as I know.

[josteinaj]

If I remember right, tbody is inserted automatically by most browsers when parsing a table. That affects how you write CSS rules. It is probably also mandatory if you want to also include a thead or tfoot. Page breaks in the middle of a table, and CSS rules for those page breaks are also something to keep in mind when defining table markup.

I think requiring a tbody ensures that the DOM is consistent across reading systems.

[AndersEkl]

I think the original reasoning was along the lines @josteinaj mentioned. We got the <tbody> anyway and if we want <thead> markup it is needed.

[AndersEkl]

I have re-worked and added to the table section. Added requirements about scope for headings and made some clarifications.

[AndersEkl]

I will close this issue soon, unless there is something I need to change.

[AndersEkl]

Do we need an example of the markup?

[martinpub]

A full, beautifully marked up table example could be very neat. I think this section is really good.

[AndersEkl]

Ok! I'll add a full example and then close this issue!

[martinpub]

Perfect!

[jonaslil]

Great updates here!

My comments:

The Daisy KB does not require (and their table example does not include) the scope attribute for simple cases where the first row(s) or column(s) contain the header cells. Screenreaders will infer the scope in such cases. To keep markup as simple as possible, we may not want to require scope for simple cases, but only for complex tables.

Benetech, who previously required scope for all heading cells in their GCA certification, also loosened this requirement last year: "Only for very complex tables where sub-headings for a subset of cells not in the first row or first column is present will explicit use of "scope" or "Headers & ID's" will be a requirement." (From their Technical Bulletin in June 2023.) Using scope is still a best practice, but a requirement only in complex tables.

We might also want to emphasize that the first column of a data table usually contains row header cells that need to be <th>. The most common error I see in table markup is that row headers are not identified as header cells at all.

Lastly, I find the Daisy KB Example 1, where repeated <tbody elements are used to group a table into subsections with ther own section headings, quite important. This type table layout is quite common, but the markup solution is not widely known. We might want to mention this possibility and refer to the Daisy KB example in the parapraph that speaks about <tbody>.

[AndersEkl]

I'll add the thing with repeated <tbody>. Regarding scope, isn't it a simpler rule if we require it? Otherwise there will be a judgement question what is complex enough? I was going to add row headings in the example. I might add some words about it too.

[jonaslil]

If we don't require scope for all cases we need clear criteria for when it is needed.

Suggested criteria: a) when heading cells are merged with colspan or rowspan, or b) when column headings are present anywhere else than in the first (topmost) row, or row headings are present anywhere else than in the first (leftmost) column. I think it is enough to use scope for the cells satisying these criteria, i.e. it may not be needed for every <th> in the table. (Compare the Daisy KB example.)

[martinpub]

Sounds like good criteria! We are a little bit unsure about how well this will be applied in production, but let's see.

/Martin, Oscar and Linda

[lindheli]

I am sorry for writing in this closed issue, but I think my question relates to this subject. Let me know if I should move this to somewhere else.

I have tried to add <tfoot> in a table. As far as I can see, it is currently not possible, because html only validates with this order:

<thead>
<tbody>
<tfoot>

And nordic-html5.rng only allows this order:

<thead>
<tfoot>
<tbody>

Should this be changed in the rng code?

[AndersEkl]

That seems like an error, to me, Probably should be changed.

[martinpub]

If that's the case, I guess it's a bug yes. The content model of <table> according to the HTML spec is:

In this order: optionally a caption element, followed by zero or more colgroup elements, followed optionally by a thead element, followed by either zero or more tbody elements or one or more tr elements, followed optionally by a tfoot element, optionally intermixed with one or more script-supporting elements.

[josteinaj]

In DTBook, tfoot was before tbody:

 <!ELEMENT table (caption?, (col* | colgroup*), thead?, tfoot?, (tbody+| (tr|pagenum)+)) >

Placing it like this was also the case in HTML4, and it was also allowed in HTML5 when the 2015 guidelines were written. To be able to convert between DTBook and EPUB3 both ways, it was therefore convenient to require this order also in our books.

In December 2015 however, HTML5 was changed to disallow placing tfoot before tbody:

whatwg/html@94d55af

Commit comment:

Disallow <tfoot> before <tbody> in the content model

In HTML4, tfoot had to appear before tbody, but HTML5 allowed
either before or after. Placing it before causes problems for
keyboard focus order and order of accessibility objects, so this
changes the content model to no longer allow tfoot before tbody.

Part of whatwg/html#352.

[AndersEkl]

Ok. Then it needs to be changed! <tfoot> should only be placed at the foot of the table.