[Planning page] Standards tables - alternative for small screens

[shawna-slh]

https://wai-media-guide.netlify.com/design-develop/media/planning/#wcag-standard

update: https://www.w3.org/WAI/media/av/planning/#wcag-standard

[shawna-slh]

I tried <div style="overflow-x:scroll;"> around the tables, which @yatil said prevents the tables from breaking out to the right of the page and making scrolling sluggish/unpredictable on small screens.

User experience with it in preview with overflow:

• on iPhone - No scrollbar appears, I instinctively put finger on table and scrolled to see the text that was cut off on the right. It worked nicely. I liked that the heading above and other non-table text stayed put.
• on Chrome Windows, when not zoomed in, there's a grayed out scrollbar at the bottom of the tables all the time. ugly and mildly distracting, yet probably not a showstopper. :-(
  When I zoom in, the scroll bars become active. However, the usability s***s.
  User starts reading the table and sees that's there's text cut off on the right, but (thinks) cannot get to it because there is not horizontal scrollbar in the browser!!! Even if eventually user figures out there is a scroll bar under the table, it's a very difficult to be reading the top, then go find the scrollbar under the table, then re-find place in table, then read some more, then go find scrollbar, etc., etc. Unless I'm missing something, this seems showstopper.

User experience without it in main preview:

• on iPhone and Chrome Windows - User gets to table, sees text cut off, sees horizontal scrollbar, uses it. Fine.

So... what to do?

[yatil]

It is possible to use media queries to hide the scrollbars on desktop/only display them when needed. (That’s why I said I would take care of the actual implementation.)

Without it, scrolling down usually scrolls also to the right. It also breaks rendering performance and some phones zoom out. Best practice is not to use tables at small screens which is not an option here.

We can add an icon/text above the table (on smaller screens) that incentivizes people to scroll. This is often done these days.

[yatil]

Decision: Can't meet usability for user of zoom on win/chrome with zoom (according to Shawn) and mobile users (according to Eric) at the same time. Doing nothing for now.

[shawna-slh]

Need to look at this site-wide. Not top priority.

[shawna-slh]

I took a look at this again to reply to query from @nitedog
Also ran into the overflow behavior earlier today in https://www.davidmacd.com/blog/wcag-2.1-quick-guide.html

I also recalled the discussions of user needs behind 1.4.10 in the Low Vision Task Force.

With zoom and the overflow functionality on laptop/Win/Chrome and laptop/Win/Firefox, the table is totally un-usable because you have to scroll and scroll and scroll to find to the horizontal scrollbar at the bottom of the table (that is, if you even figure out that it's there - and I scrolled past it a few times because it's so small and light colored and hard to see for low vision users) -- and then scroll and scroll and scroll to get back to where you were reading, etc., etc, etc. During scrolling, lose memory of what was reading before scrolling and searching. That is exactly what 1.4.10 is intended to avoid.

With zoom and current implementation at https://www.w3.org/WAI/media/av/planning/#wcag-standard in iphone/Safari and laptop/Win/Chrome and laptop/Win/Firefox, the main text does not need horizontal scrolling at all. To get to some data in the table, a little scrolling horizontal is needed. It's very easy to read the content of table cells. That is the point of 1.4.10 Reflow -- that you don't have to scroll horizontally to read a block of text.

So I still think that what we have is the only viable of the two options for accessibility/usability. And it meets both the spirit and the letter of 1.4.10.
(I agree that it's not optimum on iPhone -- it's usable, just not as a pretty.)

If we have another option that is usable and pretty in all configurations, that would be great. (Still not high priority for now.)

[yatil]

(I agree that it's not optimum on iPhone -- it's usable, just not as a pretty.)

Unless you have motor disabilities and scroll horizontally accidentally on iPhones or zoomed-in at a place where the table is not on the page. Just another consideration.

[lakeen]

Here's one example of responsive tables from loc.gov
https://www.loc.gov/programs/national-film-preservation-board/film-registry/complete-national-film-registry-listing/
sorry I don't have the time to dig into this particular css issue but thought an example might help to debug.

[yatil]

@lakeen Thanks for the link. The issue with the table in question is that the headers are very long, with words that are relatively long and five columns. So it is more a design challenge than a CSS challenge.

https://www.w3.org/WAI/media/av/planning/#pre-recorded

I usually have recommended to clients in the past to use a horizontally scrollable div around the table with shadows as affordances.

[yatil]

/me reopens the issue as there is active discussion.