How Many Disabled Users?

There is an article over at Practical Ecommerce titled Accessibility: How Many Disabled Web Users Are There? by Joe Dolson. It is refreshing to see more traditional sites dealing with accessibility, especially when it can so significantly affect their bottom line. As an indication that the author gets it:

I often hear business owners claim that their sites aren’t used by people with disabilities, so they don’t need to pay attention to web accessibility. But there’s no basis for such claims because the merchant can’t possibly know this information. The tracked profile of a user with a disability, via a typical analytics package, is identical to anybody else using that browser.

The author is smart enough to discard data that doesn’t necessarily impact web usage — such as leg amputations, for example. While presenting the information below, the author reminds us that the Baby Boomers are getting older, and crossing the 65-year-old age barrier (see below):

The most commonly discussed disabilities affecting website accessibility are sight and hearing impairments. These specific impairments encompass 6.8 percent of the population age 15 years and older — and climb to encompass 21.3 percent of the population when you look specifically at the population over 65, according to the 2005 report. Eight-point-two percent of this same population is listed as having difficulty grasping objects — which affects the use of a mouse.

A conservative estimate says 1 out of 10 of your users could have an impairment of some sort. For every day that passes, that’s another user who has aged or deteriorated in some way, making that number climb over time. That’s 15.5 million potential customers. Perhaps this is a better way to present the information to your ecommerce customers.

Follow-up Information

Just three days later the author posted a follow-up article on his own blog titled United States disability statistics: Measurement and sources. The author explains that while his official article still gets to the point about supporting disabled users, this post is intended to provide more detail on the numbers. The authors closing comments explain how the data is good enough for some general numbers, but lacks a little detail on specific issues:

In general, my assumption is that the data may include some individuals who struggle with reading due to dyslexia, dependent on the exact phrasing of the questions, but not all, and presumably includes no or very few individuals with color blindness.

The author (still Joe) is kind enough to provide links to the PDF versions of the U.S. Census Bureau reports he used as his data sources. Since I am also a fan of providing links to the raw data, here you go:


WebAIM Screen Reader User Survey Results

This article was originally posted at

WebAIM is a non-profit organization within the Center for Persons with Disabilities at Utah State University that focuses on accessible web content and technologies. WebAIM conducted a survey of the preferences of screen reader users back in December 2008, gathering a lot of interesting data about how users utilize assistive technologies (you can see the results of that survey at the WebAIM site).

WebAIM conducted another survey in October to track preferences of screen reader users. They received 665 responses to the survey consisting of a mix of disabled (90%) and abled users (10%). It’s not a truly scientific survey, but it provides some valuable insight into usage patterns and user expectations. Visit the WebAIM survey results page to get all the detail.


When asked to rate proficiency with a screen reader, those with a disability were almost 6 times more likely to report advanced proficiency. Less than 5% of all respondents claimed to be beginners. These numbers may be inflated simply because more advanced users might be more motivated to fill out this survey. 65% of all respondents claimed to have advanced Internet proficiency.



JAWS was the clear winner with users as the primary screen reader, holding 66% of the pie, with Window Eyes the next most popular option at 10%. Nearly half of the respondents use more than one screen reader. When asked about secondary screen readers, JAWS (75.2%) was still popular while Window Eyes (23.5%) slipped behind NVDA (25.6%) and barely beat out System Access or System Access To Go (22.3%). Most of the users are self-taught (72.9%) or informally taught (32.9%) as well as trained through a course (24.2%). Not surprisingly, users without disabilities where most likely to get a screen reader from an employer (43.5%) versus users with disabilities who bought the utilities for themselves (36.6%). Internet Explorer 6, 7 and 8 appear to top the chart for most-often-used browser (12.7%, 26.2%, 32.0%). Those without disabilities were more likely to use Firefox than those with disabilities (32% vs 17%), perhaps owing to the fact that many standards-based developers are interested in both Firefox and accessibility.


Respondents were asked to indicate how they would prefer an image of a smiling woman, used to convey a company is personable and friendly, be cited in its alt attribute. 57.1% preferred “Photo of smiling lady,” 20.2% preferred “Smiling lady,” 12.8% wanted a blank value (causing it to be ignored completely), and 9.9% wanted “Our company is personable and friendly.” Users without disabilities were 3 times more likely to state they they preferred the image be ignored altogether. WebAIM notes in this part of the survey that appropriate alternative text is one of the harder parts of developing a web page.

When asked about complex images (charts, diagrams, comics) users tended to prefer an option that placed the description on the page (a long alt or further down the page) instead of linking to another page with the description (such as by using the longdesc attribute).


Pie chart of JavaScript use.

Image from WebAIM Screen Reader User Survey Results

74.9% of users did not disable JavaScript (I use the negative because it reminds us that a decision must be made to disable JavaScript) and 14.7% didn’t know if JavaScript was enabled or not. That left 10.4% of respondents who actively disabled JavaScript in their screen readers.


Image from WebAIM Screen Reader User Survey Results

When asked how likely Flash is to be accessible to users, respondents tended toward somewhat unlikely or very unlikely (27.1%, 35.5%). While Flash can be made accessible, users are probably reporting issues because developers do not implement Flash accessibility features.


Pie chart of mobile screen reader use.

