JavaScript Disabled

To enjoy the full experience available to this page, please enable JavaScript for this browser.

Portfolio Responsive Tables

W3 Schools claim to have the solution to the responsive table, but I do not believe it is an inclusive solution. HTML and CSS supports a much improved solution that offers an inclusive experience for visual and none-visual users.

Inclusive Design

I am driven by fluid-responsive and inclusive design principles to step clear of popular "Glass Slipper" development frameworks - those that only fit Cinderella. I champion the simplicity of inclusive, accessible, usable, learnable, and useful design.

It is the UX designer's role to study and research our users. What are their goals, needs, and wants, and how do we meet them? If your users include general Interweb consumers, then your design needs to be inclusive or you will not communicate with all of your potential customers.

Example Business Needs

Our Technical Writer team put what should semantically have been definition list <dl> content into tables. And tables, we know are for data and not for layout. This was due in part to our Writers having inadequate digital knowledge, but also due to Adobe RoboHelp's negative attitude toward definition lists. (I affectionately referred to RoboHelp as "No-Go-Help" at times).

My initial reaction was that the Writers should adapt their literary style and use unordered lists to describe the definitions. I may as well have suggested basting their words with arsenic: I was not Mr Popular! They were clear that they wanted a visual representation for the defined terms using bold copy. And they had a point, their preferred presentation would ease visual scanning.

Styling definition lists though, even using semantic code and CSS, can be extraordinarily difficult if not impossible. I was thankful that a pair of online journals had recently tested definition lists vs. tables using alternative browser technologies. I was surprised to discover that tables are the more accessible strategy! I was sold, if slightly sour that my Writer friends were right.

Note: The journal findings also emphasised that role="column" was to be placed in each <th> cell to guide the browsers which cells were the column headings. However, as the ARIA default <th> value is, role="columnheader", this may be unnecessary. As always, test!

User Cases

Our users are not Cinderella (although she may be among them) and our solutions must be inclusive. Persona groups can lack enlightenment if they do not include users with different abilities and needs.

Many personas are built on overly-emphasised lores of age vs. computer literacy and are limited to just three user groups containing mythical - not typical users. They become a range of glass slipper templates; compromises to time, effort, and budget. But this frugal habit must be challenged if we are to derive experiences that truly reflect our user demographic and to justify our research.

Using tables in place of definition lists needed to be usable for everyone. They needed to respond to the viewport width and to offer the same experience of the data to everyone.

Table Solutions

I was not satisfied with W3C School's "Responsive Table". It is not responsive: at least, the method does nothing to update the data presentation. It puts the table in a scrollable container when squeezed by the viewport. It is not an inclusive solution for accessibility or usability. For example, users with motor challenges may find the horizontal scroll difficult - if they know to at all (on some devices).

I had previously researched and found that the HTML <table> tag can be given any CSS display attribute. For example, the table, its rows, or cells can be styled display:block; or display:in-line; and that these attributes can be updated using media queries (breakpoints) or scripting. The table can respond: not only its container.

Updating the table's visual behaviours enables it to retain its accessibility for non-visual browsing technologies while also maintaining - if not adding - usability for visual users. Although visually changed, the data experience remains largely the same. The table doesn't need to respond, of course. It can be styled as "cards" or "tiles" in all viewports. It's just a useful technique to display data in narrow viewports.

Caution: as suggested in the Strengths and Weaknesses section below, this technique may not replace the scrolling table adjunct in all user cases.

W3C School's Responsive Scrolling Table

W3C School demonstrates a responsive table as being contained in a div, <div style="overflow-x:auto;">. This allows your user to scroll across wide tables. The style can be set within a media query so the scrollbar only displays when you want or need it to.

But, is the table really responsive?

Here's the W3C Schools example (styled and captioned):
First Name Last Name Points Points Points Points Points Points Points Points Points Points
Jill Smith 50 50 50 50 50 50 50 50 50 50
Eve Jackson 94 94 94 94 94 94 94 94 94 94
Adam Johnson 67 67 67 67 67 67 67 67 67 67

