Words on the left, numbers on the right
Names, descriptions and statuses are easiest to read when they start at a straight left edge. Numbers are the other way round. When they line up on the right, the ones sit under the ones and the thousands under the thousands, so you can see which amount is bigger before you even read it.
The heading of each column should line up the same way as the column itself. A heading in the middle over numbers on the right looks tidy, but it breaks the line your eye follows. Only very short things, like a tick mark, look good in the middle.
Fig. 04.1Do and don’t
Don’t
Do
Digits of the same width
In many fonts the number 1 is thinner than the number 8, so a column of amounts still looks uneven. Developers can fix this with one line of style code, font-variant-numeric: tabular-nums, which makes every digit the same width. It also helps to show the same number of decimal places in a column, and to write the currency once in the heading, like “Amount, UAH”, instead of in every cell.
Less lines, more room
A thick border around every cell makes a table look like an old tax form. A thin line between rows is usually enough, or a very pale shade on every second row. Give each cell a bit of breathing room on both sides.
If a table is long, keep the heading row stuck to the top of the screen while people scroll. Then they don’t have to scroll back up to remember which column is which.
Sorting
When people can sort a column, for example by date, make the whole heading clickable and show a small arrow that points up or down. That arrow tells people which column is sorted and in which direction. For screen readers, developers add aria-sort to that heading. Start with the most useful order, which is often the newest date at the top.
Fig. 04.2Annotated
- The whole header is a button.
- The arrow shows the current direction.
aria-sort="descending"in the code.- The unit is in the header, not in each cell.
When the table is too wide for a phone
A table with eight columns won’t fit on a phone screen, and squeezing it makes every cell too narrow to read. There are three good ways out.
You can let the table slide sideways inside its own box, while the rest of the page stays still. Keep the first column fixed and show a hint that there is more to the right. The accessibility rules allow sideways scrolling for real data tables, as long as the page around them fits the screen.
You can also turn each row into a small card, with the name of each value written next to it. This works well when people look at one item at a time, like their orders.
Or you can show only the two or three columns that matter most on a phone, and let people tap a row to see the rest.
Fig. 04.3Two phones
Eight columns squeezed
Rows as cards
Empty tables and tables that are loading
A table with no rows should explain itself: “No invoices yet. They will appear here after your first order.” While the data is loading, keep the heading row and show a few pale grey rows in its place, so the page doesn’t jump when the numbers arrive. There is more about this on the page about empty, loading and error screens.
Built as a real table
Developers should build data tables with real table code, with proper heading cells. Then a screen reader can say “Amount: 1,240” instead of just “1,240”, and blind users know what each number means. A short title above the table, saying what it shows, helps everyone.
Before you move on
Here is a test you can do over a cup of tea. Show the table to a colleague and ask which client owes the most. Watch their eyes. If they have to read every number one by one, line the amounts up on the right, remove a few lines, and try again with someone else.