Editor’s note: The Office of Accessibility is working with subject matter experts as we explore WCAG 2.1. One discussion that comes up is around tables, data, magnification, and reflow. This month we learn from two digital accessibility coordinators:

• Linda Shoemaker, MNsure.
• John Watne, Minnesota IT Services partnering with the Minnesota Department of Revenue.

Together they cover:

• Why should we talk about reflow when deciding how to present information to our readers.
• How reflow differs from the requirement to enable the resizing of text.
• Why reflow and data tables don’t mix.
• If tables don’t reflow, when should we use them.

Linda starts us off, sharing some reflow basics.

The Benefits of Reflow

• Reflow allows people with low vision to read enlarged web content without having to scroll in more than one direction. 
• Reflow also helps people with mobility issues who have difficulty scrolling in more than one direction. 
• Everyone benefits when all content is easily viewed on a mobile device.  Reflow rearranges web content into one column on devices with smaller screens so that scrolling in more than one direction is not necessary.

How is Reflow Different from Resize Text?

The purpose of resize text 1.4.4 is to enable users to increase text size by 200% without the page display getting messed up. For example: text should not overlap other text or elements and all the information on the page should still display. This passes even if you need to scroll in two directions to reveal it.

The purpose of reflow 1.4.10 is to enable users to zoom content to 400% without having to scroll in two directions. There is no requirement to resize the text to a particular size as in 1.4.4. For some implementations the text may continue to enlarge as the magnification increases. 

 These two criteria go hand in hand, so you might as well test them together. More information is in:

• Understanding Document for 1.4.4 Resize Text.
• Understanding Document for 1.4.10 Reflow.

Next, John’s going to share some specifics about tables.

Tables and Reflow Don’t Mix

Sometimes a table is the best way to present data. This helps people reviewing and working with the information. For example, state personnel might use a web application to monitor the status of property files submitted by each county. The appropriate workers might use the application to approve or delete the submitted files after reviewing them. A sortable table is the most efficient way to present the data for every file. It can display attributes of each file. The workers may use the attributes for filtering or sorting the data. The following figure gives an example of how this table can look when viewed on a laptop display, at default 100% magnification in the browser.

In this example, the table has 7 columns, and the people using this application need to view all the columns. The table fits easily on the page when viewed on a notebook display or wider, at 100% magnification. 

The entire table will not fit within a screen width on a mobile display, or at greater magnification, without scrolling both horizontally and vertically. And, readers need to have the data presented as a 7 column unit. It would not communicate the information the same way if the second half of this table, for example, moved beneath the first half. The following figure shows how both scroll bars appear when the user magnifies to 200% on a page of the same width.

This application demonstrates how reflow may not make sense when you must use a data table, especially when one or more of the following conditions apply:

1. The table must include multiple columns of data.
2. You cannot use text wrapping within one or more columns.
3. The minimum width requirements for the columns add up to more than the width of the display, at the selected magnification.

Even when you should not reflow a table, you should still reflow related items on the page as needed. The example data table includes two controls above it. One for specifying the maximum number of rows displayed, the other a filtering text field. 

When viewing the entire table without horizontal scrolling, as in the first figure, the two controls are in a single row, above the left and right ends of the table.

When needing horizontal scroll bars to display the whole table, as in the second figure, the controls reflow. When reflowing the controls, the maximum number filter appears above the filter text field.

Linda – this covered how our readers use content with magnification and reflow. Do you have recommendations for when to use a table and making them easier to use?

When to Use a Table

Choosing to use a table is all about the data

Use tables for two-dimensional information ("data table").

Data tables organize data into rows and columns of related information. The information in each cell has little meaning on its own. It's the topics in a cell's row and/or column header that provides the context and meaning for the cell's content.

For example, the table below is about the price of apples, oranges, and bananas by year.  The data cells contain prices related to a particular fruit (column header) in a particular year (row header).

We understand from the related information in the table above: 

• Apples were $4 in 2020, $5 in 2021 and $8 in 2022.
• Bananas were $1 in 2020, $2 in 2021 and $7 in 2022. 
• Oranges were $3 in 2020, $9 in 2021 and $6 in 2022.

This is an example of two-dimensional information appropriate to code as an HTML <table>.  

What about "layout" or "presentation" tables?

Although presentation tables are not prohibited under WCAG 2.0 AA, they are deprecated in HTML5:  

Tables must not be used as layout aids. Historically, some web authors have misused tables in HTML as a way to control their page layout. This usage is non-conforming … 

Screen readers will correctly identify a presentation table from a data table ONLY if you coded the presentation table correctly (e.g., no <th> elements; no <td> elements with a header or scope attribute). And there are still problems with presentation tables even if you coded them correctly: 

• If the user enlarges text on the page, text within a pixel-sized table cell may overflow its cell boundaries, and overlap/obscure adjacent content. 
• Actual order of the content (as you coded it) may not match the intended reading order. This may cause assistive technology users to perceive the content in an order different than author intended. 
• It’s an old fashioned and clunky way to control page layout. There more flexible (and standard compliant) ways to control and position page elements. Grids, for example. (More to come on grids in a future article!)

Tips for Making Tables Readable and Easy to Use

Be clear and concise

Use short descriptive text for the table headers and avoid abbreviations if possible. This helps all readers retain the information especially when scrolling/tabbing through many rows and columns.  

Check that the data cells do not contain too much information. If you are using paragraphs or lists in cells, this could indicate you are using the table for presentation rather than data. Consider reorganizing your content as headings, paragraphs, and lists. 

Strive for simple rather than complex table structure 

• Avoid merged cells
• Avoid multiple levels of header cells / combining topics separated by blank rows. 
• Avoid header cells that span multiple columns and/or rows.

Technically, you can code tables using the above structures to be accessible but consider restructuring the information to make it less complex for all readers.  

See this Tables Tutorial on appropriate structural markup for simple and complex tables. 

Use correct HTML markup so users of assistive technology can understand the logical relationships in the table

• Identify row and column headers with the <th> element.
• Identify data cells with the <td> element
• Set the scope attribute to col or row
• Use captions and summaries 
• Avoid blank cells. If the cell has no data, then indicate the cell is intentionally blank (i.e., “NA,” “blank,” “no data.”)