Cookie

It seems trivial, but there are certain aspects of computer, and therefore also of HTML that occasionally should be revisited. It should be noted that the W3C strongly recommend against using tables to design the layout of the site. The tables are used for data input, the layout is done with div.

Tables should not be used to define the content of the graphic because it could present problems for screen readers (but also for bots). More, when you used to define the graphic, tables may force users to scroll horizontally to view a table page designed for a larger screen. To minimize these problems, authors should use CSS to control the layout instead of tables.

Interestingly, the W3C never use the imperative (they should, should not…), they know that good manners.

Today we see some table article (to serve as a table and not as layout) and variations on them. They can draw their own conclusions.

The tag for the header: “th

The tag “th” It serves to define the table header: the first line and / or the first column. The simplest structure now fallen into disuse (without “th“) it's the following:

<table>  
  <tr>  
    <td>Auto</td>  
    <td>Type</td>  
    <td>displacement</td>  
  </tr>  
  <tr>  
    <td>Opel</td>  
    <td>Corsa</td>  
    <td>1.2</td>  
  </tr>  
  <tr>  
    <td>Citroen</td>  
    <td>c2</td>  
    <td>1.1</td>  
  </tr>  
</table>

What will produce this result:

AutoTypedisplacement
OpelCorsa1.2
Citroenc21.1

For those not big eyesight it is easy to understand what we're talking, but who must rely on a screen reader for the interpretation of the web page, it would be significantly disadvantaged. This is why we introduced the tags “th“, stands for “table header“. This tag defines the table header and separates it from the table data (“td” – table data) and is used in this way:

<table>  
  <tr>  
    <th>Auto</th>  
    <th>Type</th>  
    <th>displacement</th>  
  </tr>  
  <tr>  
    <td>Opel</td>  
    <td>Corsa</td>  
    <td>1.2</td>  
  </tr>  
  <tr>  
    <td>Citroen</td>  
    <td>c2</td>  
    <td>1.1</td>  
  </tr>  
</table>

That will generate this result:

AutoTypedisplacement
OpelCorsa1.2
Citroenc21.1

The tags for captions: “caption

Just like the photographs, Also for the tables there is a caption. You can show the caption above or below the table, the CSS element that allows the positioning is “caption-side” and accepts as arguments “top” the “bottom“. However the tag “caption” it's not mandatory, depending on the circumstances it may be used or less.

If used should be placed immediately after the opening tag “table“.

<table>
  <caption>How many cars are parked in my garage?</caption>
  <tr>  
    <th>Auto</th>  
    <th>Type</th>  
    <th>displacement</th>  
  </tr>  
  <tr>  
    <td>Opel</td>  
    <td>Corsa</td>  
    <td>1.2</td>  
  </tr>  
  <tr>  
    <td>Citroen</td>  
    <td>c2</td>  
    <td>1.1</td>  
  </tr>  
</table>

What will produce this result:

How many cars are parked in my garage?
AutoTypedisplacement
OpelCorsa1.2
Citroenc21.1

The attribute to summarize the contents of the table: “summary

In addition to the tag “caption” you can use the attribute “summary” (to bind to the tag “table“) to briefly explain the contents of the table. This option is not visible to the user who sees the table, serves to those who see not using a screen reader to understand right away if the table it can affect whether or not.

The right structure is as follows:

<table summary="Brand, model and engine capacity cars parked in my garage">
  <caption>The car in my garage</caption>
  <tr>
    <th>Brand</th>
    <th>Type</th>
    <th>displacement</th>
  </tr>
  <tr>
    <td>Opel</td>
    <td>Corsa</td>
    <td>1.2</td>
  </tr>
  <tr>
    <td>Citroen</td>
    <td>c2</td>
    <td>1.1</td>
  </tr>
</table>

The result of these lines of code with the style globally applied to this site is that:

How many cars are parked in my garage?
BrandTypedisplacement
OpelCorsa1.2
Citroenc21.1

It is important to point out that the attribute “summary” It is not visible to the eye of those who surf, It is nevertheless recorded as complementary information by bots and better indexes the table and is read by screen readers to help users with visual impairments.

Headers abbreviated with the attribute “abbr

The attribute “abbr” It is another optional attribute, if that is not put does not affect the structure or operation of the table. The content is read by screen readers to give a concise definition to those who have vision problems, that in this way it will avoid feeling headers with minor differences. The attribute “abbr” It is used in this way:

<table summary="Brand, model and engine capacity cars parked in my garage">
  <caption>The machines of my garage</caption>
  <tr>
    <th abbr="Brand">The car brand</th>
    <th abbr="Type">The car model</th>
    <th abbr="displacement">The car engine</th>
  </tr>
  <tr>
    <td>Opel</td>
    <td>Corsa</td>
    <td>1.2</td>
  </tr>
  <tr>
    <td>Citroen</td>
    <td>c2</td>
    <td>1.1</td>
  </tr>