Image from WebAIM Screen Reader User Survey Results

Most surprising to me was that 53% of those with disabilities claim they use a screen reader on a mobile device. More proficient screen reader users were more likely to use a mobile screen reader. If developers already struggle with building sites for mobile devices or struggle with building sites to be accessible, this can seem like a difficult challenge for many. The survey doesn’t gather other information on mobile use, perhaps because they were surprised by its prevalence as well.


When asked about ARIA landmarks, 42.1% (240) of respondents claimed no knowledge of that functionality while 95 respondents didn’t even answer the question). Given that WAI-ARIA was introduced to address accessibility issues with dynamic web content for users with disabilities, it is a bit surprising that so many respondents are not familiar with the functionality. It may also be a compounded by the lack of developers implementing support for it.

Problematic Items

Most Problematic Items

Users were asked to select their first, second and third most problematic items from a list. Listed in order (most difficult/confusing first) they are:

  1. CAPTCHA – images presenting text used to verify that you are a human user
  2. The presence of inaccessible Flash content
  3. Links or buttons that do not make sense
  4. Images with missing or improper descriptions (alt text)
  5. Complex or difficult forms
  6. Lack of keyboard accessibility
  7. Screens or parts of screens that change unexpectedly
  8. Missing or improper headings
  9. Too many links or navigation items
  10. Complex data tables
  11. Lack of “skip to main content” or “skip navigation” links
  12. Inaccessible or missing search functionality

The following chart shows the weight of each:

Chart of most problematic issues.

Image from WebAIM Screen Reader User Survey Results

Least Problematic Items

WebAIM posits, and I agree, that the lack of skip links (links to allow users to skip the navigation and get directly to the meat of the page) is probably not much of an issue because users are used to working around the lack of them on most sites, coupled with use of heading elements to navigate within a page. The chart of results:

Chart of least problematic items.

Image from WebAIM Screen Reader User Survey Results

Social Media

Chart of frequently used social media tools.

Image from WebAIM Screen Reader User Survey Results

YouTube topped the list of most frequently used tools, beating out blogs, Facebook and Twitter. This is a bit surprising given the visual nature of YouTube. Overall, Twitter tended to be considered the most accessible, probably owing to its text-only nature and the number of Twitter clients that live outside the browser.

Finding Information

Users were asked how they go about finding information on a lengthy web page. 50.8% of users indicated they they use the page headings to navigate (really bolstering the argument of using proper headings in your content). 22.9% use the “find” feature of the browser, 16.1% navigate the links on the page, and 10.1% read through the page (and are apparently far more patient than I).

Overall Accessibility

Nearly half of the respondents feel that web accessibility has improved overall in the last year (46.3%), although those with disabilities were less positive about progress.

68.6% of respondents felt that more accessible web sites have a greater impact on accessibility improvements than improvements in assistive technology.

When asked for the primary reason that developers do not create accessible web sites, respondents tended toward lack of awareness (38.0%), lack of skills or knowledge (27.6%), fear that accessibility might impact the look or functionality (25.7%), and then lack of budget or resources (8.6%). Respondents without disabilities chose “Lack of knowledge” nearly twice as often as those with disabilities.


WebAIM makes the assertion that “there is no typical screen reader user” (emphasis theirs). Surprising to me are the numbers of users on mobile devices and using YouTube. I am not surprised that Flash is still an issue for users, although that speaks more to the developers implementing it than it does the technology. Proper use of page headings (h1 through h6) is certainly bolstered by how users navigate a page. The survey was silent on the use of forms, however, which could be very interesting when you consider that JAWS has a forms mode that essentially ignores other content on the page when invoked.

Internet Turns 40, Just Might Catch On

Media outlets seem to have settled on October 29 as the official birthday of the Internet. This date has been chosen because it’s the day that Leonard Kleinrock at the University of California-Los Angeles sent a message over a two-computer network (the other end being a computer at Stanford Research Institute) with Charley Kline manning the UCLA keyboard and Bill Duvall on the Stanford site. It’s worth noting that the computer carrying the first ever transmission on the Internet (“LOGIN”) crashed after only two letters (“LO”). I believe that Kline actually typed an “L” for the third letter (instead of “G”) and in a fit of future-sensing self-sacrifice, executed a core dump all over the floor.

Some may point out that on September 2, 1969, two computers were connected with a 15-foot cable and passed data back and forth. That was a precursor to the networking that happened a month later, but is not generally regarded as the birth of the Internet. Just as neither the first email message (1971) nor the first web browser (1993) are considered the birth of the Internet.

Given this historic day, there has been a lot of media coverage (some of it pretty bad, just like the average YouTube video) detailing some of the steps or milestones of the last 40 years. Some of the crunchy bits:

The opening image of this post is an Internet timeline (in extra large format so you can read it from the other room, or across the street) from Daily News LA article “How the Internet was born at UCLA.”

Videos and Audio Bits

The All Things Considered broadcast:

A somewhat technical perspective of the time leading up to and after the birth of the Internet:

A video from 1993 by the CBC covering the “growing phenomenon of Internet” (covering mostly just Usenet):

The Web

For those who don’t quite understand the relationship between the web and the Internet as a whole, the World Wide Web came much later. First as a proposal to CERN by Tim Berners-Lee in March of 1989 and then in the form of NCSA Mosaic in April of 1993 (yes, it was not the first web browser, but it was the first to get traction).

