Tables

What are Tables?

HTML tables are designed to display tabular data, presenting information in rows and columns. They’re created with the <table> and are ideal for presenting information that’s best understood in a matrix, like schedules, comparison charts, or datasets.

A basic HTML table is made up of:

• <table> for the overall table

• <th> for table headers

• <td> for data cells (the actual content)

• <tr> for table rows

How Do Tables Impact Accessibility?

From an accessibility perspective, tables need to be used correctly so screen readers can announce the relationship between rows and columns accurately. 

• Data relationships: Visual cues like bold text or position help sighted users identify table headers and understand data relationships. For screen readers, programmatic associations between headers (<th>) and data cells (<td>) are essential. Without these, a screen reader might read cells out of context, making the data incomprehensible.

• Alternative for visualizations: Tables can also serve as a textual alternative for complex data visualizations like charts and graphs, making the information accessible to users who cannot perceive the visual representation.

• Use tables for data, not layout: Avoid using tables for page layout. Layout tables can confuse screen reader users and break the logical reading order.

What WCAG Success Criteria are Relevant for Tables?

• 1.3.1 Info and Relationships (Level A): Requires that table structures are properly marked up so their relationships are clear and can be programmatically determined. This includes using <th> tags with scope attributes or id/headers attributes.

• 1.3.2 Meaningful Sequence (Level A): Ensures that when the sequence of content affects its meaning (as in a table), a correct reading sequence can be determined. This is tied to correct table markup.

How Do I Maximize Accessibility When I Code Tables?

Coding accessible tables correctly ensures screen readers can announce data relationships clearly, meeting WCAG requirements and improving the experience for all users. 

• Use for data only: Tables should be used only for presenting tabular data, not for layout purposes. Using tables for layout can confuse screen readers by presenting content in a non-linear, illogical order.

• Mark headers with <th>: Identify row and column headers using the <th> element instead of <td> so assistive technology recognizes them as headers.

• Add the scope attribute: For simple tables, use the scope attribute (with values like col for column headers or row for row headers) on <th> elements to explicitly associate headers with their corresponding data cells.

• Caption/summary: Provide a <caption> element or a summary attribute for the <table> to give a brief description or name for the table.

• Handle complex tables with id and headers: For more complex tables with multiple levels of headers, use id and headers attributes to programmatically associate data cells with their respective headers.

• Plan for responsive design: Use CSS techniques (like overflow scroll or stacked layouts) to make sure tables remain usable on smaller screens without breaking header associations. 

How Do I Test the Accessibility of Tables?

Testing tables ensures that all users, including those using screen readers or keyboards, can understand data relationships. Below are a few ways to test tables for accessibility.

Test with Screen Readers

Screen reader testing is the most reliable way to confirm that your table is semantically correct.

• Navigate by table: Use the table quick key (often 'T') to navigate through tables and listen for how the screen reader announces headers and data cells in context.

• Verify header associations: Verify that column and row headers are correctly identified and read aloud when navigating through the data cells. This ensures that <th> elements and scope attribute (or id/headers for complex tables) are functioning properly.

• Check captions: Listen to ensure the table’s <caption> or summary is announced before the table content. This gives context to screen reader users.

• Keyboard navigation: Use Tab and Arrow keys to confirm the table can be explored in a logical order without a mouse.

Use Automated Tools

Automation helps quickly flag common issues, but should not replace human review.

• Run WAVE or Axe: These tools can identify potential table errors, including missing <th> elements, improper heading associations, or layout tables that may cause confusion.

• Look for warnings: Pay attention to warnings about missing captions or headers and verify manually.

Perform a Manual Visual Review

Human judgment is still required to ensure content is truly accessible.

• Check readability: Ask yourself, could someone understand this table if they couldn’t see it? Are the headers descriptive enough to make the data meaningful?

• Simplify if needed: For overly complex tables, consider breaking them into smaller, simpler tables or providing a textual summary to aid comprehension.

• Responsive view:  Resize your browser window to ensure the table remains usable and headers still make sense on small screens.

How Can I Learn More About Accessible Tables?

Explore techniques for providing text descriptions or data tables to convey the same information as charts and graphs. This involves understanding how to effectively present complex visual data in an accessible, textual format and how to link these alternatives to the visual content.