7

I'm looking at creating a large multi-column table within a web app. However we are experiencing a challenge whereby none of the solutions fit the bill 100% and we are wary of just choosing one because it's just good enough (not meeting all requirements).

Question: Has anyone encountered an example of a table that is both accessible (semantic) AND responsive?

This poses a feasibility challenge whereby responsive tables tend to NOT be semantic. That said, and being aware of the tech limitations, I'm wondering if anyone has an UX-based answer to this.

Just to show some options that I've already looked at in the past:

Note: Accessibility level we are trying to reach is : Level AA

Improve this question

6 Answers 6

Reset to default
6

Hmmm take a look at this: https://github.com/filamentgroup/tablesaw

https://raw.githubusercontent.com/filamentgroup/tablesaw/master/docs/stack.gif

As width is reduced, the table converts over into a listing. You do lose the ability to do row comparisons, but it does ensure data remains accessible for small screen sizes.

Improve this answer
4

It is interesting to me that the problem with large multi-column tables is not being solved by creating better content and information architecture, because regardless of how responsive or accessible the table is the information is still going to be unusable to the reader if there is simply too much information. The question of how to fit a large amount of information into a small amount of screen real estate is always going to give you the answer of 'not very much'. The question then is: "How much is enough?" and "How much is useful enough?"

The answer provided by nightning is an example of when you need to come up with different content strategies when you have different amounts of space available that you can work with, and it is also important to remember that even in a responsive design it is unlikely for a user to be constantly switching between different view ports, but rather that there is a consistent and logical flow or link when one changes the channel or device through which they access the information.

From a UX point of view, large multi-column tables are not very usable or accessible unless it is specifically designed for a widescreen desktop application. I think you need to review the case for showing such a large amount of information on a web app, especially if it is likely to be viewed on a mobile device with limited space. From a content design point of view, multi-column tables present a challenge especially if the information is not suitable for a table structure because the relationship between the rows and columns of each table is not a linear or one-to-one, which means that you can't necessarily expand or collapse the hierarchy when you want to progressively disclose or hide content in a sensible or logical manner.

You can however, save yourself a bit of headache by working out the minimum amount of information, or the atomic block of information that makes sense for the user, and build the table hierarchy or structure based on multiple units of that block of information to make it as responsible and accessible for the user as possible. This is how many of the responsive websites are trying to solve their layout and design problems, and it applies at all levels of content strategy including large tables.

Improve this answer
0
2

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
  • Sorting
  • 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.

Enter grids

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:

A screenshot of a table

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.

So for more complex tables we had to tuck in some javascript and for the really complex stuff the whole presentation was javascript based (so no CSS grids).

Progressive disclosure

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'.

Improve this answer
12
  • 2
    Your design does not tie the lists together. Most importantly, it doesn't tie any list back to the heading: the lists are, in the markup, apparently unrelated and the third item in a list is not linked to the third item in the list that happens to supply the heading. Your design would therefore rely on the human eye judging the placement of these lists and understanding that – which won’t happen in a screen reader. Thus your design is very much not semantic, nor accessible.
    – KRyan
    Mar 31, 2015 at 1:21
  • 1
    @KRyan I'm not sure I get it. The header is marked aria-hidden. Each 'ol' and 'li' item has aria-label and other cross-readers attributes. Am I missing something?
    – Izhaki
    Mar 31, 2015 at 1:29
  • 1
    This answer does not meet the accessibility requirement as it's not semantic markup. In a table that has maybe 50 rows and 15 columns, how is a User with assistive technology intended to experience this?
    – Pdxd
    Mar 31, 2015 at 4:27
  • 1
    Screen readers treat tabular data differently to orient them on where in the table they are. w3.org/WAI/tutorials/tables
    – Pdxd
    Apr 1, 2015 at 0:12
  • 2
    We are using progressive disclosure to hide some of the columns based on priority however there's a scenario (and a control) where all the data can be revealed in its full glory. Plus, I remember the 90s and we don't use tables for layout anymore. It's back to its original use case, which is data.
    – Pdxd
    Apr 1, 2015 at 0:19
0

I just did the same as nightning when I had to bring a table (only 6 columns) into a 320 px version for mobile users. My first move was to delete all the columns that had information the user wouldn't actually need. It was just given, because... well, because obviously. So there are only 4 columns left. It flips to column again for tablet users and above, but for phone it's a list now and it works fine.
Oh, one difference: In the list I give no headers. The information in this list is obvious, so a descriptive text is not needed! I included a header row in the table layout.

Improve this answer
0

For accessibility, I can't understand your question. You can manage programmatically the appear/disappear of elements and using ARIA, role and html attributes you can do exactly what you want. Anyway:

- about hiding elements, the elements should be hidden using position:absolute; in order to keep them available only for AT. If you want to hide them to AT too, you should use ARIA hidden; You can find more on the WCAG site:
http://www.w3.org/TR/WCAG20-TECHS/H51.html
http://webaim.org/search/?q=tables

- about content, in tables you have 2 problems which are the amount of data (1) and how to explore them(2). If you tried to use a screen reader you will know that the user will be probably annoyed on the second row of the table, if there are too many fields(1).
He probably start to use keyboard(2) to shift on cell, maybe stopping himself randomly to know if there's something interesting. You understand that the problem of scrolling for a user which use keyboard and it's blind is not a problem if it is managed correctly programmatically.

I would rather get rid of unuseful data, and I would enhance keyboard operability. Maybe I would also conduct a user testing to understand the UX in accessibility context on the whole application and site. But I don't know your specific case.

Improve this answer
0

I thought this would be helpful.

http://allthingssmitty.com/2016/10/03/responsive-table-layout/

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.