The following example shows how these practices could be applied to a table of baseball statistics:

<table>
    <caption>1927 New York Yankees</caption>
    <thead>
        <tr>
            <th rowspan="2">Player</th>
            <th id="reg-hd" colspan="3">Regular Season</th>
            <th id="post-hd" colspan="3">Post Season</th>
        </tr>
        <tr>
            <th id="reg-ab">At Bats</th>
            <th id="reg-hits">Hits</th>
            <th id="reg-avg">Average</th>
            <th id="post-ab">At Bats</th>
            <th id="post-hits">Hits</th>
            <th id="post-avg">Average</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Lou Gehrig</td>
            <td headers="reg-hd reg-ab">584</td>
            <td headers="reg-hd reg-hits">218</td>
            <td headers="reg-hd reg-avg">.373</td>
            <td headers="post-hd post-ab">13</td>
            <td headers="post-hd post-hits">4</td>
            <td headers="post-hd post-avg">.308</td>
        </tr>
    </tbody>
</table>

The headers attribute on the td cells identifies both whether the cell contains a “Regular Season” or “Post Season” statistic as well as the particular kind of stat from the second header row. The value of this tagging is that a reading system or assistive technology can now announce to the reader that they are looking at “regular season hits” when presented the data for the third column, for example.

There’s also no reason why this functionality can’t be equally useful to sighted readers, except that it’s rarely made available. We just talked about the problem of visually rendering table data on small screens, and there’s an obvious solution here to the problem a sighted reader will have of seeing perhaps only a few cells at a time and not having the visual context of what they’re looking at. But whether mainstream devices begin taking advantage of this information to solve these problems remains to be seen.

It’s also good practice to provide a summary of complex tables to orient readers to their structure and purpose in advance, but the summary attribute has been dropped from HTML5. This loss is slightly less objectionable than the longdesc attribute removal we’ll touch on when we get to images, as prose attributes have many limitations—from expressivity to international language support.

The problem is that HTML5 doesn’t replace these removals with any mechanism(s) to allow the discovery of the same information, instead deferring to the aria-describedby attribute to point to the information (see the scripting section for more on WAI-ARIA). This attribute, however, may make the information even less generally discoverable to the broader accessibility community, as only persons using accessible technologies will easily find it.

The proposed HTML5 solutions for adding summaries, like using the caption element, also don’t take into account the need to predictably find this information before presenting the table. The information can’t be in any of a number of different places with the onus on the person reading the content to find it.