Category Archives: HTML

Building Accessible Websites – Part 1: Visual Impairment

The statistics from the RNIB show that 5.9 children in 10,000 have some kind of visual impairment. There are around 80,000 people in the UK that are registered as blind or partially sighted. That is a significant number of people, and if your website can expect a reasonable amount of traffic it is a number you should be paying attention to. Quite apart from that, it is a legal requirement that we do not discriminate against people in any way. If your data is public, everyone should have access to it.

The Disability Discrimination Act makes it unlawful for a service provider to discriminate against a disabled person by refusing to provide any service which it provides to members of the public. From webcredible.

Fortunately, building websites in a semantic and SEO-friendly manner has the side effect of making a site that is likely to be screen-reader friendly. That is – if you are building websites well, the issues this kind of impairment presents are less problematic than you might expect.

Screen readers

Users who are considerably visually impaired will employ some kind of screen reader to help them use their computer. For the web, this is a tool the gives the user methods to hear the text on a site, and quickly jump to sections of a page. A lot of screen readers are available, and they all work in slightly different ways (like web browsers or mobile web browsers). They are very expensive to upgrade, and upgrades are available often, and because of this it is my experience that many users do not often upgrade screen readers. Many screen readers do not allow JavaScript, and those that do typically make it easy to disable. I usually make the assumption that a screen reader user will have JavaScript disabled, although where easy I do anything I can to make JavaScript as screen reader friendly as possible. A lot of JavaScript enhancements for a user with normal eyesight will not be of much use to a screen reader user anyway. Having watched experienced users of screen readers, I can say that they are able to make use of an accessible website very quickly indeed, and listen to the text being read out at upwards of 180 words per minute! At that speed, to me it just sounds like gibberish. Apple’s VoiceOver can apparently speak intelligibly at over 750 words per minute.

Using a Firefox extension such as Fangs will let you emulate a screen reader’s behaviour, to a degree. Use this to help you get the hang of building a page in a linear fashion – remembering you need to describe things before they happen, not after.

Semantic HTML

The first rule is to apply POSH to all of your content. This is an important rule anyway, for the semantic web. The importance of this is beyond the scope of this article, and I will revisit it in a dedicated blog entry in the future. Most screen readers are able to quickly offer the user an audible representation of an outline of the document, for example, all of the level two headings on a page, or all of the forms on a page. Using POSH has many other benefits including SEO, consistent and higher quality code, validating code and future-proofing.

Skip links

Using in-page anchors to allow the user to jump to sections of the page is vital. At the very least they allow the user to jump straight to the navigation and the main content. If these anchors do not fit your design, use CSS to give these position: absolute; and left:-9999px;. Although we cannot guarantee this in the future, current screen readers typically will not read out content that is display: none; or visibility: hidden; (assuming, correctly that it is not visible) but they will read out content that is positioned off-screen. To make these more useful you can use a CSS :focus selector to bring these links back into view when the user uses the keyboard to tab to them, benefiting all other users at the same time. Use the same trick for “Back to Top” links and your user now has a way to leap around your page, without having to listen to all the content.

Consider links as holistic entities

Users of some screen readers have the ability to immediately list (audibly) all of the links on a page. These are (usually) listed one at a time, as the text (or alt text) inside the anchor tags. This means if your text says something like “click here to go to website A”, a screen read user will hear just the word “here”. If you have this all over the page they will hear just “here”, “here”, “here” and so on, which is not useful – in fact, very frustrating. Instead, try to make the links an entity in their own right, something more like “go to website A“. Where this is difficult, for example at the end of an excerpt from an article you might have a link that says “more…” that takes you to a page that details the entire article. You could actually surround this in other text so the text says “more about this article on wombats…” and ” about this article on wombats” is in a span which employs the same trick as above to take it out of the flow and position it off-screen.

AJAX/DOM hooks

When you use JavaScript to modify the contents of the page (perhaps as a result of an AJAX call), the screen reader may be reading at a position below that point. The screen reader may not notice that the contents of the page have been changed, meaning the user will have to start reading the page again at the top to find the change. There are methods you can employ to try to give a screen reader hints that the page has changed, and to offer the user a chance to leap to that point. The full extent of this is beyong the scope of this article, but ajaxian provide a great guide to accessible AJAX best practices.

Frames/iFrames == Bad

Quite aside from the plethora of other reasons you should be avoiding frames, they make the life of a screen reader very difficult. Which frame should we currently be reading? When do we jump focus to another? How do we present audibly that these are different entities, if in fact they are? Frames were designed to help solve a problem, but they ultimately just create more problems says and I concur.


Most operating systems give the user the ability to zoom in on any part of their screen. This works operating system wide, not just for web browsers. Applications can be acquired to achieve the same end, and this is really how accessibility should be handled – in a consistent, system-wide fashion. Since all these are doing is helping the user focus on a section of the page, the only caveat here is to remember to try to stop our paragraphs or blocks of text from being too wide (within reason) so the user does not have to endlessly jump back and forth to read sentences. Keeping our text in reasonable width blocks like this will also help some people with learning disabilities (to be covered in a future post) to read our content.


CAPTCHAs help us try to ensure our website is being accessed by a real person. It is vital to accept these are not fool-proof. A computer program can be formulated to read any text that we can, especially if the operational parameters of a particular CAPTCHA can be figured out. Even if you are really clever (recently I saw a CAPTCHA showing nine women, one of which was clearly more attractive than the others) techniques can be used to get around this. One pornographic site presented users with a CAPTCHA from Yahoo! when they were signing up, so that without knowing, they were actually helping the site build fake Yahoo! accounts in the background. (CNET story.)