To qualify that a bit more, if anyone comes to you claiming 25 years of web experience (as one follower on Twitter recently did), you can send them away. The web is barely old enough to drive.

SEO as Snake Oil

Originally posted on October14, 2009 by Adrian Roselli, on his personal blog.

There are many on the web who will recognize the name Derek Powazek. He is the name behind old-school sites such as and (which has apparently been taken over by spam bots) and wrote a book about communities (Design for Community, which mentions me by name, which is awesome). I also had the pleasure to meet him at SXSW back in 2001 and even participate in his Fray Cafe. So when I saw his blog post on SEO that started off with this statement, I was pleased:

Search Engine Optimization is not a legitimate form of marketing. It should not be undertaken by people with brains or souls. If someone charges you for SEO, you have been conned.

What pleases me more is that it echoes a comment I made in my post Verified: Google Ignores Meta Keywords back in September:

Those of us trying to protect our clients from SEO/SEM snake-oil salesmen are happy to finally have an official statement from Google.

Now that I’ve tooted my horn and compared myself to someone considered one of the top 40 “industry influencers” of 2007 by Folio Magazine, let me get to my point. I’ve been working on the web since Hot Java was still a browser, was excited when the first beta of Netscape Navigator made its way to world, when Yahoo were a couple of guys in a dorm posting links, when my Jolt Cola web site was included in their index because I asked them to include it, and since then the way people find things on the web has changed dramatically. For the last decade or so the search engine has become more than a convenience, it’s a necessary feature of the web, without which we’d be stuck wandering billions of terrible pages of things we don’t want to see (many thousand fewer of those pages once GeoCities finally closes down). Because of this, getting your site into the search engine in the top spot has become the holy grail of online marketing, one that far too many people are happy to exploit as an opportunity.

Derek makes two key points in his article

  1. The good advice is obvious, the rest doesn’t work.
  2. SEO is poisoning the web.

He supports the first point by noting that formatting, structure, summaries, quality links and so on have worked since the beginning and will continue to work. There’s no magic there. It’s free to read anywhere on the web. For his second point he references all the Google bombing tactics that are employed by bots to spam blogs, comment areas, twitter accounts, parked domains, etc. as well as questionable tactics that exploit loopholes (albeit temporary ones) in a search engine’s ranking algorithm.

As of now the article has 180 comments, many of which are optimizers who take umbrage with the blanket statement that SEO is the work of the soulless foulspawn and their dark arts (my words, but I think I summarize his sentiment well enough). After receiving so many comments Derek added a post yesterday, his SEO FAQ, responding to a generalization of many of the questions and comments. He also offers some suggestions, including this one targeted at clients (I just took the first part):

If someone approaches you about optimizing your search engine placement, they’re running a scam. Ignore them.

Having said something similar in the past to clients, this is normally where I’d segue into a discussion with my clients about how I’ve worked hard to ensure Algonquin Studios‘ content management system, QuantumCMS, adheres to best practices and provides many ways to get quality content into the pages, links, titles, page addresses, meta information (after I tell them Google doesn’t use meta data for ranking but they insist because they’ve been conditioned to think that way) and so on. This is also the part where I remind clients that their help is needed to write that copy, interact with users, customers, partners, industry organizations, etc. to generate quality relationships and references (often in the form of links), and to plan to spend time working on this regularly to keep it fresh and relevant.

I look forward to the time when I won’t be spending chunks of my day clearing spambots from my QuantumCMS Community forum, batting down spam email about submissions to 300+ search engines, ignoring bit.lys in unsolicited Twitter @ responses, and generally fighting the after effects of all the black hat SEO enabling we’ve allowed for years.

Corporate Social Media Policies

Chris Boudreaux is the author of an upcoming book titled Social Media Governance. His goal with the book is to help “companies clarify and manage social media priorities, coordinate shared investments (such as information security and compliance), and define meaningful metrics to hold stakeholders accountable for performance of social media and social application investments.”

Mr. Boudreaux has created an accompanying web site that contains a database of links to social media policies of over 80 organizations. The list is broken down by industry: Agencies: Advertising, PR, Marketing; Business Products or Services; Consumer Products or Services; Healthcare; Government or Non-Profit; General Guidelines and Templates.

Sometimes a company wants to build a social media strategy, sometimes they want to address how their staff reference the organization in social media outlets, and sometimes an organization is dragged kicking and screaming into social media to address what others say about them in a social forum. As more and more organizations realize the potential of social media, having access to documents like these can save valuable time path finding and stumbling. This resource can allow organizations to track down policies used by others in their industry without the need to make it up as they go.

There are some interesting examples within the pages, such as this one from Wal-Mart’s Twitter External Discussion Guidelines, written by someone who seemingly spends a good deal of time plugged into Internet memes:

We won’t reply to off topic @replies. Personal attacks and foul language = FAIL. Adding to the discussion = WIN.

The U.S. Air Force has a flowchart for its public affairs representatives to use should they discover a blog post about the U.S. Air Force (click the image for a larger view):

Image of Air Force social media policy flowchart.

Some of the policies include what would like to think is common sense, but which all too often is not, such as this sample from ESPN: “If you wouldn’t say it on the air or write it in your column, don’t tweet it.”

