w3c/wai-tutorials

Irregular table tutorial is misleading / incorrect

tombrunet opened this issue · 2 comments

tombrunet commented

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)....

  1. scope="row" applies this heading to all cells to the right of this header for all rows for which this heading spans.
  2. scope="col" applies this heading to all cells below this header for all columns for which this heading spans.
  3. scope="rowgroup" applies this heading to all subsequence cells (right or below) covered by the same thead / 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.
  4. scope="colgroup" applies this heading to all subsequent cells (right or below) covered by the same colgroup 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 #625 is also a result of a misinterpretation of the usage of scope.

tombrunet commented

See also #576.

yatil commented

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 any scope definitions since the auto definition would already give them then correct col and row 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.)