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.
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.
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.
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.
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 www.webaccessstrategies.com 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.
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
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.
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
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
- WCAG requirements
- Web accessibility techniques
- Building accessible websites
- Good guide to semantic HTM
In the next part of this series, we will look at hearing impairments.