Recently, I did some testing and quickly found that even not so complex tables often cause a lot of cognitive issues for people with and without disabilities. Especially when we don’t know enough about the context and even more so when using assistive technologies.
HTML offers a lot of semantic options when it comes to tables, but some of them are more theoretical than not, at least when I tested the table with different screen reader and browser combinations. This means that if we make the tables on the web (too) complex it will often mean we introduce huge barriers to screen reader users, especially those that can’t see the screen. But sometimes also screen reader users that can see the screen when it is zoomed in – making the tables “responsive” and actually visually more like lists than tables. Which can add to the confusion.
Semantics can be mostly theoretical
I absolutely don’t want to discourage using semantic HTML, it is the best way of making things accessible on the web. And especially because it makes complex tables semantically possible. But – at the same time we still need to be practical – considering the reality and the lack of support with assistive technology.
This is not something new – gaps between theoretical support and practical support are still a common state on the web. Especially when we compare different user agents (browsers) – and adding also assistive technology to the situation just makes thing even more complex (and introduce more gaps).
Practical argument – even table heading with row scope can be a problem for some screen readers (and browser combinations). This came as a surprise to me, being too optimistic about “old school” HTML that should just work. And then it didn’t.
Now, once again, this is very unfortunate and I wish we would have even less differences, but it is a fact that there are still quite a lot of differences between screen readers. And yes, I understand – sometimes the difference is wanted. But in this scenario – it makes accessibility more difficult, especially for people trying to really understand the semantics and then implement it and then when they test it with screen readers and don’t know what else to do to make the content work for people with disabilities.
I guess that these differences – when basic (!) semantics is there but not really supported – adds a lot of frustration – and after discussing it with some developers – I am quite sure that it unfortunately makes people neglect semantics and accessibility at the same time.
It’s makes things even worse when people report such issues to vendors just to see them get stale and sometimes even automatically closed due to inactivity on the vendors side.
Vendors – please do your part and dedicate enough of time to implement accessibility support of semantics – this is a key part to make the world more accessible.
My appeal to vendors of browsers and assistive technologies.
It doesn’t help if we all do not do our part. Accessibility needs prioritizing also with vendors of assistive technologies – otherwise it doesn’t matter a lot if designers, developers and content creators shift accessibility left just to find out at the end that it is not really supported!
And this is mainly the reason for the title of this post. Simplification, under-engineering, breaking complexity is currently the best way (and probably will still be even if the semantics is well supported).
When we do not know the user and we want the information to be understandable for most possible users, then we need to make the tables simple. And that also helps with making them responsive to support even smaller screens (or screens that are zoomed in).
Is table actually still a table when it’s broken to a list
The most common responsive table solution is to break table rows into some sort of cards and just list them, with all the table headers duplicated in these cards. This is quite a standard way as far as I can tell, and it works quite well if the original table was simple.
Even when Web Content Accessibility Guidelines (WCAG) doesn’t really require tables to be responsive (opens in new window), we all know that having users to scroll in both directions to see a table is one of the most hated things for most of people involved in the production of websites (and mobile apps).
Stakeholders don’t want it. Designers hate it. Even developers prefer to make the scrollbar to be just vertical at all times. And users also don’t like to scroll in both direction as they are used of everything being responsive as well.
When I implement responsive tables, I usually intentionally duplicate the semantics (added Accessible Rich Internet Applications (ARIA) roles on top of already semantic HTML), just to support screen-reader and browser combinations that took away the table semantics when we use the Cascading Style Sheet (CSS) techniques to make tables responsive.
But it still makes me wonder a bit sometimes – if I basically show a list and use the table semantics – wouldn’t that confuse screen reader users that see the (small / zoomed-in) screen?
I keep doing it until I will have enough data against it, just because I think it is a bit more consistent for cases when two or more users talk about a page – it would perhaps be strange if somebody would refer to a key table on the page when somebody else would wonder where the table actually is as they only got a list…
Again I need to reflect on the title of this post – perhaps it would be best for all if we would just turn that table to a list in the first place… Sometimes it’s possible, and when it is – I guess it’s worth doing.