How to make accessible tables in HTML

Accessible tables

Accessible tables should allow data to be readable

The use of tables as the bedrock of page layout in HTML is well and truly over, having been usurped by divs. This is a good thing because it means that tables can get back to concentrating on their real purpose, which is to display complex data in a simple format. But aren’t tables dreadful for accessibility? No, they are fine for accessibility as long as they are used for their primary purpose and they are used correctly.

In this post we shall look at how to properly code a table so that it is accessible and easy to use.

The data we will use

For the sake of providing an example for this post, I have used a dataset from the UK Meteorological Office from Newton Rigg. Of this data, I am only going to use data from 2006, 2007 and 2008 (for simplicity) and I will be using the maximum temperature, minimum temperature, rainfall and hours of sunshine averaged or totalled for each month. If you want to follow along with this example, you should prepare this dataset in advance.

The theory

In theory, the table should be simple to create but as tables become more complex, so does the markup. In principle, the best way to denote table headings is using an ID attribute, which is then carried over to each table cell that relates to it. In this way, you create a grid address for each table cell similar to the way that MS Excel references each cell in a spreadsheet.

Building the table

First of all, we have to get the table started:

<table id="newton_rigg" caption="Newton Rigg weather data 2006 - 2008, UK Met Office." Summary=”This table shows monthly average maximum and minimum temperatures and total rainfall in millimetres recorded at Newton Rigg weather station between 2006 and 2008.” cols="4">

</table>

Note that a caption has been given to provide a reader with an indication of what the table is about. A summary is also provided to identify the purpose of the table. This is used in a similar way to ALT text. Together these two attributes are useful for accessibility purposes to inform those using screen readers and visitors with cognitive disabilities.

Headers or Cells?

There are two types of cells within a table:

Table Header cells <th>

These are used to describe the column/row headers within the table and should be given special attention when defining a table that will meet accessibility requirements.

Table data cells <td>

These are the cells of the table that contain actual data or information that is cross-referenced against the header cells.

Defining header cells <th>

Next, we need to define the header cells that will give each column it’s context. This is done simply by adding two table rows <tr> followed by a series of <th> cells containing the relevant heading.

Once this is done, we can add a class to the <tr> tag so it can be styled later and we can get down to concentrating on making the table accessible.

We have four columns in our table, marked as ‘Month’, ‘Max Temp’, ‘Min Temp’ and ‘Rainfall’. The associated <th> for each of these is given a unique identifier, such as id=”month”. This is what enables screen readers to read table data within context as it reads the cell. It is important to ensure that the id attribute is meaningful and descriptive.

You will also note that there are two rows of headings. This is because the year of data will change, because we are covering three years worth of data. The year <th> spans all four columns, just to make the table a little more complex!

<tr><th id="month">Month</th>

<th id="tmax">Max Temp (&deg;C)</th>

<th id="tmin">Min Temp (&deg;C)</th>

<th id="rfall">Rainfall (mm)</th></tr>

<tr><th id="year" colspan="4">2006</th></tr>

<tr><th id="year" colspan="4">2007</th></tr>

<tr><th id="year" colspan="4">2008</th></tr>

Populating the data

Next we need to populate the data into the table and this is where the ids for the headings are really important.

Each row contains four cells of data. Each of these cells is referenced back to its table headers. So, for example, the first cell is referenced to the year (e.g., 2006) and to the month. Once we have th ids in place, this is fairly simple – we reference them using the headers attribute. In the first column, we would code <td headers=”year month”> whereas the second cell would be <td headers=”year tmax”>.

The order in which the headers attribute calls the column headers is important as this is the order in which a screen reader will read out the context of the data. In this case it will read (for the first row of data in our table) “2006 January, “2006 Max Temp degrees C 5.6, Min Temp degrees C 0.6, Rainfall mm 34.4”….

<tr><td headers="year month">January</td>

<td headers="tmax">5.6</td>

<td headers="tmin">0.6</td>

<td headers="rfall">34.4</td></tr>

<tr><td headers="year month">February</td>

<td headers="tmax" class="tmax">6.1</td>

<td headers="tmin" class="tmin">1.0</td>

<td headers="rfall">63.9</td></tr>

