Plenty of JavaScript demos and tutorials that you come across on the Web note that they are implemented using unobtrusive JavaScript. While that is great and should always be encouraged, some people seem to believe that unobtrusive JavaScript equals accessible JavaScript. That is not always the case.

Unobtrusive JavaScript is normally mentioned to emphasise that a script uses progressive enhancement to cater for people who use a browser without JavaScript support. But that does not mean that a script is accessible, since two key accessibility issues tend to be overlooked – keyboard navigation and screen readers.

One example of this is most lightbox clones, which can be difficult to use without a mouse and confusing for screen reader users. There are also many widgets (datepickers, dialogs, custom form controls, etc.) that, despite being unobtrusive, do not work well or at all for keyboard or screen reader users (yes, most screen reader users have JavaScript enabled).

So, just a heads up that even though a script is implemented in an unobtrusive way, it isn’t necessarily accessible.

Nowadays, it is more or less the norm to use JavaScript to insert video content embedded in Flash into web pages. While it does work in the majority of cases, there are a couple of problems: it requires JavaScript and it requires Flash.

Some people block JavaScript, some block Flash, some block both, and some use platforms or user agents that do not support JavaScript and/or Flash. Like the iPhone and iPod Touch, for example. So to reach the largest possible number of people with your videos, you may want to look into the method described by Kroc Camen in Video for Everybody!.

The method uses a combination of the object element and the HTML 5 video element to embed video files. Browsers that support video use that. If the browser does not support video, QuickTime is used if it is installed. If it isn’t, Flash is used. If there is no support for video, QuickTime or Flash, a placeholder image is displayed.

I find it a bit annoying that JavaScript and Flash are required to see videos on most sites, so this looks quite interesting. The drawback is that if you use this method, you’ll be using features from a spec that has not yet reached Last Call status. The choice is yours.

Further reading about the video element:

• YouTube and Vimeo support HTML5 Video
• The video Element In HTML5 – Great Possibilites, But Also Codec And Licensing Problems

A while ago I posted Safari, WebKit and alt text for missing images, in which I note that most WebKit-based browsers do not always display alt text when images are missing. In alt and title content display in popular browsers, Steve Faulkner presents his results from taking a closer look at this in the browsers that are currently most widely used.

In addition to checking what browsers do with an image’s alt text, Steve also checked if they do something with the title text, if any. Interestingly it turns out that Chrome and Safari display the contents of the title attribute if the image has no alt attribute. This situation shouldn’t occur in well-authored HTML documents, but I’m guessing WebKit displays the title text as error-recovery in the case of missing alt text, since in most cases it’s probably much better than displaying the file name.

The results of Steve’s testing show that the behaviour varies quite a bit across browsers, and I agree with his conclusion that it would be nice to see this standardised by specifying the recommended behaviour in HTML 5.