The Australian Government coat of Arms

Communities of practice

Communities of practice



A basic responsive HTML table component.

You can also view the component page on our documentation site for the Table component.


A couple of good options (IMHO) for responsive tables can be found here: (excuse the jQuery, the plugin itself is quite old - should be able to be ported across to Vanilla JS in a relatively straight forward fashion as it’s mostly CSS based)

The first table is to apply a shadow to the right when it is scrollable, and as the user scrolls apply a shadow to the left to indicate there is scrollable space back to the left. This approach keeps the table as a table so as to not confuse screenreaders.

The second table allows for the ability to turn off columns that aren’t as important (indicated by a class in the THEAD) depending on the screen (or you could make it element) size. Then, you have a menu appear above the table that will allow the user to enable/disable the columns as they like. This can also be combined with the shadow approach as needed.


Nice @dkeeghan. I’m really quite fond of both these techniques, particularly the first one! Because like you said, they don’t play havoc with the HTML structure or use things like CSS: content: attr(data-title); to do magic which can’t be copy-pasted. :star_struck:

Looking at the second option [ability to turn off columns], I’m thinking it might need to be more complex than just columns.

There is some fantastic content on Accessible tables over on, particularly on irregular headers and multi-level headers which we might want to consider as well…

Maybe we could look at the scope attribute to control what’s customisable?


We commissioned work on a site this time last year, and contribed a table module. I’d have to resurrect the site to get a screencap, but the PR we raised is at


Thanks for the reminder @toby.bellwood :slight_smile:

We have a ticket in the backlog for this sprint to look over our outstanding PRs that related to our earlier versions.

Recently we added much more detail to the contribution guide that outlines the work we need to do before we can add a component.

Unfortunately the PR won’t be accepted

It’s our fault, we should of got back to your pull request sooner and kept the conversation rolling. We have undergone a large refactor which means that a lot of the code and documentation would need to be changed.

For example looking at the code in the pull request we won’t be able to use the data-label="{headers} to pass a table header into CSS content: on breakpoints. As the visual representation of the table no longer matches the HTML structure. This will cause issues with assistive technologies.

Why is this component in progress?

We are still looking at the code in your pull request and the examples posted above by @dkeeghan. We will try and find a happy balance between the two.

In the mean time we have created a simple responsive table component to use in our design system documentation site. You can view the react component, and styling. You can also see the component being used on our components page.

1 Like

Thanks for the reminder @toby.bellwood In an effort to make sure we don’t lose that work I moved what I could into a CodePen so that we can continue the conversation about preferred responsive solutions.

1 Like

Thanks @treb - hopefully there’s some reusable stuff in there. We made sure to build the data-labels in to provide the context necessary for A11y


@toby.bellwood maybe a miscommunication however not confuse anyone reading this thread:

  • data-labels are used to store and embed custom data in html.
  • aria-labels are used by screen readers to label elements.

Using data-labels with CSS :before is not best practice for accessibility. The implementation in that PR manipulated the visual representation of the HTML using CSS. This will cause issues with assistive technologies:

.au--content-table td::before, table td::before {
    content: attr(data-label);

This is bad practice and should be avoided.

1 Like

Thanks Alex!

So for clarification, what would be needed in a table to ensure that most screen readers etc can handle it?

1 Like

Hi Toby

I would say it depends on the complexity of the table.
The simplest of tables (with one set of column or row headers) will need those heading cells marked up as th tags with scope attributes = “row” or “col”

Complicated tables (multiple levels of headings) may also require each cell to contain header attributes to match up the id attributes of their th headers.

Table summary attribs always help too.

In my experience these complicated tables don’t go responsive very well.
Wouldn’t want to be stuck with a design system that makes all tables go responsive at certain breakpoints. Sometimes it’s better to just deal with the sideways scrolling.


If you’re still looking for inspiration, the Drupal community is building an admin UI with react and this is their table:

1 Like

Thanks @rooby definitely useful! thanks for sharing


Hey friends here is a great article on tables and tabular data:

1 Like

As usual, ‘one size won’t fit all’ and David Rizzo talk about four different approaches to Accessible, Simple, Responsive Tables

Adrian Roselli has a nice example for an accessible responsive simple table using the collapse-rows approach.

1 Like

To be safe for screen reader users in all situations, even on the simplest tables, always use id, and header attributes

For complex tables that can’t be broken in 2 or more simple tables as per the WAI Tables with multi-level headers tutorial then the horizontal scroll seems to be the only viable option. With good table markup, a screen reader user is actually at an advantage.

1 Like

Thanks for the great information @Andrew.A


As far as I know this is the only current table related ticket:

Is there a roadmap of work/features that are required to have a releasable component?


Hi @rooby,

We don’t have any tickets relating to tables at the moment. Our current focus is on releasing the side and main navigation components. Once these are finished, our plan is to create an example of all the components being used in context (e.g. a page template).

That said, we do have examples of tables that other teams can leverage. If you check the Components page on the documentation site, you can see how we’ve implemented a table.

I believe Pagey linked to these earlier, but you can find the code for our table component and how we’ve implemented it on GitHub.

While this implementation suited our needs, it isn’t robust enough to be rolled into the design system just yet given the ongoing conversation in this thread.

There’s an opportunity for folks in the community to pick up the existing work and build a table component for inclusion in the design system. We’d be thrilled to lend any help we can if someone wants to take the lead. :slight_smile:


Yeah, I’ve been using the table from the design system repo and it works fine for my current usage aside from the issues mentioned in #393.

I was just keen to get an idea of how far away it is from being a legit component, since the requirements of design system (browser support, responsive considerations, etc.) are likely different to those of my current use case.


Given the work we have aheads of us with two navigation components and full page templates, it’s unlikely we’ll be able to devote a lot of time to the table component in the next few months.