That question is hot on the mailing list run by the Guild of Accessible Web Designers (GAWDS) right now. Specifically Accessites has been called on to explain why it is has one submission criterion demanding support for an 800×600 monitor resolution — meaning that it must be viewable without side-scrolling. Apparently more than a handful of developers at GAWDS feel that 800×600 support is a bit out-dated and no longer needed as it once was. I’ll answer this, not for Accessites, but rather for myself. I’ll explain why I feel it’s important to support that smaller resolution — or maybe I should say window size, since not everyone computes or browses with their windows maximized.
My wife uses a 15" workstation monitor set to an 800×600 display resolution. She’s running Windows XP and the native resolution was set to 1024×768 (that’s what I use), but she asked me to change it. I asked her why and she replied that
it makes everything bigger. Her vision isn’t that great so everything being bigger is helpful to her. She’s not a computer guru, and frankly I was surprised she knew this trick and requested it — even though she had no idea how to make it so. My 19-year-old daughter also uses this resolution. Her vision is sharp, but she says she likes it that way, everything is bigger. Each to their own.
It’s personal, and this is a great reason to apply it to my sites and hope that others do too, for the sake of some of my family members, but this is hardly a reason to write about it and suggest others adopt (or don’t forgo) that type of support. I can certainly empathize with those who object and want to put it all behind them — it’s like having to support some crappy old browser. Please, put us out of our misery. It’s not always easy to work with such a small resolution when so much more space is commonly available.
I generally make some sites have a fixed-width layout, like this one, while others are liquid or fluid, like my hosting site. My fixed-width sites are pretty easy to make while providing support for 800×600; I just set their width to no greater than 760 pixel wide unless elements are allowed to properly overlap. The liquid layouts are a bit trickier if I want them to look good in a range of 800 to 1280 pixels without breaking or becoming congested.
Mitigating horizontal scroll bars, maintaining readable line-lengths (<80 characters), and other considerations all come into play. These are definite and often aggravation-inducing challenges, then add cross-browser compatibility to the mix, and the reason why a developer would want to avoid these hassles becomes abundantly clear. I truly understand. After all, besides my wife and daughter, who the hell uses an 800×600 resolution in these wide-web days?
Okay. That’s a fair question. Who does use that resolution? Well, I don’t know. I don’t monitor that, though some do and can offer statistics. According to the W3Schools 800×600 accounts for 8% as of January, 2008. Wikipedia agrees. And so does The Counter. It stands to reason that these aren’t independent studies but rather just recycled figures. Can these stats be relied on? I doubt it. Stats only show a cross-section and can be skewed greatly if the test group isn’t a good representative of the whole. Who came up with these numbers originally? They were probably obtained via a passive script during a set period of time involving X-number of typical sites with typical visitors. Or should be. This isn’t the case, though, as Wikipedia disclaims:
These statistics were gathered from visitors to a website dedicated to web technologies, so there may be an over-representation of both higher resolution monitors and lower resolution handheld devices. — Wikipedia
In other words this 8% may be meaningless. Stats are often lacking in details, completely missing whole groups during sampling. The general unreliability of stats is well-known (no, I don’t have stats to back this up). In other words you shouldn’t rely on stats. I find common sense and sometimes erring on the side of caution is best. It is stats that tell me that hardly anyone comes to this site using Internet Explorer (IE), let alone IE version 6. About 30% of the people who flock to my company’s site, though, still use it (over 51% use IE versions). I guess I’ll have to support IE, including version 6, for a while since the bigger number is probably more accurate to what’s typical.
I don’t want to be negative, though. Let’s say for the sake of argument that the 8% is dead nuts, balls-on accurate. The pollsters used unerring methods, scoured all global locales, and accounted for those using a reduced window size, not just a monitor size. Let’s say that after all that the number is still 8%. Then 8% it is.
Is 8% Insignificant?
If we were to put this into business terms losing 8% of your customers could be catastrophic and you’d be scared to not provide support, but it’s not like that. This isn’t even a real accessibility issue since the content is still accessible (just inconveniently presented). But a user’s convenience counts, right? Call it usability.
Fortunately, offering support is easy.
Have Your Cake…
As developers we should create a primary style sheet, a print style sheet if the content might be printed, and a handheld style sheet (support for palm-top displays shouldn’t be confused with small scale desktop and laptop displays, it’s another subject altogether). I say this primary style sheet should support users who prefer 800×600 resolutions or surf in smaller windows. And while this can be challenging, it’s not the end of the world. A well-crafted liquid, adaptable, layout can solve the issue. And offering a clean, uncluttered 760 pixel fixed-width resolution can also serve users well. Yes, some with wide displays will have lots of wasted area, but they can’t see it all at the same time anyway so I don’t see that as a legitimate issue. I’d rather offer narrow than too wide.
There is also the option of offering a selectable alternative style sheet featuring support for 800×600 users. There are a few style changing scripts out there that can make this an easy alternative if you simply must pack ten-pounds of stuff in each of your five-pound, four column web pages. If you want to take that route, I offer such a script, as does Roger Johansson, and SitePoint and A List Apart offer them as well. Use one of those and keep everyone happy.
Turnabout is Fair Play
With these options, in this day and age of essential graphics and Web 2.0 scripts, it seems offering 800×600 support pales in a complexity comparison. I will continue to offer support for those who choose that window size or resolution, and you will do what you want to do or what you feel is right and justified in your eyes. I have tried my best to answer the question asked of Accessites, from my own standpoint as a developer (I guess we could say it is unofficially Accessites’ response as well). Now, since turnabout is fair play, and since there seems to be an unusual amount of resistance to offering 800×600 support, I will ask you, why not? Why shouldn’t developers support 800×600? What reason or reasons do you find most compelling?