Whilst they cannot be relied upon, CAPTCHAs just make it that bit more difficult for someone trying to abuse your site. As we know, in essence, they present you with an image and ask you questions about it. It is possible to also present this data audibly, but by now this is a huge undertaking to do well, and one more thing you don’t really need to be developing and supporting. To address these issues, I cannot recommend the reCAPTCHA project enough. Not only are you using an API to implement a mature and working CAPTCHA with audio and skinning support, your users are also helping to digitise books! Read more at the reCAPTCHA site for details.

Scalable text

The text on your site should all be in a relative unit be in based on percentages or “ems”. According to Wikipedia An em is a unit of measurement in the field of typography, equal to the point size of the current font.. You should be able, as a rule of thumb (my thumb, in this case) to resize your font up or down by two sizes. Resizing up has an obvious value – it makes the text easier to read. I have even done this. Running a Mac Mini on a big screen TV at HD resolution actually makes text impossible to read. Until we get resolution independence, jumping the font size up a couple of sizes provides a quick fix. You also need to be able to turn the font-size down, which may surprise some people but it’s important that text remains readable even when using the “Smallest” setting. This is important for users with tunnel vision who may wish to fit as much text in their line of sight as possible (from the RNIB Web Access Center).

The most recent browsers are now starting to scale up the entire page when the user chooses to increase font-size (though they can sometimes choose to isolate this effect to text only) resulting in pixelly graphics, but maintaining layout. For maximum compatibility, liquid layouts will cope better with text-only font size changes, and can help maximise the use of a browser’s screen estate at different resolutions. I recommend not going over the top with this. Supporting resolutions of 800 x 600 up to 1440 x 900 is a reasonable thing to do, but although supporting an HD resolution might be technically impressive, an entire paragraph on a single line is not easy to read, nor does it normally look attractive.

Colour blindness

The BBC has a tool (internally referred to as “Barlesque”) which allows the user to set various display options according to their impairment. Several colour schemes are available, which are appropriate for different levels and types of colour blindness. These sittings change a stylesheet which is applied to the site, for different colour schemes which users will find easier to read. For those of us who cannot afford the luxury of implementing this kind of functionality, our goal must be to expect a reasonable lever of contrast between text and the background. Snooks have a tool to tell you the brightness and colour difference between two colours, and whether or not the contrast ratio is acceptable. I would suggest their acceptable levels are a bit unrealistic, and you should be trying to aim for 125 or more brightness difference, and 400 or more colour difference. Access Keys also provide a tool to scan an entire page and give you a report on the contrast of text on that page.

Images and alt text

Images should only have alt text where the image has value as content. Alt text is “alternate” text. This means it is an alternative to the image, for users who have chosen not to download images or are not able to view them. If a link is an image that has the text “Order Now” on it, it needs an alt attribute that says “Order Now”. If it is a swirly blue pattern, or someone looking happy using a computer, or any other kind of image that does not provide value to the page other than aesthetically, it does not need alt text. It does need to have an alt attribute, to validate, but that attribute can be empty.

Where you have extra information to include such as copyright data for an image, or detailed descriptions of the location the title attribute is more appropriate. Where this information is very lengthy, the longdesc attribute can contain the address of a page with more details.

Pet hate: it is not an alt tag! It is alt text, or (more accurately) an alt attribute.


Try your absolute hardest to keep the layout and style of your pages consistent. If the user can always expect to find the content here and the navigation here, they can learn to navigate your site more efficiently very quickly. If you are employing skip links too, they will rapidly learn where these are and where they lead.

Some extra resources

In the next part of this series, we will look at hearing impairments.

If you have to make your own dropdown list boxes…

The dropdown list box, or select box, is a massively useful UI tool. It presents a series of predefined options in a format that doesn’t have to eat up all our screen estate. Unfortunately though, we just don’t have the ability to style this that we would like. Or, sometimes none at all. Since this is an OS control, the OS takes control – and apart from the visual implications this is no bad thing. If you absolutely have to have it match the design for the rest of your site though, you have no choice but to implement it yourself. You can achieve this either via JavaScript or Flash. Flash is probably overkill if the rest of your site doesn’t use it, so if you use JavaScript I would heavily advocate the use of progressive enhancement to start with something that works (the select tag) and build something nicer on DOM ready.

If you’re recreating something the OS does though, please try to do it as well as the OS does!

Here’s a useful list of behaviours for a dropdown list box which might seem obvious, but I have seen overlooked so many times.

  • Priority 1
    • Display the current selection in the unexpanded box
    • Display a downwards arrow to the right of the box to indicate it has a dropdown
    • When clicking the box, or the arrow, expand to offer other selections, and when clicking one of those, contract the box and display the exact text for that selection in the box
  • Priority 2
    • Allow keyboard navigation – up and down should move amongst the items, highlighting as appropriate and return should select them as if the user had clicked them
    • Allow keyboard shortcuts – pressing a character should jump the selection to items beginning with that character
  • Priority 3
    • Spacial awareness – where there is no space for a dropdown to appear beneath, or it would appear outside of the viewport, it should appear above instead
    • Dimensional awareness – where there are too many items to display reasonably a scroll bar should display to keep the entire dropdown box in view

I have seen instances where many of these have been ignored, and in the very worst case, where selecting an item showed completely different text in the contracted box. Even an instance where the text displayed actually matched a completely different item in the list!

Hope this helps. AK