Partially sighted (but not blind) users fall into one of two key groups. Those that find it hard to focus will benefit from clear, simple, medium-weighted fonts and large font sizes.^[37] Allowing them the ability to change font sizes and fonts within your website will make their lives easier. Ensuring you use relative values for font sizes will also let them use the built-in device methods for adjusting font size, and avoiding !important declarations will help ensure that you don't override any settings they may have made themselves.

Those that have a narrow field of vision (who can only focus on small areas of the screen at a time) will benefit from the ability to turn the font size down so that paragraphs take up less space onscreen. These users are more likely to zoom the entire website out, but everyone is different. You should always ensure that you have tested the site to be certain that you can turn the font size up and down by two steps within the browser without breaking the layout.

Blind users are very likely to use screen readers (which we mention in a dedicated section later in this chapter). They also browse websites in a very different way from sighted users. They are likely to want to skip directly to sections of the website, access lists of all of the links in a page, or access an outline of the page built up out of the headings in the markup. Avoid language that points to specific physical positions on the page (for example, "click the link in the top-right corner") and use WAI-ARIA, semantics, and microformats. Newer technologies will be able to take advantage of these.

Colorblind users may use their own style sheets or turn off CSS altogether. Offering them various alternative color schemes can be a great help to them and allows your organization to maintain control of its brand and ensure that your website remains attractive. We reference some tools to simulate colorblindness and check for problems with your color schemes later in this chapter.

Degrees of motor impairment can vary dramatically. In most cases, these users are already using their own assistive technologies to enable and empower them to use their devices, but there are small things we can do to help, like making clickable areas clear and as large as possible. Whenever possible, make sure the target areas of your links don't require a great deal of precision to be clicked on.^[38] These considerations also apply to users with touch interfaces such as smartphones or tablets.

In many cases (such as tabs or buttons), not making the clickable area the size of the container is a confusing user experience, anyway.

Users with partial or complete deafness are generally less challenged with accessibility issues on the Internet, other than with specific audio or video content. Most websites don't (or definitely shouldn't!) play audio,^[39] and as such will work for the hearing impaired just as well as for other users. You should avoid using sound alone to indicate any kind of state or information on your page. If your site presents audio or video as part of its primary purpose, you need to consider captioning for these pieces of media.

Open captioning is captioning that is "burned in" to the media it is associated with; for example, subtitles in a film that cannot be turned off. It is called "open" because it is shown by default. Closed captioning is textual data associated with the media that is stored in text format and served alongside the video. Televisions, for example, have long been legally required to provide a closed captioning decoder. Closed captioning has the benefit of allowing several different "tracks" of text; for example, different languages or descriptions of sounds as well as conversation. It can be used with audio as lyrics for karaoke because it is time-coded. It also has the benefit of allowing us to potentially style the text with CSS (different positions to avoid important video elements, colors to represent different people, and so on).

Closed captioning sadly has poor support so far on the Web and many different solutions. HTML5 as yet does not have official support for closed captioning, but proven methods are already being implemented and standardization is sure to follow.^[40]

For now, the CSS considerations for closed captioning depend very much upon your implementation, and a transcript is the only foolproof method for exposing this data. You can read more about captioning at http://webaim.org/techniques/captions/.

It is also important to be aware that those who were born deaf will likely have learned sign language as their first language. This means that English (or their local language) is akin to a second language for them, and therefore expressions, jargon, and colloquialisms may be harder for them to understand. For that reason, clear language is just as important as ever.

Cognitive impairments, such as dyslexia or autism, can make it difficult for users to process information. Typically, this kind of impairment is addressed with clear, unambiguous copy but there are other things you can do, too. Making layouts consistent and maintaining the positions of key elements like navigation will make life easier for all your users, but especially for those with cognitive impairments or learning disabilities. The same applies to not using too many different fonts (although the website should be flexible enough so that it is easy for users to specify their preferred font). Also, make sure there is enough space between lines, as this makes it easier for text to be read (a line-height value of 1.5 for normal text is a good default).

