Table

[govuk-design-system]

Use this issue to discuss this component in the GOV.UK Design System.

• Australian Design System Discussion

[frankieroberto]

I think it’s worth supporting a "sortable tables" pattern, whereby users can click on a column heading to re-sort the table by that column (and click again to reverse). This is useful for enabling people to quickly discover the maximum and minimum values.

This should also be discoverable, which can be achieved by making the the column header blue, with icons for sorted ascending, descending or not sorted.

Here’s an example from a live service: https://www.ethnicity-facts-figures.service.gov.uk/crime-justice-and-the-law/courts-sentencing-and-tribunals/sentences-and-custody/latest

[timpaul]

Thanks Frankie, sortable tables is definitely something services have needed in the past.

The GOV.UK Performance site has some examples of sortable tables

@LJWatson has also worked on accessible sortable tables:

• Code here: https://github.com/LJWatson/sortable-tables
• Demo here: https://ljwatson.github.io/sortable-tables/

[frankieroberto]

@timpaul nice, I should get around to publishing the code we use too. We had to support the additional complexity of tables with rowgroups (multiple <tbody> elements), eg https://www.ethnicity-facts-figures.service.gov.uk/crime-justice-and-the-law/policing/stop-and-search/latest (where the sort first sorts on the row group value, then sub-sorts on the values within that group).

One key thing we found is that whilst some patterns only contain an arrow icon on the currently-sorted column, this can lead to user confusion as the other column headers can be mis-interpreted as links (to pages explaining the column heading), and is also less discoverable. Adding a double-arrow (one pointing up, other other pointing down) helps avoid this.

[ghost]

Everyone seems to have their own understanding of when to use a table. A clear definition of tabular data would be great.

[frankieroberto]

I've made an initial release of our sortable table code here: https://github.com/frankieroberto/sortable-table – I've not done a review of how it compares with @LJWatson's code yet, but I expect it's fairly similar.

[murfious]

This improvement is about making table data work well for small screens and screen-readers.

Our tables are not optimised for small screens. They do not show all data, instead information flows out of view.

We can make changes to the UI to make it respond and show the data in a stack but when we do this the context of the data is lost unless we do more work.

Also for non-sighted users or for people using screen-readers table context is lost, as the ‘headings’ for data is at the top of a table. If the table is long or complex, referring back to these headers is a difficult task.

In the WRLS team we have done some UI work to optimise tables for mobile and small screens. We present the ‘stacked’ single column data with associated labels so that context is always present. On bigger screens we hide these labels but they are still then available for screen-readers.

Here is a link to a bug we have around tables not working for small screens
https://eaflood.atlassian.net/browse/WATER-1089

And a summery of related notes taken from a visit to the Digital Accessibility Centre in Neath where we showed the WRLS project to users with specific access needs and we saw and heard from them that our table data was not meeting a good standard of accessibility.

https://drive.google.com/open?id=1mAxzHq4Sz2YWBYPoblMnsPCls7uRFWJ9HoiqsAFK5I4

To achieve these flexible tables we made them using and styled them like tables. Also we did a bit of work to make sure that these tables work well when screenreaders are using them.

Examples of the flexible table UI are here:
https://water-resource-licensing.herokuapp.com/v18/patterns/tables
user: Water resource licensing service
pass: abstraction

[timpaul]

GOV.UK Registers contains examples of sortable, scrollable tables

[matthewrudy]

I think it'd be worth adding an example of a table with html inside the cells.

Took me experimenting with swapping the nunjucks text: to html: to work out how to do it.

{{ govukTable({
  caption: "Text and Links",
  firstCellIsHeader: true,
  head: [
    {
      text: "Text"
    },
    {
      text: "Link"
    }
  ],
  rows: [
    [
      {
        text: "Example text"
      },
      {
        html: "<a href='#'>Example link</a>"
      }
    ]
  ]
}) }}

[accessiblewebuk]

Currently tables expand automatically to full width. This creates problems for screen magnifier users (for example using Zoomtext). Where there is a significant amount of space between columns it can be difficult to keep track of relationships between the data cell and the row header. For example in the design system it shows:

Zoomed in at a fairly modest level of magnification it could look like:

and this means the user may have to do significant amounts of horizontal scrolling to establish relationships. The row borders are obviously a help, but it would be much better if the gaps were closed up.

[JeremyHHY]

Locking columns into view (or sticky columns) are not advisable as users using screen magnifiers can be blocked from viewing data columns by the locked column. This can be a common problem in large spreadsheets. I haven't seen too many tables online with locked or sticky columns, but it is definitely something to be aware of.

Freezing rows (sticky header rows) are ok to use, but are not exempt from this problem.

[JeremyHHY]

If a column has no data in it then it should be removed.