The Associated Press (AP) has a listing in the database, but the address doesn’t work any longer. Back in June the AP came under attack for policies that seemed a little too aggressive, suggesting that AP employees should delete comments an employee’s friends might make about the AP on an employee’s Facebook wall. The example (emphasis added):

Q. Anything specific to Facebook?

It’s a good idea to monitor your profile page to make sure material posted by others doesn’t violate AP standards; any such material should be deleted. Also, managers should not issue friend requests to subordinates, since that could be awkward for employees. It’s fine if employees want to initiate the friend process with their bosses.

The NFL and Chad Ochocinco have been locked in a struggle that culminated with the NFL posting its own rules essentially saying that play-by-play tweeting was not allowed, bypassing a plan by Ochocinco to signal friends to tweet pre-planned updates during the game. Ochocinco twote that he would essentially take his ball and go home, telling his followers that he was going to delete his account. He hasn’t done it.

If you’re an organization considering your own social media policy, the samples are very useful. The following articles might provide more help in fleshing it out and customizing it to your needs:

If you do come up with your own, you can add it the policy database. At least that’s what the form on the site claims.

Verified: Google Ignores Meta Keywords

In a post on the Google Webmaster Central blog today (Google does not use the keywords meta tag in web ranking), Google has clarified its policy on meta tags and page rank. Those of us trying to protect our clients from SEO/SEM snake-oil salesmen are happy to finally have an official statement from Google. In short, here it is:

  • Google does not use meta keywords in its web search ranking and “has ignored the keywords meta tag for years.”
  • Google sometimes uses the description meta tag as the abstract for search results, but not for web search ranking.

There are many other variants of the meta tag, including some unique to Google. See the Google Webmaster help page discussing meta tags for a list of values Google supports (pay attention to the robots meta tag). Watch the video below for an explanation from a Google representative and his Threadless t-shirt.

Quick Color Class

This article originally appeared in the December, 2002 issue of DisplaySearch Monitor.

One of the nice things about building for the web is that you don’t have to worry about paying for your color as you would in print. You have access to nearly every color under the sun (pun intended) when building your web project, but that doesn’t mean you should use every color.

Because it is often necessary to reproduce the colors in a logo or other identity materials when building a web page, it helps to know what to expect from the displays that will actually see the page you create. Obviously you can control how well your system is calibrated, but you have no such control over the systems of your users or even how well they perceive color.

This article addresses both the technical limitations and usability considerations of color on the web. It is by no means exhaustive, but it should get you thinking about appropriate color use when bringing your brand to the web.

Technical Issues

The first thing that we need to consider is that despite all the colors that could be available to us, not all systems can display the colors we may have available on our systems. There may still be 16-color systems out there, and there are probably more than a few 256-color (8-bit) systems. While those numbers are dwindling, many sites report that 8-bit systems make up 3% to even 10% of users (Real-World Browser Size Stats, Part II, W3 Schools Browser Stats). About half of the users on the web are reported to have their displays set to 16-bit (thousands of colors), with the rest of the users set to 24-bit or 32-bit (both of which show millions of colors and are referred to as “true-color” systems).

What does all this mean, you ask? Ideally you’d like your color palette to be based on the colors your users can see. And ideally, you’d like those colors to be generally true to your intentions. A wonderful gradient between colors may collapse to bands of speckled blotches when viewed on a lower-bit system, for example. This is because the much larger sample of colors in the image is reduced to a sample of only 256 colors, requiring “dithering” in order to mimic the effect of a soft gradient. Dithering is essentially placing a number of differently colored pixels near one another to simulate a color otherwise not in the palette.

The sample image below shows a sample gradient on the right, with its dithered equivalent on the left. A chunk of that image has been enlarged below to show the dithering in detail.

Detail of the dither:

Some of you may be familiar with the web-safe palette, a set of 216 colors that were found to be universal between Macintoshes and Microsoft Windows systems set to display 256 colors (8-bit). This color palette became one of those oft-cited requirements for web site development with which many designers were forced to wrangle. Sadly, it didn’t stop there. When 16-bit displays are factored into the mix, it turns out they don’t honor that “safe” palette, but instead only a subset.

In the end, the “even more web-safe palette” (Death of the Websafe Color Palette?) was reduced to 22 colors and, as you can see, without a lot of variance aside from light green, light blue, and yellow:

Luckily, you’re reading this in a time when those lower-bit systems are becoming more and more rare, and designers don’t worry as much about 8-bit and 16-bit systems, but instead about 16-bit and 24-bit systems. At that point, since 24-bit systems can display all the colors a 16-bit system can, designers needn’t worry as much about colors between their designated low-end systems and the high-end systems. Granted, there will still always be situations where you want to design for an audience with less powerful computers that can’t display all these colors, but knowing your audience in advance will answer that question before you even start.

Despite this potential relief from the 8-bit systems, don’t forget that when colors dither, as we discussed above, they can sometimes be shifted to colors that may not work well with other colors on the page, even causing some colors to nearly disappear when seen next to one another. It’s at least worth resetting your system to a lower bit-depth to test this factor so those users aren’t completely shut out.

