W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: [css3-multicol] accessibility and UX

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 20 Oct 2010 10:45:30 -0700
Message-ID: <AANLkTin3q2LifELCawYsoXpGCVZ3VB04YqZkFB+Le5qf@mail.gmail.com>
To: Håkon Wium Lie <howcome@opera.com>
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, "www-style@w3.org" <www-style@w3.org>
On Wed, Oct 20, 2010 at 10:30 AM, Håkon Wium Lie <howcome@opera.com> wrote:
> Also sprach Daniel Glazman:
>  > I think we have a light problem with columns as they are specified in
>  > CSS. In case the height of a multicolumned element is higher than the
>  > height of the viewport, the user experience becomes awful because when
>  > you reach the bottom of a column, you must use the pointer to scroll
>  > back to the top of the next column. In terms of accessibility, some
>  > people just cannot scroll like you and me, so that's a huge issue
>  > we should probably address.
> I'm not sure the spec should try handle it. Tables impose the same
> problem: if a table cell is higher than the viewport, the user may
> have to scroll up and down to read the first cell, before moving on to
> the second cell in the row.

I strongly disagree.  While the same problem exists in theory with
tables, it also exists in theory with inline-blocks.  In neither of
these situations is it actually a problem, though, except on
*extremely* badly designed sites.  Tables are either used as a layout
aid, in which case the contents of different cells aren't typically
connected in the relevant way, or to display tabular data, which
doesn't usually take up more than a page.

Multicol, on the other hand, suffers from this problem in the *common*
case with *completely innocuous* content and styling.  For example,
I'd like to toggle my blogposts to multicol when the screen is wide
enough, but I can't, because my posts are often long and would be
rendered difficult and annoying to read.  Multicol is completely
unusable for me due to this.

> In fact, multicol offer a way out of the table problem. By setting
> sensible numbers on column-width (say, 20em), there will often only be
> one column on small screens (where the accessibility problem would
> otherwise appear). If the author uses tables, the problem remains.

Mobile is definitely not the only place where this multicol problem
appears; it is easy to trigger on the desktop as well.  The problem
just gets more common as you make screens smaller.

>  > Adding an informative note to the spec saying "warning, a columned
>  > element higher than the viewport poses accessibility issues" is a
>  > strict minimum here but, again, given the wide variety of viewports
>  > we have around us, I'm not sure it's enough. I have a strong preference
>  > for a solution allowing users to deal with columned content IF the
>  > issue appears...
> We could possibly add a note explaining the problem and encourage
> people to test their content on many types of screens.

A note is insufficient.  I don't need testing to tell that multicol is
unusable on my blog.  As well, the range of usable content lengths
based on device compatibility is extremely small, and based somewhat
on user preferences, if they have different default fonts or
font-sizes than what you expect.

As it is, multicol is only production-usable in Paged Media, where the
problems brought up by Daniel and Shelby don't exist.  It *cannot* be
used in continuous media for anything other than experiments until
this problem is fixed in some way.

Received on Wednesday, 20 October 2010 17:46:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:40 UTC