Dyslexia is a very common impairment, and although no accurate studies have been carried out, it is believed that dyslexia affects between 5 and 10 percent of the population. Dyslexics can suffer from a whole assortment of learning or cognitive impairments, which is why this particular problem is referred to so frequently when accessibility is mentioned. Some dyslexics prefer to print out pages rather than having to read the text on a screen. This is just one of various reasons why someone would print a page.

If you are not developing a website that is specifically targeted at dyslexics, it should not be necessary to proof every single detail of your website to be dyslexic-friendly, but you should remember that the most important factor in this situation is that users can customize the pages they visit to suit their very particular needs, making it easier to read and understand the content.

Young users are as likely as anyone else to suffer many of the other impairments on this list, but they can also be considered to have a kind of cognitive impairment, in that you should use simple, clear language. Sites designed for children are also some of the only valid places to use the Comic Sans font, although some dyslexics may also find it easier to read.

Older users can suffer any or many of the impairments on this list (apart from the one directly previous, of course). In particular, sight and hearing deteriorate with age. As such, if you are making sure that your websites are accessible, you have probably designed a website that is already accessible to older users. They may also be unfamiliar or unskilled with computers, so avoiding technical jargon and working with common visual associations works well.

Epileptic users specifically may react badly to flickering or flashing pages, or elements within pages. It is law in many countries to provide a warning before presenting this kind of media. Avoid animations or Flashes of Unstyled Content (FOUC).

Accessibility problems don't necessarily mean a physical or psychological problem with the user. It might mean simply that the device or environment they are using to visit your website has lower capabilities than expected.

Let's look at a list of common problems that might translate into accessibility impairments that are not physiological:

There are no definitive numbers that can tell us how many users might fall into any of these categories. In many cases, they will probably be temporary impairments (they might be trying to verify some information while on the go, or using someone else's or their work's computer). But if we take the first issue alone and look at some statistics of how many users are still navigating the Web with older browsers, while not significant for many low-traffic websites, on high-traffic websites even small percentage numbers can translate into tens of thousands of visitors per day. Also, IE 6 usage may have dropped to around 4 or 5 percent of all Internet traffic worldwide, but it still makes up more than 12 percent of traffic for Africa. If your website gets worldwide traffic, looking at the statistics for the world rather than breaking them down by country can be misleading.^[41]

You can read more about how to help users suffering from device and environmental impairments later in this chapter.

Different countries have different sets of laws that regulate accessibility. Usually they tend to be not exclusively related to the Web, but acts against discrimination toward people with disabilities and promoting equality.

In the UK, there is the Disability Discrimination Act (DDA) of 1995, which also makes reference to websites. The vital text from the Code of Practice is this: "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."

The Royal National Institute for the Blind (RNIB) and the Disability Rights Commission (DRC) have pushed for legal action with regard to the DDA. The RNIB has approached two large websites that made the demanded changes to avoid legal action and maintain their anonymity. The DRC investigated 1,000 sites, and found that more than 80 percent of them were in conflict with the DDA requirements. Those sites were threatened with unlimited compensation payments and legal action.

In the United States, the Americans with Disabilities Act (ADA) serves the same purpose. It applies not just to websites but also to any service covering buildings, medical care, and telephones, to name but a few.

It is not uncommon for big organizations to be sued by consumer associations for their poor accessibility standards, which lock thousands of users with disabilities out of their websites and their content. There are precedents where the plaintiff has won large sums of money with these cases. For high-traffic and high-profile websites, this is a much more real threat and something that should not be taken lightly.

It is likely that the WCAG guidelines will be used in the case of legal action. The EU recommended level of compliance is Priority 2. We recommend trying to satisfy Priority 2 as a minimum and striving to satisfy Priority 3 where possible.^[43]

