W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2004

Re: question: fixed vs. liquid layout

From: Maurizio Boscarol <maurizio@usabile.it>
Date: Wed, 16 Jun 2004 14:59:02 +0200
Message-ID: <40D04416.90300@usabile.it>
To: Gregg Vanderheiden <gv@trace.wisc.edu>
Cc: 'W3C WAI' <w3c-wai-gl@w3.org>


I notice that the problem is seen as a text-line lenght problem. I'd 
like to point out two reading, among many others on the topic:



The conclusion is not definitive, but long (full screen) line lenghts 
seem to lead to faster reading time than short lines.
The perception af reading efficency is the opposite: no-one think that 
long lines are the most efficient (even if they actually are!... ;-).

The preference is towards medium line-lenghts (65 to 75 cpl, 
charcatchers per lines) for adults (childrens tends to prefer short 
lines, about 45 cpl).

The studies (on monitor, because we can't generalize paper-readability 
studies) are not definitive for many reasons: there are many factors 
(variables) that affect the results. An incomplete list:

- line lenght in pixel
- Font-size (the experiments are lead with larger font-size than those 
usually used in web pages)
- number of scrolling: the shorter the line, the higher the number of 
click in scrolling, with usability falling down...
- The screen resolution: with liquid layout at very large resolution the 
line-lenght can be really too long... ;-) but a fixed line can be really 
too short!

So my point was not really on deciding which text-line-lenght is 
optimal, cause that can be tricky, but if a fixed layout can be seen as 
an accessibility impairment. And at which conditions: are there some 
"good fixed-layout practice"? Some sites (as alistapart) use a fixed 
measure (597px) that work at any screen resolution, even if with 
different usability... Some others (like Marco's layout, as I can see: 
it uses 700px) don't. Is that important for accessibility?

And to offer an alternative layout (fixed/liquid) by mean of stylesheet 
switching is a good thing, even if that can create a mess with some 
image-based layout?

Thank you, bye.

Maurizio Boscarol
http://www.usabile.it/ (liquid layout... ;-))

Gregg Vanderheiden wrote:

>1 - good questions
>2 - in order to allow people to view things in large print without having to
>buy a huge screen - it needs to be flowable -- but that may not always be
>RE using the horizontal scrollbar -- it is almost impossible to scroll back
>and forth and keep track of the line you are on.
>Try making a window with non flowing text just 15 or 20 char wide and then
>read it using h scroll bar.
>But we need to find a way to do this that is practical.  Or to put it at
>level 3 where it is only done when by those that really want to make a page
>accessible as it can be. 
> -- ------------------------------ 
>Gregg C Vanderheiden Ph.D. 
>Professor - Ind. Engr. & BioMed Engr.
>Director - Trace R & D Center 
>University of Wisconsin-Madison 
>-----Original Message-----
>From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
>Of Maurizio Boscarol
>Sent: Thursday, June 10, 2004 7:00 AM
>To: W3C WAI
>Subject: question: fixed vs. liquid layout
>I have a question: how should we rule about relative/absolute units for 
>Do we mean that every layout should be "liquid", or fluid?
>Another way of viewing it: is a fixed layout "per se" inaccessible?
>Another related question: is a horizontal bar an accessibility (rather 
>than usability) issue?
>Let a part that pixels are defined as relative units, so that checkpoint 
>3.4 in wcag 1 tends to be very ambiguous. But what we need really to do 
>to have an accessible layout? Absolutely liquid? ;-)  Ore relatively 
>short fixed is good enough (just to fit 640 x 480)? Or fixed layouts are 
>not a problem at all, as long as you can use the horizontal scrollbar? 
>I've been thinking about it for a long time, and I'd like to hear the wg 
>Thank you
>Maurizio Boscarol
Received on Wednesday, 16 June 2004 08:58:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:49 UTC