The promise inherent in the name "World Wide Web" is an information network that can be used by everyone across the entire world. To a large degree this promise has been fulfilled, although there are still many groups of users whose needs aren't adequately met. To address these needs, the Cascading Style Sheets recommendations include specific support for accessibility by people with disabilities and for internationalization and non-English languages.
In this hour, you'll learn
When we talk about Web accessibility, we're talking about the interaction between content and presentation and about ensuring that people who may have disabilities can use the result of that interaction. The content is the information we want to convey to our audience; it's not even necessarily the HTML code, but rather the information embodied by the HTML code-or by a Flash animation, GIF image, or multimedia movie. The presentation is the specific way we've chosen to express that information to our audience.
A basic principle of accessibility is that these two types of information, the content and the presentation, should be separated from each other. This allows for alternate versions of the presentation to be constructed that convey the information in a way that the user can perceive it. If the content cannot be easily extracted from the presentation, an alternate version can be provided.
The classic example of this is the alt attribute on the HTML <img> tag (and the <area> tag as well). The content of a visual image is obviously going to be inaccessible to a user who is blind; she simply can't see it. However, if a text equivalent of the image is supplied, using the alt attribute, her computer has information about what the image means, and it can provide that to the user-for example, by reading it out loud to her.
Users with disabilities will often use assistive technology (AT) to enable access. Assistive technology is a broad category that not only includes Braille terminals and screenreaders for blind users, but also includes magnification devices, voice recognition software, specialized input devices for those who can't type or use a mouse, and other hardware and software solutions.
Although assistive technology can solve many problems for users with special needs, it can't solve all of them because it can work only with the information that is available. For example, if there is no alt attribute for an image, the assistive technology has no clue what to tell the user about the image's function and purpose. AT alone can't enable access; it requires cooperation from the Web developer as well.
Most of the time when you hear about Web accessibility, the focus is on blind and visually impaired users. The Web is commonly thought of as a visual medium; however, it's more accurate to say that it's an information medium, and the visual representation of information is simply the most common way the majority of people use the Web. A mistaken insistence that the Web is meant to be only visual can lead many Web developers to inadvertently create Web sites that are inaccessible to users who can't see well. A user who is blind will commonly use a screenreader, a software program that uses a synthetic voice to read the output of other programs. Examples of common screenreaders include JAWS for Windows and WindowsEyes. Screenreaders depend on a Web browser to retrieve and process Web pages; for example, JAWS is integrated with Internet Explorer for Web display.
Another option is a speaking Web browser, which is essentially a browser with a specialized screenreader built into it; examples are IBM's Home Page Reader and EmacSpeak for Linux/Unix. Also in use are Braille terminals, which display around 40 characters at a time using raised dots in a row.
All of these access solutions for blind users dramatically change the experience of using the typical Web site. Instead of experiencing the content as a two-dimensional visual display, a user hears (or feels) the content in a sequential, linear order. On most page designs this means having to wade through the navigation options and banner ads before finally reaching the main content of the page.
Users who have the ability to see, but not necessarily see well, often employ other solutions to access Web content. For some, screen magnification software, which allows sections of the screen to be increased to many times their original size, may be necessary for ease of reading. A user with less severe requirements may simply increase his default font size to allow for comfortable reading.
Color blindness may cause someone to be unable to distinguish content within color graphics or to have difficulty discerning text against the background colors. The use of color as the only means of conveying information can restrict access by users who are color-blind or who can't see at all.
Compared with users with visual disabilities, deaf or hearing-impaired users are relatively fortunate when using the Web because most sites don't make heavy use of sound. However, those users can miss sound cues, audio files, and the sound tracks of multimedia presentations.
Users who are unable to use a keyboard or a mouse will often employ creative means to provide equivalent input to their computers. For example, a quadriplegic user who is unable to use his arms or hands may move the mouse pointer by moving a pointer wand worn on his head.
One of the broadest groups of users with disabilities is also the least understood when it comes to Web accessibility--users with cognitive disabilities. This wide category includes everything from relatively simple dyslexia to extreme mental retardation. Many individuals with varying cognitive impairments regularly use the Web as a primary information source, and they should not be discounted as a potential audience for your site simply because of their disabilities.
Because the W3C created the CSS specifications with the needs of disabled users in mind, Cascading Style Sheets, if applied correctly, have great potential to meet the needs of those users. The primary benefit of using CSS is the separation of presentation from content; using CSS with HTML (especially Strict HTML) makes it clear which code is meant for presentational effects and which is the structured information of the page.
The CSS language has many features specifically intended to benefit users with visual disabilities, mainly because style sheet properties primarily define visual appearance. Media-specific alternate style sheets and rules can be created for screenreaders, Braille terminals, and Braille printers. Aural CSS properties, described later in this hour, give control over the pitch, frequency, and even apparent location of synthesized speech.
The use of relative measurements, such as em instead of absolute font sizes, allows your style sheets to adapt to user preferences, either in browser settings or in a user style sheet. This lets users with special needs for font or color choices continue to access your site even if the author's CSS isn't sufficient for their needs.
Style sheets do little to benefit deaf, hard of hearing, physically restricted, or cognitively impaired users, although a CSS-styled Web site based on sound usability and design principles will provide benefits for users both with and without these disabilities. Many cognitively disabled users specifically benefit from nontextual information cues, such as color, layout, and graphics.
To fully test your CSS designs on all possible Web browsers and AT devices, you'd have to spend a fortune; you already know how hard it can be to fully test a CSS design on mainstream browsers, and adding assistive technology software and hardware to the mix makes the task nearly impossible. So what is a Web developer to do?
The answer has been for those with expertise in assistive technologies to gather information on accessibility and create a set of recommendations for Web developers to follow. By learning these standards, a Web developer won't have to spend time researching every possible access method but can instead be reasonably sure that a page created according to those principles will be accessible to a broad audience of users.
The World Wide Web Consortium, in addition to publishing CSS, HTML, XHTML, XML, and other language specifications, also established the Web Accessibility Initiative (WAI). The purpose of the WAI is to create and distribute information on making the Web more accessible to people with disabilities. The WAI has issued guidelines for browser programmers, Web editing tool programmers, and Web developers that suggest how to improve Web accessibility.
Most of us aren't programming browsers or authoring environments, so the WAI recommendation we're concerned with is the Web Content Accessibility Guidelines (WCAG), a list of checkpoints that can be used to measure the accessibility of your Web site.
Each WCAG checkpoint has a priority rating of one, two, or three, where priority one checkpoints are the most important and priority three the least. The WCAG checkpoints most applicable to CSS design are shown in Table 21.1.
| Checkpoint | Priority | Explanation |
|---|---|---|
| Provide text alternatives for nontext elements | one | Most CSS images, such as backgrounds or list bullets, are purely decorative, though, so they don't require additional alternatives. |
| Don't use color as the only way to convey information | one | Make sure that the content can be understood if CSS colors aren't displayed. |
| Design pages that function even if style sheets are turned off | one | Text your page with Lynx or with styles turned off to ensure functionality is maintained. |
| Use CSS to style text instead of creating images | two | If you can make an effect with CSS rules, you should do that instead of using a graphic. |
| Style sheets should be used instead of presentational markup | two | After reading this book, this should be an easy one to meet! |
| Use relative values for styles instead of absolute values | two | For example, use x-large, smaller, or 3em instead of pixels or points. |
| Use foreground and background colors that contrast well with each other | three | Colors that don't stand out for each other cause problems for uses with poor vision or color blindness. |
Table 21.1 is far from complete, but these are the checkpoints that are most relevant for CSS developers. If a Web page or site conforms to all of the priority one checkpoints (not just those listed here), it is said to be Single-A accessible. Meeting the priority one and two checkpoints equates to Double-A accessibility, and Triple-A accessibility means that all checkpoints of any priority level are met.
Many governments, schools, and other public institutions around the world have adopted Double-A accessibility as a standard for their sites; Single-A accessibility is considered the minimum for a public Web site.
You can measure the accessibility of your Web site by going to the Center for Applied Special Technology site and using their Bobby program at http://www.cast.org/bobby/. Bobby is an automatic checker that can catch many of the most common accessibility mistakes, and also helps you manually check those problems that can't automatically be detected.
As part of employment and civil rights regulations, the U.S. government requires all agencies to make their public and internal sites accessible to people with disabilities. Known as Section 508 (from the applicable section of the Rehabilitation Act), these regulations affect how agencies can purchase and use information technology--accessibility is a requirement for hardware, software, and Web sites employed by the government.
If you're not a U.S. citizen or don't work for the U.S. government, you might think these rules don't apply to you--and you're right. Section 508 is not an attempt to regulate the private sector, just federal agencies. However, because the U.S. government is the largest employer of information technology in the world, these rules have far-reaching influence and may be considered as a model for future accessibility standards. Therefore, it's important to be familiar with these requirements and how they apply to Web development using CSS.
The requirements for Web page accessibility are based on the W3C's Web Content Accessibility Guidelines; specifically, most of the priority one checkpoints with a few additions. These include the following:
CSS can be especially useful for hiding the "skip navigation" link required by Section 508. First create the link like the following:
<a href="#content" id="skip">Skip navigation</a>
Create an anchor point at the start of the content:
<a name="content"></a>
Then write a style rule like
#skip { display: none; }
@media aural, braille {
#skip {
display: inline; }
}
These CSS rules mean that the "skip navigation" link will be hidden on most browsers but will still be displayed by screenreaders, Braille terminals, and browsers that don't support CSS at all.
Aural properties for Cascading Style Sheets were first proposed as an extension to CSS Level 1 and were incorporated into the CSS Level 2 specification. These properties allow you to control the sound properties of spoken text, just as the visual properties control the visual properties of text and other elements.
Unfortunately, this list is quite short. There are no mainstream browsers that support aural CSS properties. The EmacSpeak browser, developed for Linux and Unix by one of the primary authors of the aural properties of the CSS Level 2 specification, is the only browser that supports aural CSS.
If you're running a Unix-based system, you can download EmacSpeak from T.V. Raman's Web site at http://emacspeak.sourceforge.net/.
Currently, screenreaders and speaking browsers, such as JAWS for Windows and Home Page Reader, do not support aural CSS either; they use their own rules, which are not CSS based, to determine how to speak each page. Future versions may support aural CSS, though.
Because of this lack of support, there's little reason today to spend much time with aural style sheets; this is unfortunate because many of the properties are quite useful both for disability access and potentially for general use. Because these properties don't cause any problems in existing browsers--they're all completely ignored--it doesn't hurt anything to include them; there is a very low cost of failure when an aural CSS property is not supported.
Future versions of browsers, sreenreaders, and other access methods may support aural CSS; one particularly interesting proposal is for multi-modal access methods that would provide both visual and aural renditions simultaneously.
Rules using aural CSS properties are written just like rules for any other property, with a selector and a declaration of property names and values. You can use the @media selector from Hour 20, "CSS for Printing," to limit these rules only to media type aural, although by their very nature these properties will apply only to text that is spoken by the computer.
Because aural CSS is so poorly supported, I won't give an extensive tutorial on each property; if you want specifics, you can consult the aural properties section of the CSS specification. In this hour I'll just tell you enough to know the general capabilities of aural CSS.
The characteristics of the voice speaking the content of the page are determined by several properties relating to volume, pitch, and other qualities. These properties are listed in Table 21.2 along with the range of values allowed.
| Property Name | Values |
|---|---|
| pitch | frequency, x-low, low, medium, high, x-high, inherit |
| pitch-range | variation-number, inherit |
| richness | richness-number, inherit |
| speech-rate | words-per-minute, x-slow, slow, medium, fast, x-fast, faster, slow, inherit |
| stress | stress-number, inherit |
| voice-family | specific-family, generic-family, inherit |
| volume | volume-number, percentage, silent, x-soft, soft, medium, loud, x-loud, inherit |
The voice-family property is similar to font-family; you can define a specific voice, which may or may not be supported by the aural CSS browser, or you can use one of three generic voice families: male, female, or child. There's no standard list of voice types beyond this, and so the use of specific voices (such as robot, Spock, or "Britney Spears") depends on the browser.
Aural CSS properties allow you either to insert pauses to break up the aural reading, either before or after an element, or to insert specific sound files, called audio cues. These properties are shown on Table 21.3.
| Property Name | Values |
|---|---|
| cue | Shorthand property, setting cue-after and cue-before |
| cue-after | sound-url, none, inherit |
| cue-before | sound-url, none, inherit |
| pause | Shorthand property, setting pause-after and pause-before |
| pause-after | time-measurement, percentage, inherit |
| pause-before | time-measurement, percentage, inherit |
Cues are normal sound files, usually .wav or .au files, and are indicated by url() notation. Pauses are measured in seconds (s) or milliseconds (ms), such as 2s or 30ms.
Most humans hear in three dimensions if we have the use of both ears. Aural Cascading Style Sheets allow you to designate a specific location, within three dimensions, from which a sound could originate. Consider a transcript of an interview, marked up with voice properties similar to those of the appropriate speakers, where the interviewer's voice is heard on the left side, and the subject of the interview is heard on the right. A question from the audience could come from behind and below while an overhead announcement originates from directly above the listener.
The properties that place each sound in a specific location are shown on Table 21.4.
| Property Name | Values |
|---|---|
| azimuth | angle, left-side, far-left, left, center-left, center, center-right, right, far-right, right-side, behind, leftwards, rightwards, inherit |
| elevation | angle, below, level, above, higher, lower, inherit |
Angles are measured in degrees (deg), grads (grad), or radians (rad), such as 90deg, 100grad, or 1.571rad, which are all (approximately) a right angle. A 0deg azimuth is directly in front of the listener, and 0deg elevation is level with the listener.
Just as the display and visibility properties let you hide what is shown visually, aural CSS also lets you control what is vocalized and how that's done. You can even add the equivalent of a background image by specifying a background sound to be played while an element is spoken. These properties are shown in Table 21.5.
| Property Name | Value |
|---|---|
| play-during | background-sound, mix, repeat, auto, none, inherit |
| speak | normal, none, spell-out, inherit |
| speak-header | always, once, inherit (table cells only) |
| speak-numeral | continuous, digits, inherit |
| speak-punctuation | code, none, inherit |
The play-during property allows you to specify whether a background file is mixed in with any other background sounds already playing (from a containing element) or whether it replaces the other sound.
Listing 21.1 is an example aural style sheet. Lack of support for aural properties makes this a less-than-practical example, but this should give you an idea of how you can use aural CSS properties in action. Because these styles are purely aural, there's no printed screenshot for this example.
|
|
Internationalization--sometimes abbreviated as i18n--"the letter i, 18 other letters, and the letter n" --is the practice of making content available in a variety of languages, not simply one. With a truly worldwide World Wide Web, the standards that are used on the Web simply can't support only the English language. The Cascading Style Sheets language has been partially internationalized, which means it can be used, with varying degrees of success, with many languages and local variants.
On the Web, languages are indicated by a two-letter code, sometimes followed by a dash and an additional country code for regional versions of a language. Some of these languages are shown in Table 21.6.
| Code | Language |
|---|---|
| de | German |
| en | English |
| en-ca | Canadian English |
| en-uk | British English |
| en-us | American English |
| fr | French |
| jp | Japanese |
| ru | Russian |
The choice of language can dictate a number of factors, including the direction of the text, the fonts used, or even the dictionary for pronunciation used by a screenreader. The CSS language doesn't allow you to set the language, which must be done in the HTML or in an HTTP header, but it does let you create rules or style sheets that apply only to certain languages.
To set the language within an HTML document, you simply have to use the lang attribute on the <html> tag. Sections of a second language embedded within the document can be indicated with the lang attribute on a <span> or any other appropriate HTML element, such as <blockquote> or <div>.
The CSS Level 2 specification defines a special pseudoclass, :lang(), for indicating rules that should be applied only to elements that match a certain language. Such a rule is written like the following:
:lang(en-uk) { background-color: #CCCCFF; }
This would display anything written in British English with a light blue background color. How does the browser know which parts of the text are written in British English? It needs to be set in the HTML, like the following:
<p>He cried out in a bad Monty Python imitation,
<span
lang="en-uk">He's pinin' for the fjords!</span>
By itself, :lang() is not particularly useful, but when combined with other CSS rules and properties, it can be quite powerful. Some of those that involve generated content will be discussed in the next hour.
One way in which :lang() rules can be used is to set an appropriate marker for ordered lists. You'll recall that you can set the list marker to count using Roman numerals, numbers, or letters, but what about languages that don't use the same alphabet? A list of additional values for the list-style-type property is shown in Table 21.7.
| Value | Effect |
|---|---|
| armenian | Traditional Armenian numbers |
| cjk-ideographic | Ideographic numbers (Asian languages) |
| georgian | Traditional Georgian numbers |
| hebrew | Traditional Hebrew numbers |
| hiragana | Japanese hiragana numbers |
| hiragana-iroha | Japanese hiragana-iroha numbers |
| katakana | Japanese katakana numbers |
| katakana-iroha | Japanese katakana-iroha numbers |
| lower-greek | Lowercase Greek letters |
You don't have to use a :lang() selector to utilize these values; you could use a normal element selector, a class or id selector, or anything else that fits your markup. Here are two examples:
li:lang(jp) { list-style-type: hiragana; }
ul.alphabeta {
list-style-type: lower-greek; }
These are supported only for those browsers and operating systems that support these character sets and appropriate fonts. This is highly dependent upon the specific version and language support on each computer. Although you should feel free to use these with content in the appropriate language, you should also expect that browsers without support for such a given language will display these as list-style-type: decimal.
Most languages are read in one direction--left to right, as in English, or right to left. Some languages, such as Arabic or Hebrew, sometimes mix text direction within the same document; this is called bidirectional text (bidi for short). In most cases, the browser will have enough information to determine the direction based on the characters used and the language settings.
Two CSS properties, direction and unicode-bidi, are used to affect the calculation of the correct direction. In most cases, you won't need to use these properties, but if you find yourself needing to change the direction of text, you first use the unicode-bidi property to create an additional level of embedding or to set up an override. Then the value of direction can be set to either ltr (left-to-right) or rtl (right-to-left). For more details, see the CSS Level 2 specification. Browsers are not required to support changing direction of HTML text using these properties.
Users with disabilities are as entitled to use the Web as anyone else, but often they are unable to access sites due to careless Web design. Using Cascading Style Sheets is an excellent first step toward developing a site that can be used by everyone, as style sheets separate presentation from content. Assistive technology devices and software can often enable access by disabled users, but only if sites are designed in accordance with Web accessibility standards. The W3C has produced Web Content Accessibility Guidelines that are an invaluable resource for Web developers and that form the basis of the U.S. government's Section 508 regulations for federal agency sites.
Aural CSS properties let you determine qualities of the voice used to read content out loud, such as the pitch, speed, and "family" of the voice. Unfortunately, almost no browsers support aural CSS currently, thus limiting its usefulness.
In addition to users with disabilities, users in non-English-speaking countries also use the Web. CSS is designed with internationalization in mind; for example, rules can be made for specific languages with the :lang() pseudo-element, and the list-style-type property can produce a number of non-English number markers.
| CSS Feature | Grade | Notes |
|---|---|---|
| All Aural CSS properties | C- | No mainstream browser support |
| :lang() pseudo-class selectors | C | Variable support |
| International list markers | C | Variable support |
| Bidirectional text | n/a | Avoid changing text direction |
The workshop contains quiz questions and activities to help reinforce what you've learned in this hour. If you get stuck, the answers to the quiz can be found after the questions.
Expand your skills with Web development by learning more about Web accessibility. Here are some sites you can visit to get started: