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

Re: [css3-multicol] accessibility and UX

From: Shelby Moore <shelby@coolpage.com>
Date: Fri, 15 Oct 2010 06:48:23 -0400
Message-ID: <8e0428c9524c7311862e37130782188b.squirrel@sm.webmail.pair.com>
To: "Daniel Glazman" <daniel.glazman@disruptive-innovations.com>
Cc: "www-style@w3.org" <www-style@w3.org>
> 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 think this is same issue I am reporting, for which we have already
proposed a solution (see "column-height:constrain", not "overflow:block")?


The only difference is I was proposing to exclude the viewport (and
<iframe> and <frame), but you are proposing to including it.

Always forcing the "content row height" to be no greater than the viewport
height may do not what the designer wants, but in my proposal, the
designer can opt-out with "column-height:auto".

Note this proposal will not change that the page (outer container that has
the constraint and scroll bar, e.g. viewport in your case) still has to be
scroll to read more columns.  What my proposal fixes is that_EACH_ ROW of
columns has a height that does not require scrolling.  Thus each row of
columns can be read in the inline direction without scrolling.

That is I think what you want.

> You may reply that constraining the height of the element to 100vh and
> setting |overflow: scroll| solves the problem. No it does not because
> then you still have a vertical scrollbar on the element.

Disagree.  That is a solution, but many designers may forget to set it,
which is why I made my proposal above.

When you constrain the _BOTH_ the weidth and the height, then the "column
row height" is constrained, so you only need to scroll vertically (block
direction) after you've read the entire row of columns.

If you don't want any vertical scrolling of columns, the set the height
but not the width, then all the scrolling will be in the horizontal
(inline) direction.

> Another possible idea is to have some sort of "button" at the bottom of
> the element to move in one click to the top of the element. Oh well, and
> what if the element is higher than 2 viewports' height? On a small
> netbook screen? Hum.

I have a better idea.  If the above fixes are applied, then the button
doesn't need to scroll you back up, but rather down by the "column row
height" so that you can read the next row of columns without any scroll
bar.  The browser's accessibility would implement "overflow:block" using a
"Next" and "Previous" buttons instead of a scroll bar.

> Of course, you can still control the height of the element in vh units,
> set the width of columns and let the rendering engine compute the number
> of columns. Then the horizontal scrollbar becomes needed and you'll
> often end up with a horiz-scrollbar **no web designer is ready for**.

The "Next" and "Previous" accessibility button replaces for scroll bar
could also apply in the horizontal direction.

> So if the the web page has no real control on the textual contents of
> the element and therefore the author is unable to be sure the element
> will not overflow beyond viewport's limit, I guess one possible way to
> provide an acceptable UX to people with some disabilities and in fact
> to all readers is the following one: *if* a multicolumned element's
> height is higher than the viewport's height, I think it should be the
> browser's responsability to allow the user to toggle multicolumns off.
> And back on if that's the user wants.

Why?  The content will still need to be scrolled.  What ever you replace
the scroll bar with, can be used for both single and multi-column content,
as long as the "column row height" is properly constrained as I wrote
about above.

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

I think that warning is unnecessary after the necessary improvements have
been made.
Received on Friday, 15 October 2010 10:48:50 UTC

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