This article is the third in a series of three where I look at some quick and easy tests that can be carried out to help determine whether or not a site is likely to be accessible. Of course, passing all of these tests wouldn’t guarantee that your site is accessible, but I think if you did pass all of the tests, it’s much more likely that people would find your site accessible. Again, bear in mind the checklist is intended as a quick n’ dirty guide.

The items break down into three broad areas: coding, content and function although these obviously overlap somewhat. Each article will focus on a different one of these broad areas.

This one will focus on function.

Relative fonts

Font sizes should be specified as % or em sizes only in your stylesheets and anywhere else they may occur. Fonts sizes in px units cannot be resized in Internet Explorer browsers prior to version 7.0. It shoudn’t do any real harm however to use px units for the sizings of margins, padding and so on (providing that the site doesn’t break if you resize the text!)

Note that this is only really necessary while commonly available browsers don’t support increasing the size in all cases — this may not be required in the future when if all browsers allow for easy text re-sizing or zooming irrespective of the units of measure specified.

Page layout does not break

You should test that the page layout at different text sizes. As an absolute minimum, the page layout should not break out of its boxes or overlap lines within two size increments either side of your default setting.

If you have a wheel mouse, hold down CTRL and scroll the wheel up or down to adjust the text size while the page is selected.

To alter the text size in Internet Explorer, select Text Size from the View menu (or Page menu if you’re on IE7) and then change your setting.

In Mozilla Firefox, select Text Size from the View menu and then either increase or decrease as appropriate.

Alt text

All non-text items should have an alt attribute specified (this usually means images but includes other <object>s as well).

Why do we need to specify alt text?

• Some people browse with images off — in the UK more than 70% of internet connections are broadband but this not the case everywhere else in the world, and if you’re on a poor connection you don’t want to download any unnecessary extras!
• People who use screen readers or refreshable Braille displays to access their computers can’t see images
• The images themselves aren’t understood by site spiders — if you want google to know you’ve got a picture of yourself with a pirate hat on for TLAP 2006, you’ll have to tell them

In each case, we need to ensure that the meaning of the image is provided elsewhere in the page. If it’s provided elsewhere in the main text where it is available to everyone, you can mark up your alt attribute as alt="". This will indicate that there is no additional meaning to be gained from the image.

If not, you’ll need to consider “what should the alt text be?”. Well, it depends. It not only depends on what the image is, it also depends on the meaning you’re conveying by it. Tommy Olsson covered this extremely well in his sitepoint article “Bulletproof HTML: 37 Steps to Perfect Markup”, which they’ve kindly given me permission to reprint this excerpt from:

Let us look at an example: say we have an image of a grazing cow. This particular cow happens to be an Aberdeen Angus. Let us then consider a few use cases for this image.

• In the first case, this image is used as a generic illustration for an article about beef cattle farming in Scotland. The actual cow isn’t germane to the article; it’s just an illustration, a decorative design element that draws the reader’s eye and relieves the monotony of the text. In this case, the image doesn’t convey any relevant information. Therefore it should have an empty text equivalent: alt="".
• In the second case, the image is used on a children’s web site about farm animals. The page shows pictures of various animals: a horse, a sheep, a pig, a cow, etc. Next to each image is a block of text that presents some facts about each species. In this case, alt="Cow:" could be appropriate. It’s not important that it’s an Aberdeen Angus; the picture represents bovine quadrupeds in general.
• In the third case, the image is used on a site about different breeds of cattle. Here it is used to illustrate what an Aberdeen Angus looks like, and how it is different from other breeds. The page comprises a number of images, each with a caption that identifies the breed, but no other textual information. In this case, the text equivalent should describe the particular attributes and traits that are specific to an Aberdeen Angus: the robust build, the massive chest, the relatively short legs, the buffalo-like hump behind the head, etc.
• In the fourth case, the image is used on a photographer’s portfolio page. It’s one image among several others, with very different motifs. This is one of the few cases where the alt attribute might actually include a description of the image itself, e.g., “A black Aberdeen Angus grazing in the sunshine with Ben Nevis in the background.”

Bulletproof HTML: 37 Steps to Perfect Markup

Colour indicating meaning

No information should be provided by colour alone as this will be unavailable to blind users with a screen reader or to colour blind users, or to any users who for some obscure reason are using a monochrome monitor. It is acceptable to use colour as well as something else to provide information — some users will get the benefit of the colour and the other thing, but users who don’t have access to the colour will still be ok.

• Don’t: All fields indicated in red are mandatory
• Do: All fields indicated by * are mandatory

New windows and popups

Do not cause a new window or a pop-up to open unless the user is warned first (ideally in the link text itself), but failing that, in either the title attribute of the link or in the sentence containing the link.

Opening links in a new window breaks the usual and expected behaviour of the internet — that users can get back to where they used to be by selecting “back” in their browser.

Logical tab order

Ensure that if you tab through a page — in particular a page with a form on it — ensure that you progress through the page in the same logical manner that you would normally expect.

If you tab through and the first thing you come to is “reset” followed by “name”, “address” and then “submit”, users — particularly screen reader users — may be rather infuriated when they find they weren’t taken to the mandatory field “postcode” because the submit button appeared first. It would similarly seem illogical to ask for first name, postcode, surname, address…

System works using the keyboard only

Many users with mobility difficulties are unable to use a mouse. You should therefore ensure that all of the functions on the page can be accessed solely by using your keyboard.

This would normally ensure that the page does not rely on mouse only events (onclick, hover etc), that it does not use any drop down menus which trigger automatically on selection, and that any highlighting of active elements occurs when they are tabbed to as well as hovered over.

Controls with Labels

Each form element should have a label explicitly associated with it, using the for attribute of the label.. This will mean that when a screen reader user enters a form field, their software will tell them the type of field, and then read out any label that is associated with it.

If there’s no label associated with it, they’ll hear something like “Input”, when they encounter an input box, which isn’t particularly helpful. On the other hand, mark up your labels correctly and they’ll hear “Input first name” … which is obviously a lot more useful!

System works with no unhandled errors

You’d think this would be blatantly obvious, but it’s surprising the number of sites where you encounter unhandled errors. The system should carry out all of its functions, all which should work as expected and it should not generate any unhandled errors. If any functions do not work or any unhandled errors are generated then the system is not ready to go live.

Javascript for enhancements

A common misconception is that in order to make sites accessible, javascript should not be used. This is not the case. It is possible to offer javascript to enhance features on the website — for example to allow someone to input their house number and postcode and have their full address returned — provided that the user can still carry out all of the normal features of the website even if javascript was disabled, inoperative, or partially operative. In this case, simply allowing the user to add the address manually would be sufficient.

You can switch off javascript to test how well websites work without it in one of the following ways:

• Using the Web Accessibility Toolbarfor Internet Explorer or Opera, and select “Toggle Javascript” from the IE options menu so that it is not selected (and toggle again to switch it back on later).
• Using the Web Developer Toolbar for Mozilla Firefox, select “Disable Javascript” from the “Disable” menu (and toggle again to re-enable it later).

Note that in both cases the toolbars use javascript to carry out some of the other functions, and so you should re-enable javascript once you have carried out site testing without it.

Alternate browser testing

For all internet applications it is important to consider that just because you use a specific browser, there are no guarantees you’re your users will be using the same browser. Try to test your sites on as many browsers and platforms as possible.