What other factors can affect the colors your users see? You’d be surprised. Given all the different ways people can surf web sites, you can already see the variables starting to come into play. Is the user on a color PDA? Surfing on his or her television? Using a flat panel display or an old CRT? Next, who’s to say the user has good lighting, or that the display is calibrated in any way? A simple glare filter will guarantee the colors will be different. Even the color of the walls around a display will affect how the colors look.

Ultimately, your colors won’t look the same across media, so be certain you know that going in. Your marketing team may insist on a specific Pantone color or CMYK value, but that’s just not possible. Partly for the reasons stated above, and partly due to the inability of your monitor to display all the colors that can be made by inks. This doesn’t mean there’s something wrong with your monitor, just that it’s apples and oranges, one doesn’t show all the colors of the other. You can’t expect perfect color matches between your print materials, your web site, and your shirt.

Usability Issues

Now that you’ve seen that you cannot guarantee that colors will look precisely the way you want them or even perfectly match your letterhead, let’s pretend that everyone is going to see generally the same color. Now we have to consider how those colors are perceived.

There’s the issue of colorblind users to consider. With roughly 8% of the male audience colorblind to some degree (Colors For The Colorblind), relying too much on color to convey a message, or even a function of the site, can sometimes be problematic. After all, if the only way you inform a user that a field in an online shopping cart is required to be filled out is by coloring it red, imagine how those users who can’t see red may fee. They may get stuck on the page, unable to advance because they don’t see the warning or error. The image below shows the concept greatly simplified — as if the user could see neither red nor green, but only had brightness to go on. The top half is in color, the bottom half has had its color removed.

Consider that there are probably more users who have difficulty distinguishing the color red (6% of Caucasian males) than there are computers set to display at 256 colors (3% based on aggregate site logs). One of those statistics is unlikely to shrink.

On top of considering the hue of a color, you need to consider its contrast when put against other colors. Green text at about 50% brightness set on a 50% grey background may be completely invisible to some users — and not just colorblind users. As color acuity, and general visual acuity, falls off with age, too little contrast can be a major hurdle to users. Below is a sample of that effect.

All in all, you want to be certain that your colors play well together, that the site doesn’t rely on them to function, and that no users will be left stranded as a result of your color choices.


From here, I’d normally start to go over the factors behind choosing colors and how they play well together, but we’ll save that for my next article. In the meantime, consider the pages you already have out there and whether or not they degrade well for users on older or less powerful systems, and whether or not they are usable for users with less color acuity than you.

Style Switcher in ASP

This article originally appeared at

As more and more sites move away from embedded style tags (<font> tags, for example), the benefits of CSS to customize a user’s visit has become all the rage. It’s hard to find a site bragging about its use of XHTML and CSS for layout that doesn’t have a style switcher of some sort stuffed into a corner like some unruly hamster.

Some of the sites that heavily advocate using CSS for all presentation even provide some handy scripts to allow your users to switch between styles. A List Apart featured two such articles; Alternative Style: Working with Alternate Style Sheets and A Backward Compatible Style Sheet Switcher.

Unfortunately, both of these tutorials require client-side scripting in order to work. No matter how backward-compatible or user-friendly the techniques used, if you have JavaScript disabled, it’s a no-go. Granted, if you don’t have access to a server-side scripting language, its cut-n-paste ease is undeniable, but to both handle for users without JavaScript enabled (but who can still support CSS), or even later versions of browsers where it’s all too possible for JavaScript support may get wonky, I’ve created a very simple server-side method to switch styles.

The Concept

The concept is very simple, really. A user comes to the site and he or she sees the default style that you’ve specified. If, however, the user has been to the site before and chose a different style, you want the site to accept it. Short of storing a user profile for every user and dealing with the hassle of letting users log in to see custom styles, the next approach would be to simply store the preferences within a cookie. So, if there’s a cookie with a style set, the site uses it, otherwise it uses the default. Simple.

How you choose to display these options, however, should be up to you. The script samples given will allow you to use form elements (radio buttons or a select menu, for example) or simple hyperlinks.

Code Samples

Those of you familiar with my font sizing article from way back in 1999, Give the User Control Over Your Fonts, may recall that I used a set of three buttons to allow a user to cycle through three stylesheets with different type sizes for each selection. Well, we’re just going to repurpose that code. Back then, we talked about browser detection so you could display the option only to those who could use it. I’m skipping that for now, since your average site doesn’t care too much, and there are many other and better scripts out there that you can customize to do your browser detection for you.

This block of code first checks to see if a style has been selected by the user, and if not, it checks to see if there is a cookie with the CSS style. Failing both of those it writes the default value to the cookie and then to the <link> element that calls the CSS file. So, on a user’s first visit, it will still show the default style. If the user has cookies disabled, he or she will simply see the default style regardless of what he or she selects, although you can add a cookie detection script in here if you wish to hide the option. Make sure this sits at the top of your document, before any HTML/XHTML is written to the browser. Note that I’ve called the cookie cCSS, which ideally will demonstrate to users with cookies enabled that, with the associated value, the cookie is nothing more than a harmless style preference.

I’d recommend you make the below chunk of script into an include so you can re-use it all over your site.