This helps with accessibility as it reduces the need for (further) horizontal scrolling if a user is using a screen magnifier.

[JeremyHHY]

Australian Design System chat regarding tables... https://community.digital.gov.au/t/table/92/20

[frankieroberto]

I think there's definitely a case for 'sticky' header columns, as well as header rows (which are more common), especially for very large tables and specialist users.

That said, they're not yet easy to implement without some complex javascript.

For an example of where this does work, see Google Sheets, which has this as an option.

[leekowalkowski-hmrc]

I just added a comment to an accessibility checklist, but I think it belongs here:

Tables should only be as wide as the content within them (not 100% wide). Tables that are wider than they need to be make it difficult scan the rows, especially when magnified.

[adamsilver]

One gap with the table component is how they work on smaller screens. At the moment the table's width breaks the layout like this:

There are a number of options to consider such as:

(1) In the case of two or three column tables we could decide to use the “Check your answers” pattern that actually uses a <dl>

(2) To give the table container its own horizontal scroll bar with appropriate signifiers that this behaviour exists such as a fade out effect on the side.

(3) Using CSS to change the layout on small screens so that table headings are repeated for every row as described in Responsive table layouts

And for each of these options there maybe various usability and accessibility implications.

I'm not sure there is one size fits all but at the moment, a pretty major component of the Design System is lacking an opinion for a fairly common scenario.

[RoxanneGux]

Hi there. I'm interested in following developments for adjusting the table UI according to breakpoints. I saw above in comments troubles on smaller screens. At this Asset Management company I work for, the UX team is investigating moving from columns(true table) to list view for the XS and S bootstrap breakpoint widths. Has the GOV UK design system had movement on a UI adjustment for the XS and S breakpoints ? I'd love to see the result. This is what we are playing with so far:

[querkmachine]

Hi @RoxanneGux,

Determining whether a table needs to be responsive, and the most appropriate method of doing so, is largely dependent on the actual contents of the table.

For example:

• If a table has only a few columns with very short data, such as in this example from the Design System, then you probably don't need to modify the table for narrow screens at all.
• If the table has one or more columns that're intended to be directly compared by the reader, such as wholesale banana prices from each country, then you'll likely want to make the table scrollable, so that the 'Price' column remains in a consistent position with the values proximate to one another.
• If a table has lots of columns that are not directly comparable, but still some that are, such as fruit and vegetable types, varieties and prices, the best option may be to merge multiple columns together on narrower screens—such as creating a single column that includes 'Type', 'Item' and 'Variety'.
• If a table is entirely columns that have noncomparable values, such as the import requirements for seeds, then transforming each row to have more 'card-like' layout on mobile may be the best option.

As it's so contextual, with no obvious one-size-fits-all answer, we don't provide any particular code or guidance for making tables responsive. It's really up to what works best for the data.

Hope that helps!

[RoxanneGux]

Thank you @querkmachine. Thinking about whether the columns need to remain column-comparable based on their contents and the table's purpose is super helpful. In my example, I might be able to get away with turning the table into cards based on this argument. And thank you for the examples. One question, as I would like to show these examples to the team, is why this one "the import requirements for seeds" is not turning to cards when I resize. It looks like this maintaining horizontal scrolling :

Thank you!

[querkmachine]

@RoxanneGux Ah sorry, I was giving the links as examples of tables being used to display different types of data. As far as I'm aware, neither of the last two solutions I suggested have actually been implemented on GOV.UK.

[stevenjmesser]

There's lots of discussion on designing tables for small screens in this thread, so I wonder if the guidance should be updated to bring all of that in. It seems like it would be useful for people.

