Tagged “tables”

Here’s Eric Bailey with some very relatable thoughts on the need to tell design system stories even though it’s difficult.

The component works. And because it works, nobody pays attention to it.

This is the promise of a design system made manifest: Consistent, quality experiences for complicated interactions, distributed at scale with minimal fuss.

This is objectively great. The problem, however, is how we talk, or fail to talk about this type of success.

A lack of bug reports, accessibility issues, design tweaks, etc. are all objectively great, but there are no easy datapoints you can measure here. By this, I mean it is difficult to quantify a void.

Eric advices crafting stories about the important aspects of design system work that are not directly about components:

• Identifying and collecting various ways to weave compelling narratives about the invisible, successful work you’ve done, and then
• Putting those stories in front of the people who need to know them.

At work we are currently working on that very thing as part of a communication strategy.

Sidenote: Eric frames all this in the context of a Data table component he recently worked on for GitHub. It looks good! This is also highly relatable, because I built one of these a few years back, too, and know how much work is involved.

Responsive design for tables is tricky. Sure, you can just make the table’s container horizontally scrollable but that’s more a developer convenience than a great user experience. And if you instead try to do something more clever, you can run into challenges as I did in the past. Still, we should strive to design good narrow screen user experiences for tables, alongside feasible technical solutions to achieve them.

In terms of UI design, I was interested to read Erik Kennedy’s recent newsletter on The best way to display tables on mobile. Erik lists three different approaches, which are (in reverse order of his preference):

1. Hide the least important columns
2. Cards with rows of Label-Value pairs
3. More radical “remix” as a “Mobile List”

Another article worth checking is Andrew Coyle’s The Responsive Table. He describes the following approaches:

1. Horizontal overflow table (inc. fixed first column)
2. Transitional table
3. Priority responsive table

For the transitional table, Andrew links to Charlie Cathcart’s Responsive & Accessible Data Table codepen. It looks similar (perhaps better looking but not quite as accessible) to Adrian Roselli’s Responsive Accessible Table.

By day I’m currently working on our Design System’s Table component. In order to achieve a design spec where the table has no bottom-border I needed to set:

1. all cells in the final row of the <tfoot> to have no bottom-border; but also
2. if there is no <tfoot> then set all cells in the final row of the <tbody> to have no bottom-border.

Modern CSS’s support for writing selectors which traverse the DOM up, down and sideways is pretty amazing here.

I’ve gone with:

tfoot > :last-child td, tbody:not(:has(+ tfoot)) > :last-child td { border-bottom-width: 0; }

(Some BEM stuff renamed for brevity but that’s the gist of it)

In the past we’ve had to bloat the backend layer with complex and awkward logic that adds “convenience classes” like .fe-Table-bodyLastRow but as Eric Meyer has been saying :has() in particular is going to remove the need for those convenience classes.

Hat-tip to Jhey Tompkins for his excellent recent article on :has which was a great help.

Yesterday the Design System team received a tentative enquiry regarding making table cells editable. I’m not yet sure whether or not this is a good idea – experience and spidey sense tell me it’s not – but regardless I decided to start exploring so as to base my answer on facts and avoid being overly cautious.

In my mind’s eye, there are two ways to achieve this:

1. on clicking the cell, the cell content is presented in an (editable) form input; or
2. apply the contenteditable attribute

In both cases you get into slightly gnarlier territory when you start considering the need for a submit button and how to position it.

I don’t have anything further to add at the moment other than to say that if I had to spike this out, I’d probably start by following Scott O’Hara’s article Using JavaScript & contenteditable.

I’d probably also tweet Scott and ask if he can say anything more on his closing statement which was:

I have more thoughts on the accessibility of contenteditable elements, but that will also have to be a topic for another day…

Update 27-09-22: I’ve also remembered that (if I were to pursue Option 1: input within cell) Adrian Roselli has an article on Accessibly including inputs in tables.

