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.
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">
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
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
These are the cells of the table that contain actual data or information that is cross-referenced against the header cells.
Defining header cells
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!
<th id="tmax">Max Temp (°C)</th>
<th id="tmin">Min Temp (°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>
<tr><td headers="year month">February</td>
<td headers="tmax" class="tmax">6.1</td>
<td headers="tmin" class="tmin">1.0</td>
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.
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:
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.
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