wai-tutorials
wai-tutorials copied to clipboard
Irregular table tutorial is misleading / incorrect
This is regarding https://www.w3.org/WAI/tutorials/tables/irregular/ . This tutorial incorrectly implies that scope="col"
does not work when colspan
is used and seems to direct authors to use scope="colgroup"
instead. Similar for row / rowgroup
. There is no relation between usage of colgroup
/ colspan
and rowgroup
/ rowspan
. scope="col"
is correct to use with using a colspan
and scope="row"
is correct to use with a rowspan
.
We received a bug report related to this, and while trying to figure out where they received this misconception, the only w3c-related page I could find was this tutorial. I've found several other non-w3c tutorials that take this a step further and claim that the colspan
defines the column group, which will result in completely inaccessible tables.
To summarize how scope
has worked since it was introduced (and still works this way) (I'm using top-to-bottom, left-to-right directions for clarity)....
-
scope="row"
applies this heading to all cells to the right of this header for all rows for which this heading spans. -
scope="col"
applies this heading to all cells below this header for all columns for which this heading spans. -
scope="rowgroup"
applies this heading to all subsequence cells (right or below) covered by the samethead
/tbody
/tfoot
element. The first example of https://html.spec.whatwg.org/multipage/tables.html#the-th-element is very clear on this one, and note that there are no colspan / rowspans used in this example. -
scope="colgroup"
applies this heading to all subsequent cells (right or below) covered by the samecolgroup
element. Honestly, I haven't really seen a meaningful example yet that needs to use this.
This has been the spec since at least ~2001 when I implemented this for Homepage Reader 3.x.
While the examples themselves used on this page technically 'work' because the colgroups and rowgroups happen to match the spanned columns and rows, the descriptions are incorrect in saying that this approach is necessary due to the use of colspan
/ rowspan
. The same header associations would be applied if the example used scope="col"
in place of the scope="colgroup"
and scope="row"
in place of the scope="rowgroup"
. In that case, the colgroup
/ rowgroup
elements are basically unnecessary. Further, since HTML5 introduced the concept of scope="auto"
by default, neither of these tables require any scope
definitions since the auto
definition would already give them then correct col
and row
states.
As noted, I really haven't found a situation where scope="colgroup"
is necessary. The only situation I've found for scope="rowgroup"
is similar to that noted above where each group of rows has a heading that applies to that group of rows. Typically, this would be used in connection with a colspan to span the heading across the top of the section, as opposed to the implied relation to rowspan.
Another example of usage of scope="rowgroup"
without colspan
/ rowspan
is in the examples section: https://html.spec.whatwg.org/multipage/tables.html#table-examples.
Note, https://www.w3.org/WAI/tutorials/tables/multi-level/ example 2 fits with this pattern, but seems to imply colgroup
instead of rowgroup
, which doesn't fit with the spec.
Unfortunately, for an example I wrote up using rowgroup
, JAWS doesn't seem to correctly identify the heading as related to cells within the rowgroup. Works fine with scope="row"
.
It seems that https://github.com/w3c/wai-tutorials/issues/625 is also a result of a misinterpretation of the usage of scope
.
See also https://github.com/w3c/wai-tutorials/issues/576.
Hi @tombrunet, first, thanks for reporting the issue and providing so much detail.
What would your general advice be, especially regarding this part:
Further, since HTML5 introduced the concept of
scope="auto"
by default, neither of these tables require anyscope
definitions since theauto
definition would already give them then correctcol
androw
states.
If we can say “use <th>
properly and browsers will in general take care of it” that should be beneficial to everyone. Would you be open to work with me on a pull request to address the issue? I might be able to create a proposal for you to review.
(FWIW, we had reviewed the spec when writing it and had a JAWS user at the time reviewing the code and found that specifying some of these attributes was necessary.)