'# styleswitcher.asp               Version 1.0                                #
'# Copyright 2000 Adrian Roselli                           #
'# Created 26/5/2002               Last Modified 26/5/2002                    #
'# COPYRIGHT NOTICE                                                           #
'# Copyright [and -left] 2002 Adrian Roselli  All Rights Reserved except as   #
'# provided below.                                                            #
'#                                                                            #
'# styleswitcher.asp may be used and modified free of charge by anyone so     #
'# long as this copyright notice and the comments above remain intact. By     #
'# using this code you agree to indemnify Adrian Roselli from any liability   #
'# that might arise from it's use.                                            #
'#                                                                            #
'# This script is released under the GPL.                                     #
'# Selling the code for this program or any derivative work is expressly      #
'# forbidden. A full copy of the GPL can be found in the Code section of      #
'# In all cases copyright and this header must remain       #
'# intact.                                                                    #

'# Set the name of the current script to variable so you
'# can use this script on any page of your site
strScriptName = Request.ServerVariables("SCRIPT_NAME")

'# First check the cookie value to see if anything has
'# already been selected.
'# Then, request the style from the entire Request collection,
'# so it could come from a form submission, or an appended
'# URL.
cCSS = Request.Cookies("cCSS")
rCSS = Request("rCSS")

'# If there is a style, write it to the cookie with any
'# arbitrary date in the future so it sticks, and set the
'# value for fCSS, our final variable from all this.

	'# Set the cookie to what came in from the request.
	Response.Cookies("cCSS") = rCSS
	Response.Cookies("cCSS").expires = #10/10/2003#

	'# Set the final value equal to what came in from
	'# the request collection.
	fCSS = rCSS

'# If there is no style selected by the user...

	'# ...and the cookie is blank, write the default.
	IF cCSS = "" THEN
		Response.Cookies("cCSS") = "default"
		cCSS = "default"

	'# Now set the final variable to the default value
	'# we've just set above.
	fCSS = cCSS

	'# Finally, set the rCSS value in case you have a form
	'# that relies on it to draw the selected value.
	rCSS = fCSS


Now that you’ve created the value for the stylesheet to display, you might as well have the page select the right one. This works best if the value you used in your form or hyperlink is the filename, sans the extension, of the CSS file you wish to call:

<link rel="stylesheet" href="/<% = fCSS %>.css" media="all" type="text/css"/>

Now, further down the page you actually want to give the user a means by which to select a style. The examples I’ll show are a select menu, a set of radio buttons, and some text links. The text links could easily be modified to become images, so I’ll leave out images for the scope of this example.

Select Menu

Unfortunately, the select menu requires a click to see all the options, and then a click to select one. It does not, however, fire without a submission click, which alleviates the hassle of users missing their target, although it does bring it up to three clicks. You can always add an onchange if you so desire, however.

<form action="<% = strScriptName %>">
<p><strong>Got CSS?</strong></p>
	<select name="rCSS" id="rCSS">
		<option value="default"<% IF rCSS = "" OR rCSS = "default" THEN %> selected="selected"<% END IF %>>Default</option>
		<option value="heaven"<% IF rCSS = "heaven" THEN %> selected="selected"<% END IF %>>Heaven</option>
		<option value="hell"<% IF rCSS = "hell" THEN %> selected="selected"<% END IF %>>Hell</option>
		<option value="evolt"<% IF rCSS = "evolt" THEN %> selected="selected"<% END IF %>></option>
		<option value="stealth"<% IF rCSS = "stealth" THEN %> selected="selected"<% END IF %>>Stealth</option>
		<option value="none"<% IF rCSS = "none" THEN %> selected="selected"<% END IF %>>None</option>
	<input type="submit" name="" value="Style Me!"/>

Which will look like this:

Got CSS?


Radio Buttons

This option takes up more space on the page, but presents all the options to the user at once. It’s a two-clicker to get a new style in place, and as above, doesn’t rely on JavaScript to submit the form, so the user must click the submit button. Make sure you keep the <label> elements in place to provide a larger hit state for those browsers that support it.

<form action="<% = strScriptName %>">
<strong>Got CSS?</strong><br/>
	<input type="radio" name="rCSS" id="rCSS_default" value="default"<% IF rCSS = "" OR rCSS = "default" THEN %> checked="checked"<% END IF %> /><label for="rCSS_default">Default</label><br/>
	<input type="radio" name="rCSS" id="rCSS_heaven" value="heaven"<% IF rCSS = "heaven" THEN %> checked="checked"<% END IF %> /><label for="rCSS_heaven">Heaven</label><br/>
	<input type="radio" name="rCSS" id="rCSS_hell" value="hell"<% IF rCSS = "hell" THEN %> checked="checked"<% END IF %> /><label for="rCSS_hell">Hell</label><br/>
	<input type="radio" name="rCSS" id="rCSS_evolt" value="evolt"<% IF rCSS = "evolt" THEN %> checked="checked"<% END IF %> /><label for="rCSS_evolt"></label><br/>
	<input type="radio" name="rCSS" id="rCSS_stealth" value="stealth"<% IF rCSS = "stealth" THEN %> checked="checked"<% END IF %> /><label for="rCSS_stealth">Stealth</label><br/>
	<input type="radio" name="rCSS" id="rCSS_none" value="none"<% IF rCSS = "none" THEN %> checked="checked"<% END IF %> /><label for="rCSS_none">None</label><br/>
	<input type="submit" name="" value="Style Me!"/>

Which will look like this:

Got CSS?






Good Ol’ Fashioned Hyperlinks

Sometimes a form is just a waste of clicks and totally unnecessary. In those circumstances, you want your script to support hyperlinks, and you want it to show the selected style as well. Here is some very basic code to handle that. I’ve set the script to insert an inline style of bold for the selected sylesheet. You can modify that or create a more robust method to style the selected option.

<strong>Got CSS?</strong>

 <li><a href="<% = strScriptName %>?rCSS=default"<% IF rCSS = "" OR rCSS = "default" THEN %> style="font-weight:bold;"<% END IF %>>Default</a></li>
 <li><a href="<% = strScriptName %>?rCSS=heaven"<% IF rCSS = "heaven" THEN %> style="font-weight:bold;"<% END IF %>>Heaven</a></li>
 <li><a href="<% = strScriptName %>?rCSS=hell"<% IF rCSS = "hell" THEN %> style="font-weight:bold;"<% END IF %>>Hell</a></li>
 <li><a href="<% = strScriptName %>?rCSS=evolt"<% IF rCSS = "evolt" THEN %> style="font-weight:bold;"<% END IF %>></a></li>
 <li><a href="<% = strScriptName %>?rCSS=stealth"<% IF rCSS = "stealth" THEN %> style="font-weight:bold;"<% END IF %>>Stealth</a></li>
 <li><a href="<% = strScriptName %>?rCSS=none"<% IF rCSS = "none" THEN %> style="font-weight:bold;"<% END IF %>>None</a></li>

Which will look like this:

Got CSS?

You can, of course, use images in place of plain-text hyperlinks. I don’t primarily because my styles vary so much in color that no single set of images would work — I’d have to create a new set of images for each style.


You can modify this script to support one style switcher that only changes colors, and another that changes the layout of the page, as well. Or a third one that resizes type, and on and on. Ultimately, whatever you make should take into account how the user will interact with the page and allow a quick and easy way to see and make selections.

A Merger of Content Management and Localization Workflow

The following is an excerpt and link to a PDF of an article appearing in Volume 13 Issue 4 of Multilingual Computing & Technology magazine.

In December 2001, Algonquin Studios and E-Merge Strategies completed a merger of two different companies with different products and targeted markets. Algonquin Studios had developed the QuantumCMS content management system, which was designed to support multiple Web sites on one platform. E-Merge Strategies had released a localization workflow software called Transmerge in early 2001. Once the paperwork was complete, the two companies had to bring together their different business models as well as their different software products. The participants discovered that the merger of the two systems paralleled what is going on in the overall Web development market: content management and localization are being intertwined as a total multilingual content management solution.

The rest of the article can be viewed by downloading the Adobe Acrobat file. The file is 695kb.

The Wrong Way to Use CSS in Page Layouts

This article originally appeared at

Lately I’ve come across an ever-increasing amount of web sites that use absolute positioning with Cascading Style Sheets (CSS) to achieve some very specific layouts.

While this has been going on essentially since Macromedia Dreamweaver was released, allowing anybody comfortable with a WYSIWYG web layout package to build CSS-laden sites, recent pushes for accessibility and standards compliance in HTML has made CSS the new buzzword of the wanna-be-elite developer.

Unfortunately, many people are still using WYSIWYG packages to do their web development, and many of them are trying a table-free approach in their attempts to ride the wave of the CSS flood. What some of these developers tend to forget is that pixel-precise layouts are anything but, especially when you consider all the custom settings users may have on their systems.