Screen readers are not a tool exclusive to users with visual impairments. Users with other types of disabilities find in screen readers an efficient and more tolerable way of browsing the Internet (for example, when tired, finding it hard to concentrate, or busy doing something else), something that presents content in a linear fashion, without imposing on them behaviors that might make them more anxious, making it harder to understand the content. This brings the percentage of potential screen reader users up.

Like browsers, screen readers receive updates, and each update adds support for new functionalities. And, just like browsers, users don't necessarily update their screen reader software. One of the main reasons for this is cost. Screen readers are not trivial to build and are typically targeted at a niche market. As such, they are usually very expensive. The capabilities and behaviors of screen readers differ dramatically. VoiceOver (http://www.apple.com/accessibility/voiceover/) is an Apple screen reader that is free as part of OS X and is fully featured. If you are using a Mac, we recommend trying it out to introduce you to some of the issues your users will face. It is a genuinely enlightening experience. Press Command-F5 to turn VoiceOver on or off at any time. Windows has also included its basic screen reader, Windows Narrator, since Windows 2000.

Screen readers present methods of interacting with websites that are different from those used by sighted users. VoiceOver calls this the Web Item Rotor. This lets the user bring up lists of links, headings, and so on, and navigate straight to them instead of being forced to navigate through the website in a linear fashion until they find what they are looking for. This quickly surfaces many obvious accessibility problems. VoiceOver also presents visually what it speaks out loud. Figures 6-1, 6-2, and 6-3 show some examples.

Figure 6-1. Wikipedia presents the user with sensible links, although there are 306 of them.

Figure 6-2. CNN has a reasonable list of headings, although the heading levels are confusing.

Figure 6-3. McDonald's only uses images for its links, with no title attributes. It gets worse, but let's move on.

Dealing with screen readers has a few considerations the CSS author should take into account.

All these techniques will help your screen reader users, and also search engines and users of other unexpected devices in the future! To do a basic test, try turning your CSS off and verifying that the content still makes sense. However, we cannot understate the value of using your site with a screen reader yourself; some of the problems you will encounter are so easy to fix and so obvious that you will kick yourself, and your users will love you for fixing them.

The speech and (deprecated) aural media types are intended to help you target CSS at screen readers specifically. There are three reasons we suggest you avoid this technique.

We are far better off dealing with as much as we can in a single style sheet, except in very specific and unlikely scenarios.

Often we will hide HTML elements from the visual representation of our page, using CSS properties such as display, visibility, or text-indent. For example, if we are replacing a heading with an image, we might use something similar to the following code:

h2 {
   background: url(img/heading.png) no-repeat;
   text-indent: -9999px;
}

By doing this, the original text is moved so far from the center of the page that it is now not visible, and instead we see the intended background, which usually contains text set in a custom non-web-safe font.^[44]

Another common scenario is markup such as the following:

<a href="page.html">Read more</a>.

A screen reader being used to access lists of links will simply announce "Read more" with no context, often many times on a single page. This is very frustrating for the user.^[45]

Providing a class for our publishers to hook into solves this issue gracefully. Here's another example of the markup:

<a href="page.html">Read more <span class="accessible">about the exploding lemming epidemic</span></a>.

And here's the CSS we could use with it:

.accessible {
   position: absolute;
   text-indent: -9999px;
}

Now, although the page looks visually exactly as it did before, the screen reader will read out "Read more about the exploding lemming epidemic," which makes sense out of context.^[46]

Even though display:none or visibility:hidden seem like valid solutions—and it is true of some screen readers that as long as the text is present in the markup, they will read it—this is not true for all screen readers. The text-indent we have suggested is currently the best solution we have for this problem. Users visiting the page with CSS disabled may see slightly more verbose text, but this is an acceptable compromise.

Some users may not have the motor skills to use a mouse, or may just not have access to one. For these users, providing a focus state for links is vital, as a keyboard-only user can easily lose track of which link is selected if there isn't a visual indication of it. It may be tempting to hide the outline for links that are focused for aesthetic reasons, but if you do this make sure you provide some kind of visual alternative. Don't rely on hover for access to content or anything important, since you cannot guarantee that users will have a hover state (for example, when using a touch screen device).

