Tables

If you build it (correctly), they will come

Tables are a great way of getting across complicated information quickly. Forget “a picture is worth a thousand words”. A well-designed table is the thing.

Well designed and correctly configured.

The thing about tables in Terminal Four is that you have to build them, from scratch, in Terminal Four. There are no short-cuts. Do not copy a table over from another platform (such as Word or Excel). Your table will not present correctly and will not be responsive on mobile devices.

The way Terminal Four deals with tables for mobile devices is fantastic. T4 tables are responsive and reflow so they fit within the device window. There is no having to scroll across the page to find the information. 

How to get it right

To make our tables accessible, we need to do two things. The first, as described, is to build them from scratch in T4 so that they are responsive and do not cause scrolling in two directions on mobile (a no-no in terms of the accessibility regulations).

The second is to ensure the table is constructed in such a way that the content makes sense to the user in both desktop and mobile views.

In mobile view, for tables with more than two columns, the tables are broken up into sections that are, in essence, mini tables. The row headings (or the content in the first cell in any row) become section headings and the columns become rows. This ensures the table fits within the screen window.

So you need to carefully consider what you are using for your column/row headings and you may need to reconfigure your table so it retains its meaning in both views.

How to check

The first clue that your table has been created correctly is that it will have white on blue text in the column headings. You can check this in preview. Remember, it is important to consider giving your table a title (as I have done here) because the first cell in the header row will not be visible in mobile view if the table is wider that two columns.

English Index of Multiple Deprivation

However, be warned, just because a table has white-on-blue column headings does not mean it has been correctly formatted. For a final check with tables, you should go to mobile view (which you can do with this page) using your preview skills to see how the table will present. Check that it reflows and remember to check it still makes sense for the user on mobile.

Now I'm going to show you some scary HTML. This is the nice clean source code for this table you would see in the Tools/Source code window in T4.

<table>
<thead>
<tr>
<th scope="col">EIMD quintile</th>
<th scope="col">Number of applications</th>
<th scope="col">Percentage of applications that received an offer</th>
<th scope="col">Percentage of applications that accepted an offer</th>
<th scope="col">Percentage of applications that led to a registration</th>
</tr>
</thead>
<tbody>
<tr>
<td>1 and 2</td>
<td>7,830</td>
<td>77.2%</td>
<td>27.3%</td>
<td>24.6%</td>
</tr>
<tr>
<td>3 to 5</td>
<td>10,010</td>
<td>84.4%</td>
<td>25.5%</td>
<td>23.2%</td>
</tr>
</tbody>
</table>

That's another clue that your table is formatted correctly.

Spotting problems

If your table has not been formatted correctly, it is likely that it will not reflow on mobile (it will stay in its original shape and go beyond the page width). Your user will therefore be left with a page that scrolls in two directions. 

This is the same table copied from Excel.

Your first clue that something is wrong is that the headings are black on grey rather than white on blue. And, when you check it in mobile view in preview, you will see it doesn't reflow and it is wider than the screen width.

A check of the source code shows you it has brought over a lot of code from Excel that stops it from reflowing to the size of the screen. We never want to see widths in our table source code.

<table border="0" width="320" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td class="xl63" width="64" height="99">EIMD quintile</td>
<td class="xl63" width="64">Number of applications</td>
<td class="xl63" width="64">Percentage of applications that received an offer</td>
<td class="xl63" width="64">Percentage of applications that accepted an offer</td>
<td class="xl63" width="64">Percentage of applications that led to a registration</td>
</tr>
<tr>
<td class="xl64" width="64" height="21">1 and 2</td>
<td class="xl65" align="right" width="64">7,830</td>
<td class="xl66" align="right" width="64">77.20%</td>
<td class="xl66" align="right" width="64">27.30%</td>
<td class="xl66" align="right" width="64">24.60%</td>
</tr>
<tr>
<td class="xl64" width="64" height="21">3 to 5</td>
<td class="xl65" align="right" width="64">10,010</td>
<td class="xl66" align="right" width="64">84.40%</td>
<td class="xl66" align="right" width="64">25.50%</td>
<td class="xl66" align="right" width="64">23.20%</td>
</tr>
</tbody>
</table>

NB To reiterate, sometimes a table will have white on blue headings but will not reflow in the correct manner. Always check mobile view.

Additional considerations

Sometimes, it seems that, no matter what you do, your table is still wider than the screen width in mobile view. This is likely that it will be due to long words - or “strings” - in the narrow columns forcing the table beyond the screen width.

Our standard text does not automatically hyphenate so will require some assistance in these circumstances. If you have a long word, such as “antidisestablishmentarianism” or, more realistically, “accommodation”, you may need to add a manual coded hyphen, which will only appear in mobile view to break the word. You do this by adding the extra code in the Tools/Source code window in T4.

For details on how to do this and more advice on breaking long strings of content, including compound words separated by a / and strings caused by non-breaking spaces (both of which can also cause problems in tables), read our guidance on how to deal with long words/strings on mobile.