Eric Meyer’s S5 standards based presentation slides system is used quite a lot by webstandardismos for their presentations.

However, some of its functionality is great for presenters but can be quite hard to follow for web surfers who just want to see what someone has presented.

My personal challenge was to come up with something that is as cool as Eric’s system, but much easier to use and more lightweight when it comes to creating your own slides.

The outcome is called DOMSlides and is licensed under Creative Commons for you to use, change and copy.

Any feedback, testing on Macs and own style sheets to bundle with the script are welcome.

I gave a presentation in a workshop this morning on the topic of “HTML tables best practices”. The catch: I didn’t get time to prepare properly and the audience was predominantly designers and non-technical types.

I cobbled the thing together in half an hour during the first presentation of a colleague and the result is a bit tongue-in-cheek, but might be helpful to you aswell:

Best practise on HTML tables for the non-techie audience

Yes, I couldn’t resist creating my own slideshow JavaScript thingy…

As a part of my job I am right now conducting an accessibility audit of one of our clients’ sites. My findings so far and the background and history of the project are a perfect example of how much of a gap is between accessibility best practice tutorials / articles and the real business world.

The Project

• We have developed and maintained the site since 2001
• We are only partly responsible for the design and the content. A design agency delivers all of that – with focus on print and TV.
• It is a maintenance project on a monthly budget that includes all deliveries – from content maintenance (image optimization) to server infrastructure and hosting
• To keep within budget, the maintenance development is outsourced to an office outside the UK with a quick turnover in developers of a wide range of skills and quality awareness

The client expectations and attributes

• The site should show the brand and be “fun to use”
• The client is not dependent on the site as a main customer channel – it is a worldwide known brand and has real outlet stores.
• The site does not have any products for sale or order; it is simply another communication channel to show the brand

The technical background

• The technical implementation was initially ASP with some database functionality for lookups and was optimized to work for IE4 and Netscape Communicator 4.x. All the interactive sections like signing up for the newsletter, download of fun wallpapers, screensavers and other brand collateral is still in this format and just got a new lick of paint in between.
• About two years ago, the client wanted to go Flash, but have an HTML fallback option. Both should be maintained from the same source, and there should not be any overhead or extra work for the HTML version. This is achieved by using XML for the content, XSLT to generate the HTML and Turbine to generate the Flash on the fly. The live site is generated statically by Cocoon.
• As interaction with a database was out of budget and scope, all the earlier mentioned server-interaction sections are opened in pop up windows.
• As the Flash version is the “fun to use” one the site as it is now automatically sends users with Flash enabled to that one – rendering the HTML version as an “accessible” version rather inaccessible for users with special needs and Flash.

Enter “Accessibility on a shoestring”

As the brand is constantly in the limelight and also gets a fair amount of flak, and with some gentle prodding of yours truly, the client got aware of accessibility needs and demanded “some of that”.

In an initial presentation I tried my best to point out that accessibility is more than just some technical changes to the HTML, introduced different kinds of disability and showed sections of the page that are inaccessible by trying to use them with a keyboard and speech recognition.

Aware of budget restraints, I came up with three options to tackle “the accessibility problem” (they were named differently though):

• COA (cover our a…. you know): Get rid of the automatic redirect and offer the user a choice between a Flash version – that might not be accessible to all – and a more basic HTML version that is accessible. Offer a mean of contact on each page to tell the client about issues and offer an accessibility statement explaining why some parts of the site are not accessible.
• Clean Up: All of the COA and changing the forms not to appear in pop-ups any longer.
• Face Facts: Embracing the fact that most of the site is not necessary content but advertising, we split the site into “brand experience” and “business” sites, where the former can be as flashy as they come and the latter easy to use and fully accessible.

Needless to say, the budget demanded COA only, and after another brand session the client decided not to have a landing page that allows the user to choose between Flash and HTML but offer a small link to the HTML version on the Flash site.

So here are the facts:

