Coding with Jesse

Accessibility Is About Minimizing Requirements

What are the minimum requirements for using the web?

  • an Internet connection
  • a web browser

What are the minimum requirements for using your web site? Well, the answer could include any of the following:

  • a high-speed Internet connection
  • a keyboard
  • a mouse (and the ability to use a mouse)
  • a large computer screen (eg. 1024x768+)
  • specific web browser versions (eg. IE 7, FF 2+)
  • specific browser plugins and version (eg. Flash 7 or VRML)
  • JavaScript
  • a PDF viewer
  • near perfect vision
  • lack of colour blindness
  • knowledge of a language (English) or jargon (web development)
  • potentially many more...

How many requirements does your site make? How many are really necessary and how many can you eliminate?

Being accessible means minimizing requirements. The less requirements you have, the more freedom people have to use your site, the more accessible it is to the world.

The more requirements you make, the more you're requiring people to have specific devices, software and even physical abilities that may not be possible. As a result, the site becomes inaccessible to some.

Of course, some requirements are necessary. Can you imagine a web site translated into every language? And what would this blog be without assuming a basic knowledge of HTML, JavaScript and CSS?

But how many are just trivial requirements, made to save a bit of programming or decision making? And how many are simply unreasonable given the wide range of physical and technical limitations people face in the world?

One thing is for sure: plain HTML makes the fewest requirements. Start with that and add other technologies carefully and unobtrusively.

Published on September 30th, 2007. © Jesse Skinner

CSS Sprite Generator

Finally, there is an automated CSS Sprite Generator (via)! Just upload a zip of graphics and it will spit out a single image and a block of CSS you can use.

What are CSS Sprites? If you use a ton of CSS backgrounds for things like icons, buttons and other non-repeating graphics, then you can combine them into a single graphic and use background-position with width and height to show a slice of the larger graphic. This can make a site load faster since there are less files to download.

This is generally a pain to do by hand (not only combining the graphics, but calculating and remembering pixel positions), but with a tool like this it should be a cinch!

Published on September 30th, 2007. © Jesse Skinner

Getting an Image's onload to Fire

Are you attaching an onload function to an image but finding it doesn't always get called?

The problem is almost always this: you need to set the onload before you set the src. The reason is obvious when you think about it: if the image is in the cache, the image will be loaded immediately after setting the src, even before the onload is set.

Adding fuel to the fire, Firefox and Safari will let you set an onload immediately after (it seems they don't call the onload until the block of JavaScript finishes). This doesn't happen in Internet Explorer or Opera.

Long story short:

// evil:
var image = new Image();
image.src = 'image.jpg';
image.onload = function() {
    // sometimes called
    alert('image loaded');
};

// good:
var image = new Image();
image.onload = function() {
    // always called
    alert('image loaded');
};
image.src = 'image.jpg';

No matter how many times I come across this bug and find the solution, I end up making the same mistake a few weeks later. I'm hoping that blogging about it will get this stuck in my long-term memory.

Published on September 28th, 2007. © Jesse Skinner

Using Hash for JavaScript Debugging

No, I don't recommend smoking hash before doing your JavaScript debugging :) But I did figure out a technique which you can use to switch a page in and out of debugging mode.

What happens if you need to debug a site that's getting traffic, and you don't want everyone getting your alert() messages or whatever else you need to debug?

Well why not check location.hash and look for a special keyword:

function debug_mode() {
    return location.hash == '#debug';
}

if (debug_mode()) {
    alert('We are in debug mode!');
}

Now you can just add #debug to the URL (and hit enter) to turn on debug mode, or just drop the #debug to turn it off. You can even have more than one special "mode" and use different hash values to switch between these modes.

Published on September 26th, 2007. © Jesse Skinner

Detect Internet Explorer 6 in JavaScript

Update: As some of the comments mention, the technique below doesn't work anymore. It's best to use object detection to accomplish what you need, or use conditional comments. But if you need to detect IE6, this should work: /MSIE 6/i.test(navigator.userAgent)

Sometimes you just have to sniff for Internet Explorer 6 (and under) in JavaScript. Using conditional comments is a decent solution, but I don't want them scattered all over my code.

With a bit of help from Dean Edwards, I worked out the following:


var IE6 = false /*@cc_on || @_jscript_version < 5.7 @*/;

With just a single conditional comment, you can have a JavaScript variable that you can reuse throughout your code.

(IE6 will be true in Internet Explorer 6 and under, but does anyone really care about IE5 anymore? Thought not.)

You could use this technique to sniff for other things:


// exactly Internet Explorer 7
var IE7 = false /*@cc_on || @_jscript_version == 5.7 @*/;

// at least Internet Explorer 7
var gteIE7 = false /*@cc_on || @_jscript_version >= 5.7 @*/;


// any Internet Explorer (thanks to Dean)
var isMSIE = /*@cc_on!@*/false;

Note: browser sniffing is evil but sometimes painfully necessary.

Published on September 21st, 2007. © Jesse Skinner
<< older posts newer posts >> All posts