Some tables in govspeak are hard to navigate

[andysellick]

We're still investigating this issue but here are some initial thoughts.

Problem

Content publishers are using govspeak tables and in some cases the data is too tall or too wide (or both) for the page. This is hard to navigate and causes some specific further problems:

• scrollbars on the bottom of tables aren't always visible or easy to get hold of (because they're so thin)
• if the table is too wide and too tall, users can't easily find the scrollbar along the bottom of the table, having to scroll a lot to get to it
• there's a further orientation issue with this - if you have to scroll many pages to move the table across, then back up again to read

Some example pages (thanks to @selfthinker for supplying many of these):

• page with a long table
• page with a reeeally long table
• page with a wide (and tall) table
• table used for layout, a calculation formula
• table without any headers
• tables that include an empty row
• single column tables used for paragraphs
• table used as a list
• table used as layout
• another table used as a list
• very small table used as a list
• no table headers
• lacking a row header
• lacking a row header and being generally not fit for a table
• empty headers
• far too wide and bad link texts
• deliberately inserted empty columns for spacing
• tables that should be more than one table or something else
• no headers but should have headers
• only two rows
• single cell table
• broken table
• impractically long table

Context

Tables in govspeak are all the same and we can't add specific attributes to treat some of them differently from others.

Tables in govspeak also aren't all the same - sometimes they have one table header row along the top, sometimes they have two, sometimes they have table headers down the side, or both.

We're also not going to move away from tables because they're often the best way to present information, and there's far too many of them at this point to change.

Possible solutions

Limit height

Add a max-height e.g. 90vh to all tables to ensure any horizontal scrollbar is always available nearby.

Problem: still have to scroll a lot to get to the bottom then back up again to read the table headings.

Fix table headers in place

Possible to use position: sticky to keep the top row of a table always at the top of the screen while the table is in the viewport.

Problem: tables sometimes have more than one table header row.

Popout

Add some JavaScript to allow users to 'pop out' the table into a full height/width modal.

Problem: doesn't solve the orientation problem, users would still have to scroll a lot, also may not help on the majority of screen sizes.

Separate page

Provide a link to the table on its own on another page.

Problem: implementation is going to be hard - tables are part of a govspeak block, so figuring out how to extract just that bit onto another page would be difficult.

Download as a CSV

Add some JavaScript to provide a link to download the table data as a CSV or similar, so people can read it in their own software.

Problem: local copies won't be in sync with GOV.UK changes.

Give the user control

Write some JS that would allow for all of the things above, and present the user with options for how they want the table to be displayed.

Problem: overly complex?

Fix at the source

Many of these table issues (see examples above) should be fixed directly in the content - by changing the layout of the table, splitting into multiple tables, or not using a table at all.

Problem: whack-a-mole

Go see what the internet thinks

Currently investigating.

Thanks to @AshGDS for pairing on this.

Related zendesk issue: https://govuk.zendesk.com/agent/tickets/6265910

[selfthinker]

When we talked about this issues a few years ago we suggested to implement what is described in the article 'Under-Engineered Responsive Tables'. (Sorry, I couldn't find the relevant Trello card or GitHub issue or I would have linked to it.)