Tables

Why this matters

Screen readers linearize table content, reading left to right and top to bottom. Without proper header cells and scope information, a user has no way to know which header applies to which data cell. A table that looks obvious on screen becomes incomprehensible when read aloud.

For students with visual impairments, cognitive processing challenges, or temporary limitations (reading in bright sunlight, on a mobile device), a well-structured table with clear headers makes information accessible and understandable. For faculty and staff, accessible tables ensure that data visualizations and comparisons work across all platforms and formats, from web pages to PDFs to presentations.

Accessible table design also improves data quality and maintainability – tables with proper structure are easier to update, repurpose, and export to other tools. This institutional responsibility benefits the entire UGA community.

Data vs layout tables

Data tables

Data tables present information organized into rows and columns where the relationship between cells matters. Examples include course schedules, comparison charts, grade books, pricing tables, or test results. Data tables require semantic markup (headers, scope attributes, captions) so users understand what each cell represents.

Layout tables should never be used

Never use a table to arrange page content, create multi-column layouts, or structure navigation menus. This practice was common in early web design, but it breaks accessibility and modern responsive design. Use CSS, HTML semantic elements (like flexbox or grid), or proper page structure instead. If you have content arranged in rows and columns only for visual layout – not because the data relationships matter – you don’t need a table.

Building accessible table structure

Header cells (th) vs data cells (td)

Use the <th> tag for header cells and <td> tag for data cells. Don’t use <td> for headers even if you style them to look like headers. Screen readers must know which cells are headers to make sense of the table.

The scope attribute

The scope attribute tells screen readers which header applies to which cells. A header can have a scope of “col” (applies to the column below) or “row” (applies to the row to the right). For simple tables with a header row and a header column, scope attributes clarify relationships. For complex tables with multiple rows or columns of headers, scope becomes even more critical.

Table captions and summaries

Every table should have a caption that describes what the table shows. The caption is part of the table’s semantic structure and helps all users understand its purpose. For complex tables, you might also include a brief summary describing the table’s structure and main findings.

Simple vs complex tables

A simple table has one row of headers at the top and/or one column of headers on the left. A complex table has multiple rows of headers, multiple columns of headers, or headers that don’t fit neatly into rows or columns. Complex tables may require more detailed scope attributes or even additional ARIA attributes to be fully accessible. When in doubt, simplify your table structure.

Avoid merged cells

Merged cells (cells that span multiple rows or columns) confuse screen readers because they break the regular grid structure. Whenever possible, avoid merging cells. If merging is necessary to convey meaning, use scope attributes carefully and test with a screen reader.

Table structure in documents

This guidance applies to tables in Word documents, PDFs, and presentations too. Use native table features and mark header rows and columns properly. Software-specific instructions vary, but the principle is the same: make headers identifiable and data relationships clear.

Example: accessible table

The following table demonstrates accessible structure. It includes a caption, header cells with scope attributes, and clear descriptive headers. After the table, each accessibility feature is explained.

What makes this table accessible

• Caption: The <caption> element describes the table’s purpose — “Digital accessibility training completion by department, Fall 2025.” Screen readers announce this before reading table data, giving users context.
• Column headers with scope: Each column header uses <th scope=”col”>, telling screen readers that “Staff trained,” “Completion rate,” and “Status” apply to the cells below them.
• Row headers with scope: Each department name uses <th scope=”row”>, so when a screen reader reaches “92%,” it announces “Academic Affairs, Completion rate, 92%.” Without row headers, a user would hear just “92%” with no context.
• Descriptive header text: Headers like “Staff trained” and “Completion rate” are specific. Vague headers like “Number” or “Percent” would leave users guessing.
• No merged cells: Every cell occupies one row and one column, keeping the grid structure intact for assistive technology.
• No color-only meaning: The “Status” column uses text (“On track,” “Complete,” “In progress”) rather than relying on colored indicators alone.

How a screen reader reads this table

When a screen reader user navigates to this table, they hear the caption first. As they move through cells, the screen reader announces the relevant headers automatically. For example, pressing the down arrow in the “Completion rate” column would read:

• “Academic Affairs, Completion rate, 92%”
• “Student Affairs, Completion rate, 85%”
• “Information Technology, Completion rate, 98%”

Without proper headers and scope, the screen reader would just say “92%,” “85%,” “98%” — meaningless without context.

Best practices for tables

Keep tables focused and simple

Each table should present one main idea or dataset. If you’re combining multiple unrelated datasets, split them into separate tables. Simpler tables are easier to understand for everyone.

Use descriptive headers

Headers should be clear and specific. “Name” is better than “Item,” and “Fall 2026 Enrollment” is better than “Data.” Descriptive headers help readers (and screen readers) immediately understand what each column or row represents.

Format numbers consistently

If a table contains numbers, align them to the right and use consistent decimal places. Consistent formatting makes patterns easier to spot and comparisons easier to make.

Avoid color as the only way to convey information

Don’t use color alone to highlight important cells or distinguish categories. Pair color with text, icons, or other visual cues. Users with color blindness or who are reading in grayscale must still understand the information.

Test with a screen reader

Before publishing a table, test it with a screen reader to make sure the structure is clear and headers are announced correctly. What looks fine on screen might be confusing when read aloud.

Common mistakes to avoid

• Using tables for layout: Tables are for data, not for arranging page elements. Using tables to create columns or structure navigation confuses screen readers and breaks responsive design. Use CSS and semantic HTML instead.
• Missing header cells: Every table should have header cells that identify what each column and row represents. Using regular data cells with bold styling isn’t enough – screen readers won’t recognize them as headers.
• Forgetting scope attributes: In anything but the simplest tables, scope attributes clarify which header applies to which data. Without them, screen reader users are left guessing what information means.
• No table caption: Every table should have a caption describing its purpose. This helps all users understand why the table is there and what to expect.
• Excessive merged cells: Merged cells break table structure and confuse assistive technology. Simplify your table design to avoid merging when possible.
• Unclear or vague headers: Headers like “Info,” “Data,” or “Results” don’t tell users what they’re looking at. Be specific: “Spring 2026 Class Enrollment” or “Average Test Score by Department.”

WCAG criteria

Accessible tables address the following WCAG 2.1 success criteria:

• 1.3.1 Info and Relationships (Level A) — Information, structure, and relationships conveyed through presentation can be programmatically determined. This is the primary criterion for table accessibility.
• 1.3.2 Meaningful Sequence (Level A) — The reading sequence of table content must be logical when linearized by assistive technology.
• 1.3.3 Sensory Characteristics (Level A) — Instructions for understanding table content should not rely solely on visual characteristics like position or color.
• 1.4.1 Use of Color (Level A) — Color should not be the only visual means of conveying information in table cells.

Related DASH resources

• Creating accessible documents including Word, PDF, and presentations
• Making data visualizations accessible
• Digital accessibility checkpoints for evaluating your content
• Accessibility testing tools and resources

Getting help

UGA’s Digital Accessibility Services Hub (DASH) is here to support you. Whether you need guidance on making your content accessible, help troubleshooting an issue, or training for your team, we are ready to help.

• Contact DASH at [email protected] for consultations, training, or technical assistance.

Accessibility is a shared responsibility, and every step you take makes UGA’s digital environment more inclusive.