At work I have to think about complex HTML tables a lot. The challenge with doing tables well is that 99% of online table tutorials use fairly simple examples… whereas in reality design and product teams often want to squeeze in lots more. It’s really hard to balance those needs against accessibility, systemisation, styling and responsiveness.

Heads up: I’ve published this post early while it’s still a work in progress because it’s better for me to have it available for reference than languishing in drafts and forgotten. Apologies if you read it in a temporarily rough state.

Following a lot of work on tables I’ve recently gained additional insight into the possibilities and constraints, thanks to an accessibility review by Tetralogical and some great articles by Adrian Roselli.

Here are my new rules of thumb.

Avoid complex recreations of tables with alternate elements

In addition to developing a component wrapping the HTML table element to handle simple data tables, I recently created an alternate component for “tables with bells and whistles”. It used a combination of the HTML description list element plus CSS Grid plus some display: contents in lieu of the currently poorly supported subgrid. This approach allowed recreating a table-like appearance but facilitating much more responsive layout flexibility, amongst other benefits.

Unfortunately this resulted in an accessibiliy fail around using the description list in this way. Popular combinations of browsers and assistive technologies do not support description lists sufficiently to convey the intended crucial relationships between the faux table headers and faux table cells.

Note: I think it’s OK to use the description list element in general – just not for such an unconventional and complex use case.

ARIA Grid role: an alternative in theory (if not in practice)

I noted that Github handle their “repository directory indexes” using the ARIA grid role. Their HTML is like this (I’ve abbreviated it a touch):

<div role="grid" aria-labelledby="files" class="…">
  <div class="sr-only" role="row">
    <div role="columnheader">Type</div>
    <div role="columnheader">Name</div>
    <div role="columnheader" class="d-none d-md-block">Latest commit message</div>
    <div role="columnheader">Commit time</div>
  </div>
  <!-- interesting 'fake' row here -->
  <div role="row" class="…">
    <div role="rowheader" class="…">
      <a rel="nofollow" title="Go to parent directory" class="…" href="…"><span class="…" style="…">.&hairsp;.</span></a>
    </div>
    <div role="gridcell" class="…"></div>
    <div role="gridcell"></div>
  </div>
  <!-- first real row -->
  <div role="row" class="Box-row Box-row--focus-gray py-2 d-flex position-relative js-navigation-item navigation-focus">
    <div role="gridcell" class="…"><svg …></svg></div>
    <div role="rowheader" class="…">
      <span class="…"><a class="…" href="…">my-file-name.md</a></span>
    </div>
    <div role="gridcell" class="…">
      <span class="…"><a href="…">The commit message</a></span>
    </div>
    <div role="gridcell" class="…">
      <time-ago datetime="2021-06-17T16:45:42Z">11 months ago</time-ago>
    </div>
  </div>
  <!-- more rows go here -->
</div>

I like the idea of looking at alternatives to tables but don’t think I’d take this approach right now. Where there are lots of focusable elements it turns those multiple tab-stops into one (the grid is a single widget) which is perhaps useful for some cases, but I’ve yet to encounter them. It’d also require you to do manual focus management within the widget.

It’s an interesting approach though, and one I’ll keep in the back of my mind.

You can achieve “bells and whistles” within a table accessibly

Here are some handy techniques – done accesibly – courtesy of Adrian Roselli:

• Accessibly including inputs in tables
• Under-engineered responsive tables
• Responsive accessible tables – this more complex approach employs JavaScript to i) apply appropriate ARIA roles to existing table HTML, and ii) create clever alternate labelling using pseudo elements. It uses CSS to change the display of the table and its children to create a small-screen-friendly layout. The JS-applied roles serve to maintain the necessary semantics that would otherwise be lost when applying the radical CSS changes.
• Charlie Cathcart’s responsive table is similar to the above although perhaps less comprehensive. However it might have other interesting aspects.
• Clip long, overflowing content
• Expandable rows
• Fixed headers

References

• Grids pt1: To grid or not to grid by Sarah Higley
• ARIA Grid as an anti-pattern by Adrian Roselli