There are many other devices users can use to make the Internet more accessible:

Again, these devices seek to solve problems on their own. If you follow the best practices outlined in this chapter, you will be doing the best you can to step out of their way and let them get on with it.

Accessibility starts from the foundations that you are building upon (the HTML that marks up your content) but also goes farther up the ladder to the colors that you use on your website and even its behaviors.

Color impairments don't necessarily translate into a user with poor sight or colorblindness (to give only a couple of examples), it might be simply that the user is visiting your website using a screen that is not as well calibrated or expensive as the designer's that created the layout, the almost unnoticeably different shades of gray that you are using to convey the distinction between simple text and links might become imperceptible—for that user, your links are invisible.

As a basic guideline, you should always make sure there is enough contrast between background and foreground. Also remember that some users prefer low-contrast color schemes (and other very high-contrast color schemes such as lime or yellow text on black). While it may not be possible for you to provide all the alternatives, again, you should make it as easy as possible for your users to customize the colors of your website to the settings that are most comfortable to them.

As mentioned previously, this is a process that starts in the designer's hands, but can be checked during the implementation phase, too.

Besides differentiating links by color (with enough contrast), differentiating them from the rest of the text by shape (for example, making them bold, or underlined—which is universally recognized as the styling of a link) can help colorblind users to easily distinguish links from the rest of the text. To go a step farther, you can add bottom borders to links instead of the default text underline, which can make text harder to read since it runs across descenders (letters like j or g have descenders). You would also need a little padding to ensure that a gap exists between the text and the underline. For this, you would use the following CSS:

a {
 text-decoration: none;
 padding-bottom: 2px;
 border-bottom: 1px solid #333333;
}

In the preceding example, we only included the generic a element selector, but you should always make sure you have a different style for visited, hovered, active, and focused links.^[47]

A complete default link style could be the following:

a, a:link {
 color: #333333;
 text-decoration: none;
 padding-bottom: 2px;
 border-bottom: 1px solid #333333;
}
a:visited {
 color: #6e5252;
border-bottom-color: #6e5252;
}
a:hover, a:active, a:focus {
 color: #e89121;
border-bottom-color: #e89121;
}

As we have already stressed, it is vital to ensure that your links have a visual indication of being focused, as keyboard users can easily lose track of where they are in the page.

It is also very important that the order of these selectors is correct. Let's see why. These are pseudo-class selectors; the :link (unvisited) and :visited pseudo-classes are mutually exclusive, while :hover, :active and :focus are not (they can be used with each other or even in conjunction with :link and :visited). All the selectors (bar the a selector, which has fewer) in the preceding code snippet have a specificity of 0,0,1,1 (one element selector and one pseudo-class selector—you can read Chapter 3 for more detail on specificity), and that means that any of the selectors can override all the others by coming last in the code. Knowing this, we define the :link and :visited states before the other ones—if they were defined last, we would never see the other states, as they would be overridden by either the unvisited or visited states.

There are several tools online that can help you to see your websites through the eyes of someone with visual disabilities:

Don't panic when you see a long list of errors when you test your website's color contrast, though. This does not mean that all your content is inaccessible; you may choose to leave areas that don't have enough contrast, but also don't hold content, as they are.

When comparing color contrast, the specified thresholds may be too restrictive and unrealistic for your designers to work with. Instead, aim for at least 125 brightness difference and at least 400 color difference.

While not the same as testing the accessibility of your website with a real user, and experiencing his difficulties that you might have overseen, checking for cases where there is poor color contrast using these tools will put you one step closer to catering for the widest audience possible. Imagine the frustration that a user with colorblindness would feel were he faced with a poor contrasting navigation! If he can't read the text, how will he find anything on your website?