• The site content is brand orientated, most text provided only makes sense when you can see the imagery that comes with it or there is simply no text but only visuals.
• These visuals and any content has gone through a painstaking and expensive approval process, and the client won’t be happy for us to tell we cannot use it for an accessible version.
• Anything we come up with as extra for the accessible version (information text, alternative texts, changes to “click here” and “choose on the right” wording) has to go through the same approval processes.
• The client does not want to spend extra time and money on the accessible version and relies on us to do the right thing. We get paid as the delivery agency and there is no need for them to get someone involved in accessibility.
• As part of the Flash/HTML redesign was us telling the client there is no extra work involved, it is tough for us to say, “Well there is more work involved now”

Now tell me: How many tutorials, best practice and information articles about accessibility have you seen that help in this case – and it is not a singular case, a lot of design oriented agencies and those who have to rely on third party content face the same issues.

We got the bloggers, and brochureware small to medium business web site owners, now it is time to think about how to make business aware of what accessibility encompasses. And no, there is no such thing as “Accessibility does not affect design”, unless the original design is developed with diversity in mind.

Maybe it is time to stop advocating accessibility as an easy to achieve goal, and a technical problem that can be tackled independently from the other layers involved.
It is a state of mind, a way to design and write that anyone can benefit of.

Products developed with limitations in mind have given designers a new perspective and resulted in innovation. Thomas Edison developed the carbon transmitter (microphone) for Bell’s telephone because he had trouble hearing its faint sounds. On his invention of the phonograph, Edison explained: “Deafness, pure and simple, was responsible for the experimentation which perfected the machine.”
From Innovative Design Inspired by Accessibility

Digital Web will release an article of mine on the 20th called “10 reasons why our clients don’t care about accessibility” with more examples like this one.

I hate The Scorpions but I can feel a wind of change. While there was many a flamewar on mailinglists, forums and chatrooms in the last few years it seems that we finally realised that airy designers, dysfunctional developers, usabilitistas and accessibility zealots actually all have the same goal: Delivering good, successful web sites

The recipe for those is easy:

• Solve problems the user has
• Offer content the user wants
• Deliver it in a slick and beautiful fashion
• Make it darn easy to use
• Make sure it works at least on the basic level for everybody

Now, whoever claims to be able to do all of the above is either highly gifted or a stinking liar.
Therefore we need to hop on our toes and glance over the garden fence to see what the others do, the finger painting kids one side, the ones building huge sand castles on the other, and the ones feeding the sandcastles to other kids and write down their impressions on a piece of paper in the last garden.

The other problem with our pie in the sky wish list is the harsh business world:

• The user issues are assumed by marketing (“They want to buy our product, everybody needs it”)
• The content is provided by business (“We got lots of material, our newspaper press releases from 1981 onwards and all our business case papers, 430 pages each!”)
• The design is defined by the 1962 guideline for internal memos or the new 3D logo creator of the CEO’s son
• There is no feedback on how hard it is to use the site, visitors just leave and the developer gets blamed for being crap at SEO.
• The stake holders heard of accessibility and know it has something to do with putting an “AAA” banner on the site or get sued.

So there – we are a bit stuck. But that should not stop us from learning and sharing, because if we ever get to talk to a stakeholder with him/her listening (wedging them in toilet doors is an option, or stealing the TP roll and make them listen till we give it back), we better have some good material based on facts at hand.

But oh, woe is us – when we look around for good tutorials we will find a lot of material written by someone of group A for group A, B for group B and so on…

• Design tutorials talking about typography and colours and harmony not considering the restrictions of the web
• Scripting tutorials with yet another foo(bar) example with no real-life connection
• CSS tutorials assuming everyone uses Opera or Firefox
• Accessibility tutorials that look like someone forgot to connect a style sheet, just to find out there is actually one, but it looks just like the browser standard.
• CSS or scripting tutorials showing that it is possible to do something that was meant to be achieved by the other, or even by HTML.

What we need is better tutorials, aimed outside our area of expertise and delivered slick, painless and with a practical use. Collaboration is the key to that.

• Scripters should liaise with designers to get their code examples designed in a nice fashion and their articles re-edited to make them understandable to somebody who does not consider regular expressions a valid mean of communication
• Designers should liaise with HTML developers, scripters and accessibility gurus to see if what they want to achieve is feasible and where the pitfalls are.
• Accessibility and usability people should get input from designers to understand why some things were designed the way they are and find a consensus, and to get help making their own texts prettier and illustrated.
• Everybody should grab someone outside our world and see if the things we write are understandable