For those who have read my article on liquid web design (“Liquid Design for the Web,” DisplaySearch Monitor, August 30, 2001; also available here on, you may be familiar with my simple mantra of building for the user and allowing the layout and design of the web page to adapt to nearly any conditions that users may throw your way. Lately, however, frustrated laptop users have been directed my way (partly due to my article) because sites they visit, or worse, sites for which they’ve paid, don’t display properly on their systems.

At first, the symptoms were confusing. Blocks of text supposedly sat on top of other blocks of text, copy was unreadable as words stacked themselves atop one another, and sometimes text seemed to appear out of order. It took a little while to coax a screen capture out of anyone, but eventually I got one. A sample of what I saw is included in Figures 1 and 2. Please note that I’ve butchered a page on my own site as an example, since I think the affected parties would rather not have their sites shown.

Figure 1 Figure 1: This screen capture shows just a minor overlap, but enough that some of the text is unreadable.

Figure 2 Figure 2: This screen capture shows a more severe example of the reported issues. Text is more illegible, and it seems impossible to determine what text goes where.

So how did this happen?

In each of these cases, a developer using a WYSIWYG editor was the culprit. Having spent many of my years as a web developer cleaning code spit out by these editors, I’ve gotten used to recognizing much of the specific syntax and style that they use. I recognized most of these offenders as Macromedia Dreamweaver. Generally regarded as one of the better editors on the market, and deservedly so, it offers the ability for developers to create table-free layouts thanks to CSS positioning syntax. Developers who wanted to claim they were ditching tabled layouts for CSS-only layouts, something that organizations such as the Web Standards Project (WaSP) have been pushing for some time, could now do just that without having to learn a lick of CSS.

Unfortunately, Dreamweaver’s approach to layouts powered by CSS is anything but ideal. It eschews structural and semantic HTML elements in favor of the most basic elements, the ones that imply nothing but act simply as containers — <div>s. Instead of wrapping headlines in headline tags (<h1> through <h6>) or blocks of text in paragraph tags (<p>), everything gets wrapped in a <div>, every paragraph, every headline, even every table. This can be overridden, and there are many talented developers who do just that, but they aren’t the ones creating these problem pages.

Once a developer starts dragging paragraphs around the screen, each one is assigned an absolute x and y coordinate that it must occupy, as opposed to simply flowing one after another as in a word processor. And developers did just that, they dragged every block of text to just where they wanted it. With the WYSIWYG interface hiding the underlying code, these developers never saw the coordinate being assigned to each <div>, let alone the fact that each <div> was also assigned an absolute height and width, regardless of how much content it held. Figure 3 shows what the developer would have seen, a simple layout with paragraphs of copy flowing one after another.

It’s worth noting that I have a bit of a bias against WYSIWYG editors, something you can read more about in the article “To Hell With Bad Editors“.

Figure 3 Figure 3: The developer sees nothing wrong. After all, he or she is developing on his or her own system, so it should look ideal there.

What made it break?

One problem with laying out blocks of text in very specific positions on the screen is that it doesn’t take into account users who have their font sizes enlarged for any reason. It also doesn’t take into account users on flat panel displays who often have the display set to something other than 72 or 96 pixels-per-inch (ppi). And it seemed there were enough of both of these kinds of users that the calls came in.

Blocks of text ended up being larger than accounted for by the designers for these users. So while the second paragraph may have been placed 175 pixels from the top of the page, at higher resolutions or larger font sizes, the end of the paragraph above it extended below that 175 pixel mark, causing the text to overlap. Of course, this was compounded as the page progressed, and sometimes a third paragraph would start before the first one had ended.

All three of the above images are screen captures from Netscape 6.02 on Windows 2000. The default size for text in Netscape 6 is 16 pixels at 96ppi. Figure 3 shows the default setting the developer would have used. Figure 1 shows how that same page looks if the default font size is set to 18 pixels, and Figure 2 shows it set to 20 pixels. If the user had extremely good eyesight and set the font sizes to 12 pixels (lower than the developer’s settings), there would be very large gaps between the blocks of text.

Those users on laptops, for example, would see similar results if their display settings, not their browser settings, were modified. During more testing, general users of flat panel displays experienced these problems as well, owing to their tendency to run their displays at resolutions higher than 72 ppi — often 100 ppi, and even a few at 140 ppi for the group used for testing. These users were initially told by developers that the users simply had their font sizes set too large. This is regardless of the fact that if the developers were correct, users did that so they could actually read the text. And so users correctly responded that, for the most part, their font settings were at the default.

It occurred to some of the developers that people might come to the sites with larger fonts, but it was generally decided that these users could simply make their text smaller to see the page. Some of those developers, however, built their pages with type size units (pixels or points, for example) that could not be resized by the browser. It never occurred to any of the developers, however, that some users might be running at different pixel densities. So when developers had ordered their clients and their users to simply resize their fonts, and it didn’t work, they were stumped. They hadn’t gotten under the hood to see what was wrong with the code.

How did you fix this?

Correcting this problem was embarrassingly simple. By opening the pages in a plain text editor, I could immediately see the offending code. It was just a matter of replacing every positioned <div> with a more semantically correct <p> tag for paragraphs, and <h1><h6> tags for headings. With the removal of all positioning, the page would flow well for any user, regardless of their browser, screen settings, or font size settings. Clearly there could be exceptions, but none were encountered.

The solution was simply a case of under-engineering. Removing all the widgets resulted in an eminently usable page.

How can I tell if my site is broken?

Well, one of the simpler ways is to change your font sizes in your favorite browser. A slightly more complex method involves changing your display settings to something significantly higher than 96 ppi.

The simplest way, however, is to look at the code. It’s one thing to absolutely position some elements on the page, such as logos, navigation, or other design elements, but it’s another thing to do that with every paragraph of copy. If, in the source code, every paragraph is wrapped in a tag like the one below, you may want to run the other tests I mention above:

<div style="position:absolute;left:20px; top:175px; width:500px; height:50px; z-index:2">

The statement "position:absolute" is the first sign of trouble. The assignment of pixel values to "left" and "top" means the block is positioned a specific distance from the top left corner of the window. While a "width" attribute might not be bad, a "height" attribute could be an issue as well if the code is also set to hide text that doesn’t fit within the specified dimensions (via a "clipping" attribute).

Compounded errors

Not directly related to this, but somewhat ironic given the attempts by these designers to make more accessible pages by using CSS, was how the pages read to screen readers. Many of the developers had entered text a paragraph at a time, and not in order. When the page itself was seen by screen readers, the paragraphs were all out of order in the code, making for a very confusing page. But the developers couldn’t see this problem because every block of copy was placed on the page visually, without regard for the code beneath. This distance from the code ended up creating far more problems than intended.


Clearly this article addresses some very specific cases that don’t pop up too often, but they’ve popped up enough, and with increasing frequency, that it’s worth watching out for them as a developer, user, or a buyer of web development. Web pages are anything but static, let the user push them around and you’ll be ahead of the game.