Of course, I needed to give him a photo gallery. I first considered using Gallery2, which I implemented for Oscar Whicheloe’s site, but ended up building something a bit more individual. While this approach means more manual work for making changes (which wouldn’t have been appropriate for Oscar’s site), I minimised this in a few key ways:

1. The image for the overlay is determined by checking the value of the image “src” attribute rather than needing to manually pass it through to the javascript.
2. The alt text for each of the thumbnails is read by the javascript and used for the little description box.
3. I used jQuery. The point is more that I used a javascript library than which one I used - but jQuery certainly worked well!

Not having had much call to use setTimeout in the past, I simply put:

setTimeout(myFunction(parameter),myTimeout);

but that doesn’t work. An apparent solution (until tried in Internet Explorer) is:

setTimeout(myFunction,myTimeout,parameter);

It wasn’t as easy as I expected to find out how to get around this, but it turns out that all is needed is a “closure”:

setTimeout(function(){myFunction(parameter)},myTimeout);

A quick sample of how to use it follows, or you can see the news ticker in action.

$(document).ready(function() {
var options = {
newsList: "#news",
startDelay: 10,
placeHolder1: " []”
}
$().newsTicker(options);
});

For news items along the lines of:

<ul id="news">
<li><a href="http://www.makemineatriple.com">MakeMineATriple.com</a></li>
<li><a href="http://www.jquery.com">jQuery</a></li>
</ul>

The ticker will write out each news item in turn, and keep looping. Various parameters can be specified for things such as the pause between news items and the speed of the ticker. Full details and the download are on the jQuery plugin page. Hope you find it useful!

On the site I’ve been building at work, one particular example was to get jQuery to write in the “Print page” link, since that needs javascript.

// add print page link - since it can only work for JS, only add it for JS users
$('<li></li>') // create list item
    .addClass('print') //add relevant class to it
    .append('<a href="javascript:window.print();">Print this page</a>') //put in the link
    .insertBefore('li a.foo'); //add before the li item with link of class 'foo'

The above example is slightly more verbose than it need be, but it illustrates some of the different built-in functionalities of jQuery quite well.

Another example was to attach popup window behaviour to a couple of the links, while avoiding two particular ways this is sometimes done.

<a href="javascript:function();">Foo</a>
<a href="foo.html" onclick="function();" onkeypress="function();">Bar</a>

The first is inaccessible, because there’s no non-javascript alternative. The second is somewhat obtrusive - the javascript code sits around regardless of whether it can actually be used or not. Additionally, it doesn’t take into account which key has been pressed, which will be a problem for users who are tabbing between links.

Hooking the javascript functionality onto the links is very easy. Assuming a link with class ‘popup’, you’d do the following:

//attach js funtionality to a link
$('a.popup').bind('click keypress', function(event) {
    var code=event.charCode || event.keyCode;
    if(!code || (code && code == 13)) {// if no key code (mouse) or if enter is pressed
        [...]; // do whatever we need to do
        event.preventDefault(); //prevent browser from following the actual href
    }
});

To make this easier to re-use, I ended up writing a little jQuery plugin (see it in action). The function essentially allows binding of mouse click and Enter keypress to a specified element. On either of those events, a given function is called, and the default action is blocked (which, for a link, is to follow the link).

• Users scan web pages rather than reading every word.
• Users typically won’t give a web page their full attention. For example, they may also be listening to music and using instant messaging.
• Web pages are interactive.

The six elementary rules

George Orwell’s rules (”Politics and the English Language”, 1946) are just as relevant today for the web.

1. Never use a metaphor, simile or other figure of speech which you are used to seeing in print. [The point here is not "print vs. web" but "avoid ones which are used all the time".]
2. Never use a long word where a short one will do.
3. If it is possible to cut out a word, always cut it out.
4. Never use the passive where you can use the active.
5. Never use a foreign phrase, a scientific word or a jargon word if you can think of an everyday English equivalent.
6. Break any of these rules sooner than say anything outright barbarous.

Organising your page

The structure and organisation of your content should generally be very different from a print version.

Introduce the page

Help the user to know that they’re in the right place. Give them a short outline of what they can expect to get if they read on. Do not repeat the page title.

Important content first

What is the main point of your page? Give the user that information or message first, and anything else can follow.

Short and simple

Users will be looking for specific information; being concise and ensuring that you use easy to understand language will help them to find it. If the information is necessarily very long, a PDF download may be more appropriate. Web content will typically be about half the length of print content.

Don’t repeat content

If it’s been said elsewhere, link to it. This will keep your pages shorter and remove the administrative burden of having to keep checking whether updates are needed.

Highlight key points