This all should not be restricted to our blogs, but should also happen before something gets published in web zines. While a lot of editors of web zines are great writers and know a lot about getting messages across, their technical knowledge might be limited. Not all of them employ or invite technical reviewers and experts and that is why we end up with a lot of tutorials that are buggy or flat out wrong and yet very successful.

So please, think a bit before submitting the next article and get some more people involved to sort out the issues and add the nice wrapping paper before giving your ideas to the public.

Things that are not helpful and have to go:

• Bleeding edge tutorials working in a small environment advertised as a cool new feature rather than an experiment
• Scripts for their own sake – without a real business task at hand (business stakeholders would never ask for coloured scrollbars if they hadn’t seen them somewhere)
• Untested functionality breaking in a big percentage of the browsers in use or in modern browsers
• “Hey I can do in X what we rightfully did in Y for years” tutorials
• Tutorials with examples focused on one level but violating the other two badly – if you want to explain a cool JavaScript idea, make sure your HTML is semantically correct, validates and you leave the styling to the CSS.

“Don’t judge a book by its cover” is a nice idea, but that is exactly what people do, so let’s sell standards based development as a nice shiny and easy to grasp parcel, rather than a bit of string, some crumbled wrapper and a almost unused box.

My favourite pieces to commission when I jobbed as a packer at a chainsaw factory were the health and safety instruction videos. "Never check the level of petrol by holding a lighter to the opening" and "Never keep the blade between your legs when trying to start the chainsaw" were just two of the highlights.

Health and safety measures are important – they ensure that our work environment is enjoyable and will not make us sick. Just because our job is handling user agents and typing funky words into an editor does not mean we shouldn’t follow some of our own.

Right now, DOM scripting with JavaScript is hot again (the over 3000 unique hits on my post about outdated JavaScript techniques proved that to me) and we run into the danger of overusing it or using it in the same obtrusive ways we used JavaScript when DHTML was the flavour of the month.

When your tool is a hammer, everything looks like a nail, or – in some cases – a thumb.

Let’s not bash anything in sight or mince our own thumbs. DOM and JavaScript are there to enhance the structure and interact with the presentation of a web site – and not replace them.

Ideas that prevented me from repeatedly hitting my thumb:

1. Don’t create HTML that should be there without JavaScript. Re-use what is already in the page instead. An accessible site starts with a semantic, well-structured HTML document. If that is not given, there is no chance we can be accessible. Not creating HTML via DOM makes the product a lot easier to maintain. Non JS-savvy colleagues won’t have to butcher your code to make a change on the page.
2. Generated HTML follows the same rules as written HTML: Don’t create invalid HTML. We stopped using CSS to make elements look like headers instead of using real header elements. The same applies to the DOM - redundant HTML elements to fix a design or add a design feat are – well, redundant, no matter what technology was used to add them. By the way, this also applies to server side scripting.
3. Be aware of visitor and user agent restrictions. An example are my fabulous clickable headers of the Unobtrusive JavaScript course. They look handy, work cross-browser and were developed with a clear separation of structure, presentation and behaviour. Where they fail is when you try to use them with a keyboard. The power of the DOM seduced me to turn a header into a hover-able and clickable element, but there is no way to use it without a mouse. That is why I will add a real interactive element to the headline – a link – to make them work for keyboard users (and possibly screen reader users) as well (thanks must go to Stéphane for flagging that up to me).
4. Understatement is class. Before adding all kind of cool new JavaScript features and make everything hover, click and move it is a good idea to lean back and think: "Is this really necessary? Do I add it to help the user or do I add it because it is cool?"
5. Don’t break too many conventions. As posted earlier, I see the web as a secondary media, and assuming that the visitor pays detailed attention to our web sites is more narcissism than reality. If we need to explain functionality to the visitor in a piece of text, there is a big chance that we will confuse rather than help. Example? Users hitting the back button on AJAX apps and pure Flash sites.
6. Leave a clean desk. Especially in distributed developments it is of utmost importance that everybody speaks the same "code language" and that handovers are painless and quick as the code is already properly documented. Define an in-house coding standard, comment your code where applicable and there will be a lot less stressed faces and moaning when people get assigned to projects.