cons of fixed width design
Hi All
I'm trying to get a better understanding of different site layout techniques and develop a 'good practice' rule sheet to follow.
First on the list is 'Don't Use Fixed Width'.
But why not?
- because it introduces horizontal scrolling on smaller screen resolutions
- when text is enlarged it breaks the design
- wasted space around the content on higher resolutions
Are there any other reasons fixed with width should be avoided [as if this is not enough??]?
Many Thanks
Peter
I'm trying to get a better understanding of different site layout techniques and develop a 'good practice' rule sheet to follow.
First on the list is 'Don't Use Fixed Width'.
But why not?
- because it introduces horizontal scrolling on smaller screen resolutions
- when text is enlarged it breaks the design
- wasted space around the content on higher resolutions
Are there any other reasons fixed with width should be avoided [as if this is not enough??]?
Many Thanks
Peter
I'll throw in a link to cause a stir then.
http://www.cre8asiteforums.com/viewtopic.php?p=55434#55434 is a post by Ron Carnell over at my main home. He's no accessibility expert but writes very well and always raises some good points. He does though know a good bit about writing and design generally, so he's certainly not just stabbing in the dark.
The thread was about using a CSS hack to get IE to use max-width to stop lines of text getting to long, which prompted the response from Ron which delved into the downfalls of fluid design.
http://www.cre8asiteforums.com/viewtopic.php?p=55434#55434 is a post by Ron Carnell over at my main home. He's no accessibility expert but writes very well and always raises some good points. He does though know a good bit about writing and design generally, so he's certainly not just stabbing in the dark.
The thread was about using a CSS hack to get IE to use max-width to stop lines of text getting to long, which prompted the response from Ron which delved into the downfalls of fluid design.
The three reasons you listed pretty much cover it. There is also the issue of printing. Many sites that are 'optimised for 1024x768' don't fare too well when printed; the right-hand edge of each page is lost. (This can be rectified through a print style sheet, of course.)
Tommy has left the building
Tommy has left the building
I'd like to add my two cents on this one.
"Don't use fixed widths." is a gross oversimplification. As with a great deal of life's "no-no's," it would be more proper to understand that general guidelines such as these can be broken if you know what you're doing.
It only does so if the designer makes the fixed width too large. There are very few people browsing the web with resolutions less than 800x600 pixels. Web accessibility gurus will immediately point out that one should design for all screen sizes.
However, there are obvious limitations. A logo image, for example, may need to be fully visible. Hence making it the background to a percentage width element might not be the way to go. Otherwise if the browser window is small enough, parts of the logo will be clipped. On the other hand, if one were to make that logo element a certain fixed width and properly float it, other elements would simply slide underneath it as the browser window size decreases.
Also, making the layout widths defined in percentages does not guarantee that no horizontal scrolling with take place. Let's say that we have an image want to display with a width of 800 pixels. If we want the entire image to be visible, then users with resolutions less than that will obviously need to scroll regardless. If there are words and/or inline elements that have certain widths, or if the peer widths add up to more than 100%, then there will be horizontal scrolling (novices can very easily use improper padding techniques to accomplish this).
Again, this is only true if the designer doesn't know what he/she is doing. One can avoid such a trap quite easily by using simple techniques. Also, a percentage width container may also "break the design" if improperly employed.
"Wasted space" is a highly relative term. Is a line-break after an unfloated DIV "wasted space"? Are margins or paddings of any kind "wasted space"? White space is not the enemy. In fact, white space is very important when it comes to good design. Also, consider this: very often if one were to allow a layout to fill the entire width of the screen, the text would be so spread out so as to make the design very unappealing indeed. So long as the text may be resized without breaking the design, the "wasted space" argument is an aesthetical consideration, not an accessibility one, unless of course the fixed width is ridiculously narrow.
I almost always use percentage widths nowadays, so please don't think that I simply dislike the concept. I'm just pointing out that the issue is far from black and white. That being said, only used fixed widths if you can do so without making the website inaccessible.
"Don't use fixed widths." is a gross oversimplification. As with a great deal of life's "no-no's," it would be more proper to understand that general guidelines such as these can be broken if you know what you're doing.
| Quote: |
| because it introduces horizontal scrolling on smaller screen resolutions |
It only does so if the designer makes the fixed width too large. There are very few people browsing the web with resolutions less than 800x600 pixels. Web accessibility gurus will immediately point out that one should design for all screen sizes.
However, there are obvious limitations. A logo image, for example, may need to be fully visible. Hence making it the background to a percentage width element might not be the way to go. Otherwise if the browser window is small enough, parts of the logo will be clipped. On the other hand, if one were to make that logo element a certain fixed width and properly float it, other elements would simply slide underneath it as the browser window size decreases.
Also, making the layout widths defined in percentages does not guarantee that no horizontal scrolling with take place. Let's say that we have an image want to display with a width of 800 pixels. If we want the entire image to be visible, then users with resolutions less than that will obviously need to scroll regardless. If there are words and/or inline elements that have certain widths, or if the peer widths add up to more than 100%, then there will be horizontal scrolling (novices can very easily use improper padding techniques to accomplish this).
| Quote: |
| when text is enlarged it breaks the design |
Again, this is only true if the designer doesn't know what he/she is doing. One can avoid such a trap quite easily by using simple techniques. Also, a percentage width container may also "break the design" if improperly employed.
| Quote: |
| wasted space around the content on higher resolutions |
"Wasted space" is a highly relative term. Is a line-break after an unfloated DIV "wasted space"? Are margins or paddings of any kind "wasted space"? White space is not the enemy. In fact, white space is very important when it comes to good design. Also, consider this: very often if one were to allow a layout to fill the entire width of the screen, the text would be so spread out so as to make the design very unappealing indeed. So long as the text may be resized without breaking the design, the "wasted space" argument is an aesthetical consideration, not an accessibility one, unless of course the fixed width is ridiculously narrow.
I almost always use percentage widths nowadays, so please don't think that I simply dislike the concept. I'm just pointing out that the issue is far from black and white. That being said, only used fixed widths if you can do so without making the website inaccessible.
| DragonEye wrote: | ||
It only does so if the designer makes the fixed width too large. There are very few people browsing the web with resolutions less than 800x600 pixels. |
But the thing is that it will always be too large for some display. The number of small-display users may not be significant at this time, but it is growing steadily. PDAs and web-enabled mobile phones are becoming commonplace. Some of those have displays that aren't more than 128 pixels wide. If you design for a width of 800, there will be a lot of horizontal scrolling. Of course it's not possible to do a liquid design that will work down to 128 pixels either.
| DragonEye wrote: |
| Also, making the layout widths defined in percentages does not guarantee that no horizontal scrolling with take place. Let's say that we have an image want to display with a width of 800 pixels. If we want the entire image to be visible, then users with resolutions less than that will obviously need to scroll regardless. |
No, a stable liquid design has to take this into consideration, specifying image widths as percentages (with a max-width to avoid enlarging images, which is rarely beneficial to image quality).
| DragonEye wrote: | ||
Again, this is only true if the designer doesn't know what he/she is doing. One can avoid such a trap quite easily by using simple techniques. Also, a percentage width container may also "break the design" if improperly employed. |
I'd very much like to see the simple techniques you're using to prevent a fixed-width design from breaking when the text is enlarged. This is a serious problem with languages such as Swedish, where words often become very long. Sure, you can sprinkle the markup with ­'s, but sooner or later it will break anyway.
A liquid design also suffers from this problem. Only an elastic (em-based) design handles it, but will instead induce horizontal scrolling.
| DragonEye wrote: | ||
"Wasted space" is a highly relative term. Is a line-break after an unfloated DIV "wasted space"? Are margins or paddings of any kind "wasted space"? White space is not the enemy. In fact, white space is very important when it comes to good design. |
White space is important in design, and nothing to be afraid of. However, a centred fixed-width design 'optimised' to a width of 740px or whatever will look rather ridiculous on a 1600x1200 display. It's an aesthetic problem, though, rather than an issue of accessibility or usability.
| DragonEye wrote: |
| That being said, only used fixed widths if you can do so without making the website inaccessible. |
Please don't think I'm being sarcastic here, but I'd really like to see an example of an accessible fixed-width site. Would you mind posting a URL?
Tommy has left the building
| Quote: |
| But the thing is that it will always be too large for some display. The number of small-display users may not be significant at this time, but it is growing steadily. PDAs and web-enabled mobile phones are becoming commonplace. Some of those have displays that aren't more than 128 pixels wide. If you design for a width of 800, there will be a lot of horizontal scrolling. Of course it's not possible to do a liquid design that will work down to 128 pixels either. |
Exactly -- that's my point. Whether liquid or fixed width, it will always be too large for some display. Besides, I would wager a guess that anyone browsing the web at 128 pixels isn't really in it for the aesthetics. Plus most that I'm aware of operate in text-only mode anyway (which would make the fixed-width debate moot) -- any website that expects a significant amount of phone/PDA based traffic will probably serve up WAP versions or at least expect that the user will be viewing text only.
But granted, take a design like this one: http://dragoneyedesign.com/gawds/2/. Almost every part of it is defined in percentages. Even so, it's going to start looking ridiculous when you get under 640px. I would challenge anyone to produce a design that's worth a shake with a liquid design that looks just great at 128px. In fact, the fixed width guarantees that the design itself will at least sort of remain intact (even if making the user scroll horizontally), whereas a liquid layout keeps minimizing regardless of how mangled the result is.
| Quote: |
| No, a stable liquid design has to take this into consideration, specifying image widths as percentages (with a max-width to avoid enlarging images, which is rarely beneficial to image quality). |
Besides the fact that such a technique won't work in IE ("max-width" doesn't do anything), it may be impractical in some cases anyway. If the image is meant to convey anything meaningful, it may be imperative that a minimum pixel size be maintained. Let's say I have a company logo which I wish the visitor to be able to see for the sake of brand recognition. Well if a visitor's screen resolution is such that the alotted space for that logo will be minimized to such a degree so as to make it unrecognizable, I will have failed. This especially true if no other textual clues are shown as to where the user is (for sighted users).
| Quote: |
| I'd very much like to see the simple techniques you're using to prevent a fixed-width design from breaking when the text is enlarged. This is a serious problem with languages such as Swedish, where words often become very long. Sure, you can sprinkle the markup with ­'s, but sooner or later it will break anyway.
A liquid design also suffers from this problem. Only an elastic (em-based) design handles it, but will instead induce horizontal scrolling. |
For horizontal menu where it is imperative that the text stay on one line, leave plenty of room on one or both sides so that if the text is enlarged, it won't screw everything up. If it's not important that it stay on one line, then there's no problem. Of course it's a given that a designer needs to be aware of his content. If there's more to stuff into a certain container (regardless of whether the reason is that it is Swedish or it's just alot period), the designer has to take that into consideration. This problem is not unique to fixed width layouts.
Like you said, a liquid design suffers from this same problem. If the widths are defined as percentages, then the exact same constraints exist -- that is, the text may be resized so as to screw up the design some how. If it's EM based, then you're just exchanging one problem for another, just like you said. In any case the problem isn't unique to fixed widths -- that's my point.
| Quote: |
| White space is important in design, and nothing to be afraid of. However, a centred fixed-width design 'optimised' to a width of 740px or whatever will look rather ridiculous on a 1600x1200 display. It's an aesthetic problem, though, rather than an issue of accessibility or usability. |
At least we can agree that it's an aesthetic consideration more than anything else. However ridiculous a 760px centered design looks on a 1600px wide display, it is my contention that most designs which look good at 800px will also be ridiculously spread out at 1600px. Content that once took up quite a bit of vertical space will take up much less, which could look quite absurd itself. I suppose it's all a matter of the specific design we're talking about and user preference.
| Quote: |
| Please don't think I'm being sarcastic here, but I'd really like to see an example of an accessible fixed-width site. Would you mind posting a URL? |
Sure, I took the very same design as the one I showed earlier, but constrained it to a fixed width: http://dragoneyedesign.com/gawds/2/test.html
Whatever your critique of the accessibility of the two versions, the only real difference is that the liquid percentage version starts looking weird at resolutions under 800px, whereas one must scroll for the fixed width version at that resolution. I would actually argue that I'd rather have someone scroll in this case than subject them to a very mangled design.
Once again, I'll reiterate: percentages are great as a rule of thumb. However, it's categorically false to assert that fixed widths are inaccessible in all cases at all times. Admittedly, it is often more difficult to make a fixed width layout accessible than it is for a percentage layout -- all I'm saying is that there are exceptions to the rule, and that there are cases where fixed width elements are indeed preferable for one reason or another.
Are we getting too hung up on these points? Whatever design we use, liquid or fixed width, we are always going to have problems with users not being able to use our site as we would like. Surely the key is to make our sites as accessible as possible to the majority of users and if demand becomes such, find a way of accomodating small screen users.
I question why mobile users want to have main sites available, surely they realise that by having this technology they are restricting their options anyway, besides, would they want flashy graphics or to be able to access information on the move?
I think it's time to take a breather from this debate and see how experience pans out then re-visit it in, say, 12 months.

