Responsive Table Research

[lnicks]

We've covered some of the options shown on the documentation at:

https://github.com/ucla/WebBlocks/wiki/Research:-Responsive-Tables

The results mostly come down to usability and accessibility issues. We're pretty sure that reformatting the table isnt the best approach for us, as accessibility tools rely on DOM structure and its confusing in general.

• Linearized tables reformat the table in a way that might be confusing to users or difficult to navigate through (tabbing through 100 records etc)
• The zurb version of pinned tables is not accessible on a DOM level, as it splits the table into two, and hides the first column of the initial table.
• The Bushell version of the pinned table reorganizes the table in a way that could confuse users as well, as it doesn't change orientation until you hit a certain breakpoint. It makes sense why they do it that way, but the change is too severe for users. We are doing some accessibility checking on this, in case we can adapt it without reorienting it somehow.
• There is some merit to linking to the full version as a default

Right now, the link to the full version and putting an IFRAME around it are our options unless we can find a way to make one of the above accessible without changing the how the table is laid out. I'm going to do some testing on these methods and I'll report back below.

One extra problem that we're dancing around is that to implement and IFRAME or a custom class for tables (in any of these methods), it has to be inserted via javascript or similar method, as we cannot expect content editors to add classes and code these in for themselves. It's not a big deal in terms of effort, but its a consideration that must be noted.

We're still looking for solutions if anyone knows how to improve or get around these issues, please chime in.

/cc @chris4ucla (I can't tag Jeff or Sal here through github like I normally do)

[spiritcapsule]

@jeff1evesque @ssantaana -- just checking if typing them in without autocomplete will work

[lnicks]

Just took a look at the first Bushell example, and it functions well enough accessibility wise. You still don't get the background cell info, but at least the table comes back to screen readers as fine.

Patrick has made a good point that if the table is written up correctly, and the only changes are CSS, it really shouldn't effect accessibility. Looking at the Bushell example, I think that is the challenge here is providing both accessible and responsive at the same time. We have issues with the reorientation being too much of a change for every day users and content editors alike, but that might be worth discussing?

[lnicks]

tagging @pburkeucla so he can be in on the conversation.

[lnicks]

IFRAMES are a no go, as they have issues with sizing and scrolling on mobile devices. We need the frame to trigger a scrollbar, and that requires a degree of overflow. There's no way to ensure the width of the frame without setting it to be absolute, so that just doesn't work with RWD if I'm not mistaken. Problem is very pronounced on IOS devices.

I tried using object as well, but it had similar issues.

The entire concept of a table doesn't fit 'responsive', especially where variable table content is concerned (drupal). So from that point of view, traditional tables will never be responsive. To make a table responsive, it will need a structural change.

That leaves us with two options for responsive that might be accessible.

• using the bushell approach, with the table flip. if we can get the background table cell info to show up, this might be the best option.
• linearized is more accessible by default, but usability wise, having to tab through 100 records isn't practical, so this isn't an option to me.

The only real way to retain a traditional table format at this point appears to be a link to the full table. I have some concerns about how to pull that off in Drupal though. I'm sure it can be done with javascript though.

We're going to have to decide if forcing users into a different experience than they're used to is OK for the sake of usability itself. As I do more work with this, I'm leaning towards accepting the table flip as the cost of making a table usable on a mobile device.

/cc @chris4ucla @pburkeucla

[lnicks]

It also occurs to me that we could just provide a link to a full version and use whatever visual we want. It's not the best, most complete solution, but I don't know if its possible to serve each case with the same solution.

[lnicks]

We've implemented the bushell version which flips the table on its axis.

Some discussion has been had and it was decided that if we're doing this just to make it scrollable, we should just stick with the original table.

Only issue I'm seeing right now is that to do this, the parent container of the table has to be set to overflow-auto and I'm not sure we want to be doing that by default on the only container we know around it, which ends up being the main content 'block'. That's an issue on several fronts for anyone using a CMS. Users might change the layout unexpectedly and we can't assume they know enough to put the DIV there.

We could insert a div around tables via javascript, if that's a viable option.

Opinions?

@chris4ucla @ebollens