The BBC's accessibility site (see Figure 6-4) uses a system called Barlesque to deal with user problems with color.

Figure 6-4. The BBC's accessibility site

This page includes a small panel that allows users to change their font size (sadly, only two steps are available and both are higher than the default setting, but this can be easily set in the browser preferences) and color scheme. Aside from the default color scheme, there are options for an entirely blue color scheme (for colorblind users), a high-visibility color scheme (for users with poor eyesight), and a soft color scheme (for users with eye strain). These settings are saved and applied to the site via dynamic style sheets (read more about these in Chapter 9) and custom image paths. Although these settings once used to apply to all of the BBC's many sites using the "BBC Barlesque" template, it seems that this methodology has fallen from favor. This is a great shame since it presented a fantastic demonstration of the best way to cope with these color schemes, although managing them was difficult.

User style sheets and alternate style sheets (read about those later in this chapter) can still be used to achieve the same result.

Modern browsers have built-in page zooming, which enlarges the entire page, including fonts, images, layout elements, and so on. But this is not the silver bullet that saves us from having to deal with the eternal font zooming problem in older browsers, especially when dealing with high-traffic websites, where 5 percent of the visitors using Internet Explorer 6 might mean more than 50,000 visitors and potential clients. Zooming the page can also have negative side effects, like horizontal scrolling and less legible content (even though the opposite is the intent).

An alternative exists (and many use it): to zoom only the text. Let's look at a comparison. Figure 6-5 shows a news article on Yahoo!, which has been zoomed in by one step using the default full page zooming:

Figure 6-5. A Yahoo! News article, zoomed in one step

Figure 6-6 shows the same article, zoomed in one step with Zoom Text Only enabled:

Figure 6-6. A Yahoo! News article zoomed in one step with Zoom Text Only enabled

As you can see, the first method immediately introduced horizontal scrolling and began to crop content on the right side of the screen. The second method zoomed text by the same level, but maintained the layout, while also avoiding the pixelation of images. There is no problem if your users prefer to use the default method: they are used to it, and your website will likely behave exactly as everyone else's. However, if they choose to only zoom the text (or have a browser that only supports this method), you should cater for them. You can do this by making an effort to use relative font sizes.

Because an em is a unit that is dependent on font size, changing the font size on the page with Zoom Text Only will affect all the elements that are sized using ems, not just the text. When developing for IE 6, it may be tempting to size everything in ems so that IE 6 exhibits the same zooming behavior as other browsers' defaults (zooming the entire page). However, this choice would preclude users from only zooming the text and as such is an inaccessible technique.

For fixed-sized elements such as images, pixels are the most sensible option. Older browsers will fail to zoom them, and newer browsers will zoom them in proportion with the rest of the page. Either way, the images will become pixelated, but the text is usually the most important part of the content.

For liquid widths, or dimensions that depend upon the size of the viewport or their container, percentages are the most appropriate unit to use. These sizes can change dynamically as you resize the window or by other means modify the dimensions of the window or parent elements.

Users with learning disabilities such as dyslexia may find it easier to read text set in particular fonts. There is not a rule that can be followed that caters for every scenario, as some people prefer to read sans-serif fonts, others find it easier to read serif fonts, and some will even prefer specific fonts like Comic Sans. We do not recommend that you use Comic Sans across your websites, though, or even to restrict yourself to using just certain fonts that have been proved to be favored by many dyslexics. The important thing to retain here is that the more flexibly your websites are built, avoiding image replacement and trying to use plain text wherever possible (even if that sometimes means compromising the design at some levels) will make it a lot easier for users to browse your website the way they want to.

Your website should pass the text increasing test. Increasing or reducing the text size by one or two sizes (or steps) should not be a problem for your layout.

A common issue with using font-face services (mentioned in greater detail in Chapter 5) is the Flash of Unstyled Text (FOUT) that the page suffers in some browsers from when the page hasn't yet loaded the embedded font to when it is fully loaded. For dyslexics, this behavior can render a page impossible to read as they favor consistency of layout, where the elements maintain the same position throughout all the pages of a website; sudden changes (like for example, a flashy hover behavior) make it hard for the user to follow and understand the content.

