Web Access Centre

Layout tables - Web Access Centre

Summary: The Website Accessibility Initiative allows table used for layout if coded correctly as an interim solution while CSS becomes more widely supported.

• Rationale
• Techniques
• Testing tips
• Website Accessibility Initiative compliance
• Other pages about layout and structure

---

Rationale

Layout tables are not always visible on the page, but are present in the coding and need to be made accessible. They need to be optimised to support people who require low screen resolutions as well as those who need to use assistive technology such as speech or braille output and screen magnification software.

As people get older, their sight can deteriorate, and one of the simplest ways to compensate for this is by reducing the computer screen resolution, so that everything is larger. Tables that use fixed values for sizes may define a width that is larger than the screen resolution, making it necessary to scroll sideways to read the entire page. This can be disorienting, making reading laborious, especially for those who also use magnification to read the screen or who are viewing the page on a very small screen, such as in a mobile device.

Multiple levels of nested tables can create a number of accessibility problems:

• Where information is provided in a visually separate "box", which is anchored to the beginning of a paragraph, once linearized, it will be read ahead of that text, and may confuse or interrupt the flow of reading from the previous paragraph.
  
  
• Many screen readers announce the beginning and end of each table; so multiple levels of nesting can mean that table announcements are repeated several times in succession before the content can be read.

The WAI (Web Accessibility Initiative) promotes using CSS (Cascading Style sheets) for layout and formatting but it is fully accepted that this is not always possible. So, until most browsers and access technology fully supports CSS, tables used for layout are accepted as a legitimate accessible means of positioning layout.

Techniques

• Opt for CSS layout and only use tables for design if CSS layout is impractical. In any case, use CSS to format the 'look and feel' of tables and their contents.
  
  
• Build in Flexibility, wherever possible use percentage (%) values for the size of a table and its elements. This will allow the layout to be resized relative to the screen resolution it is being viewed in and minimise scrolling.

Row HEIGHT attributes should always be given a relative value, if they are defined at all. Fixed heights may mean that users who choose larger text sizes from their browser settings will be unable to read a cell's content, as it will be truncated or even overlap because it is trying to fit into an area that is fixed at too small a height.

• Keep it simple, wherever possible, avoid unnecessary nesting of tables. In any case, no more than three levels of nesting should be used.

Also avoid the temptation to use one row for a heading and another for its related content, especially where content is presented in more than one column. The effect of this would be that screen reader users would hear the headings grouped together, followed by the now disconnected, content.

Keep headings (formatted by CSS) and all related content in one cell to prevent producing an illogical reading order when the page is read by a screen reader, or linearized by the user's software.

• The table SUMMARY attribute should really be used for data tables only but some users may find it helpful to have this information as a form of map to which area of the page they are in.

Screen reader users will hear the summary at the start of a table. A less experienced user might like to know when they have reached “main content” but a more experienced user may find this intrusive. Certainly superfluous information in the summary can spoil the user experience, especially when the same information is repeated on every page ie “This table contains the global navigation”; “This table contains the main content”. So the summary should be concise, almost to the point of being terse.

One option may be to use summaries on the home page only, which would give the user an overview of the layout and what to expect in the rest of the site. However, if pages are constructed with content correctly structured with headings, clear link text and well written content, then the need for summarised layout tables is lessened.

• Headers and captions must not be used in layout tables, the <TH> and CAPTION element signal that a data table is present. It may cause confusion if they were used simply to apply text formatting to content in layout tables.

Testing tips

Verify that text is fully and clearly readable, it must not become overlapping or truncated when text is enlarged. Summaries if used should be brief and concise, headers and captions should not be used for text formatting. Also make sure that the content is presented in a logical order if the table layout is removed.

• Accessibility toolbar – Go to Structure - Simple Data Table to identify any use of <TH>. Structure - Other Element(s) - "caption" to find any captions used.

To reformat the page without tables, go to Structure – Table Cell Order or Structure – Linearize and make sure that the resulting content still makes sense without the table layout.

Finally go to Resize and select the 640 x 480 screen resolution to simulate a low screen resolution, and ensure that the result does not require extensive scrolling for page content to be read.

• Browser - Manual View - Text Size - "Largest" to ensure that all text is clearly readable.

To check that headers and captions have not been inappropriately used, go to View - Source. Edit - Find <TH. Then Find – CAPTION and make sure that, if they are present, it is as part of a data table, and not for text formatting.

• Screen reader - Listen to the order of output.
  
  
• Text browser - Ensure that the page reads in a logical order.

Website Accessibility Initiative compliance

• 11.2 Avoid deprecated features of W3C technologies. Priority 2
  
  
• 11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. Priority 2
  
  
• 5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). Priority 2
  
  
• 5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. Priority 2
  
  
• 3.5 Use header elements to convey document structure and use them according to specification. Priority 2
  
  
• 3.3 Use style sheets to control layout and presentation. Priority 2
  
  
• 3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values. Priority 2
  
  
• 5.5 Provide summaries for tables. Priority 3.
  
  
• 10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns. Priority 3
  
  

For more information on techniques visit the Web Accessibility Initiative techniques page.

Other pages about layout and structure

• CSS
• Data tables
• Doctypes
• Frames
• Layout tables
• Metadata
• Structure

Back to Design & Build

For Web Access Centre updates email webaccess@rnib.org.uk

Content author: henny.swan@rnib.org.uk

Last updated: 20/11/2008 11:13