0:05
Speaker 1: Welcome! Content Lab brings you the next video in our series about accessible content practices for web authors.
0:12
In this video, you'll learn about making accessible tables in the Mass.gov CMS.
0:17
We will focus on the tables you build in rich text fields.
0:20
Building a simple table in a rich text field makes sense when you need to organize similar types of data or information for quick, easy scanning or reference.
0:30
This table on the Saltwater Fishing Derby Rules page organizes data in a predictable way so you can quickly see the minimum weights and lengths for each ground fish species to qualify for the competition.
0:43
Here is a table that does not organize information for easy use.
0:47
Listing these language translations in a table with no headers was a design choice.
0:52
Maybe the author wanted to save vertical space on the page, but you don't want to use tables for design reasons.
0:58
That's not the purpose of a table, and a screen reader can't correctly read a table without headers.
1:04
Using tables for the right reasons is good content practice, but it's also good accessibility practice.
1:10
We'll explain why in this video.
1:13
The tables you build in rich text fields in the CMS are best for small sets of data, 50 rows maximum.
1:21
You can build tables on any page type that offers a rich text field.
1:25
The author creates a new info details page in the CMS.
1:29
In edit mode, they go to the Content tab and select the Rich Text component.
1:33
When the Rich text field opens, they select the table icon and then select the number of rows and columns they want for the table.
1:41
Now they can enter data in the table.
1:44
A screen reader will read out the row and column headers as it navigates through a table.
1:50
The screen reader speaks 1 cell at a time and announces the relevant header cells so the reader doesn't lose context.
1:57
Here is a sample of a screen reader announcing data in a table.
2:01
Note how it says the header for each cell.
2:04
Common name, scientific name, status range, Summer habitat, Winter habitat row link, Big brown bat column header.
2:14
Common name Row 2 of 10 Column one of six.
2:18
Eptiscus fuscus column header.
2:20
Scientific name column two of six.
2:24
Common column header status column three of six.
2:30
The screen reader user builds a mental model of the table as the information is announced.
2:35
Headers act like landmarks.
2:37
They orient the person as they build that model.
2:40
If your table is not accessible, the reader has to work harder to consume the information auditorily.
2:48
Here are some best practices to follow to build an accessible table in a rich text field.
2:55
It's best to create your table in the rich text field to ensure proper formatting and accessibility.
3:02
Do not copy and paste a table from another source into a rich text field.
3:07
Also, do not put screenshots of tables in a rich text field.
3:12
An image of a table is not readable by screen readers.
3:16
This MassHealth table is a screenshot.
3:19
It's labeled as an image in the rich text field.
3:21
The alt text says 2025 MassHealth Income Standards and Federal Poverty Guidelines.
3:28
A person using a screen reader would only hear that, and none of the data in the table.
3:34
Screenshots and images that are complex, like this image of a table with a lot of text, require text descriptions to convey everything they portray.
3:44
Alt text is not adequate.
3:47
Note that this table image about EOTSS Top 10 priorities has a text description as an alternative to the visual.
3:55
This makes the content in the image accessible to everyone.
4:00
Use headers for each column or row.
4:03
The CMS will not let you save a table without headers.
4:07
Here is a table with the row headers.
4:09
Here is a table with column headers.
4:13
Make sure the headers are specific and meaningful.
4:16
Everyone appreciates A descriptive header that reveals exactly what data or information they'll find in the corresponding column or row.
4:24
For example, this table about bats that live in Massachusetts uses specific column headers like scientific name and summer habitat, and the data that follows under each is exactly what the header promises.
4:38
Avoid using special characters in headers.
4:41
Screen readers will say the name of the character like a hashtag.
4:45
Instead, write out the word number or percent instead of using the characters.
4:52
Avoid abbreviations in tables unless they're spelled out in the header or the first time they're used on this page.
4:59
About bar exams.
5:00
For example, "Multi-State Performance Test" is written out with "MPT" in parentheses in the header as a way to introduce that acronym.
5:10
Make sure the data in the table is consistent in type or format in this table.
5:16
About speed display signs, for example, each manufacturer and product name is hyperlinked.
5:22
Notice too that when the header says qualification date, every date in that column is written in the same format.
5:29
Information in a table is easier for every user to scan and consume when it follows A consistent format.
5:36
Remember, an accessible table organizes data.
5:40
You don't want to use tables for layout.
5:42
Notice that this Group Insurance Commission table arranges newsletter copy about member links side by side. Editoria11y flags it as inaccessible because the table has no proper column headers.
5:55
Instead, the headings are in the same cell as the information.
6:00
Screen readers can't correctly announce the information in a table that's not properly formatted.
6:05
So while it may be tempting to use tables for layout purposes, it's best to avoid that practice.
6:13
Tables do make sense for quick lookup purposes.
6:16
These tables about camping fees organize that information for easy scanning.
6:22
Certain choices you might make with headers will lead to a confusing screen reader experience.
6:28
Here are some things to avoid.
6:30
Do not add extra empty header rows as this table does.
6:34
The screen reader will read these as blank.
6:37
Note that editorially flags this error.
6:40
Do not use stacked headers as this table does because the screen reader will reference the top header as it works through each cell and will not recognize the second header row.
6:50
The person listening won't get the correct context for the data in any of the columns.
6:56
This same table also merges cells in the first row.
7:00
Avoid that practice.
7:02
Also, do not split cells.
7:04
The user won't have the correct header as context for the data.
7:08
Note that editorially does not catch all of these issues.
7:12
It's not a perfect accessibility checker.
7:14
It's up to you to catch what Editoria11y misses.
7:18
If your table cells contain links, use descriptive link text as you would anywhere else, not URLs or text that says things like "click here."
7:28
You can learn more about descriptive link text in our video on that topic.
7:32
Make sure to format phone numbers and emails as links so people on mobile devices can tap the number to make a call or tap the e-mail address to write an e-mail.
7:42
You can learn more about linking phone numbers in our video about accessibility practices for people using mobile devices.
7:48
Simple, accessible tables, where information is presented in a predictable way are useful for everyone, and they're essential for people using screen readers and other assistive technologies.
8:01
For more help with accessibility practices, check out the ACCESS Team's resources.