Table Design and Accessibility

Hello there,

We have been trying to improve the Learn More About CSS Pseudo Selectors by Building a Balance Sheet practice project.

Points to improve on:

Current mock:

Any help is appreciated - we are trying to get this done right.

Thanks for putting this out there for review. I’ll be in touch :smiley:


I’ve created my own codepen with some accessibility enhancements for this table:

freeCodeCamp Balance Sheet codepen

There are two approaches we can take here. The original was to put everything into one table. This can definitely be done accessibly but it requires a lot of extra attributes in the HTML, such as id's on the <th>s and the headers attribute on their corresponding <td>s. You can see an example of this in example 2 on the W3C’s Tables with multi-level headers tutorial.

If you look at example 3 in that tutorial you’ll see that the other alternative is to break them up into separate, smaller tables, which is the approach I took. This allows us to keep the HTML simple and clean, and potentially makes it easier for screen reader users to understand (simpler tables are generally easier to navigate and comprehend).

Besides splitting this into three tables, the other major enhancements I added to the HTML are:

  • Pull the main heading out of the table.
  • Convert <td> to <th> where appropriate.
  • Combine the note for each line item into the <th> for the line item (so it does not take up a separate row in the table).

And then I updated the CSS to mimic the look of the original. I switched most width-based properties from px to rem. I feel this is better for responsiveness because the table will scale if just the text size is changed. Speaking of responsiveness, it is good down to around 360px view port width (assuming a default text size of 16px). I didn’t bother doing a narrow-first approach here since I wasn’t sure you wanted the added complexity. If you do want it to be able to handle even narrower widths let me know and I’ll throw out some options.

I also added one new feature which I think enhances accessibility. There is now a sticky bar across the top for the years so that the user will always be able to see them if they need to scroll vertically. This does introduce the aria-hidden attribute, so if that is too much to add then I would suggest we make the years in the first table visible instead.

I have tested this with both NVDA and JAWS screen readers on Windows 10. But since these tables are very simple and I’m following best practices they should be universally accessible.


Many thanks for all that work, @bbsmoth!

For the most part, Nich and I took what you had as is. The only thing being changing the CSS selectors, because the main focus of this project is CSS selectors.

This is what I was struggling with, because, for some reason, I assumed it would be less accessible to split the table up into multiple tables.

Generally, we try to have most of the projects look nice to about 320px, but do take liberties with this rule.

I really like this.

Thanks again.

I can definitely see arguments for that. Since the balance sheet is the only thing on the page I think it is clear that all three tables are parts of the balance sheet and thus it’s OK to split them. If the page were more complex then I would be tempted to make the entire balance sheet a landmark region by adding role="region" to the <section>, giving the <h1> an id and then giving the region an accessible name with aria-labelledby="[h1_id]". This would make it clear to screen readers that all three tables belong to the balance sheet. Another thing I thought about doing was adding “freeCodeCamp” as sr-only text at the beginning of each table caption just to clarify a little more that each table was a part of the same balance sheet.

Me too. In fact, I usually try to get down into the mid-200s (because I love a challenge :smiley:)

One approach is to make the table truly responsive by using CSS to change its display property (to something like flex or grid or block) and then rearrange things so they format nicely. But in order to do this you have to manually add back the original table roles on every <tr>, <th> and <td> in the table because changing the display property on tables makes most screen readers very unhappy.

The other option would be to use overflow: auto to allow the balance sheet to horizontal scroll when there isn’t enough horizontal room. This is one of those instances where horizontal scroll is acceptable. In order to do this accessibly though then you would have to turn the balance sheet into a landmark region (as explained above) because not all browsers (cough, chrome, cough) allow keyboard users to scroll an element that is overflowing. And then you would also have to add tabindex="0" to the scrollable element, which opens up a whole can of worms. But if I had to pick I’d probably go with this solution since it will be much easier to implement.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.