Tables are soooo 90s (they are about to turn 30)
HTML tables were proposed in 1993 and took off around 1996. During this time, few considered accessibility and even less predicted responsive design. UX was never considered in the process.
This case isn't unique, there are many other HTML standards that nowadays look ludicrous - selects and radio groups all have design and usability flaws.
The real problem is that (due to the existence bias) designers keep applying familiar solutions to new problems. The killer feature in tables is their auto-fit ability, which is really a presentation business; other than that, they offer little compared to alternative solutions.
A complex component
In contrast to their original intent, the various features tables might need in today's web are nothing short of monstrous. Amongst them:
- Column resize
- Column show/hide
- Sticky header/column
- Hierarchical header
- Inline editing
- Row editing
- Single row-selection
- Multi select
- Progressive loading
- Summary rows
- Responsive support
- Accessibility support
The point is that there are so many requirements for tables that aren't part of the HTML standard that you may just as well write your own component, and you may just as well not base it on HTML tables.
Having struggled with tables a lot, particularly with exactly the same issues you mention, this is what I've found to work much better:
- Instead of using tables, use a simple
<ol><li></li></ol> markup. This make it accessible.
- Use CSS to remove the list presentation.
- Use grids to create a table presentation. This makes it responsive.
This is what the bare version looks like:
Now this will obviously work under a very limited set of requirements; namely, when you are happy with fixed (and constrained) column widths. The benefit is that you get an orderly visual flow for the whole page, which normal tables nearly always break.
Another thing about tables worth remembering, particularly with large datasets, is that again - we use a solution without considering the problem. In other words, we throw everything at the user.
From a UX perspective, there's a limited amount of information people can digest and more often than not there is limited amount of information they really need.
So the way we solved it is by using table views to allow users to locate with ease the record of interest, but only showing columns that may be of 'locate interest'.
Additional data is either presented as a tool tip, or by collapse - clicking on a row reveals the full record (or on mobile will actually 'navigate' to the detailed view).
This practice also promote accessibility with the 'table' row marked (eg, aria-label) as 'overview' and the collapsed area as 'full details'.