A simple way of trying to minimize this problem is to follow the recommendation mentioned in Chapter 5: make sure the fallback font that the browser will render before downloading the preferred font is as close in aspect ratio as possible to the embedded one. This will make the jump less obtrusive or (ideally) unnoticeable.

You can also use alternative style sheets (covered in the "Style Switchers" section later in this chapter) to disabled jarring animations or interaction behaviors.

User style sheets (mentioned in Chapter 3) can play an important role in aiding users with disabilities to adapt websites to their needs. Making sure your (author) style sheets lend themselves to be easily overridden (mainly by not having complicated and overly specific selectors and avoiding the !important keyword) will make these users' lives a lot easier.

Another thing you can do to make it easier for users to customize your site is to provide hooks, in the shape of body classes or IDs, that they can use on their style sheets. For example, if you add two classes to the body element of your pages (one that is site-wide and another that is page-specific), it will be a lot easier for the user to create rules that affect only your site or a specific page (or section) that they have particular problems with (or visit often).

Having a user create a user style sheet for your site does not mean you failed in making sure your website is accessible. It is impossible to cater for every possible scenario. Just make sure to have flexible enough CSS so as not to make this task harder for the user.

Alternate style sheets can be put in place with simple link tags. Three different types of style sheet exist: persistent, preferred, and alternate. Persistent style sheets simply use the link tag with a rel attribute of "stylesheet" and no title, like so:

<link rel="stylesheet" href="persistent.css" />

Persistent style sheets will not be replaced if the user selects an alternate style sheet. Preferred style sheets look the same, but with a title tag:

<link rel="stylesheet" href="preferred.css" title="Basic" />

You can group several preferred style sheets together by giving them the same title:

<link rel="stylesheet" href="preferred1.css" title="Basic" />
<link rel="stylesheet" href="preferred2.css" title="Basic" />
<link rel="stylesheet" href="preferred3.css" title="Basic" />

Alternate style sheets will entirely replace the preferred style sheets. These are included in exactly the same way as preferred style sheets, but with a rel attribute of "alternate stylesheet". Again, you can group multiple files by duplicating the title:

<link rel="alternate stylesheet" href="alternate1.css" title="Alternate" />
<link rel="alternate stylesheet" href="alternate2.css" title="Alternate" />
<link rel="alternate stylesheet" href="alternate3.css" title="Alternate" />

The user can then switch between style sheets in the browser (see Figures 6-7 and 6-8).

Figure 6-7. The style switcher in Firefox

Figure 6-8. The style switcher in Opera

Unfortunately, there are two major caveats to this otherwise perfect technique:

To offer genuine alternate style sheets' functionality and present it as part of your website's tools, allowing the user to choose, for example, a high-visibility color scheme, you need to write your own code. This entails JavaScript, but is fairly trivial to achieve.

Be aware, as always, that these style sheets will still download regardless of whether or not they are applied. As a result, apart from sites specifically targeted at users with impairments that alternate style sheets can help with, it is often better to simply ensure that it is easy for your users to override your styles via whatever means they think best.

CSS3 is one the latest buzzwords in the web industry, alongside HTML5. This means many developers jump in without thinking of the potential consequences of their actions. There are some very obvious ways using CSS3 can lead to inaccessible websites:

The best way of dealing with these is to understand the potential issues that we have explained throughout this chapter. Remember to progressively enhance whenever possible and provide fallbacks for instances where these features may be unsupported. Be aware of the color accessibility issues some newer techniques might bring along with them, and try to provide alternate style sheets. Use transitions, transforms, and animations as decorative effects, not for vital features.

This is mainly common sense. Remember to test in older browsers, and pre-empt the problems users will have. Progressive enhancement is your friend.