Page layout using tables or frames

This set of notes covers the issue of using tables and frames to control the layout of content on a page. Some accessibility “purists” claim that tables should never be used for layout. However, if applied correctly, the table element is perfectly acceptable and, on some occasions, it can be a more accessible method than using CSS. Unfortunately the same cannot be said for frames which should be avoided if at all possible.

Using tables for an accessible layout

 

The case for using tables for layout

Sometimes it is not “most efficient” to use just stylesheets (CSS) to control the layout of a page. An example of this is when you want to have three vertical columns as in the page shown below.

Three column layout

Figure 1 - Using a table for a three-column layout

Trying to get CSS to display three columns reliably has been called “the holy grail” by some CSS experts. The problem is that we need to code the right-hand column before we can use CSS to "float" it to the right of the other two columns. This means that screen readers hear the right-hand column before they hear the other columns. 

The most practical, and simplest, solution is to use a basic table structure in HTML to hold the three columns. It is important that the table only has one row so that each of the three columns goes from top to bottom without a break. This means that the headings for each of the columns MUST be in the same cell as the text content of the column. If section headings are in seperate cells they will be read out of sequence to the content so that the user will not know which heading relates to which section of text.

Reading sequence (Linearised output)

Using layout tables is not restricted to three columns. There may be good reasons to use a table for more complex layouts. However it is important that the results always translate into a linear version that makes sense to the visitor. You must remember that automated tools read tables one cell at a time from left to right across each row. The diagrams below show the sequence of cell reading for some different table layouts.

1 2 3
4 5 6
7 8

Table 1
1
2 3
4 5
6
7 8
9 10

Table 2

In table 1 we have merged two cells whilst in table 2 we have also nested a second table within the first. In both cases the logical reading sequence for assistive software is identified by the numbers in the cells. This may not be the most logical order for reading your content. So, if you do need to use a table to control your layout please remember to keep it as simple as possible.

Merging cells to benefit screen readers

Previously we looked at how to organise our document so that our main content is presented in HTML as early as possible (near the top of the page). In the following example we have done this using a table with three columns and two rows to hold our layout. By merging the central column and leaving empty cells in the first row of columns 1 and 3. Screenreader or text-only browser will thus present the main content before the left-hand navigation bar or advertisements.

(1)

2) Central column

presents main content first

(3)
4) List of navigation links 5) Advertisements

Although visual users will see a standard web page layout the main text will be displayed first in Lynx and read first by a screenreader, even though it is visually positioned to the right of the navigation bar. Because these assistive software tools read tables in a linear format the sequence they present to the user will be :-

  1. Empty cell
  2. Main content
  3. Empty cell
  4. Navigation
  5. Advertisements

This benefits blind users and users of text-only browsers (including some hand-held devices)

We have merged the two rows of the central cells using the attribute rowspan="2" . The code for this is shown below.

 

<table>

<tr><td></td><td colspan="2"><h3>Central column</h3><p>Presents main content first</p></td><td></td></tr>

<tr><td>list of navigation links</td><td>Advertisements</td></tr>

</table>

 

Reminder: It is vital that you do not use any of the special data table elements and attributes when using a table to control page layout. In particular you should never use the heading, summary, title, th or tbody elements as these are all associated with handling data.

Borders - are they inside or outside the table ?

In lesson 4 we looked at how CSS defines borders for layers (divisions). A similar problem arises when we use tables for layout. If you specify a border width for a table, is that border placed inside or outside the stated dimension of the area? Let us take a very simple example. A table is defined in CSS and being a certain width that results in it being displayed on a screen as 100 pixels wide with a border of 1 pixel. Is the inside of the area 98 pixels or is the outside width 102 pixels? The answer depends upon the user's browser.

By itself one pixel here or there may not be a problem – but what happens if we try to insert four areas within this box to create a four-column layout. If we set each column area to be 25% wide will they be 25% of 100 or 25% of 98? If they are 25% of 98 then the screen cannot display 24.5 pixels so it will probably enlarge the areas to be 25 pixels wide, but we don’t have 4 * 25 (100) pixels available!. Different browsers will handle this problem in different ways. Some browsers will either put the fourth area below (creating a new row), others will push the length of original box to be bigger, others will simply allow the fourth area to overlap the side of the containing box. This gets quite complicated, as you have no control over which type of browser your visitor will use. The simple answer is to accept that your display may not be absolutely perfect on every browser and allow for the difference by ensuring that the total of the widths of any internal areas always equals less that 100% of the proposed available space. In the case above we would define the internal areas as having a width of 24% and accept that some browsers display this perfectly whilst others may show a small gap at the right-hand side. This solution is better than trying to be to exact and finding that some people get a distorted table.

Transparent gifs !!

Even using a table to layout part of the page may not be quite accurate enough for your purpose. There is a temptation here to use transparent images to force additional spaces within the table. This is very confusing for blind visitors because they hear the image name being read out aloud as they hear the content. This breaks the flow of the content and raises concerns within the mind of the visitor as to whether the image is important or not. So please do not be tempted - use CSS to arrange layouts within the individual cells of a table.

Page Load times

Another thing to bear in mind is that browsers such as Internet Explorer need to load and interpret the whole table before it can show anything to the user. If the table contains pictures, or other tables, this can take a longtime. Worse still if the whole page is laid out within a single table because the whole page has to be interpreted before it is rendered. People with slow Internet connections (not everyone has broadband) will get very frustrated if your pages take too long to arrive.

If you do need to use a table to layout your content, just use seperate tables within a page to layout specific parts only. Do not use transparent gifs to create spaces. KEEP IT SIMPLE.

Using Frames to layout page content

In the mid 1990’s using frames were very popular for controlling for page layout. Unfortunately frames present real problems for disabled users. For visual users these frames organised the content of a page into different zones that are each, in practice, separate web pages. However screen readers and text only browsers can only work with one page (frame) at a time so the relationship between the frames is lost.

In essence frames work by using a combination of separate HTML files to compose a single visible page. The first document contains the declaration and calls the various documents (frames), until the combination of documents forms the intended page as displayed in the browser window. The benefit of this approach is that each of the individual components (frames) can be replaced leaving the structural set of frames, such as the banner and navigation bars, in place. This makes it easier for the web engineer to create a dynamic site that maintain a consistent look and feel. It also means that individual frames can be scrolled up and down whilst leaving the surrounding frames static.

For example, if we take our simple page layout  (shown below) we could create the same look using four separate documents. We need the basic frame setting document and the three frame documents that make up the parts of the page.

Frame B

Navigation
Bar

Frame C

Page content

 

 The main disadvantage of this method is that each page contains four (or more) separate HTML documents. A blind user will not get an overview of the whole document. Instead the user can only read one frame at a time. If they want to move from the navigation frame to the content frame they have to load a new document. Almost everything that frames can do can CSS can do better.

The other disadvantages of using frames are:

  • Frames are not expected to be supported in future versions of HTML
  • Frames are difficult to use. (Printing the entire page is difficult).

  • The web developer must keep track of more HTML documents

So if you are creating new content please avoid using frames. If your existing content uses frames then please make sure that each frame has a unique title that explains its relationship to the page as a whole. Also make sure that you provide a <noframes> alternative for browsers that do not work well with frames.