The reactions of the audience at @media, and many a chat afterwards made it obvious to me that the concept of JavaScript adding the behaviour layer above the HTML markup (or structure) and the CSS (or presentation) has become commonly known.

This is nothing new, after all, Zeldman’s book explained that in 1999 with a nice movie metaphor:

If your web page were a movie, XHTML would be the screenwriter, CSS would be the art director, scripting languages would be the special effects, and the DOM would be the director who oversees the entire production.

However, when it comes to accessibility and ease of maintenance, I’ll dare to make things more confusing now, by telling you there are five levels of web development, each of them with its own technologies and methodologies. Only when all of them work properly and are aware of standards and accessibility / usability constraints we can work without breaking a sweat.

The levels are:

• The behaviour layer – Executed on the client, defines how different elements behave (Javascript, Action Script)
• The presentation layer – Displayed on the client, the look and feel of the site (CSS, images)
• The structure layer – Displayed on the client, the mark-up defining what a certain text or media is (xHTML)
• The content layer – On the server, the text, image and multimedia content that are in the site. (XML, DB)
• The business logic layer – On the server, defines what is done with incoming information and determines what is returned (Backend, various environments)

The Business Logic Layer needs to

• provide the different states in a styleable and changeable format

The Content Layer needs to have

• Text that is easy to understand
• Text that makes sense without a visual representation (wrong example: “click on the links below”)
• Alternative text for every image, sound piece or video that is content
• Text that is fit for the web (KISS, structured into headers, paragraphs and lists)
• Explanations of Acronyms and Abbreviations
• Content images need to be unambiguous for the colourblind and text in images needs to have a sufficient size and contrast.
• Information to the users of changes necessary to her environment (example: “opens in a new window” or “PDF document, 182kb”)

The Structure Layer needs to

• provide a consistent document structure with the content available as early as possible
• provide the “invisible accessibility enhancements” like accesskeys, link relationships and table serialisation aids.

The Presentation Layer needs to

• ensure that text can be zoomed without making the site unusable
• ensure that the interactive elements of the site are easy to find
• ensure that images and foreground and background have enough contrast and are unambiguous to the colourblind
• give the site a consistent navigation
• Aid the user through business processes
• Separate content into easily understandable units

The Behaviour Layer needs to

• ensure that all the functionality is available to the user regardless of input device
• make the user experience as easy as possible by cutting down on options until they are necessary

Raising awareness of this might help in the future, and accessibility / usability will not be considered a “plug-in” added in the final week of the project lifecycle any longer.

Shifting my localhost to my cool new 1GB USB stick, I also discovered that the same company does jewellery with USB sticks. While my keyring one is still easy to use I really don’t see how you can work with either your neck or your ear connected to the USB outlet. :-)

I have to give our test team some resources to spot different browser bugs. The client is one of those classic cases considering a web site only good when it looks the same on every outdated UA out there, and of course the main stakeholder uses IE5.0 on Windows NT.

The question is now, are there more up-to-date resources out there?

Currently I have:

• http://www.richinstyle.com/bugs/
• http://www.quirksmode.org/bugreports/
• http://www.positioniseverything.net/
• http://www.l-c-n.com/IE5tests/

I bounced the following idea off some people at @media (Douglas Bowman, Molly and a lot of others) and I am ready to go along with it. It’d be good to hear some thoughts though:

We all know and love CSSZengarden. It showed the design community what can be achieved with CSS and how easy it is to redesign a web page completely, simply by applying another style sheet.

However, for our day to day web development life, the garden has become a bit of a problem, mainly because:

• The designs have become an image replacement competition instead of testing what CSS can do
• It is too easy to style only one document that has been marked up with loads of IDs and classes – in the real business world we’ll have CMS defining the content markup and we don’t have that option
• The focus seems to have shifted from style and functionality to style/brand on its own.

My idea now is to start a CSSFactory. The idea is the same as CSSZengarden, the difference though is:

• The Markup will be a 5 page web site with different layouts and content for each page
• The Markup might have variable content order on reload to simulate a CMS that allows editors to rearrange them
• The content will be available in English, German and maybe French (I’d need help with the French – Stephane?)

That way we can prove that it is possible to create bullet-proof CSS that can be applied to real life web sites, and maybe get a bit more buy-in from project management and managements when we try to advocate standards.

Comments?

14.07 Changes

Ok, I realise that some of the bits mentioned here confused people, so here are some extra explanations:

• The JavaScript is only an idea to simulate how a real backend would allow editors to change the content. I intend to use it to avoid the need to reload the pages from the server each time. Saves me server traffic and you time during development. I develop and write most of my hobby works (like this idea or the unobtrusive JavaScript course) on the tube whilst commuting every day, I thought it’d be handy to show how flexible CSS is without the need to run a localhost with PHP.
• The random order of course will only apply to the content slot of the template. Much like we do for most clients. One of the basic princibles of accessible and usable sites is that we keep the navigation on the same spot throughout the site, moving it would be counterproductive.
• I started on some of the markup, but want to get an offline version of the course and the linkrot prevention idea out of the way first. I also wonder if I should get a dedicated server and domain or use this one instead.

I must have been kissed by a Muse at @media, because I had another idea, that I’d like to get help with.

The problem

• There are far too many outdated, obtrusive and plainly badly written tutorials and scripts out there
• As they have been around for a long long time, they are ranked very high in search engines, and new, interested developers will find them instead of The Good Stuff™.

The dilemma

As the developer or writer of these scripts and articles, you do have the choice of the rock and the hard place:

• You hardly have the time or the inclination to rewrite the articles, sometimes they have been published by a third party and you cannot do that.
• You don’t want to delete them, as you do get visitors, and they might be persuaded to explore your publications more and find The Good Stuff™.

One solution

What I thought about, and many people at @media agreed is that there should be an option to keep these scripts and tutorials for achived reasons and tell the visitor about The Good Stuff™
The idea is to set up a service, which I intend to call Obsoletely Famous (yes, I miss Futurama), which is basically a RSS feed listing good, modern articles and resources for the topic at hand.

(Basically a pre-filtered del.icio.us, as many people linking to it sadly enough does not necessarily mean it is a good quality resource, it is simply popular, probably by oversimplifying the issue at hand. A good example of that are a lot of ALA articles, where the real good information ended up in the comments, but not many users go there)

As the developer / maintainer of the script you can set up a bridge page (or a custom error page) that tells the visitor that the above was fun while it lasted, but the list here actually shows better ones.

The benefits

• We re-use the high google ranking to promote The Good Stuff™
• We help writers and scripters / developers to back off things they are not proud of any longer without giving the visitors alternatives
• We ensure that newer users find The Good Stuff™
• New writers of The Good Stuff™ can easily reach more people

The plan of action

Give me the bricks, and I’ll build the house

Basically, we need to identify our areas of expertise and define The Good Stuff™ links. Then I can set up the RSS feed and create some example bridge pages. In the long run, I might persuade my evolt colleagues to host it.

Areas covered:

• JavaScript
• DOM JavaScript
• CSS
• HTML
• Visual Design
• Usability
• Accessibility

We can start by listing some here in the comments.

Check your own stuff

• Let’s all go through what we have online and see what is a possible candidate for becoming obsoletely famous (I know for a fact that 75% of my onlinetools.org is). Squint your eyes and look at it in a menacing way – make it aware that its days are numbered^*
• Scan your bookmarks for good, modern tutorials and name them here.

^* optional