AUTHOR’S NOTE – You’re reading the HTML version of a chapter from the book Building Accessible Websites (ISBN 0-7357-1150-X). Copyright © Joe Clark, 2002 (about the author). All rights reserved. ¶ Back to Contents
Cascading stylesheets (CSS) hold the grand promise of enabling Web authors to separate presentation from structure, form from function, decoration from essence. In principle, that is.
Also in principle, stylesheets provide for increased accessibility, though the actual accessibility provisions of CSS are so poorly supported that the entire project amounts to vapourware.
I should point out that this book, conceived as it was for developers and designers, limits itself to the stylesheets a developer or designer, not a Website visitor, would create. If you’re already au courant with accessible CSS and feel I’m leaving too much out, keep that limitation in mind.
In this chapter:
With modest exceptions to be discussed later, the weight of CSS accessibility rests on the shoulders of so-called media stylesheets.
In general, and quite apart from the issue of accessibility, stylesheets attempt to separate the details of a document’s presentation from its underlying HTML structure. If you would prefer your first-level headings to appear in bold Verdana capitals with a hint of added letterspacing, that’s just what you can have. A device unable to interpret such a stylesheet will simply ignore it, or at least interpret whatever features it actually can. (Consistent with the philosophy of this book, we will not concentrate on disastrously standards-noncompliant interpretations of CSS.)
Underlying the whole system, of course, is well-written HTML that uses, for example, actual heading styles for headings rather than tarting up paragraph tags to make text look big and important to a sighted reader.
If we broaden our understanding of “presentation” to mean something more like “representation,” thereby obviating even an implied visual form, it becomes possible to customize CSS for a range of output media. It becomes possible to write separate stylesheets for media whose modes of presentation vary enormously, from Braille to printers to computer screens.
CSS Level 2 media types were defined in 1998. Their details (as excerpted from the World Wide Web Consortium document focusing on accessibility-specific media) are as follows:
aural- Intended for speech synthesizers.
braille- Intended for Braille tactile feedback devices.
embossed- Intended for paged Braille printers.
- Intended for paged, opaque material and for documents viewed on screen in print preview mode.
screen- Intended primarily for colour computer screens.
tty- Intended for media using a fixed-pitch character grid, such as teletypes, terminals, or portable devices with limited display capabilities.
Kray-zee, huh? Now you can write a stylesheet that works with Braille. In principle, at least.
It is quite possible to embed stylesheets in a document, by typing out the many attributes within <style></style> tags inside the <head></head> element. Then each document carries its own stylesheet, meaning you must manually alter each document should you change your mind or make a mistake.
It’s also possible to specify style information inline inside nearly any element, as in this example:
<h2 style="font-weight: bold; font-family: Verdana; font-size: 18px; text-transform: uppercase; margin-bottom: 0.5em; letter-spacing: 0.2em">
It’s best to reserve this practice for emergencies or rarities – e.g., the one and only time you might ever need the cursive generic font family, where you could specify it as style="font-family: cursive" inside an element.
By far the preferred method of styling a document involves external stylesheets – separately-maintained documents that can be included by reference in an unlimited number of HTML files and updated in one fell swoop. It will probably not surprise you to learn that external stylesheets are called via a link element inside the <head></head> element. An oldschool example that does not set a media type might look like this:
<link rel="stylesheet" href="stylesheet.css" type="text/css" />
The rel="" segment signifies a relationship between the link and the current document. The external stylesheet’s filename (actually, it is a URL or address) goes inside href=""; the MIME filetype declaration type="text/css" is not technically mandatory but is highly recommended; some browsers refuse to load the stylesheet if the declaration is missing. You also must close the tag with a space and a slash.
To use media stylesheets, simply add one more attribute to the link element: media="" (which can go anywhere in the element). Some possible examples (note the filenames):
<link rel="stylesheet" href="stylesheet-tty.css" type="text/css" media="tty" />
<link rel="stylesheet" href="stylesheet-aural.css" type="text/css" media="aural" />
<link rel="stylesheet" href="stylesheet-braille.css" type="text/css" media="braille" />
I suggest a naming convention like the one above: Decide on a name for the default stylesheet and add a hyphen and the full name of the medium before the file extension for each media variant. Unlike, say, my recommended naming convention for long descriptions (
imagefilename-LD.html), you can’t rely on two-letter abbreviations due to the conflict between br for braille and br for Brazil, for which one could readily envision a localized stylesheet. (There is little likelihood of confusion with the language code br, as it refers to the Breton language, with half a million native speakers in France. Brazilian Portuguese is specified by pt-br.) If you find that level of detail academic and extraneous (a first for this book, shurely?!), feel free to devise your own naming scheme.
If you do not specify a medium for a stylesheet, graphical Web browsers default to an interpretation of media="all". That may not be true for cellphones, toaster-ovens, or other Internet-connected devices, not that any of them actually make use of media CSS.
In CSS Level 2, you do not have to use separate stylesheets for different media; you can use the @media rule to specify the media. That is not, however, a “basic” technique, so we will skip the details here.
From an access standpoint, the media stylesheets that matter are screen, aural, braille, and tty. (You may be wondering: “Is the term written Braille or braille?” In XHTML, attribute values do not need to be lowercase, as elements and attributes themselves must. For consistency with official documents, however, in stylesheets we will consider braille correct, even if it causes mild affront to the legacy of Louis Braille.)
The screen medium might seem unrelated to access because of our continuing interest in people who cannot actually see a screen. As you know, though, many low-vision people and essentially all mobility-impaired and deaf or hard-of-hearing people look at conventional computer monitors to surf the Web. As you learned in Chapter 9, “Type and colour,” there is nothing special you can do to make type legible for a low-vision person that screen-magnification software cannot more properly do.
But you’ll also recall that colour combinations are an accessibility issue for colourblind people. It is generally recommended to specify colours in a stylesheet. What kind of stylesheet? A default stylesheet, invariably interpreted as media="all" by graphical browsers. A stylesheet explicitly marked as media="screen" self-evidently falls into the same category.
Further, user stylesheets created to accommodate a visually-impaired visitor’s colour, size, and presentation preferences are always of media="screen" by definition. However, the print media style can be an indirect form of accessibility given that typical print stylesheets produce black-on-white text, which some visually-impaired people find easier to use with screen magnifiers.
There is some evidence that CSS media types created for accessibility were not all that well-considered by the World Wide Web Consortium (W3C), a concern that is quite separate from implementation issues subsequent to their introduction.
tty is an example. We start with the terminology problem. Just as the name of the oddball accesskey attribute tricks you into thinking the issue is keystrokes on a keyboard (an accesskey
is actually an accesscharacter), the tty nomenclature may conjure the following images among oldtimers in the computer and/or accessibility demimondes:
Indeed, recapping the tty CSS specification tells us it is “[i]ntended for media using a fixed-pitch character grid, such as
teletypes, terminals, or portable devices with limited display
capabilities.” So much for divorcing presentation from structure: We are explicitly told not to use proportionally-spaced fonts, and that “[a]uthors should not use pixel units with the tty media
type.” But do the writers of the specification understand the true range of presentation modes of “media using a fixed-pitch character grid”?
handheld media style: “Intended for handheld devices [typically small screen, monochrome, limited bandwidth].”)
Are we to assume that the tty media stylesheet is meant to simultaneously accommodate devices that print out in capitals, display single lines of text (and cause preceding text outside that window to disappear), offer full-screen addressing in double-high, double-wide type, let you use coloured italic fonts, and give you full bitmapped graphics?
The under-researched tty style appears to have been created as a theoretical exercise. To the ill-informed, it must sound like a good idea. It certainly seems to have been devised in near-complete ignorance of the kind of tty implementation the W3C should have had in mind all along: Lynx, the text-only Web browser. It ignores CSS completely, but does nothing less than a spectacular job of rendering even ill-formed HTML in plain old characters and lines, just like MS-DOS. A typical Web designer could never write a tty stylesheet that makes Web pages look better than Lynx does without stylesheets at all.
All right. How about Braille?
It’s fun to envision your Web pages automatically reformatting themselves into raised dots. But you’ll recall that Braille intended for adults isn’t a transliteration of a single printed to a single Braille character. Dozens of contractions are in use, some of them representing entire (short) words. Stylesheets do not handle that kind of character substitution, full stop. (The same sort of thing happens in Arabic and Farsi, where the shape of a letter varies with its position in a word; in Greek, with its regular and word-ending sigmas; and in Latin-alphabet languages with the many ligatures involving the letter f. Stylesheets do not handle those substitutions, either.)
A Braille stylesheet could, for example, turn all <h1></h1> elements into capitals (there are Braille codes for all-capitals text) preceded by a blank line, but it could not properly encode the characters between the opening and closing tags, except at a juvenile grade of Braille.
(This says nothing of the related embossed media style, “intended for paged Braille printers.” Apart from accessible media types, CSS2 also introduced styles suited to the formatting of printed pages. The embossed media style is a cousin to those styles. But Braille transcriptionists undergo months of training and practice before they are competent to be unleashed on the reading public. Braille has its own set of conventions for page layout and division that a simple stylesheet, even making use of those other page-related CSS2 features, could not possibly accommodate. It’s another concept that sounds good to the ill-informed.)
Who are we really serving here?
That isn’t a rhetorical question. Which disabled groups are genuinely served by these media stylesheets? Certainly not these:
tty style, as everything else in the observable universe does.)
When it comes to accessibility, however, the star of the media-stylesheet show is the aural variant. It’s discussed often enough that the acronym ACSS (for aural cascading stylesheets) is used in online discussions of the bright and promising future of what is obviously a unique, valuable, and terribly clever invention.
The name itself is the first strike against it. Aural, a term favoured exclusively by pedants, sounds exactly like oral. When chatting with your friends about aural stylesheets at the local espresso joint, they may begin to wonder what CSS has to do with the human mouth. (“ ‘Oral’ stylesheets? Is that like oral hygiene?” is one of the few G-rated jokes you’re likely to hear.) You simply cannot discuss “aural” stylesheets out loud without causing confusion and sounding like a twit.
Words like audio, audible, and even auditory are far less ambiguous, not to mention less pretentious, but it’s aural we’re stuck with. (The minor differences in meaning among those words are less of a cross to bear than the homonym oral.)
Where “visual” CSS permits you to set myriad details of graphical presentation (size, margins, borders, fonts, and beyond), aural CSS gives you control over audible characteristics, including:
A whole new set of toys to play with, right?
As everywhere in media access per se (think of captioning, audio description, subtitling, and dubbing), even if we enjoyed a flawlessly reliable technical infrastructure for aural stylesheets, how many working Web designers and developers would know how to write them?
You’re pretty handy in Photoshop, and you can even write all-CSS layouts. You’ve written entire back ends in SQL. Audio? You can handle audio, kind of. You’ve certainly ripped MP3s to compact disc. Now, though, your boss (or the World Wide Web Consortium, whichever is worse) wants you to craft computer voices, position them in three-dimensional space, and specify background music and tones for special components.
You simply don’t have that training. Nor should anyone expect you to have it. Nor is there anywhere you can get that training.
At the authorial level, aural stylesheets are a character in search of an author. Literally.
“Who’s gonna use this?” you ask. The answer is: Effectively no one.
Media stylesheets in general are poorly supported. Even a simple print stylesheet – for printed pages as opposed to screen display – will be ignored by certain browser versions (and some media-stylesheet combinations will crash our old friend, that carcinoma of the Web, Netscape 4).
We also face the issue of appropriateness of device. Remember the summary attribute of HTML tables? The W3C specification tells us unequivocally: “This attribute provides a summary of the table’s purpose and structure for user agents rendering to non-visual media such as speech and Braille.” It is not even a subject of debate whether or not a graphical browser should support summary. It must not do so, except inasmuch as such a browser has a speech or “non-visual” mode. (iCab on Macintosh can read Web pages aloud, and when it does so it reads the summary aloud, too.)
Why should graphical browsers support aural stylesheets?
Shouldn’t that support be hived off onto screen readers?
But those programs already offer a vast range of controls for vocal characteristics. To make a visual analogy, a low-vision person may find the graphical defaults chosen by Web authors mildly annoying and may set up browser defaults or a user stylesheet to override them. But if Web designers set up aural stylesheets that override a screen-reader user’s very-carefully-thought-out speech choices, honed over weeks and months of use, in favour of something you slapped together because you liked the idea of using Elmer Fudd’s voice to enunciate link text, the blind visitor may well end up far more than mildly annoyed.
It is a greater sin to mess with an individual blind visitor’s speech settings via ACSS than any sin you could imagine that affects low-vision or colourblind people. Annoying sounds are far more annoying than annoying images. Rejigging a user’s volume settings alone is more than enough to make you an enemy for life. Among other things, sound settings are harder to avoid: If you think a blackboard is ugly, you can look away, but you cannot look away from the sound of fingernails scratching a blackboard. If you dislike the appearance of a Website, you have a remarkable armamentarium at your disposal to reformulate that site’s visual rendering to your liking via user CSS. But if you’re stuck with somebody else’s voice and sound choices, you truly are stuck.
It’s all vaguely academic, though. Quite a bit of research and digging has uncovered exactly one existing assistive technology that supports aural stylesheets: Emacspeak, a rather advanced Linux software package that goes well beyond what conventional screen readers can do. (A screen-reader program whose name has the strangest capitalization ever encountered, pwWebSpeak, allegedly supported ACSS, but the program is no longer sold.)
Of course, Linux is a hacker playground. Very few real-world blind (or sighted) people use Linux, let alone Emacspeak. In fact, Emacspeak’s greatest proponent happens to be the worldwide authority on audio interfaces for computers: T.V. Raman, formerly of Cornell University and Adobe Systems and, at time of writing, a researcher at the IBM Almaden Research Center in California working on the “multimodal” Web. Raman literally wrote the book on audio interfaces, entitled, surprisingly enough, Auditory User Interfaces: Toward the Speaking Computer (Kluwer Academic Publishers, 1997).
I interviewed Raman on current and future uses of aural stylesheets. He agrees that browser support for ACSS is nonexistent, but adds that support for stylesheets among assistive devices is also limited for technical reasons. Screen readers, for example, sit on top of browsers and do not have independent access to Web content of all kinds. “The problem is that mainstream browsers are not self-voicing browsers. It’s not the browser that talks,” Raman notes. “It’s some third-party aid that comes along and talks. And when that happens, the third-party tool does not have access to the browser’s internal CSS implementation.” Someday that may change, of course.
Raman, a blind person, enjoys the luxury of ACSS support via Emacspeak, and he often uses it to make certain sections of long and tedious documents silent. Just as user stylesheets can be applied post-facto to alter an author’s stylesheet (or act alone if the author didn’t specify one), under Emacspeak it is possible to write user aural stylesheets that modify the rendering on the visitor’s computer of prewritten, prestyled documents without the original author’s knowledge.
Raman can thus skip over paragraphs coded as <p class="note"> or similar by altering his aural stylesheet to make such classes silent. That option may be an augury of the future: Raman’s advice to Web authors is not to worry about ACSS for the moment, but to provide as much meaningful stylesheet markup as possible.
Paragraphs of a certain type, for example (notes, navigation, meeting minutes) should be marked as such using <p class="classname"> rather than just <p></p>. “If they use the class attribute in some meaningful manner, even if they don’t write aural presentation rules... then either now or down the pipe someone would be able to potentially map aural representations to it,” Raman says.
What this implies, of course, is limiting the use of inline styles – along the lines of <p style="font: 18pt/22pt Impact"> – to very unusual cases, since you aren’t identifying a class whose manifestation an aural stylesheet can manipulate. (In that example, it’s better to define .impact { 18pt/22pt Impact } and invoke it with <p class="impact">.)
(Raman, by the way, does see a use for aural stylesheets in self-voicing electronic books, but those are not Websites.)
It appears, then, that your job as Web author need not include worrying about media stylesheets for accessibility. They’re poorly thought out and are effectively unsupported in the real world.
Your greatest contribution to accessibility through stylesheets appears to rest on the proper, thorough, but indeed somewhat inconvenient use of class selectors for paragraphs and other elements. It requires you to consider the purpose of each section of your documents and mark it up accordingly.
At the authorial level, though, there are a couple of tricks you have at your disposal to use CSS for accessibility.
Remember the dilemma of specifying accesskeys and somehow “exposing” them to visitors so they could actually be noticed and used, assuming the browser supports them in the first place?
It turns out that, in Cascading Stylesheets Level 2, you can “generate content” to appear before or after an item through the :before and :after pseudo-elements.
It would then be possible to set up virtually anything to which an accesskey can be assigned – even a link that is an image (<a><img></a>) – so that the actual accesskey is listed after it. You simply add :after to the declaration of whatever item you wish to affect.
An example:
[accesskey]:after { content: "[" attr(accesskey) "]" }
The brackets in the sequence [accesskey]:after are used to specify that we’re after that specific attribute of the element in question. (You could specify generated content for an element unconditionally: p:after { content "*" } would add an asterisk after every single paragraph, for example. Here we’re interested in the accesskey attribute of any applicable element.)
There are a couple of rules for marking up the content to be generated by the browser. Place literal characters (entities work fine) inside neutral quotation marks; that part you probably figured out. You can also use variables, as we do here: attr(accesskey) will substitute whatever value you have selected for the accesskey attribute. And as you can see, you can combine literal and variable content.
Using that previous snippet of stylesheet, an element like <a href="home.html" title="Homepage" accesskey="H">Homepage</a> might be rendered as Homepage [H] in a browser rather than just Homepage.
This does not completely solve the problem of hidden accesskeys. For one thing, your visitors still have to know what the letters in brackets signify, and that invariably means writing it out somewhere on your site. Moreover, Cascading Stylesheets Level 1 support remains imperfect among browsers, and CSS2 support is even spottier. We’re dealing with overlapping minorities here: The small subset of browsers that support accesskey and support the :before and :after pseudo-elements.
You may also be displeased with the visual impact on your page. You are, after all, littering it with brackets and (usually) letters. But as you know, on rare occasion appearance must be modified (let’s not say “sacrificed”) for accessibility.
You may, moreover, use :before and :after to spell out the expansions of abbreviations and acronyms, though that rather defeats the purpose. (Why would you want to read the acronym and the expansion, which succeeds merely in being longer, wordier, and harder to understand?) If you really must use this technique, the style looks like so (using parentheses to enclose the expansion):
abbr[title]:after, acronym[title]:after { content: " (" attr(title) ")" }
The W3C actually suggests using :before and :after to make alt texts visible:
img:after { content: attr(alt) }
The W3C helpfully notes that “the value of the attribute is displayed even though the image may not be (e.g., the user has turned off images through the user interface).” I thought alts were substitutions, not additions; for that we have title. The whole approach is a bad idea.
As mentioned in Chapter 9, “Type and colour,” authors are strongly encouraged to name a generic font family (generally serif or sans-serif) whenever any font is specified by name. In that way, under battle conditions a graphical browser or other visual device will at least have a fallback font it can use. (In the rare case that a serif font does not exist on the system while a sans-serif font does, the device can simply ignore a serif declaration.)