Use visual cues (which a CMS would translate into mark-up to make them accessible) to make important content stand out. Someone scanning your page will be more likely to spot this content and read it. Examples include:

• sub-headings
• blockquotes (”callouts” or “pull-quotes”)
• bulleted or numbered lists

Note that some text formatting does not translate well to the web. Never underline text - that suggests a link. Italics are harder to read and should be used only if necessary (e.g. citations). Highlighting content with capitals is the online equivalent of shouting.

User-focused content

Know who your audience is and use appropriate language to ensure that they understand you. Make sure that any background information they need is available and obvious. Use a friendly (but not over-familiar) tone, and don’t distract users with jargon or over-used phrases.

What next?

Give the user something to do next. For example:

• Put links to other articles which may be of interest at the bottom of your page.
• Offer subscription to a mailing list.

Use keywords

Make sure you include relevant keywords – words and phrases which your users would use – within your content, especially within the headings and first few paragraphs. This will help your pages to show up in search engine results, as well as helping to reassure the user that they’re looking at the right page. (Users arriving at a page from search results will often skim the page for keywords before deciding whether to read a page.)

Regular revisions

It can be frustrating to come across a page with out-of date or inaccurate content. Make sure that every page has an “owner” responsible for updating it or removing it if it’s no longer relevant.

Accessibility

This is very important. Not all of your users will have the same ability to view your content. This could be because of outdated software, missing plug-ins, or because of a physical disability, for example. There are many different points to bear in mind, though many of this will be dealt with from the technical end by a CMS, for example. Some of the most important considerations are:

• Image alt text.
  • If an image conveys a message, make sure you supply alt text to give that message to people who can’t see the image.
  • If the image is purely decorative, leave the alt text blank.
• Link text.
  • Make sure that the link text tells the user what to expect if they follow that link. Never use “click here” or similar – it doesn’t give useful information (and indeed not all users can “click”).
  • e.g. “For information, please contact us” rather than “Click here to contact us”.
• Page structure
  • Structuring your page, using headings, lists, and so on, is a big help not only to people who can see the page, but also to screen-reader users.
• Simple writing
  • Guideline 14 of the Web Content Accessibility Guidelines (WCAG) 1.0 is “Ensure that documents are clear and simple”.

In summary

• Content should be short and to the point.
• Put key information at the beginning and then elaborate.
• Structure is good. In particular, use sub-headings, short paragraphs of a few sentences, and lists.
• Don’t use jargon or slang.
• Don’t just paste in content from another source, be it a print document or the previous version of your website.
• Do an online version of a download unless it doesn’t translate for the web (e.g. too long or unsuitable for HTML).
• Keep your content up-to-date and accurate
• What next? Make it obvious.
• Keep accessibility in mind.

Further reading

If you’re interested in going into a bit more detail, here are a few resources to get you started:

• Queensland Government: web writing
• W3C checklist for Web Content Accessibility Guidelines (WCAG) 1.0
• The Guardian (A PDF version is freely available)
• The Plain English Society has before and after examples and a guide on writing in plain English
• Jakob Neilsen’s summary of how users read on the web (”they don’t”)

A quick thank you to Torchbox for letting me reproduce these guidelines here - I wrote these as part of my work there.

I was applying a fade-out effect to a news ticker, and all was going well (thank you Yahoo! User Interface library!) until I was ready to test in Internet Explorer. Unfortunately, as soon as the second news item was displayed, the text suddenly gained a strange border effect (perhaps a glow or halo effect might also describe it - but it isn’t pretty).

This is very easy to replicate in IE (either 6 or 7). Just apply filter:alpha(opacity=50); to some text and take a look. It’s worth noting that while this effect shows on any text on my Windows computer, it turned out to only do it for bold text on some. It’s possible that Microsoft’s ClearType font smoothing has somthing to do with this, but I have not looked into this in any detail.

At first I wasn’t concerned - I simply applied position:relative to the item with the opacity (this being a solution I’d come up with for a similar text effect in the past), and sure enough the text now looked fine.

However, I wasn’t yet done, it turned out: now the fade effect didn’t happen. My text changed from one item to the next, but did it instantly. I played around with the styling for a bit with no effect before the realisation that perhaps background colour might be the key - and sure enough, setting a background colour (but not transparent) solved it.

I mentioned having had a similar effect happen in a different situation. In that case, I wasn’t doing anything with opacity, but was showing and hiding different blocks of text within the same area of the page. I haven’t tried out specifying a background colour for that problem, but position:relative worked just fine, so my advice is:

If you get this border effect on your text, first try applying position:relative or set a background colour if that doesn’t work.

Firstly, a big thanks to Alan White for organising the conference, and of course to all the speakers.