Note: scrollbars are not displayed in some small device browsers. This renders W3C School's solution rather useless in some cases? Our users may not recognise that the table has more data columns to explore, or they may not know to swipe the table to scroll it on touch-enabled devices. (Now you know!)

Illustrating W3C School's responsive table with the horizontal scrollbar
An HTML table presented within a scrollable division layer showing the scrollbar in a smaller viewport

The Accessible and Usable Responsive Table

We know that not all of our users find horizontal scrolling easy on desktop or touch device. Why make them scroll as the W3C School's responsive table solution does?

We can use media queries and convert our table elements to "block", or "inline-block" elements. The semantic table mark up and basic column roles <th><td role="column">... (needed for accessibility, although disputed in some journals) are left intact. The table is accessible! We then update the visual presentation to something more usable than a scroll bar.

In the table below, we update the tabular layout to one resembling cards or tiles. We hide the column headings and style the first two cells of each row to look like a heading. You can do what you want, really.

We can also break the, "HTML for Content and CSS for presentation" lore guilt-free. Pseudo elements with content:"My CSS-generated Content"; are presented to only visual users. But that's OK here if it's to match the experience of visual to non-visual users for example, by adding content to the pseudo element that matches the otherwise "missing" column headings. It's inclusively accessible!

Here's a demonstration wireframe. In wider viewports (above 900px width) the presentation is as a tabular table similar to the W3C School's example above. On narrowing your viewport below 900px wide (or perhaps rotating your device), the table transforms into cards - or tiles, depending on your favoured framework UI names.

Responsive Table
First Name Last Name Score 1 Score 2 Score 3 Score 4 Score 5 Score 6 Score 7 Score 8 Score 9 Score 10
Jill Smith 50 50 50 50 50 50 50 50 50 50
Eve Jackson 60 70 80 60 70 80 80 60 70 80
Adam Johnson 70 60 30 70 60 30 80 60 70 80
Illustrating the responsive table displayed as a card
An HTML table visually presented as user interface using CSS

Strengths and Weaknesses

Tables are for data presentation and not for layout. In this case we exploit the mark up using CSS to change the visual layout to meet the viewport circumstance while leaving the semantic table layout intact.

It seems a win-win? However, if your user task is to compare scores across a rows, then it may be better to keep to a table presentation and to enable the scroll? There is no rule here. This is an alternative strategy that may solve some problems.

Scrolling across the table and hiding the student names, for example, may challenge cognitive load. Our user must remember which row is which student's. This may be OK for small numbers or rows, but for a class of thirty students the challenge to memory will increase exponentially. It is possible to "freeze" the student name columns and to only scroll the score columns, but the engineering complexity and physical demand for some users is increased.

What this technique achieves is a presentation. It may fit our problem, or assist with presentations on smaller devices. It may even be an improved presentation for our data in any viewport width?  We only need to be cognisant of the technique's strengths and weaknesses.

Show and Hide Hybrid

I installed a fluid responsive table within a legacy architecture and added a Show/Hide row effect. It used jQuery to affect the cell height with the function called on a pseudo element. This gave the presentation of cell show / hide but as the platform was not inherently accessible, I did not test its accessibility.

Accessibility testing aside, this may lead to a solution when the fluid-responsive table technique is used with wider data tables? I've included a prototype here for your interest.

Note: ideally, the cell content would be selectable and not toggle the hide function and we'd achieve a smoother transition.

Responsive Table with Show/Hide Rows
First Name Last Name Score 1 Score 2 Score 3 Score 4 Score 5 Score 6 Score 7 Score 8 Score 9 Score 10
Jill Smith 50 50 50 50 50 50 50 50 50 50
Eve Jackson 60 70 80 60 70 80 80 60 70 80
Adam Johnson 70 60 30 70 60 30 80 60 70 80
Illustrating the responsive table with a show hide feature
An HTML table visually presented as a show hide user interface

Summary

As with most UI, it depends. Consider the responsive table techniques and employ the one best suited to the task and to your users.

Top