</table>

Relate headers and data: “scope“, “id” and “headers

The tables are far enough banal views, This is how to make it clear to the screen reader the correlation between headers and data. We eliminate the header “Brand” This in our chart, and modify the entries for the brand so that they become a header.

<table summary="Brand, model and engine capacity cars parked in my garage">
  <caption>The car in my garage?</caption>
  <tr>
    <td></td>
    <th>Type</th>
    <th>displacement</th>
  </tr>
  <tr>
    <th>Opel</th>
    <td>Corsa</td>
    <td>1.2</td>
  </tr>
  <tr>
    <th>Citroen</th>
    <td>c2</td>
    <td>1.1</td>
  </tr>
</table>

And the result will be:

How many cars are parked in my garage?
Typedisplacement
OpelCorsa1.2
Citroenc21.1

We add the attribute “scope” to facilitate the work to the screen reader:

<table summary="Brand, model and engine capacity cars parked in my garage">
  <caption>The car in my garage</caption>
  <tr>
    <td></td>
    <th scope="col">Type</th>
    <th scope="col">displacement</th>
  </tr>
  <tr>
    <th scope="row">Opel</th>
    <td>Corsa</td>
    <td>1.2</td>
  </tr>
  <tr>
    <th scope="row">Citroen</th>
    <td>c2</td>
    <td>1.1</td>
  </tr>
</table>

The attribute scope It defines a header cell and provides header information for a column or row:

  • col: header for the column
  • row: header for the row

Adding scope with the value with the headers of the first row we go to indicate that they are the headers for the cells listed below.

Conversely using row We will denote that the headers refer to the cells of the corresponding row (to the right).

The attribute scope also it supports two other values:

  • colgroup: headers for the column group that contains
  • rowgroup: headers for the group of rows that contains

For the groups of columns you are using the element colgroup, while for groups of rows can use thead, tfoot and tbody (we'll see).

Another technique for linking the data of a cell with the appropriate header is attributable to each header a id univocal, then add the attribute header at any given. This attribute contains a space separated list of id of each header cell that applies to the data of that cell. This technique is more complicated and should only be used when there is data that should be tied to more than two header cells, when the attribute scope It is insufficient such as in very complex tables or irregular.

To illustrate this example I changed the table.

How many cars are parked in my garage?
Technical dataType
displacementSupply
Opel1.2GPLCorsa
Citroen1.1Petrolc2

Clearly this method becomes complicated rather quickly, best to use the attribute scope When possible.

Row Groups: thead, tfoot and tbody

The rows in the table can be grouped into headers (thead), Pie di page (tfoot) and one or more bodies (tbody). Obviously each group of rows must contain one or more rows of the table.

If a table contains a instestazione (thead), must appear before footer sections (tfoot) e body (tbody). If we decide not to use the header or footer elementtbody it's not mandatory (but not prohibited, so we use it at will). The structure of the table with groups resemble lines to this:

<table>
   <thead>
      <tr></tr>
      … righe relative all'header
   </thead>
   <tfoot>
      <tr></tr>
      ... rows relating to footer
   </tfoot>
   <tbody>
      <tr></tr>
      ... rows relating to body
   </tbody>
   <tbody>
      <tr></tr>
      ... lines relating to the body of the second table
   </tbody>
   ... other body sections if necessary
</table>

Grouping the rows may be advantageous for several reasons:

  • simplifies apply styles (CSS) sections thead, tfoot and tbody independently, without adding any classes or other,
  • when we launch the release of particularly long tables some browsers (for example those based on gecko) repeat the information contained in thead and tfoot on each printed page, making reading easier,
  • separate sections “header” and “footer” the body of the table makes it possible for browsers to display scrolling the only body.

What benefits

It may seem like a lot of work to create accessible tables in HTML, and indeed for complex tables it is. Sometimes it is impossible they can be created by hand. For simple tables, still use the header cells with the attribute scope it is faster and easier.

It seems obvious that those who use assistive technologies such as screen readers get an absolute benefit from tables optimized for accessibility. Try to make sense of a table of large and complex data simply by listening to a synthesized voice can be very difficult or even impossible. To simplify and make them accessible is a duty.

Less obvious is the benefit obtained by the designer and the average user, but an accessible table is full markup to which to apply CSS styles. An attractive and well-displayed table can make the chart easier to read for everyone.

This article It appeared for the first time in English in 2004 and it is quite impressive that is still relevant despite its 14 years.

Not enough?


TheJoe

I keep this blog as a hobby by 2009. I am passionate about graphic, technology, software Open Source. Among my articles will be easy to find music, and some personal thoughts, but I prefer the direct line of the blog mainly to technology. For more information contact me.

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.