6 Easy Ways to Improve Accessibility in HTML Tables

6 Easy Ways to Improve Accessibility in HTML Tables

HTML tables are a great way of visually representing data in a tabular format. They allow users to absorb information that would otherwise be more difficult to read. For instance, users can relate the data in each cell to others by skimming through the table.

However, this also means that blind users can’t relate these cells to one another as easily. And if they can’t easily access your tables, you’ll be preventing a large number of people from using your product.

What we can do to solve this problem is write proper HTML code that screen readers can interpret well. And to accomplish that, you’ll need to learn how you can improve HTML table accessibility.

In this article, you will learn more about HTML table accessibility and how to make accessible tables. You’ll also learn how you can fast-track the creation of accessible HTML tables in your app using a WYSIWYG editor. Let’s start by exploring more about accessible HTML tables.

Brief background on the HTML table element

We’re all familiar with HTML tables. These are HTML elements that organize and display data in a tabular format (rows and columns of varying lengths). They can also contain different types of information, such as text, images, links, and HTML elements, including nested tables.

HTML tables are versatile because you can use them anywhere as long as you need to represent related data in an organized way. In fact, they’re essential to some fields or tasks like data science or analytics.

You shouldn’t use HTML tables as a page layout method, even though it’s possible to do so. This is because their purpose is data display and not page layout. Furthermore, using them for layout could lead to lower-quality code and difficulties in implementing responsiveness and accessibility features.

What is HTML table accessibility?

Accessibility features exist to assist people with disabilities in using software applications or websites. These features include keyboard shortcuts, text-to-speech, color-blind accessibility, captions, mono audio, and more. So what is HTML table accessibility, exactly? It refers to making HTML tables as convenient for people with disabilities as they are for others.

And when it comes to making tables accessible, a screen reader is one of the best tools. Screen readers are an accessibility feature that blind people use to digest the contents of a website or app. These helpful tools decipher HTML tags and read the information to the user. How do screen readers interpret HTML tables, though?

Screen readers read HTML tables from left to right and top to bottom. Because of this, it’s usually difficult for them to interpret the placement of a cell or its relationship to another cell or header. Therefore, developers should write proper HTML code that assistive technologies can read. Let’s discuss how you can do this in the following section.

How can you improve HTML table accessibility?

At first, it might be confusing for some to make accessible HTML tables. But don’t worry too much, because there are plenty of resources out there that can guide you. To save you some time, I’ve compiled some of the best ways to improve HTML table accessibility for screen readers.

Use captions when you can.

Do you use normal headings (e.g., h2, h3) for table titles? If so, you should consider shifting to the <caption> tag instead. That’s because this tag indicates that it’s the right caption for a specific table. This makes it a lot easier for screen readers to associate the caption with the table.

This, in turn, makes things easier for people who use screen readers. By the way, the caption tag must always reside as the first element within an HTML table for it to work.

Use table headers properly.

Header cells (<th>) allow screen readers to give context to users by letting them know where they are. They also let users know how a cell relates to others. More importantly, row and column headers (along with regular data cells) should never have an empty value. That’s because it might derail the screen reader’s flow of reading.

But how can we do this if many of the tables have the top left cell empty? The answer is to make “visually hidden” content that’s invisible to visual users but visible to screen readers. One way of doing so is to use Bootstrap 5’s visually-hidden class. It’s important to note that this also applies to regular data cells.

Use the scope attribute.

The scope attribute of a <th> element further clarifies the context of cells. For instance, if you add “scope = row” to a <th> element, the screen reader will know that that header cell applies to all cells in that row. Similarly, “scope = col” associates every cell in a column with that header cell.

Use the alt attribute for images in tables.

We often need to add necessary images to tables. For example, what if you’re generating a report table that contains a comparison between the visual results of two processes (e.g., graphs)?

Adding the alt attribute to images makes sure that people who use screen readers can digest those types of content as well. Of course, the alternative text should be clear or detailed enough.

Consider the table’s complexity

