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.

[stevenaproctor]

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.

[stevenaproctor]

@adamsilver Have a look at https://responsive-tables.herokuapp.com/tables/transactions for a way of doing 3. This was done by @Fenwick17 in a service with a 4 or 5 column table of financial data. Code is available at https://github.com/Fenwick17/responsive-tables

[adamsilver]

@stevenaproctor that's really helpful—what usability/accessibility testing has it had so far? (I see that there are some ticks against some screen readers.)

I notice that the inline headers are hidden using aria. One situation here which might be worth exploring is sighted screen reader users. In this case, the user sees a header for every row but doesn't hear it which might be disorientating.

[stevenaproctor]

@adamsilver I think there are visuallyhidden <span>s that solve this problem. @Fenwick17 knows more than me.

[adamsilver]

An example with horizontal scrolling on the table for smaller screens: https://www.compare-school-performance.service.gov.uk/schools-by-type?step=default&table=schools&region=all-england&for=secondary&basedon=Attainment%208%20by%20subject%20group&show=All%20pupils

[Fenwick17]

@adamsilver When you navigate to a cell such as '1 January 2017' It will be read out as 'Date, 1st January 2017'. So a sighted screen reader user will see a header on the left, as well as it being read out as they navigate the table. So they will hear the appropriate header for that piece of data.

[robarmes]

Hi @stevenaproctor thanks for the responsive tables link above looks ace, images are an example of how myself and @adamsilver have mocked this up on a project we are working on, something very similar and for financial data where a user is looking for a particular item in a table this works well labelling every column header next to the row data. I'll take a look at using the code from above.

But as previously said for users looking to compare data across a table another option might be better.

[dashouse]

Article with some useful information and examples

https://www.smashingmagazine.com/2019/01/table-design-patterns-web/#top

[edwardhorsford]

The table component doesn't handle really long strings of text with no spaces very well.

@colinrotherham raised a pr for the summary list component two weeks ago to address this on that component - I wonder if a similar thing would be suitable here too.

[leekowalkowski-hmrc]

I don't receive alerts for the summary list component, so missed that. It's a shame they didn't make it opt-in for email addresses and URLs, because apart from unrealistic test data, those are the few situations this applies to. It's not worth applying the break-word property in blanket fashion because of how the unnecessary breaking of words in standard cases hinders readability: https://jsfiddle.net/lee_kowalkowski/efvb7uxm/3/

[edwardhorsford]

@leekowalkowski-hmrc perhaps an opt-in class that can be applied as needed then?

Edit - I wonder if js will be the way it has to happen - we won't always know in advance if a field will have really long text.

Example: My service collects a fair amount of paragraphs of text in textareas. Users may include urls in these paragraphs of text. So I'd be minded to try to break those urls. I obviously don't want the case from your example above where a paragraph of text breaks in the middle of regular words.

[leekowalkowski-hmrc]

Actually no, standards have improved, it's overflow-wrap we need: https://jsfiddle.net/lee_kowalkowski/efvb7uxm/6/

[edwardhorsford]

I've now suggested the summary list fix be reverted (#1211).

Hopefully we can come up with a better fix (js or otherwise) that can replace it.

[antimega]

To record the original GOV.UK design decision to remove the zebra striping:

We saw in user research that users were inferring that the background colours meant something ie there was a grouping that was important that was not mentioned anywhere. There are also more contrast issues to worry about. Doing row by row interactive highlights makes more sense (but of course doesn’t help on mobile).

[terrysimpson99]

There's a broken link on this page where says "Use this issue to discuss this component in the GOV.UK Design System.". Can somebody update it?

[synergy-mark]

Over the past 6 months, the HMRC Classic Services teams in Manchester and Telford have been undertaking a UI refresh of the services they maintain to be in line with the GOV.UK Design System, within the PAYE Expenses and Benefits service, one use case if to view a table of Employees of an organisation that are available for adding expenses and benefits.

Example:

The table is sortable by column, but as there is no pattern for this in the design system, links within the table header row have been used to select the column to be sorted on. This causes confusion when it comes to accessibility and screen readers, so a standard accessible pattern would be useful.

I have found an accessible example from Deque University code examples that may be a good starting point: https://dequeuniversity.com/library/aria/tables/sf-table-sortable

[adamsilver]

@synergy-mark The MOJ Design System has sortable tables which is accessible: https://moj-design-system.herokuapp.com/components/sortable-table

[synergy-mark]

@adamsilver Thanks. I was asked by @frankieroberto to add a comment explaining our use case, as they may be tempted to add sortable tables to the design system.

[ghost]

Noticed a bug when viewing a table on Firefox, it doesn't show the border bottom. The issue seems to be around the "border-collaspe" property, by setting it to collaspe it doesn't work but if you change it to seperate it works.

[hannalaakso]

Hi @mgearon-ch thanks a lot for your comment 👍 Are you able to replicate the problem on the table example in the Design System itself? If yes, which OS and version of Firefox are you using? Could you also specify which element is missing the border bottom, this wasn't quite clear to me from the screenshot.

[ghost]

@hannalaakso No it's fine on the design system, I think it's my fault as I'm using 2.12.0 frontend so it probaly has been resolved since so I just need to update my prototype. But I am seeing the issue on MacOS Mojave 10.14.6 and Firefox 72.0.2

