Layout as a Clue to Semantics

I did not mean to write a series on tables. It’s not a series on tables. To show the impact of CSS display properties, ARIA, browser layout, and responsiveness, tables just happen to be a really good proxy.

The example in this post comes from a real-world site that I cannot share. But here is the general gist — as a user gets to the final row in a table where she is entering information, more rows are added. This allows her to not be overwhelmed with twenty-five rows of blank fields, but still provide plenty of information.

The problem is that the developers hide the final twenty rows of the table, displaying them when needed by using display: block.

I’ve written plenty on the impact that display properties can have on the semantics of elements, but often that is not obvious to anyone but a screen reader user.

In this case, it should be obvious to a sighted developer because the browser clearly breaks the columns of the table, jamming all the subsequent content into the first column for each row. I made a CodePen example, embedded below.

See the Pen Table Rows with Different Display Properties by Adrian Roselli (@aardrian) on CodePen.

As you toggle the display properties of the rows, you can see how the layout falls apart. If a browser (Edge, right now) does not yet support display: contents then that one should be unaffected.

I also left ARIA attributes on the first data row of the table, to demonstrate the need for ARIA until browsers fix their implementation, and to demonstrate how ARIA will not fix your layout. Even with the ARIA, table navigation in screen readers is still jacked up.

I think the takeaway here is: look at the visual display of your code.