While this is a bloated way of making a table accessible, at the moment it is the only reliable way of doing so. Future changes in HTML 5 may refine and change this method but at the moment (and until screen readers are updated in line with the HTML standards) this is the most likely method to work.

You can see the finished table from this example here and view the complete code by selecting ‘view source’ in your browser. Note, I have styled this example page to make it easier to see how the data is structured.

The Design Process

Rowers by Y

Rowers by Y

This is the second stage of the 5 Stages of Project Management series for web design projects. So far, we have taken an overview of the 5 stages as a whole and looked at how to write a successful design brief as part of the Inception stage. We are now ready to look at Stage 2, Design.

Before starting this stage, if you have completed the inception stage, you should have a well defined brief and understand the scope of the job. Without these, your project may end up with higher costs and delay because your expectations differ to those of your client. Now you are ready to evolve your ideas into some concepts to present to your client. For now, you are not actually building the site; you are designing concepts to a pre-construction stage that can be presented to and agreed by your client.

The brief may have given you a number of ideas for how to design the site and this stage is intended to consider these ideas, present the best to your client and identify the preferred option. But before you can do that you need to get answers to a few more questions and test your ideas against them.

Some things a web designer should consider:

Users

You need to test your ideas against what users will expect to see. The users of the site are of absolute importance – if you put your navigation system at the bottom of the page, for example, is this what users will expect? Where will they expect to see the logo? There are a number of conventions that users will expect and you should consider these carefully before you decide to go against them.

You also need to consider user-specified items that should appear on the site, such as login widgets, video, interactive elements, forms, etc. How and where will these appear? How important are they for functionality, usability and ‘stickiness’ — the ability to keep users on the site. Create a hierarchy of these objects.

Functionality

Really this is a subsection of Users because it describes how users interact with the site and whether it provides the functionality they expect in the places where they expect to find it. Do users have to search through 20 pages of description to get to the ‘buy me’ button? If they do, it ain’t functionin’! This is about making it easy for people to do what they want to do on the site. Functionality, to some extent, also covers speed: how quickly does the page load, how many server calls are made to load the page, does the JavaScript slow the page down?, and also how quickly can a user skim the content to find the piece that they want to read (is the typography helpful or a hindrance, is the structure of the page suitable to the content…)?

Accessibility

This is another important feature of any site and one that you should start designing into the site from the first drawing. In this sense, accessibility is about the colours you use — do they provide sufficient contrast? — The fonts you use, — are they easily legible? Is the content going to be overshadowed by that great picture you want to use? Are the link methods you are planning to use accessible? Have you structured content correctly, — is data stored in a table and is the table accessible?

The fundamentals of these questions will be put into practice when you start building the site. Creating the foundation of that best practice now, will make life a lot easier further down the line.

Plan the site

You should also have a clear idea of the content that will appear on the site, how pages will fit together — which page will link to which? This will help you to develop your site structure and the overall site map. This is essential for a large site but is also really useful for a small site and will help you to start structuring your Search Engine Optimisation as a core part of the page design.

Do you want to see my sketches?

Before you start anything electronically, you should use pen and paper to sketch your ideas. This gives you the opportunity to see how they look, modify them and hone them without spending hours getting Fireworks, Photoshop, Illustrator, etc. displaying what you intended and finding it doesn’t work. It also gives you some rough concepts to present to your client and seek feedback. You should only start committing them to electronic form when you have some clear ideas on paper.

Sketching a design allows you to play with where elements of a page should go to maximise visitors’ attention and optimise use of the hotspots on the page. It also allows you to ensure that visual elements work together.

What do you get out of following a design process?

There are very clear benefits to working through a design process (no matter how basic). It gives you a structure to work to and elements on which to focus; so, rather than jumping in and getting it wrong, you are able to concentrate on making the design achieve the results it expects before dedicating time and your client’s money to a concept that simply won’t work. Furthermore, it will help you to explain your design process to your client.

At the end of this stage you should be presenting your final mock-ups to your client for approval and to decide on which design to follow. This is much easier if you are able to describe the process you have followed and explain the reason you have made the decisions you have made.

The next stage in the five step project management cycle is construction. If you have developed your design well, you should have:

  • A site structure and site map
  • An understanding of the back-end data structure
  • An agreed design to carry forward
  • An understanding of what content will be required