evolt.org Workers of the Web, Evolt!

Accessibility and Usability are words you hear a lot more these days than let's say a year ago. One reason is that companies and developers realise that the hype about having a flashy web site is slowly ebbing down. Not too many people are impressed any longer by designs and navigations that engulf you completely - they start looking for the content and the services you offer instead.

Another thing is the legal Sword of Damocles above the our heads - Are we OK with our web site as it is or is there a chance we will be sued if we are not accessible?

Guess what, that is not the point.

It is frustrating how many times you need to answer questions like:

• Do we use accessibility on project XYZ?
• Can I tell the client we are A(or AA or AAA or 508) compliant?
• Client XYZ wants a flash page, that's not accessible, right?
• Can we tell the client that the page is 80% WAI A compliant? (What, like a wheelchair ramp with "only" three steps in it?)

Accessibility is mainly about one thing: Learning to let go.

Working in limbo

For years we have been misusing the web - it is not a print canvas on steroids, and it is not a film reel either. It is a vast, complex system of connected computers, and each of them has a different user with different abilities and different technology.

Realising this makes it rather easy for us to rationalise the following:

We cannot control the experience of the user. We can try, but we can never be sure.

This makes it rather awkward to sell products and services for the web - no-one likes to admit that what you offer might not work.

That's why we start reassuring ourselves, with all kind of bogus facts:

• Our users are all XYZ which means they have browser ABC with DEF enabled.
• Browser XYZ has been outdated for years, no one uses that any longer.
• Only geeks and weirdos disable XYZ, surely not paying customers.
• The source version works like a charm, all the users need to do is disable XYZ and DEF and it'll be accessible to them.

Sadly enough many a time technology is in our way, that is why the following good ideas won't necessarily hold up to what they promise.

• We only use web standards, all our code validates, therefore our website works.
• We added all the accessibility enhancing attributes and elements, and it is the browser's problem now.
• We made sure every multimedia element has alternative content, that will be displayed when the real element can't be loaded. We did that by adding the content to the OBJECT tag.

So we meant well, and what do we get?

• Browsers that implement attribute and element functionality different, or not at all.
• Alternative content not showing up or showing up alongside the real content.
• Browsers not resizing fonts when they are defined in a certain measure, or rendering them different.
• Onkeypress getting triggered when you press non-alphanumeric characters.
• Designs only looking good and working across browsers when we either sacrifice the code validity, functionality or add hacks that make us remember the bad old times of browser sniffing.

In short - browsers are bad, some worse, some just slightly bad, but we cannot rely on them to give the users what they need. It does not matter if one or more are very good, we cannot force the user to install them.

Back to the linked text pages then?

So are we stuck with the two options hotly discussed in many a forum, chat channel or mailing list these days? Cut down on the audience, or don't style at all and let the users and their style sheets do the dirty work for us?

Well, no, as there is a third option:

Make your enhancements optional. Give the user the power to change the site with a server side solution.

Keeping the functionality browser-independent

We started with that already. As users often simply don't know how to change the size of their browser text, a lot of web sites offer widgets to do that with a click on a link or an icon. Style switchers allow for skinning of a web site. Portal software even allowed me as the user to click together the content I want to see on the page next time I get there. Now all we need is to make sure that these tools are used the right way:

• Style switchers can be used to enhance the accessibility - offer large font sizes and high contrast rather than "background image #3".
• Font size changing widgets should store the setting of the user, rather than be nick-nack for each page.
• The controls should be easy to find and independent of scripting, it does not help users with low vision if the resizing widget is 10x10 pixels in light grey on white.

The Learning To Let Go example

Easy to say, but what happens if I don't know any server side scripting? Well, you can be helped.

Take a look at the learning to let go example.

This example works with PHP and cookies, and is easy to implement in your sites. What it does is the following:

Taking the normal style switcher a step further, we offer the users to change:

• The foreground and background colours of the page content
• The link colours of the content and the navigation
• The font size
• The width of the page
• The location of the navigation - top, right, left or bottom
• The location of the page - left or center.
• The design to one of a number of predefined stylesheets.

It provides the user with a form to change all of the above settings of the site. Once these settings are entered, it stores the data in a cookie. The PHP script that gets applied as a style sheet loads this cookie, and displays a chunk of a predefined style sheet. By printing out the css/text header, the browser considers it a normal style sheet.

As the maintainer of the site, you can define the name of the cookie, predefine the settings and define the style sheet elements necessary for the different layouts (navigation on the right, left, top or bottom - you can also only offer some of these).

By applying the stylesheet via PHP, we can use variables in CSS, in this case, the colours that were defined in the form, something developers asked for for a long time.

This script is just an example how you can provide the users with the power to change the site to their needs without giving away a lot of the styling power you have as a web designer. The way it was written, it does not require you as the designer to know any PHP, just CSS and HTML.

But, cookies aren't accessible, you cannot take them for granted!

True, but this is just an example. The code could be easily changed to store the data in a database or a flat file on the server. This way you could make it really independent of the user's computer.

What to do next?

This script is here to show you what can be done if you use a server-side scripting language together with CSS to enhance your users experience, and allow them to change things they need or don't want. It can be applied to anything. Both sides win - you can apply your fancy design and the users can cut it down to what they need or benefit from the offers you give them.

Other possible uses of this approach:

• Allow users to define if they want a DHTML drop down navigation or simply a list.
• Allow the users to have straight text headlines or images instead.
• Allow users to bookmark single pages, and give them a list of the pages they already visited, much like permanent breadcrumbs.
• Allow the users to switch from multi-column to single column layout of your text.
• Let the users choose if they want flash or a static replacement.

Whatever you do, you do something good. You let go of the things you cannot really control, and give the user the power to do so.

Acknowledgements

Joe Clark for his article High Accessibility - High Design which inspired me to create the script.

Various members of the WebAim mailing list for testing it and asking for new features.