[hannalaakso]

@mgearon-ch Thanks for clarifying. I'm not going to take any action right now as it sounds like this might not be a bug in the Design System component. But if you find otherwise please feel free to open an issue and we can investigate 👍

[edwardhorsford]

Sharing some work I did in the Prototype kit that might be useful to others using the table macro.

I find working with / manipulating the data needed for the govukTable to be tricky. I recently had a large table to update - and going from google sheet > govukTable is a pain.

I made a nunjucks filter to go from csv or array to the form needed by the govukTable. It's not as flexible as the native govukTable json format, but much easier to work with (and suits my simple tables).

A possible suggestion for the design system (or maybe the kit) would be to consider supporting simpler / alternate data formats. Either by testing the provided data, or offering explicit csvRows / arrayRows attributes that can be used instead of rows

[joelanman]

From memory one of the tricky issues with the macro as it stands is it requires all items to be in the form {'text': 'my text'} or {'html': '<p>my html</p>. So it can't just take a more basic form of arrays of arrays.

Take the example in the Design System:

rows: [
    [
      {
        text: "First 6 weeks"
      },
      {
        text: "£109.80 per week"
      }
    ],
    [
      {
        text: "Next 33 weeks"
      },
      {
        text: "£109.80 per week"
      }
    ],
    [
      {
        text: "Total estimated pay"
      },
      {
        text: "£4,282.20"
      }
    ]
  ]

Could possibly be:

rows: [
    ["First 6 weeks", "£109.80 per week"],
    ["Next 33 weeks", "£109.80 per week"],
    ["Total estimated pay", "£4,282.20"]
  ]

[edwardhorsford]

We've got a use case where we want to right align a column. It would be helpful for a generic class that does this.

govuk-table__header--numeric aligns a column right, but has the wrong name. Put another way, numeric entries are not the only reason you might want to align something right.

[matthewford]

re: zebra striping.

The trade tariff uses it, we have lots of data, I wonder if the volume of data makes an impact on the experience?

[Fenwick17]

@adamsilver Have a look at https://responsive-tables.herokuapp.com/tables/transactions for a way of doing 3. This was done by @Fenwick17 in a service with a 4 or 5 column table of financial data. Code is available at https://github.com/Fenwick17/responsive-tables

I have made a few improvements to this as part of the work I am doing on NHS Frontend. Most notably swapping to using role="table" which is more appropriate. There is also a modifier for word wrapping which could come in handy for extra long strings that do not auto wrap. https://github.com/Fenwick17/nhs-responsive-tables or https://nhs-responsive-tables.herokuapp.com/ user: nhsuk pass: tables

[joelanman]

a roundup of tables and accessibility: https://www.brucelawson.co.uk/2020/accessible-data-tables/

[Dean-A-Smith]

The Canadian government's Web Experience Toolkit project have a thread about how to indicate "no data" for empty cells in tables - https://github.com/wet-boew/wet-boew/issues/7488

The (slightly shaky) consensus there seems to be that, where a table cell is missing data:

• leave the cell blank, as the majority of all adaptive technologies notify the user that it is indeed a blank cell
• reserve hyphens and dashes for text components of the content
• provide a note before or immediately after the table (preferably before) explaining the meaning of any other indicator that represents some further meaning

[jbuller]

Potentially useful reference on "the bare minimum you need to make a WCAG-compliant responsive HTML table." https://adrianroselli.com/2020/11/under-engineered-responsive-tables.html

[edwardhorsford]

A minor need we've had - to be able to turn off the last bottom border. This is because the table sits within an accordion, and the accordion sections already have borders between each section.

Example:

Our solution was this css:

.app-table__in-accordion tr:last-child td {
  border-bottom: none;
}

[samantharwright]

Does anyone have insight on why the first column values are styled as column headers and made bold on the Gov design system? https://design-system.service.gov.uk/components/table/default/index.html

The NHS design system table does not make these bold and are styled the same as the second column: https://service-manual.nhs.uk/design-example/components/table/default?fullpage=undefined&blankpage=undefined

[querkmachine]

@samantharsaw All of the examples in our documentation are two-dimensional tables, where the 'heading' for a cell is a combination of both the column and row header.

To pull from the table you linked: The "Amount" for the "First 6 weeks" is "£109.80 per week".

Both row and column headers should be marked up in certain ways so that assistive technologies understand them. If either "Amount" or "First 6 weeks" were omitted, a screen reader user may not understand what the context of "£109.80 per week" is or what it means. We show both column and row headers in bold to make this clearer to sighted users too.

I'm interested if the NHS design system folks have any specific reason for not using row headers, as it seems like they should exist—especially on their other example, where it is possible for a screen reader user to hear that they should give "200mg to 400mg" of ibuprofen, without necessarily hearing what age group that applies to!

[samanthasawdfe]

Has anyone worked on a table with two headers? All the table examples on the design system have a one header row. However I've been looking at tables with a row header and a column header and found an example on the W3 org site: https://www.w3.org/WAI/tutorials/tables/two-headers/. Has anyone worked on creating an accessible example of a table like this using the kit?

[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!