Jeremy Keith kicked us off with an overview of progressive enhancement, paving the way for Mark Norman Francis to tie in graded browser support, as used by Yahoo!

Andy Budd brought CSS3 into the mix, talking about the “Future of CSS”, encouraging us to start making use of the parts which some browsers (essentially the major players other than Internet Explorer) already support; doing this will hopefully help to push the next CSS recommendation through, possibly in an intermediate step.

Drew McLellan delved into the possibilities of using microformats to throw in an API for our sites.

After a break for basking in the Edinburgh sunshine and eating lunch, Christian Heilmann took us through some principles of using Javascript and Ajax in the context of progressive enhancement, giving some great examples. James Edwards was hot on his heels with some warnings from the accessibility perspective - for example, the fact that screen readers partially support javascript means that our checks will detect the support and enable the functionality, but unfortunately they can’t handle a lot of the things which javascript can do.

Last but (as the old saying goes) by no means least, was Andy Clarke, encouraging us with ways to take things forward. A sneak preview of the new design for his website revealed his intention of using some of the CSS3 techniques to enhance the presentation in browsers which support them.

After a bit of Q&A, we piled off to the bar for a whisky or three. Photos to come…

The first thing to remember is that the link text should “identify the target of each link”. In other words, don’t use text like “click here”. Apart from the implication that the user must use a mouse, imagine what a screen reader user would have read out to them on tabbing from link to link and having the link text of each one read out!

The other aspect to this is that if your link text is misleading about the information available at the other end of the link, you could well waste people’s time. Consider how you feel when you follow a search result, only to find that the page you ended up on has no useful information.

My theory (just my theory - I’d be interested to hear other opinions) on the use of “click here” as link text is that it originally came about in the early days of the internet, when users were somewhat new to it all, and some of the people building websites tried to help users out by telling them where to click. Of course, the fact that links look / behave like links should is enough. Now we just need to get rid of some rather ingrained bad practice!

There’s also a slight catch which the advice on the W3C website doesn’t account for.

The advice given is that the title attribute should be used to help provide additional information about the target of different links, in particular where they share the same link text. This would be most useful for users of screen readers, but what is not so widely known, it seems, is that screen readers do not by default read out the title attribute.

Since the majority of screen reader users do not customise the settings of their readers (there are a couple of reasons for this, and I’ll be writing a post on screen readers in the near future), the title attribute is therefore of more limited use than it would first seem.

So, to summarise:

• Make sure the link text gives your users a good idea of where they’ll end up.
• Don’t use text like “click here”.
• Make use of the title attribute where appropriate, but remember that not everyone will get this information.

A quick recap (or introduction, if you weren’t there or haven’t seen my slides!):

An image’s alt text is presented to a user if their “user agent’ (the thing they’re using to browse web pages) does not display the image. e.g.

• A text browser is being used
• The user is blind and a screen reader reads out the web pages

Inclusion of the alt attribute on image (”<img>”) tags is required by the W3C specification.

If you’re an Internet Explorer user, you’ll very likely have seen alt text when you mouse over an image. That’s not actually what alt text is for, and it’s unfortunately encouraged a bit of bad practice because people have used it for detail which should go into the title attribute.

Images containing text

The alt text should say what the image says. For example, if you’ve got a pretty graphic which is trying to encourage your users to make a donation, then the alt text will be simply “Make a donation” or similar. Don’t describe the picture itself - that’s irrelevant.

Decorative images

When an image is purely decorative, the alt attribute should be left empty. Describing the image to your users is not necessary. Ideally, you will be using CSS to specify decorative images such as bullet points.

In summary

Always consider the context of the image when deciding on the appropriate alt text. Leave it blank if it’s going to duplicate information or if the image is actually on there to look pretty! The easy way to check whether you’re doing things correctly is to read out your page, including the alt text for each image, and making sure that it makes sense.

Other points to consider

• If your image contains a large amount of text, then you’ll probably need to use the longdesc attribute, which would contain a link to the full description. The alt text would be a brief summary to enable a user to decide whether following that link would be worthwhile.
• Make your images as accessible as possible. Consider:
  • Colour blind users
  • Try to keep images clear with reasonably-sized text

I hope you find this useful. Comments and questions welcome.

I did one of the “microslots” - a five minute talk on “Avoiding accessibility pitfalls”. This is of course a huge area, and one I’d happily talk for hours about, so I focussed on three areas in which I keep seeing people trip up:

1. Giving appropriate alt text
2. Correct use of link text
3. Using markup correctly

I’ll be elaborating on each of these areas in my next few posts; in the meantime, you can download my slides as a pdf.