Christian Heilmann

Author Archive

Oddly executed accessibility – hide the widget

Friday, June 17th, 2005

I just stumbled upon yet another web site widget that should enhance the accessibility and usability of the site, by offering different site widths and font sizes:

site widget to change font size

My question now is who that really helps? A visitor with bad eyesight is not likely to be able to decypher what these icons mean.
They do have a proper alternative text, but that is not visible until you turn off images (or hover over the images in MSIE).
The implementation is even worse: All the links point to “javascript:void(0)”, which means that without JavaScript, they are dead and useless.

It is a wonderful idea to help visitors with special needs, but it is harmful to implement them using design and technology that assumes the same users don’t have these needs.

Three separated layers of web development? Think again.

Thursday, June 16th, 2005

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 five levels of web design

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.

USB Earrings – A usability nightmare

Wednesday, June 15th, 2005

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. :-)

Browser bug lists

Wednesday, June 15th, 2005

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:

CSS factory (@media call for participation)

Sunday, June 12th, 2005

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.