[Speaker] Welcome! Content Lab brings you the next video in our
series about accessible content practices for web authors.
In this video, you'll learn about making accessible tables
in the Mass.gov CMS.
We'll focus on tables you build in rich text fields.
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.
This table on the Salt Water 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. Here is a table
that does not organize information for easy use.
Listing these language translations in a table
with no headers was a design choice.
Maybe the author wanted to save vertical space on the page,
but you don't wanna use tables for design reasons.
That's not the purpose of a table
and a screen reader can't correctly read a
table without headers.
Using tables for the right reasons is good content practice,
but it's also good accessibility practice.
We'll explain why in this video.
The tables you build in rich text fields in the CMS are best
for small sets of data.
50 rows maximum.
You can build tables on any page type
that offers a rich text field.
Here's how. The author creates a new info details page in the CMS.
In edit mode,
They go to the Content tab
and select the Rich Text component.
When the rich text field opens, they select the Table icon
and then select the number of rows
and columns they want for their table.
Now they can enter data in the table.
A screen reader will read out the row
and column headers as it navigates through a table.
The screen reader speaks one cell at a time
and announces the relevant header cells
so the reader doesn't lose context.
Here is a sample of a screen reader
announcing data in a table.
Note how it says the header for each cell.
[Screen reader] Executive office for administration and finance,
row two, Julia M. Wong.
Title column three, secretariat IT accessibility officer
email column four, link anf.accessibility@mass gov.
Executive Office of economic Development row three,
Link eoed.accessibility@mass.gov.
Executive office of education row four TBD
title Column three secretariat it accessibility officer
name column two, Lawrence Weru.
[Speaker] The screen reader user builds a mental model of the table
as the information is announced.
Headers act like landmarks.
They orient the person as they build that model.
If your table is not accessible, the reader has
to work harder to consume the information auditorily.
Here are some best practices to follow
to build an accessible table in a rich text field.
It's best to create your table in the rich text field
to ensure proper formatting and accessibility.
Do not copy
and paste a table from another source
into a rich text field.
Also, do not put screenshots of tables in a rich text field.
An image of a table is not readable by screen readers.
This MassHealth table is a screenshot.
It's labeled as an image in the rich text field.
The alt text says, "2025 MassHealth income standards
and federal poverty guidelines."
A person using a screen reader would only hear that
and none of the data in the table.
Use headers for each column or row.
The CMS will not let you save a table without headers.
Here is a table with row headers.
Here is a table with column headers.
Make sure the headers are specific and meaningful.
Everyone appreciates a descriptive header
that reveals exactly what data
or information they'll find in the
corresponding column or row.
For example, this table about agricultural pests from a 2024
survey uses specific column headers like "common name"
and "scientific name,"
and the data that follows under each is exactly
what the header promises.
Avoid using special characters in headers.
Screen readers will say the name
of the character, like hashtag.
Instead, write out the word "number" or "percent"
instead of using the characters.
Avoid abbreviations in tables
unless they're spelled out in the header
or the first time they're used. On this page about bar exams
for example, "multi-state performance test" is written out
with "MPT"
in parentheses in the header as a way
to introduce the acronym.
Make sure the data in the table is consistent in type
and format. In this table about hiking trails
for example, notice that each park name is hyperlinked.
Notice too that the mileage
and activity level
for each trail follows a consistent format.
Information in a table is easier for every user to scan
and consume when it follows a consistent format.
Remember, an accessible table organizes data.
You don't want to use tables for layout.
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.
Instead, the headings are in the same cell
as the information.
Screen readers can't correctly announce the information in a table
that's not properly formatted, so while it may be tempting
to use tables for layout purposes, it's best to avoid
that practice. Tables do make sense
for quick lookup purposes.
These tables about camping fees, organize
that information for easy scanning.
Certain choices you might make with headers will lead
to a confusing screen reader experience.
Here are some things to avoid.
Do not add extra empty header rows as this table does.
The screen reader will read these as blank.
Note that Editoria11y flags this error.
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.
The person listening won't get the correct context
for the data in any of the columns.
This same table also merges cells in the first row.
Avoid that practice. Also do not split cells.
The user won't have the correct header
as context for the data.
Note that Editoria11y does not catch all of these issues.
It's not a perfect accessibility checker.
It's up to you to catch what Editoria11y misses.
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."
You can learn more about descriptive link text in our
video on that topic.
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 email address to write an email.
You can learn more about linking phone numbers in our video
about accessibility practices
for people using mobile devices.
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.
For more help with accessibility practices,
check out the ACCESS team's resources.