HTML tables aren’t a good choice to use to create columns or layouts in a webpage because they aren’t as responsive to small screens and can cause confusion to screen reader users. Back in the late 1990s a lot of designers used tables for visual layout, but this was later found to be a bad practice because fixed-width table-based layouts didn’t adaptive well to different-sized screens. This layout practice used the HTML <table> element for a use that it wasn’t semantically intended. HTML tables were designed for data grids, from the perspective of semantic structure, so it is better to use them only for that purpose.
How developers can ensure layout tables don’t cause problems for assistive technology
Web developers should take steps to ensure layout tables don’t cause problems for screen reader users. If an HTML table must be used for a layout, the developer should add the role=”presentation” attribute to the <table> element so it’s not confused with a data table. Role=”presentation” tells the screen reader to ignore the semantic table markup and treat it as normal text. The web developer also should not include any of the header markup for data tables in a purely visual layout table. These data table header markup tags to avoid are:
- The <caption> element
- The <summary> attribute
- The <th> element
- The scope attribute (that goes in a <th> tag)
- The headers attribute (that goes in a <td> table cell tag)
If data table markup tags are used in a purely visual layout table, screen reader users might expect the table to represent tabular data leading to confusion or a poor user experience. So, if a purely visual layout table must be used the developer should ensure that ARIA is used to make it look like normal text to screen readers. Any purely decorative images used in the table so be marked with null alt text (alt=” “) or hidden from readers with aria-hidden=”true”. Back in the late 1990s, web designers used to use tools like Macromedia Fireworks to slice up webpage visual mockups into layout tables and many time these tables would include a bunch of purely decorative images.
An easy way to avoid the troubles with layout tables is to avoid using them at all. For the modern web CSS (cascading style sheets) is a more robust way to design visual layouts. Once web developers realized web sites would be viewed on devices of many different screen sizes, they began using CSS to create columns, float content, and adapt to different viewport widths. The latest Web Accessibility Guidelines (WCAG 2.1) say that websites should be responsive and including layout tables would likely work against that. According to WCAG guidelines, tables should reflow to fill most of the width of the viewport, without causing any horizontal viewport overflow. On smaller screens it becomes more difficult avoid horizontal scrolling (horizontal overflow). The WCAG SC that is related to tables and horizontal viewport overflow is 1.4.10 Reflow. This success criterion requires that content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for vertical scrolling content at a width of 320 CSS pixels.
How content authors can avoid using tables for layout
As a content author, might craft your blog posts in MS Word documents and you might desire to create a visually interesting layouts using tables in Word. But doing so will introduce some of the same accessibility problems as with using HTML tables for layout in a webpage. It’s best to paste your content into WordPress blog posts as plain text without MS Word formatting so the conversion to HTML will be more semantically correct, free from accessibility problems. Pasting a table-based visual layout from a Word doc should be avoided because it can introduce accessibility problems into a blog post and lead to poor user experiences for both visual and screen reader users. Tables aren’t really a valid layout technique in Word documents. They are meant for tabular date (data grids). When publicly shared on the web at public universities, Word docs (and PDFs) are expected to follow WCAG guidelines. So, it’s best to follow accessibility best practices even in our Word documents.
WordPress blog sites may or may not include a table tool in the rich text editor for posts. If your WordPress blog does include a table tool, be sure to use it responsibly. Avoid using the table tool for layout tables unless you have the HTML expertise to markup the table so it doesn’t cause problems for assistive technology. If your blog includes a table tool, it’s best to stick to using it just for data tables. You can ask your department’s web developer to check your data table for accessible markup. It’s possible for rich text editors to create simple accessible data tables but when you get into more complex data tables you’ll have to go to the code view to insert the correct accessible markup. Some more advance table markup that might not be in your rich text editor’s table tool may include:
- Ability to add the scope attribute (that goes in a <th> tag)
- Ability to add the headers attribute (that goes in a <td> table cell tag)
Once you get into creating more complex data tables you should probably work with your department’s web developer to make them accessible. For accessible presentation in websites, sometimes it’s better to split a complex table into two or more simple tables. This makes the data tables easier to understand to screen reader users a more adaptable to different screen sizes (more responsive).