Tables are a vital component of many documents. A table’s matrix of cells offers a potent means of conveying information in a way that simply cannot be replicated. Even better, the structural concepts of accessible tables are well understood and relatively well supported in high-quality assistive technologies that assist with many types of disabilities.
While almost any valid table (ie, an equal number of cells in every row and header cells as appropriate) can be made formally accessible, there are some key criteria to consider when designing tables with accessibility in mind.
To assistive technology, table tags indicate specifically that the contents of a <table> is tabular data, period. If you use tables because it’s a way to spread stuff around the page, consider another method. Don’t use a table.
If a table tool in an authoring application (such as Microsoft Word) has been used to simply arrange objects, we refer to this usage as a “presentation table”. For accessibility purposes, presentation tables should be avoided because the fact of a table indicates tabular information where none is present.
A legitimate data table almost always include <TH> header cells for one or more top rows or columns on the side. These <TH> cells describe the rows and columns of <TD> (Table Data) cells. Individual cells may span multiple columns or rows.
If titles and other notes occur within <Table> tags they must be tagged appropriately (with <Caption> or <Note> tags, as appropriate). These can go within the table structure or immediately before or after the table.
A common tendency is to squeeze everything into one table, or representing two sets of data within the same table structure.
Always look at your information and decide whether or not you’ve used a table structure to depict a single set of tablular information, and that that scope of information makes sense for that table.
It might well be easier for both the author and user if a table’s content is broken into two tables. Tagged PDF offers the flexibility to “correct” existing tag structures by simply re-tagging existing content as it should have been designed. This can be done in the Logical view or Table Editor without changing the physical layout at all, but it’s obviously more time-consuming to re-construct two tables from one when two were required in the first place.
It’s a reality that when remediating existing documents you’re dealing with a fixed physical table. Breaking up such tables in the tags will not change the physical appearance and can make the page far more accessible by assistive technologies.