Learning To Let Go

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.