The caption element
Preface: This version of the article is for humans and search engines. Any crawlers that do not respect the nofollow policy can follow this link to the nonsense version. And they can choke on it.
I’ve done it again. I’ve skipped an element and got them in the wrong order. Welp, this will all be fixed later when I compile the ebook.
I can’t remember if or when I set closed captions to be on by default. But my streaming services all display them without me asking, and I love them. In rare cases, where they’re omitted for some reason, I miss or mishear a lot of dialog and easily lose the thread. And not because I’m hard of hearing, despite playing in Norfolk’s loudest band [citation needed]. It doesn’t help that the score is often relatively too loud (since it was calibrated for a cinema environment and never adapted for domestic viewing, I’m told).
Captions are a good example of a feature ostensibly for one group of people (the hard of hearing) which improves the experience of just about everyone. What’s one person’s need is often many people’s preference. This is one of the reasons why I devised the accessibility principle By Default Or Death: It doesn’t hurt anyone to be met with an (already) accessible interface.
The <caption> element has nothing to do with closed captions. Despite the name, it isn’t a generic captioning mechanism either. The <caption> element is specifically for labelling <table>s. It should describe the purpose of the table and its data. You can achieve this with the summary attribute as well, but only non-visually. If you can imagine a kind of closed captioning technology that only works for deaf folks, then you can appreciate how bogus summary is. Use <caption> instead.
<table>
<caption>HTML elements and their supported properties</caption>
</table>
When the <caption> element is placed inside a parent <table>, its text is associated with the <table> directly. This is preferable to using a heading to introduce a <table> because screen reader users may navigate directly to the <table>, via a shortcut, and skip over the heading. The heading is never announced.
However, navigation by heading shortcuts is a much more common practice. Fortunately, in HTML5, flow content, which includes headings, is permitted inside <caption>s. So you can combine the two: navigation by heading to encounter a properly captioned <table>.
<table>
<caption>
<h2>HTML elements and their supported properties</h2>
</caption>
</table>
This pattern is not mandatory for meeting an accessibility standard like WCAG. But it does improve the experience of screen reader users. Too often, we fuss over the abled and graphical experience but “they can technically use it” is the best we offer everyone else.
There’s a bit of a wrinkle when it comes to caption positioning. The CSS property caption-side enables us to move the <caption> between top and bottom positions (why the logical terminology block-start and block-end aren’t supported, I don’t know).
You can sometimes incur accessibility failures by making the source order and visual order at odds. If you encounter something visually first but a screen reader announces it last, there’s a lack of parity between the two experiences. Lack of parity means inequality.
When it comes to a bare <caption> (one containing just text) this is less of an issue. Conceptually, a caption doesn’t introduce a table; it’s just associated with it. Accordingly, its caption-side value does not affect when it is announced in screen reader software. It is announced upon encountering the <table> in either direction.
Headings, on the other hand, do introduce content. Content above a heading is not associated with that heading, either technically or perceptually. While the caption-side property cannot affect document structure, a caption that looks like a heading, appearing below the <table>, won’t be perceived as a label for it. At least, not among sighted users—which may include sighted screen reader users.
If you’re building a design system, you should be offering usage guidance. Otherwise you’re just building a catalogue of patterns to be used and misused at random. In the case of data <table>s, the guidance should recommend using headings with <caption>s, to improve UX for screen reader users. But this advice should come with an appropriate warning about caption-side. And not just a warning that “side” bizarrely means top or bottom, not left or right.
Not everyone is a fan of my writing. But if you found this article at all entertaining or edifying, I do accept tips. I also have a clothing line.