Web developers have been using HTML tables to control page layout for decades. Unfortunately, that doesn’t mean that it’s good practice!
Tables are meant for tabular data. When they’re used to present other types of content — for example, images with captions — that can create a confusing experience for people who use screen readers and other assistive technologies.
Below, we’ll explain how HTML tables can influence screen reader behavior. We’ll also provide an alternative: Utilizing the HTML5 <figure> element.
For help with a specific web accessibility issue, send us a message to connect with an expert.
People might use HTML tables to associate captions with their respective images and maintain a particular presentation. Here’s an example we found when evaluating one site for accessibility issues (we removed all identifying information and CSS):
<table>
<tbody>
<tr>
<td><img src="image.jpg" alt="image alt text)"</td>
</tr>
<tr>
<td>This is the image caption.</td>
</tr>
</tbody>
</table>
For visual users, this works: The image is presented neatly above its caption, and CSS can be used to control other aspects of the presentation.
But for non-visual users, it’s a bit of a mess. Screen readers might announce the presence of a table, then read the alt text of the image as data from the first cell, along with other identifiers to help the user read the “table" (which doesn’t really exist).
You could use the ARIA presentation role to hide the semantics of the <table> element — or just use a <div>, which is what some content editors will do by default.
But if you’re using ARIA, you’re making a commitment to test your website with a selection of different screen readers, web browsers, and operating systems. A far better way to solve this problem is to use the correct HTML for the job: The <figure> element.
Related: How To Build Accessible Tables
Introduced in HTML5, the <figure> element is a semantic container used to enclose self-contained content — usually, it’s content that is referenced as a single unit from the main flow of the document.
In other words, it’s intended for cases where you could move a “figure” to a different part of the document or remove it entirely without impacting the document’s overall meaning.
That’s often applicable to images, but it’s also useful for illustrations, videos, diagrams, audio clips, and similar content. It’s frequently used with the <figcaption> element, which provides a caption and connects it to the figure as a single “chunk" of content.
Here’s how the <figure> element looks in practice:
<figure><img src="image.jpg" alt="brief alt text"><figcaption>This is the caption for the image. It isn’t identical to the alt text.</figcaption></figure>
(Note that we specified “brief alt text” for the image in this example; that’s because captions and alt text can be redundant, and redundancy is also bad for screen reader users.)
This approach is much simpler than using a table — and like many accessibility improvements, it makes your markup cleaner, more concise, and easier to change in the future.
Related: How Accessibility in the Web Development Process Saves Time
The <figure> element might not be the perfect tool for every instance of an image that appears with a caption. In some cases, you may need ARIA, particularly if the content is dynamic or if your website has a unique presentation that doesn’t fit the typical image-caption pattern.
But in general, plain old semantic HTML (POSH) provides the best basis for accessibility. By using HTML to deliver semantics, then styling your content with CSS, you can provide a more consistent experience for your users — including nonvisual users.
To learn more about the best practices of accessibility, download our free eBook: Essential Guide to ADA Accessibility Compliance for Websites.