Generally, the simpler a table is (the fewer merged cells or nested elements), the more accessible it is. That’s because it’s easier for screen readers to interpret simpler tables compared to complex ones.

However, when complex tables are inevitable, using the scope attribute becomes essential. If possible, you should always simplify tables by limiting the row and column headers to one each. You can also split tables into multiple ones instead of joining them to further reduce their complexity.

Be careful when using abbreviations and special characters.

It’s unfortunate that screen readers can’t always read abbreviations and special characters correctly. For example, a screen reader could pronounce the acronym “IT” as the “it” pronoun. Thankfully, there are solutions for this:

  • Add a period after every letter of the abbreviation (e.g., from “IT” to “I.T.”).

  • Add visually hidden text while using the aria-hidden=”true” attribute for the visual text (e.g., <td><span aria-hidden=”true”>IT</span><span class=”visually-hidden”>I.T.</span></td>)

  • Use the HTML tag <abbr>.

There are more tips to make HTML tables accessible, but it’s usually enough to follow the ones we’ve discussed above. If you want to learn more, check out the W3C’s Web Accessibility Initiative tutorial on tables here. Otherwise, that’s all you need to improve table accessibility in your projects.

But what if I told you that there’s an easier and much faster way to do this, especially if your application allows users to make their own tables (i.e., blogs or forums)? This method involves a WYSIWYG (what you see is what you get) editor, which we’ll explain in the next section.

How to make an HTML table accessible instantly using a WYSIWYG editor

WYSIWYG editors are tools that allow users to edit content while seeing how it will look once published easily. Both developers and application or website users can use these editors for any editing needs. A WYSIWYG editor usually has rich-text editing capabilities coupled with image handling, real-time editing, and other advanced features.

Here’s one of the fun parts of these editors: it lets users create accessible tables right away. Users only have to click on the button for tables, select the size, adjust the table layout, and write their content. This lets even those without prior HTML knowledge make accessible, sleek, and responsive tables quickly. In other words, WYSIWYG editors have a built-in table generator.

You should, however, assess the editing and table capabilities of a WYSIWYG editor before you choose one. While all WYSIWYG editors are helpful, most of them handle tables differently. To be safe, you should pick one that has the features, speed, elegance, usability, and accessibility that your app needs. Froala is one such editor, having won G2’s top WYSIWYG editor title and the hearts of developers around the globe.

Boost your productivity with Froala Editor

There are a lot of things to love about Froala’s HTML Editor. It reduces the effort required to make high-quality applications or web content. Because of its framework support and seconds-long integration process, developers can easily integrate it into their apps. It also makes adding and removing features easy for developers because of its modular (plugin-based) architecture.

Furthermore, application users can rely on Froala for the easiest and most comfortable editing experience. Froala is lightweight, feature-rich, and intuitive, which means that it takes the user experience to the next level. You can even choose (or let your users choose) between Froala’s standard, inline, and document modes.

Lastly, this editor already has accessibility support, so you won’t have to do the heavy lifting. There are numerous reasons why it’s helpful. Here are some things that you should expect when you choose Froala:

  • Easy integration into your projects, especially for popular libraries and frameworks, such as React and Angular

  • Basic and advanced rich-text editing capabilities

  • Responsiveness and mobile friendliness

  • Real-time editing

  • Markdown functionality

  • Carefully organized toolbar, elegant interface

  • Compatibility with every platform and browser

  • High degree of customization

  • Accessibility and language support

  • Scalability

  • No maintenance is required

  • Community support, documentation, and Froala support

  • 100+ features

When it comes to productivity and accessibility, Froala is a solid choice. Still, you should always refer back to the HTML table accessibility tips we’ve tackled in this article. As developers, we must ensure that the applications and websites we make can cater to the needs of everyone in our target market.

This includes people with disabilities, especially. And to do this, we must be aware of the steps we need to take, including adding accessibility and language support, to make our projects as usable as possible.

This article was originally published in Froala’s blog.