(Note: this hasn't been prioritised by the community currently, only leaving a comment for our future selves.)

[selfthinker]

Has anyone come across difficulties with understanding tables due to the missing borders between columns?
I became aware that missing column borders makes it much easier for GOV.UK publishers to misuse tables or to not see when something goes wrong with a table.

Some examples of problems with tables that probably only exist because of the table design:

• when too many columns are cut off that is due to the implementation on www.gov.uk not due to the Design System but it would be much easier to notice it if a table had vertical lines
• when someone uses a single cell to make it appear as if it was merged with neighbouring cells is partly because Govspeak doesn't have a merging feature, but when this happens it's not noticeable due to the design
• when breaking a table up so it's wrongly multiple tables with a single row it's harder to see that there is a problem
• it's very difficult to notice when there are empty column headers or empty columns and somewhat difficult to notice when there are empty row headers or empty rows
• it's impossible to notice when a single row table has been misused for layout purposes, like splitting up a mathematical formula

I collected examples of bad tables that show some of these things compared to a (not pretty) design that shows all main table features. (Sorry, that document is only visible to GDS people.)

[Terry-Price]

With regard to table column labels that sit above the top table line. These are currently text-aligned top.

In the scenario that some of these column labels are quite long and so need to be two- or three-deck to fit, it would be much better if all were text-aligned bottom.

This would benefit in two ways.

• Keep the close relationship of any single-deck labels to the actual table. And avoid (as is currently) the ‘floating look’.

• The footprint of the table as a whole would appear more solid and so less fragmented. Creating a visual unit.

I’d be interest to know exactly what research has been performed on these. My testing (in another company setting) resulted in general but overwhelming feedback as being easier to locate and more related to the to table when there was a mix of varying table label lengths.

The attached is my table label alignment proposal for consideration.

[atinGovUK]

Hi Terry,
Where can we find the sort by component for a table, like the one above.

[CharlotteDowns]

@Terry-Price are you able to help @atinGovUK with their query?

Where can we find the sort by component for a table, like the one above.

[nhsbsa-grhow]

Hey GOV UK community, I would like to ask if there is any advice on nesting tables and the accessibility challenges there might be fun this space. I have a solution that requires me to display a primary person and there secondary dependant details together, in a dashboard-esque manner.

I'm at a point that I'd like to understand any challenges there might be in nested tables that we know of so I can then review my solution. Thanks in advance.

Prototype sketch.

[querkmachine]

@GrahamHNHSBSA Accessibility expert Adrian Roselli has written a little about this. The bulk of the post regards showing rows with the same headings conditionally, but some parts of it are transferable, such as what control you use to toggle the rows.

At the bottom of the post is a link to a nested table example similar to what you're looking to develop, which Adrian regards as being "valid but annoying" to use.

He also points out that JAWS/Chromium had a bug which prevented navigating nested tables, which has since been fixed, but may affect your approach depending on what your window for assistive technology support is.

[nhsbsa-grhow]

Brilliant, thanks for your time and shares @querkmachine I'll have a read now.

[dnyuar]

Problem

We currently have an issue displaying our tables in mobile view in which the table goes off the page when the table has 4 or more columns. Users currently on mobile view need horizontal scroll in order to be able to see further information that does not fit within our screen. The current table design pattern does not offer a responsive table pattern out-of-the-box.

Research

Office for National Statistics (ONS) and the NHS both have responsive table patterns which allow the table to be displayed for users in mobile view. With their responsive table design pattern, tables have stacked rows for small viewports. I've attached links below to both design manual websites which show these patterns.

https://service-manual.nhs.uk/design-system/components/table
https://service-manual.ons.gov.uk/design-system/components/table#example.example-table-responsive.html

I've also created a draft PR which involved using a table in which the table goes off the page and creating a CSS class in our service which can replicate the responsive table pattern shown in the links above. The page chosen was the 'Payment you made to HMRC' page shown in the screenshot below.

hmrc/income-tax-view-change-frontend#3077

By adding the custom CSS (based off the ONS version) for a responsive table pattern, the table was able to stay within the page. Below are screenshots of the page in mobile view as it is currently and the next with the added responsive CSS class added. There are however a couple accessibility issues to do with the rows which contain a link which is something I am currently investigating.

With the custom CSS added, I was able to keep the same styling that is used in the GOV.UK design system.

Suggested guidance

A potential solution for this issue would be to add a responsive pattern for tables into the GOV.UK design system. I was able to update this table as it is using plain HTML rather than twirl templates, however this would not be able to be added if I was using twirl. Also it would be a much better user experience for mobile users if we're able to keep the information on the page rather than having the user have to scroll horizontally to find information.

I've attached the CSS/Nunjucks for the responsive table patterns below for ONS & NHS

https://github.com/nhsuk/nhsuk-frontend/blob/main/packages/nhsuk-frontend/src/nhsuk/components/tables/_index.scss
https://github.com/nhsuk/nhsuk-frontend/blob/main/packages/nhsuk-frontend/src/nhsuk/components/tables/template.njk

https://github.com/ONSdigital/design-system/blob/79783b34de3592bfd0fdfb37938ea26e255ccc86/src/components/table/_table.scss
https://github.com/ONSdigital/design-system/blob/79783b34de3592bfd0fdfb37938ea26e255ccc86/src/components/table/_macro.njk

[sensecall]

Has anyone explored or used a pattern for selecting multiple rows in a table so users can perform bulk actions, for example export or other actions on several items at once?

We’ve got caseworkers handling multiple items at a time, typically search results, so the table is doing more than just displaying data.

[foobacca]

I was wondering if "zebra" striping had been considered for the table component? Is there any user research to say why it was preferred to use a table with horizontal lines, no shading and no vertical lines?

I'm not pushing a different design. We have debates in our team and I'm wondering about what was considered and why this design was chosen - and in particular what evidence there is - to feed into our discussions.