Page Content

Older screen readers had trouble reading tables, but this is not a problem for newer screen readers. See the tips section for information on how to make formatting tables more accessible.


  1. Layouts with multiple columns are accessible to newer screen readers, but you must ensure that the flow of the text is coherent.
  2. You can use the TABLE attribute for layout, but keep in mind that cells are read left to right, top to bottom. You do not need to include data table accessibility tags such as TH and SCOPE.
  3. CSS formatting is often preferred, but you must ensure that positioning doesn’t place elements out of visual order, causing the text to become incoherent when CSS is disabled.

Older Screen Readers and Multi-Column Formats

Older screen readers were unable to recognize columns (whether they were in TABLEs or formatted with CSS). Instead they would read the text on the page left to right as if it were linear, causing text to be read out of order

For this reason, some accessibility experts used to strongly discourage the use of multiple column layouts, which were then mostly implemented with formatting tables.

NOTE: Some screen reader software packages, such as JAWS, allow users to enter a table-reading mode, but some users may not be aware that this feature exists.

Is CSS better than TABLE?

With regard to accessibility, the difference is actually minimal. The main advantage of using CSS over TABLEs is that there is usually less code, making maintenance much easier.

However, you can cause accessibility glitches with CSS if positioning is not properly implemented. There are also inconsistencies in how CSS is rendered across browsers.

Almost all experts recommend using CSS-styled DIVs to set up layouts, but there are a number of serious pitfalls to be wary of. If in doubt, using tables for layout may be a better solution in the short term. It is not currently a part of Section 508 policy that all formatting tables be eliminated, just that they be accessible.

Benefits of CSS-Styled DIVs

  1. Screen readers do not announce the number of cells for DIVs.
  2. There are more formatting options available.
  3. Code is less bloated.

Pitfalls of CSS-Styled DIVs

  1. Floating DIVS may place content out of order for screen readers.
  2. They will probably not resolve the issues that older screen readers have with multiple column layouts.
  3. Implementation of CSS varies widely between browsers, so any design must be tested on multiple browsers. This problem has been lessening over time.
  4. Section 508 requires that content be readable with stylesheets disabled. Test to see that your site is coherent with CSS disabled.

    WCAG 2.0 Guideline 1.3.2—"When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined."

Tips for Implementing Formatting Tables

In general formatting tables are NOT recommended, but if they need to be implemented or maintained for some reason, these tips will make the output more accessible.
  1. Add the ARIA attribute role="presentation" to the TABLE tag (i.e. <table role="presentation">). This will disable some of the more distracting table attributes for a screen reader.
  2. When using a table for formatting, you do not need to use the TH, SCOPE, or CAPTION tags. These are only used for data tables.
  3. Make sure your text makes sense when read cell-by-cell, row-by-row, starting from the upper left . This is the default reading order of table cells for screen readers.
  4. If one of the columns is used for navigation, implement a Skip Navigation strategy so that users can navigate into content and skip repeating a set of site navigational links.

    WCAG 2.0 Guideline 2.4.1—"A mechanism is available to bypass blocks of content that are repeated on multiple Web pages."

  5. You can use the SUMMARY tag to indicate to screen reader users that the table is being used for layout purposes.
  6. Avoid using tables to create "textbars". CSS has more formatting options for this purpose and generates cleaner code.
  7. Avoid nesting tables for visual effect. Screen readers read out the number of rows and cells for each table, so the fewer tables, the better.
  8. Whenever possible, set column and table widths to relative sizes (e.g. width="25%") rather than absolute sizes (e.g. width="200"). This way, tables can be adjusted to fit the screen more appropriately depending on monitor resolution or zoomed text.
    NOTE: Some users deliberately set their monitors to a lower resolution (e.g. 800 x 1200 or 640 x 400) as a way to increase text size in general.
  9. Some formatting tables can be avoided by using CSS styles to specify background colors and borders for elements such as H1 tags or DIV classes.

Reading Order Issues

As mentioned above, the default reading order of table cells is left to right, top to bottom as shown in the example table below.

Example Table

Table Showing Screen Reader Order
Cell 1 Cell 2 Cell 3
Cell 4 Cell 5 Cell 6
Cell 7 Cell 8 Cell 9

It’s important that, when using tables for formatting, the text be coherent when read in cell table order. See the following example for details.

Inaccessible Table Reading Order

Here’s a table with "3 2 1 Ignition" going from the lower left to the upper right.


Users of visual browsers would process the text as "3 2 1 Ignition," but because of how the table is laid out, a screen reader would say "Ignition 1 2 3."

CSS Options

See the CSS page for links to tutorials, and for options regarding multiple column layouts.

The DIVs Resembling Tables section of the CSS page shows some options for adding borders and background colors with more control than in HTML tables. The Inaccessible CSS section shows how CSS can be used to inadvertently position text out of logical order.

Top of Page