I hate using CSS hacks and filters. I strongly believe it is not my job to cover up the mistakes of browser vendors, and I hate relying on things I cannot test myself. As I also cannot be bothered to hunt the web for every new hack and workaround I considered buying this title to put it on my desk and get it over with. (more…)

I ordered it even before it came out, but as I just got stuck in writing a part of my own chapter in an upcoming book, I finally opened Stuart Langridges DHTML Utopia: Modern Web Design Using JavaScript & DOM published by Sitepoint. (more…)

European Digital Rights and Privacy International have sent an urgent letter yesterday to the UK Presidency and the European Commissioners for Justice and Media to show restraint in today’s extraordinary JHA Council. EDRI expects the UK Presidency to table a new urgent procedure for the proposal on telecommunication data retention, bypassing the European Commission and the European Parliament.

Full news and downloadable PDF on the EDRI site

• www.edri.org
• http://www.privacyinternational.org

I just went through some sites for an accessibility audit and keep bumping into the same issue: Alternative text for the sake of alternative text. If I surf some pages with a text browser, IBM Homepage Reader or Jaws and it takes me 10 minutes more to find my way around, I start wondering where the common sense was when the site was created or who was the main target for these alternative texts. Take this gem taken from a noscript block:

We use javascript to write a “breadcrumb” here. If you want to view it you need to enable scripting in your browser. If this is not an option for you, you can navigate easily and in an equivalent way, by modifying the address of the page that you are viewing. For example: if the address shown is http://www.example.com/section1/a_and_b/c_and_d.html – you can change this to http://www.example.com/section1/a_and_b.html to navigate to the previous page in the hierachy or to http://www.example.com/section1.html to navigate to the top page in the hierachy.

They forgot to mention that I can also go to their competitors site, who didn’t bother using JavaScript to generate breadcrumbs, and offers me three easily understandable links.

Another issue is that a lot of developers rely on title attributes to deliver crucial information, like “PDF Document” or “opens in new window”, and not all who use assistive technology do have title reading enabled. Some even get rid of it by default, and who could blame them when you get titles like “Click to skip to content (skips navigation)” for a “Skip to content” link and a “click to visit the xyz page” for links stating “xyz”?

Generally, there are some sins I try to avoid:

• Alternative text that is dependent on the image/effect
• Alternative text that is overly elaborate – think of explaining something over the phone, not read out a manual
• Needless repetition of text. A link is a link, no need to repeat that (My favourite was “link to www.example.com – click to activate – opens in new window” as a title).

The sites with the best usability are the ones that helped us reach our visit goal without realising how the site helped us. As soon as you need elaborate explanations it is a sign that you either broke a convention or your interaction steps to reach the goal are simply too complex.

Notice: The following is a “best practice document”. You can follow its advice and live happily ever after, but there might be situations where you cannot apply the ideas mentioned within. This is especially the case when you have to maintain an old product or complex web application. You cannot replace everything in those in one go – as you are very lucky indeed if you get the time and budget – but you can tackle those step by step.

According to many web designers at @media2005, JavaScript is sexy again, and in demand. Ajax is the new CSS was a quote in one of the presentations, that – taken out of context – makes my stomach go wonky.

Working largely with b2b sites and restricted environments, I never knew it was out of fashion.

It is a tool, much like a shovel, a screwdriver or a towel. While a towel is handy in every situation, as every HHGTTG reader knows, JavaScript has its place and its merits, but also its limitations and places it shouldn’t be applied to.

You can use a screwdriver to screw in screws or to clean your ears, however, the latter needs real skill, determination and a lack of fear of injuring yourself. It is much the same with JavaScript, you can use it for great things, but you can also use it to make a product inaccessible, confusing and not usable.

Here are some danger signs you encounter in many a bad script example and tutorials written in the spur of the moment rather than following proper research.

Things that should make you go Noooooooooooooooooo!

1. document.write What this does is write out content to the HTML document, inside the body of the document and merrily mixed with the markup. Bad web developer, bad! Go to your corner! A better solution: reach the element you want via getElementById or getElementsByTagName and then insert your newly created content (via createElement and createTextNode) there.
2. This you encounter a lot in “Accessibility Tutorials” and it should “make sure that every user can use your site”. Actually, it is a sign that the script you use (or did) is bad and should have never been used in the first place. It is like using white-out on the wallpaper after you used your crayons there. Comment: I was asked to clarify this, as web application developers who have to rely on JavaScipt (which is a flaw in the application design IMHO) use noscript to tell the users they need JavaScript enabled. Normally this is added as a warning message at the start of the non-working page. The more logical option in this case would be to have the "no JavaScript" message in the document and replace it with a link to the application when Javascript is available. Check this example page on how to avoid noscript. Turn JavaScript on and off to see the difference.
3. href="javascript:", onclick="javascript:" There is no such thing as a JavaScript protocol on the web. Links use protocols to connect documents. Create real links or don’t use any link at all – do or do not, there is no try!
4. onclick="void(0)" Why would one put effort into creating something that by definition is not doing anything? Glossing over bugs and bad scripting, that’s why. A link that only points to a JavaScript function should be added via JavaScript.
5. document.all , document.layers, navigator.userAgent Unless your defined project environment is MSIE 5.x and Netscape Communicator 4.x (my condolences if it is), there is no need for that any longer. Object detection is so much better than trying to guess what the browser in use is, and the W3C DOM is also more likely to be used in future UAs than the bespoke Netscape or Microsoft ones. (If you say “huh, what?” now, just trust me that everything with document.getElementById is much more stable than the other two mentioned earlier)
6. onmouseover="myCall('I','pity','the','foo',1233,'I aint going on no plane')" Anything crucial to the user experience that you generate via JavaScript needs to be in the document anyways – for users without JavaScript. Reusing this markup is a lot easier, cleaner and more maintainable than sending a lot of parameters. If there is any reason to send parameters, a simple ‘this’ does the trick in most of the cases, as you can navigate through the DOM from there.

On request

And what about innerHTML?

As some pointed out in the comments, innerHTML is another way to create content on web sites. In some cases, it is even the fastest method, as Peter-Paul Koch found out when comparing methods to generate content. However innerHTML is neither standard, nor applicable to any DOM scripting outside the browser environment. There is an excellent discussion about innerHTML on developer-x. My personal view? innerHTML makes it a lot easier, but advertises HTML documents as strings rather than node trees, and that makes it hard for junior developers to go further in their scripting ventures.

Partly inspired by Robert Nyman’s recent post about JavaScript