Mike Abbott
Accessible to everyone
I question why mobile users want to have main sites available, surely they realise that by having this technology they are restricting their options anyway, besides, would they want flashy graphics or to be able to access information on the move?
I think it's time to take a breather from this debate and see how experience pans out then re-visit it in, say, 12 months.
Mike Abbott
Accessible to everyone
Dear all
Just a note to say that i appreciate all of your thoughts on this thread - i'm afraid i've been tied up visiting my father in hospital but he is making a fine recovery now - so i'll print this thread off and delve into it asap.
Thanks again.
Pete
Just a note to say that i appreciate all of your thoughts on this thread - i'm afraid i've been tied up visiting my father in hospital but he is making a fine recovery now - so i'll print this thread off and delve into it asap.
Thanks again.
Pete
Peter
Hope your Father completes his recovery in the way you wish it to be
Mike Abbott
Accessible to everyone
Hope your Father completes his recovery in the way you wish it to be
Mike Abbott
Accessible to everyone
Well, the question which was posed is whether or not fixed widths inherently make layouts inaccessible and to what degree. The answer is clearly "no", but be careful.
I would agree to just sit on it for a year as Mikea suggests, but I for one will be making websites in the mean time. I am also reasonably certain that the situation in one year will be quite similar to what it is now. Screen resolutions for the majority will continue to get bigger, and, like Mikea has so aptly noted, nobody browsing the web on a phone or PDA should expect to have an aesthetically pleasing browsing experience because, quite frankly, that was never the point. Such users are just after information, plain and simple. It's a good thing, too, otherwise no design technique would be safe.
We as designers ought to make a reasonable effor to include as many people as possible, emphasis on the word "reasonable." It is reasonable to code according to standards. It is also reasonable to make sure a layout looks good on resolutions 800px and up, and are at least usable on resolutions lower than that. It is not reasonable, however, to insist that a design look good at 128px. That's simply ridiculous in most cases -- unless of course you expect a good deal of traffic to be at that resolution (in which case you really ought to serve up a WAP alternative anyway).
I would agree to just sit on it for a year as Mikea suggests, but I for one will be making websites in the mean time. I am also reasonably certain that the situation in one year will be quite similar to what it is now. Screen resolutions for the majority will continue to get bigger, and, like Mikea has so aptly noted, nobody browsing the web on a phone or PDA should expect to have an aesthetically pleasing browsing experience because, quite frankly, that was never the point. Such users are just after information, plain and simple. It's a good thing, too, otherwise no design technique would be safe.
We as designers ought to make a reasonable effor to include as many people as possible, emphasis on the word "reasonable." It is reasonable to code according to standards. It is also reasonable to make sure a layout looks good on resolutions 800px and up, and are at least usable on resolutions lower than that. It is not reasonable, however, to insist that a design look good at 128px. That's simply ridiculous in most cases -- unless of course you expect a good deal of traffic to be at that resolution (in which case you really ought to serve up a WAP alternative anyway).
| DragonEye wrote: |
| Besides the fact that such a technique won't work in IE ("max-width" doesn't do anything), it may be impractical in some cases anyway. |
One could argue, to borrow an expression from Patrick, that part of the onus is on the user. If they need accessibility, they could download a standards-compliant browser for free. You can't stick to an old and buggy piece of software and demand that everything work in it.
| DragonEye wrote: |
| If the image is meant to convey anything meaningful, it may be imperative that a minimum pixel size be maintained. |
In that case, you will have to use the longdesc attribute to convey the important information anyway, because image-only is never accessible.
| DragonEye wrote: |
| For horizontal menu where it is imperative that the text stay on one line, leave plenty of room on one or both sides so that if the text is enlarged, it won't screw everything up. |
That may survive a size change in one or two steps, but for a low-vision user who needs a 240% increase, it will certainly break. Unless you restrict yourself to very simple designs, of course.
| DragonEye wrote: |
| Sure, I took the very same design as the one I showed earlier, but constrained it to a fixed width: http://dragoneyedesign.com/gawds/2/test.html |
Sorry, but I can't accept that to be any more accessible than a liquid or elastic design. Apart from the fact that I had to hit Reload to get it to display in Mozilla in the first place, it doesn't cope too well with resolution issues or text size issues. At a mere 200% text size, I get a horizontal scroll bar on the center column. At 640x480, I get a horizontal scroll bar on the entire page, even though there are acres of empty space available on my screen.
In my personal opinion, it also looks silly at 1280x1024, with the tiny sqare in the centre of the screen. What's the use of my getting a large monitor, if I still have to squint to see a small content area?
| DragonEye wrote: |
| Admittedly, it is often more difficult to make a fixed width layout accessible than it is for a percentage layout -- all I'm saying is that there are exceptions to the rule, and that there are cases where fixed width elements are indeed preferable for one reason or another. |
I'd go so far as to say that a fixed-width layout cannot be accessible. A liquid design might (in a modern browser), but it takes a very skilled designer to do it.
<flamebait>There may be cases and reasons where a fixed-width design is preferable, but I can't see how accessibility is one of them. Time constraints, lack of design/markup/CSS skills, laziness ... yes. Accessibility? No.
Tommy has left the building
| Quote: |
| One could argue, to borrow an expression from Patrick, that part of the onus is on the user. If they need accessibility, they could download a standards-compliant browser for free. You can't stick to an old and buggy piece of software and demand that everything work in it. |
One could, but one would be wrong. It defeats the entire purpose of accessibility to demand a user to download another browser. Have we forgotten that IE users constitute the vast majority? They would be the very worst group to alienate. Frankly I'm getting a little tired of the "screw everyone that doesn't want to have whatever browser I think is best" attitude, especially when that browser is extremely popular. Our job is to accomodate, period.
| Quote: |
| In that case, you will have to use the longdesc attribute to convey the important information anyway, because image-only is never accessible. |
To offer a text equivalent of an image is a given, but that wasn't the point. The point is that not only would relying on the max-width property alienate a majority of users, but it would also run the risk of making an important image such as a logo unrecognizable for people with images turned on and who are not blind.
| Quote: |
| That may survive a size change in one or two steps, but for a low-vision user who needs a 240% increase, it will certainly break. Unless you restrict yourself to very simple designs, of course. |
Like I said earlier, we need to consider what is reasonable. For example, I usually design such that a user with a screen resolution of 1024px width may increase his/her text size to the largest setting in IE without breaking the design. That is what I consider reasonable. Of course there is a threshold for which any design will break, regardless of what technique is used. But what I've been saying again and again (and again), is that this problem is not specific to fixed widths -- it is an issue for any and all techniques.
| Quote: |
| Sorry, but I can't accept that to be any more accessible than a liquid or elastic design. Apart from the fact that I had to hit Reload to get it to display in Mozilla in the first place, it doesn't cope too well with resolution issues or text size issues. At a mere 200% text size, I get a horizontal scroll bar on the center column. At 640x480, I get a horizontal scroll bar on the entire page, even though there are acres of empty space available on my screen.
In my personal opinion, it also looks silly at 1280x1024, with the tiny sqare in the centre of the screen. What's the use of my getting a large monitor, if I still have to squint to see a small content area? |
Of course not. I never made the claim that fixed width layouts are MORE accessible than liquid ones. I said that fixed width layouts aren't necessarily inherently inaccessible. Personally, I don't think a horizontal scrollbar when the text size is increased 200% is so terrible at all. Who browses at 640x480?
You see, the point is that a layout at a fixed width of 800px should be just as usable as a liquid layout for someone running 800x600. Whatever problems you encounter with any given liquid design running at 800px width, those are the very same problems with a 800px fixed width layout. In other words, every single criticism you had of the design at a fixed width could just as well have been said about the liquid version for a majority of users running at 800x600. Therefore you may certainly argue that the layout doesn't meet your accessibility standards, but any attempt to claim that one is accessible and the other not is nonsense.
The only criticism which you have offered which is specific to the fixed width version (as opposed to the liquid version running at 800x600) has to do more with aesthetics than accessibility.
| Quote: |
| I'd go so far as to say that a fixed-width layout cannot be accessible. A liquid design might (in a modern browser), but it takes a very skilled designer to do it. |
I'm still trying to figure out what your arguments in support of such an assertion are. Like I said before, everything you said about the fixed version of my example would happen to the liquid version at a resolution of 800x600 or below. Hence you may argue that I am a poor designer, but it would be fallacious to claim that one is necessarily less accessible than the other.
| Quote: |
| <flamebait>There may be cases and reasons where a fixed-width design is preferable, but I can't see how accessibility is one of them. Time constraints, lack of design/markup/CSS skills, laziness ... yes. Accessibility? No. </flamebait> |
If you read carefully what I have said, I never made the claim that a fixed width layout is MORE accessible than a liquid layout. The choice to use a fixed layout would be purely aesthetical. Perhaps you misunderstood me.
You've given me your threshold for acceptable accessibility standards. Now may I see an example of your work which adheres to these standards? Namely, could you point me in the direction of a good looking design which does not horizontally scroll whatsoever at a resolution of 640x480 with a text size at 240%?
Hopefully said design uses small words. I've made a quick list of long words (some proper nouns, some not) which I placed against a visible measuring stick found at the top of the page. The words are all English except for one (which is Greek). So just how long are these Swedish words you seem so concerned about? When you subtract the scrollbar width of 20 pixels, you're left with 620 pixels with which to work. The example assumes a single column with absolutely no padding or margins whatsoever and the text is at 240%, normal weight, Arial. In case you haven't noticed, I'm absolutely mocking your accessibility standards. By the measuring stick you've given me, any website which uses any really long words is inherently inaccessible because it introduces horizontal scrolling at a resolution of 640x480 with text jacked up to 240%.
Here it is: http://dragoneyedesign.com/test2.html
So let's see an example of something you consider to be the most accessible it can be (that looks good).
| DragonEye wrote: |
| One could, but one would be wrong. It defeats the entire purpose of accessibility to demand a user to download another browser. — — — Our job is to accomodate, period. |
I'd beg to disagree. If we were to cater for any browser (design-wise) we'd have to go back to the coding practice of the browser wars. Surely you don't want that?
The onus of accessibility falls on several parties:
- The designer/developer who creates the web site.
- The browser manufacturer.
- The user (choosingand learning how to use his/her browser).
- (The development tool manufacturer, to some extent.)
The browser manufacturers must adhere to standards and guidelines, in order to give the designers a fair chance of doing a good job. Since some don't, some onus falls on the user to choose the right tool for the job – and to learn how to use it. My site isn't inaccessible because the user doesn't know how to resize the text size with his/her browser.
IE's ubiquity skews the equation somewhat, of course. Whatever we do has to work in that one, if we're concerned about reaching a broad audience. In my opinion, it doesn't have to be perfect in IE, just usable, if the amount of effort involved to work around IE's bugs is out of proportion to the gain.
| DragonEye wrote: |
| To offer a text equivalent of an image is a given, but that wasn't the point. The point is that not only would relying on the max-width property alienate a majority of users, but it would also run the risk of making an important image such as a logo unrecognizable for people with images turned on and who are not blind. |
This is dependent on the design. If the overly large image crashes the design (whether it be fixed-width, elastic or fluid) by overlapping some other content, it's no more accessible than an illegible image. At least in the latter case, someone who really needs to see the image could right-click it, save it, and open it in another program.
Besides, it's not only blind people who are unable to see images. Lynx users cannot, and some dial-up users disable images because they don't think it's worth the massive download times.
| DragonEye wrote: |
| Like I said earlier, we need to consider what is reasonable. For example, I usually design such that a user with a screen resolution of 1024px width may increase his/her text size to the largest setting in IE without breaking the design. That is what I consider reasonable. |
IE can change the text size in five steps (two up, two down). That's it. If you set a small base font size, as some are wont to do, even 'largest' won't be enough for many users.
| DragonEye wrote: |
| I never made the claim that fixed width layouts are MORE accessible than liquid ones. I said that fixed width layouts aren't necessarily inherently inaccessible. |
It depends on how one define's 'accessible', I suppose. Requiring a certain width (or height) in pixels is considered inaccessible by some, since there will always be displays that are too small, whatever size you choose. I'd consider it more of a usability issue myself.
| DragonEye wrote: |
| Personally, I don't think a horizontal scrollbar when the text size is increased 200% is so terrible at all. Who browses at 640x480? |
Wait a second? Didn't you just say "Our job is to accomodate, period."?
So it's not OK to say to people that they should download a standards-compliant browser for free, but it's OK to tell them that they have to buy an expensive, large monitor?
As I said, more and more people are using PDAs and mobile phones to surf. Those are usually even below 640x480. Who knows what the future holds?
| DragonEye wrote: |
| You see, the point is that a layout at a fixed width of 800px should be just as usable as a liquid layout for someone running 800x600. |
Yes, but the thing is that not everyone runs 800x600. According to the most recent statistics I saw, in fact, it's only about 40% that do. And some of those who do run 800x600 have a favourites panel open, or something else that detracts from the available width. They may not even wish to surf with a maximized window.
Yes, I agree that they may have to expect a scroll bar if they do. The point is that you can never assume anything on the web.
| DragonEye wrote: |
| The only criticism which you have offered which is specific to the fixed width version (as opposed to the liquid version running at 800x600) has to do more with aesthetics than accessibility. |
I'd rather say usability, but let's not get into semantics.
| DragonEye wrote: |
| Hence you may argue that I am a poor designer |
The mere thought hadn't even begun to cross my mind. I hope I haven't come across that way. We're just discussing the pros and cons of various design methods here. Nothing personal, just a difference in opinions.
| DragonEye wrote: |
| If you read carefully what I have said, I never made the claim that a fixed width layout is MORE accessible than a liquid layout. The choice to use a fixed layout would be purely aesthetical. Perhaps you misunderstood me. |
That is very likely.
| DragonEye wrote: |
| You've given me your threshold for acceptable accessibility standards. Now may I see an example of your work which adheres to these standards? Namely, could you point me in the direction of a good looking design which does not horizontally scroll whatsoever at a resolution of 640x480 with a text size at 240%? |
I'm not a skilled designer, so I can't show you anything dazzling. And I don't think there's any design that survives 640x480 and 240%. Low resolutions make for large letters, so you shouldn't have to enlarge text as much. The higher the resolution, the more low-vision users have to enlarge the text.
You're welcome to look at my weblog, but remember that I don't claim to be a designer. In a compliant browser, it works at 640x480 (up to 150%). At 1280x1024, it survives a 300% font size increase. But it's a simple 2-column layout.
The one I'm doing at work (not publicly available until July 1) is a 3-column layout (some pages use 4). It works (barely) at 640x480 (100%) and survives at least 200% at 1280. 3-col layouts are difficult on small screens, though.
| DragonEye wrote: |
| So just how long are these Swedish words you seem so concerned about? |
The longest one on the front page of the Swedish version of my weblog is "webbformgivningsverktyg" (web design tool). The longest one I've seen (other than fictional extremes) is "kontraktsanställningsålderstilläggsklassföljsamhet".
I think that whips even "antidisestablishmentarianism".
| DragonEye wrote: |
| In case you haven't noticed, I'm absolutely mocking your accessibility standards. By the measuring stick you've given me, any website which uses any really long words is inherently inaccessible because it introduces horizontal scrolling at a resolution of 640x480 with text jacked up to 240%. |
I'd rather say hard to use than inaccessible, because it will only cause a horisontal scroll bar to appear. And as I said before, 640x480 and 240% is overkill, IMHO.
| DragonEye wrote: |
| So let's see an example of something you consider to be the most accessible it can be (that looks good). |
I'll have to get back to you on that one. I haven't hunted for one. All I can offer right now is my own weblog, and I don't claim that it looks good. I think it's fairly accessible, though, and it's only my lack of graphics design skills that cause it to be bland.
I'm definitely not disparaging your design skills, nor am I mocking your accessibility standards (only the double standards about browsers vs. displays
I hope you don't take this as any kind of criticism against you personally. I'm just enjoying a discussion with a knowledgeable opponent.
Tommy has left the building
No, no worries; I like sparring. I'll save the extensive quoting this time and dive right in.
Sprinkled in my writing, I often refer to what is "reasonable" -- or, for my purposes, a tradeoff that has more positive effects than negative and which is possible to do. When I say that it is our job to accomodate, I should have made the qualification right that this refers to things within reason. Obviously it is impossible to accomodate everyone in every circumstance. My point is simply that it is ridiculous to not code for IE since its users make up the majority of users. Once that qualification is made, any perceived ambiguity in my position slips away.
How many users are running IE? 80% or more.
How many users are running at 640x480 or less? Probably between 1-5%.
There is no double standard here. It is reasonable to code for 80% of users. It is not reasonable to make 95-99% of users suffer because 1-5% browse at a very low resolution. Of those who browse at such low resolutions, there are probably quite a few who are doing it from phones and/or PDAs, who, as discussed, shouldn't be expecting a very graphical experience, or who hook into WAP enabled websites in the first place. As for the unfortunate souls browsing the Internet on a desktop at 640x480, I would say that their screen resolution is only one of a whole host of issues they will be facing. Such a user is most likely running 256 colors, and a CPU so slow that the actual loading of a web page is probably takes longer than the actual HTTP request and answer. (I may be exaggerating, but you get the point).
I am not advocating compatibility with every browser, or even every possible screen resolution. I'm saying that we need to pay attention to what the demographics tell us and try to include the most people we can, within reason. I agree with your take on who SHOULD be responsible for accessibility to a certain extent. I'm much more of a realist than an idealist, though. Say what you will about IE, but its widespread use means that we have to code accordingly.
In the case of our important image example, overlapping can usually be avoided using floated elements which slide underneath one another as the screen width lessens. It is a given that a blind or Lynx user will not see the image, but that's still not the point. The point is that MOST people WILL see it, and it will be important for brand recognition or whatever else the designer intended.
According to recent stats I've seen, about 94% of web users browse at 800x600 or above. My general rule of thumb is to make things look good at 800x600 and at least be usable at 640x480. I do see your poing about favorites panels open, but nobody can control or predict the size of a user's cascaded browser window. It could be under 200x200 for all we can know -- therefore it's really not something that a designer can code for.
Okay, just one quote:
That's all I wanted to hear. I felt that you were trying to put constraints on the design I showed that seemed unreasonable to me. It's all a game of give and take, and the accessibility of any given site is often quite grey. I mean, getting a Bobby AAA rating doesn't guarantee accessibility. After all, even websites whose text is not resizeable can get that. And even so, after that it's a matter of degree and differs according to who's doing the assessment.
We have good graphic artists and designers who have been happily creating cool but inaccessible designs in one corner, and accessibility purists in the other corner that aren't so strong in the design department. My gaol is to strike a balance -- a website can be pretty darn accessible and still look awesome. There's always going to be a certain accessibility threshold that the designer intended. It's true that my example scrolls horizontally when the text is sized really high, but the website's still very usable. There's always a tradeoff. I decided in this case that making the design look the way I wanted it to was worth making people that resized the text to over double its default size scroll a little bit. In the end I don't think I'll have any non-disabled users mad at me for making a crappy design, nor will I have any disabled persons mad at me for making it inaccessible. Perhaps you disagree, but that was the decision I made.
The one thing I strongly disagree with is making accessibility a black and white issue. If a website can't even pass the Bobby AAA test, then it is. But beyond Bobby approval, accessibility can better be described as an art rather than a science. There shouldn't be any automatic flags at that point, unless some portion of content simply can't be gotten to by a user. Fixed width? I don't think that it automatically makes it inaccessible. Horizontal scrolling? I don't think that that necessarily makes the website inaccessible if it only happens when text sizing is increased dramatically. And even so, it's then a matter of degrees more than anything else. What does it mean for a website to be accessible? Surely we cannot code for every eventuality, hence no website can be 100% accessible. Even the mere fact that some people still use NS 4.7 means that website cannot be accessed by absolutely everyone, at least not without making all kinds of pesky alternate versions.
So if you're grading my example and determine that horizontal scrolling makes it inaccessible, then it is such only in degree less than what is possible. I am quite confident that nobody will tell me that they were unable to use that design altogether. If they do, then I'll need to change it. I'm actually using the liquid version, but it may still scroll horizontally when a screen resolution is very low and the text size is jacked up. I'm prepared to take my chances on that.
"Standards" are only useful to the degree that they are ubiquitous. People tend to get so obsessed with the standards themselves that they forget that the whole point of the standard is to provide universal behavior/protocol. A standard is worthless to the degree that it fails to be adopted by all parties. We can bitch and complain about IE all we want to, but at the end of the day, things just have to work in it. If they don't, you're alienating the majority. How is that accessible? Standards compliance is not a necessary component of accessibility per se, but luckily in this case we have enough ubiquity to make it the case.
Please understand that I'm not trying to be too negative with what I'm about to say, but I'm using it as an example to prove my point. I visited your blog. Even at 800x600 at the default text size, there is a horizontal scroll bar. I didn't look at it extensively, but I'll take your word that it's standards compliant (it sure seemed to work great in Mozilla). Now let's say that this behavior was reversed. Let's say you had coded such that it worked great in IE but it scrolled horizontally in Mozilla. Now which is more accessible, your site as it is now or the hypothetical situation I just described.
Mozilla is more standards compliant, but the latter would still be more accessible anyway. Accessibility is the degree to which people are able to easily use the website. This definition need not have anything to do with standards compliance, but, like I mentioned, fortunately in this case it does. Even so, a more usable website for 80% of web users would be more accessible overall that a website which was more usable to the same degree to only 20% of users. Of course it is best if you are able to code for all browsers -- but my point is that we should go toward the majority demographic when universality is not possible. The more usable the website is for the more people, the more accessible it is.
Sprinkled in my writing, I often refer to what is "reasonable" -- or, for my purposes, a tradeoff that has more positive effects than negative and which is possible to do. When I say that it is our job to accomodate, I should have made the qualification right that this refers to things within reason. Obviously it is impossible to accomodate everyone in every circumstance. My point is simply that it is ridiculous to not code for IE since its users make up the majority of users. Once that qualification is made, any perceived ambiguity in my position slips away.
How many users are running IE? 80% or more.
How many users are running at 640x480 or less? Probably between 1-5%.
There is no double standard here. It is reasonable to code for 80% of users. It is not reasonable to make 95-99% of users suffer because 1-5% browse at a very low resolution. Of those who browse at such low resolutions, there are probably quite a few who are doing it from phones and/or PDAs, who, as discussed, shouldn't be expecting a very graphical experience, or who hook into WAP enabled websites in the first place. As for the unfortunate souls browsing the Internet on a desktop at 640x480, I would say that their screen resolution is only one of a whole host of issues they will be facing. Such a user is most likely running 256 colors, and a CPU so slow that the actual loading of a web page is probably takes longer than the actual HTTP request and answer. (I may be exaggerating, but you get the point).
I am not advocating compatibility with every browser, or even every possible screen resolution. I'm saying that we need to pay attention to what the demographics tell us and try to include the most people we can, within reason. I agree with your take on who SHOULD be responsible for accessibility to a certain extent. I'm much more of a realist than an idealist, though. Say what you will about IE, but its widespread use means that we have to code accordingly.
In the case of our important image example, overlapping can usually be avoided using floated elements which slide underneath one another as the screen width lessens. It is a given that a blind or Lynx user will not see the image, but that's still not the point. The point is that MOST people WILL see it, and it will be important for brand recognition or whatever else the designer intended.
According to recent stats I've seen, about 94% of web users browse at 800x600 or above. My general rule of thumb is to make things look good at 800x600 and at least be usable at 640x480. I do see your poing about favorites panels open, but nobody can control or predict the size of a user's cascaded browser window. It could be under 200x200 for all we can know -- therefore it's really not something that a designer can code for.
Okay, just one quote:
| Quote: |
| I'm not a skilled designer, so I can't show you anything dazzling. And I don't think there's any design that survives 640x480 and 240%. Low resolutions make for large letters, so you shouldn't have to enlarge text as much. The higher the resolution, the more low-vision users have to enlarge the text. |
That's all I wanted to hear. I felt that you were trying to put constraints on the design I showed that seemed unreasonable to me. It's all a game of give and take, and the accessibility of any given site is often quite grey. I mean, getting a Bobby AAA rating doesn't guarantee accessibility. After all, even websites whose text is not resizeable can get that. And even so, after that it's a matter of degree and differs according to who's doing the assessment.
We have good graphic artists and designers who have been happily creating cool but inaccessible designs in one corner, and accessibility purists in the other corner that aren't so strong in the design department. My gaol is to strike a balance -- a website can be pretty darn accessible and still look awesome. There's always going to be a certain accessibility threshold that the designer intended. It's true that my example scrolls horizontally when the text is sized really high, but the website's still very usable. There's always a tradeoff. I decided in this case that making the design look the way I wanted it to was worth making people that resized the text to over double its default size scroll a little bit. In the end I don't think I'll have any non-disabled users mad at me for making a crappy design, nor will I have any disabled persons mad at me for making it inaccessible. Perhaps you disagree, but that was the decision I made.
The one thing I strongly disagree with is making accessibility a black and white issue. If a website can't even pass the Bobby AAA test, then it is. But beyond Bobby approval, accessibility can better be described as an art rather than a science. There shouldn't be any automatic flags at that point, unless some portion of content simply can't be gotten to by a user. Fixed width? I don't think that it automatically makes it inaccessible. Horizontal scrolling? I don't think that that necessarily makes the website inaccessible if it only happens when text sizing is increased dramatically. And even so, it's then a matter of degrees more than anything else. What does it mean for a website to be accessible? Surely we cannot code for every eventuality, hence no website can be 100% accessible. Even the mere fact that some people still use NS 4.7 means that website cannot be accessed by absolutely everyone, at least not without making all kinds of pesky alternate versions.
So if you're grading my example and determine that horizontal scrolling makes it inaccessible, then it is such only in degree less than what is possible. I am quite confident that nobody will tell me that they were unable to use that design altogether. If they do, then I'll need to change it. I'm actually using the liquid version, but it may still scroll horizontally when a screen resolution is very low and the text size is jacked up. I'm prepared to take my chances on that.
"Standards" are only useful to the degree that they are ubiquitous. People tend to get so obsessed with the standards themselves that they forget that the whole point of the standard is to provide universal behavior/protocol. A standard is worthless to the degree that it fails to be adopted by all parties. We can bitch and complain about IE all we want to, but at the end of the day, things just have to work in it. If they don't, you're alienating the majority. How is that accessible? Standards compliance is not a necessary component of accessibility per se, but luckily in this case we have enough ubiquity to make it the case.
Please understand that I'm not trying to be too negative with what I'm about to say, but I'm using it as an example to prove my point. I visited your blog. Even at 800x600 at the default text size, there is a horizontal scroll bar. I didn't look at it extensively, but I'll take your word that it's standards compliant (it sure seemed to work great in Mozilla). Now let's say that this behavior was reversed. Let's say you had coded such that it worked great in IE but it scrolled horizontally in Mozilla. Now which is more accessible, your site as it is now or the hypothetical situation I just described.
Mozilla is more standards compliant, but the latter would still be more accessible anyway. Accessibility is the degree to which people are able to easily use the website. This definition need not have anything to do with standards compliance, but, like I mentioned, fortunately in this case it does. Even so, a more usable website for 80% of web users would be more accessible overall that a website which was more usable to the same degree to only 20% of users. Of course it is best if you are able to code for all browsers -- but my point is that we should go toward the majority demographic when universality is not possible. The more usable the website is for the more people, the more accessible it is.
I don't think we really disagree all that much when we get down to it. Hmm ... I must find something to heat up the argument.
I agree with you that one has to be reasonable, especially when it comes to commercial sites or public interest sites (including government sites). I disagree slightly with your definition of accessibility as being based on statistics, though. Let's say, as you did, that 80+% run IE and 1-5% run at 640x480 or less. Naturally, one would make sure that the site works well in IE at 800x600 and above. Naturally. But disregarding the remaining percentage just isn't possible if one wants to claim to be accessible. The design doesn't have to be the same (or even present) for the minority users, but the content (i.e. information) must be available for "everyone". Now, as you see, I put "everyone" in quotes. That's because "everyone" is absolutely impossible to achieve. Even if you go to extreme lengths, such as having a culture-neutral images-only version for those who cannot digest textual content (severe dyslexics, illiterates, etc), there will always be some that cannot access it. Those without an Internet connection, for instance.
You're right, we mustn't let the 95-99% majority suffer. That's the tough part of web accessibility. We need to create sites that are attractive for the majority, while still being accessible for the minorities.
I repeat: I don't consider a horizontal scroll bar to be an accessibility problem, really. It's a usability issue. Still, it's something I try to avoid if possible. I don't think the scroll bars (I got four of them at some point) make your site inaccessible, just hard to use.
Regarding Bobby testing: I never bother. OK, it can tell you if you did something really stupid, but machine validation of accessibility can only go so far. It can never ascertain whether you've used the "clearest and simplest language appropriate for a site's content" for instance. Nor can it see if you have an accessible alternative to an inaccessive page. Unfortunately, there seems to be people who think that passing a Bobby test means that the page is fully accessible. Then they slap a AAA icon on their pages, which don't even reach level-A compliance.
I don't know why you got a scroll bar at 800x600 at my site. I don't get one even at 640x480. Unless you were using IE, of course. It gets an elastic design, since it's utterly incapable of understanding even the simplest CSS such as min-width or max-width. I didn't even want to bother with an IE style sheet, but a more pragmatic friend of mine persuaded me.
I think you confuse accessibility with availability in your last paragraph, though. If a site looks great for the 90% (or whatever) who run IE/Win, have JScript enabled, the latest Flash version installed, and use a 800x600 or better monitor, then that's wonderful. If, however, the content of that same site cannot be accessed at all by a blind person, then it is utterly inaccessible.
Let's compare that to a site whose content is accessible to "100%" (i.e. those who understand the language the site is written in), but looks boring. It may not attract as many customers (if it's commercial), but it's still more accessible.
I'm not saying that we should create boring sites just to be accessible, only that 95-99% isn't enough to be called 'fully accessible'. (I'm not counting those who can never access any site.) OTOH, 'fully accessible' is a very difficult state to attain. Very few designers/developers are capable of it, and I'm not one of them.
And very few of the sites out there that claim AAA compliance are, indeed, AAA compliant. Passing Bobby isn't enough, not even close.
Conclusion: I agree about being practical and reasonable. I disagree about calling it 'accessible'. We can make trade-offs, but we must be honest enough to admit that we're not fully accessible if we do.
Tommy has left the building
I agree with you that one has to be reasonable, especially when it comes to commercial sites or public interest sites (including government sites). I disagree slightly with your definition of accessibility as being based on statistics, though. Let's say, as you did, that 80+% run IE and 1-5% run at 640x480 or less. Naturally, one would make sure that the site works well in IE at 800x600 and above. Naturally. But disregarding the remaining percentage just isn't possible if one wants to claim to be accessible. The design doesn't have to be the same (or even present) for the minority users, but the content (i.e. information) must be available for "everyone". Now, as you see, I put "everyone" in quotes. That's because "everyone" is absolutely impossible to achieve. Even if you go to extreme lengths, such as having a culture-neutral images-only version for those who cannot digest textual content (severe dyslexics, illiterates, etc), there will always be some that cannot access it. Those without an Internet connection, for instance.
You're right, we mustn't let the 95-99% majority suffer. That's the tough part of web accessibility. We need to create sites that are attractive for the majority, while still being accessible for the minorities.
I repeat: I don't consider a horizontal scroll bar to be an accessibility problem, really. It's a usability issue. Still, it's something I try to avoid if possible. I don't think the scroll bars (I got four of them at some point) make your site inaccessible, just hard to use.
Regarding Bobby testing: I never bother. OK, it can tell you if you did something really stupid, but machine validation of accessibility can only go so far. It can never ascertain whether you've used the "clearest and simplest language appropriate for a site's content" for instance. Nor can it see if you have an accessible alternative to an inaccessive page. Unfortunately, there seems to be people who think that passing a Bobby test means that the page is fully accessible. Then they slap a AAA icon on their pages, which don't even reach level-A compliance.
I don't know why you got a scroll bar at 800x600 at my site. I don't get one even at 640x480. Unless you were using IE, of course. It gets an elastic design, since it's utterly incapable of understanding even the simplest CSS such as min-width or max-width. I didn't even want to bother with an IE style sheet, but a more pragmatic friend of mine persuaded me.
I think you confuse accessibility with availability in your last paragraph, though. If a site looks great for the 90% (or whatever) who run IE/Win, have JScript enabled, the latest Flash version installed, and use a 800x600 or better monitor, then that's wonderful. If, however, the content of that same site cannot be accessed at all by a blind person, then it is utterly inaccessible.
Let's compare that to a site whose content is accessible to "100%" (i.e. those who understand the language the site is written in), but looks boring. It may not attract as many customers (if it's commercial), but it's still more accessible.
I'm not saying that we should create boring sites just to be accessible, only that 95-99% isn't enough to be called 'fully accessible'. (I'm not counting those who can never access any site.) OTOH, 'fully accessible' is a very difficult state to attain. Very few designers/developers are capable of it, and I'm not one of them.
And very few of the sites out there that claim AAA compliance are, indeed, AAA compliant. Passing Bobby isn't enough, not even close.
Conclusion: I agree about being practical and reasonable. I disagree about calling it 'accessible'. We can make trade-offs, but we must be honest enough to admit that we're not fully accessible if we do.
Tommy has left the building


