These notes are derived from presentations at @media 2007, in San Francisco on 2007.05.25 and in London on 2007.06.07 (podcast [MP3]).
The title of this presentation is “When accessibility is not your problem” – in other words, the specific limited edge cases in which you, as a content author, do not have to worry about accessibility. I had four people in London telling me they got the impression, or feared others would get the impression, that I am claiming accessibility is not your problem. That is nonsense, of course.
Our topic today is the fact that people who write “Web content,” or authors as they are called in the jargon, have been expected to carry nearly the full weight of Web accessibility.
If you’re the one creating the page, you have to take care of pretty much everything – if you want that page to be accessible. Or if you want the page to meet WCAG, which isn’t always the same thing. Or if you want to avoid having pedants write in and criticize you for busting WCAG. I hate it when pedants write in and do that.
Anyway, the whole idea is nonsense. Web content does not magically transmit itself from you to a disabled person. There are a number of intermediaries along the way. Most of those aren’t very important, like your actual Web server. But by far the most important intermediaries between you and whoever is visiting your site are the browser and adaptive technology. And not your browser, either – theirs.
It’s not even that new, but what certainly is new is the fact that I’m calling for everyone to take a pledge of some kind. The philosophy is really simple: If a browser or adaptive technology can or should handle an accessibility issue, I won’t.
You can say this in a really crude, punchy way: “It’s not my problem.” Because sometimes it isn’t.
The easiest example is font resizing. It just isn’t your problem if any visitor, with or without a disability, prefers a different font size. It still isn’t your problem even if the visitor cannot use or read your page without a different font size.
It isn’t your problem because you do not control the font size. You merely suggest the font size. It’s up to the browser and adaptive technology to decide what font size to actually display.
You find this problem expressed in a couple of ways. And people restate the same points over and over again until it seems like they actually make sense. They don’t.
For example, we’re constantly told not to use pixels as a unit to size text. Or we’re told that pixels are an absolute unit and you must only use relative units. Usually we’re told this by people who only recently found out there’s such a thing as Firefox.
Pixels are a relative unit by spec, full stop. You can use them if you want, full stop. You can use any unit for any purpose. You are merely suggesting the font size. It’s up to the browser or screen magnifier or whatever to pick the real size.
You usually won’t use px as a unit because there are really very few cases where type has to be a certain exact number of pixels in height. Maybe the fine print at the bottom of a page that lists the copyright notice and various disclaimers, that sort of thing. Standards-compliant authors aren’t gonna use pixels very much because the semantics of the pixel unit don’t come up very much.
If you run into a site that uses px for a lot of text, that’s gonna be the least of your worries. It’s like saying it’s OK to use tables for layout as long as you use exactly one table. It may be OK, and that’s debatable, but you never find that in the wild. You find a dozen tables for layout on one page. You don’t find just one table.
By the same token, you never find a really well-made site whose only flaw is the use of pixels for all its text. Those are 1997-era sites we’re talking about that use tables for layout and spacer GIFs and JavaScript links and all that nonsense. Picking on standards-compliant developers who very occasionally use the px unit avoids the real problem. It’s fundamentally dishonest. The people who overuse the pixel unit are the worst authors on the Web. Go after them instead.
There’s a variation of the complaint about pixels: We’re told not to use pixels because they can’t be resized. Well, they can’t be resized in a couple of broken browsers, IE6 and IE7. Yes, it really is true that they didn’t fix this bug in IE7. Incredible, right? The IE team fell down on the job there.
And anyway, font resizing is an issue for nondisabled people – or people who don’t have a visual impairment, more accurately. People with crap vision are already using a screen magnifier or a screen reader. I dispute the idea that making your fonts even 50% bigger is truly an accessibility issue. I dispute that it’s a dealbreaker for an actual person with a disability. If they’re that visually impaired, they can’t use their whole computer without help. The fact that your copyright notice is nine pixels tall isn’t gonna be make-or-break for them.
Font size just is not your problem as an author. We wouldn’t be using cascading stylesheets if we didn’t believe in the cascade. Whoever visits your site has ultimate control over how it looks, even if they don’t know that or they’re using a broken browser.
If you’re worried about text inside Flash movies, yes, it’s a nightmare. Why are you using Flash to deliver any kind of text that’s smaller than a headline? If you’re doing that, what business do you have criticizing other people about accessibility?
If you are truly interested in making things better for people who need really big fonts, then you need to agitate for screen magnifiers to produce really clear text. As far as I can tell, everything that isn’t ZoomText 9 blows up the already-drawn bitmap; it scales the pixels you’d be looking at if you weren’t using a magnifier. To my knowledge, only ZoomText 9 re-polls the original outline font file and asks for a new character at something like 250 point. You want things to improve, work on that.
And yes, this really does mean you should never jimmy up your own font-resizer on your own Web page. Do you jimmy up your own scrollbars, too? It’s a browser problem. You’re a doctor, not a bricklayer.
I read a lot of complaints about accessibility, and I hate the ones that come from critics who claim to represent people with cognitive disabilities. Usually this means dyslexia, but not always.
Their complaints are usually half-baked, and they’re not supported by research, and they defy the actual Web. The groups they purportedly represent have conflicting requirements and a wide range of needs even within the same diagnosis. And these critics are the most insistent on forcing authors to do things their way, almost to the point of calling you fascist if you disagree with them.
One thing I definitely agree with, though, is the impact of foreground and background colours. Even if the research is inconclusive, I know from my own experience that some colour combinations are a total bitch to read. And I’m not dyslexic. So of course I’m willing to believe that colour combinations have an effect on people with various reading disorders.
The problem is you can’t get a straight answer about what colour combinations to use. Or there might not be a straight answer because people with a certain condition prefer one set of colours while another group needs a different set. Or – and this is the biggie – the colours they need conflict with your own graphic design.
Because, at root, these critics don’t want you to have control over your own graphic design. They want a veto over the design of your site because someone they claim to represent might show up one day and have a hard time. They want to march you off to the Hague to face war-crimes charges for using black text on a white background. Because they mistakenly think it’s the author’s responsibility.
But they do have a point. It’s really taxing to look at white-on-black text all day when it’s coming from a luminous source like a glowing computer monitor. But the alternatives? Using some other set of colours? Not your problem. It’s a browser problem.
Remember, if these people can’t read your site, there are other sites they can’t read. Millions of them. You simply aren’t solving their problem if you cook up a set of new colour combos just for your site. They need accommodation across the board, not just from you.
So again, this is a case for browsers. And it’s somewhat easily fixed.
In Opera, you can select a so-called accessibility layout for any site. It gives you widely-spaced black text on pale-green background.
I’m calling on the Web Standards Project to publish a library of colour schemes and typography settings that can be included in all browsers. Some of the obvious options are:
Added letterspacing might or might not be useful. If you need that, then use CSS: letter-spacing: .1em;.
What I’m suggesting is that these libraries be published for universal adoption. I want every browser and screen magnifier to have them built in.
Another thing here: Content has to fit to the window width by default. You can override that if you want. I think Opera has it backwards; it permits horizontal scrollbars by default.
This is not a proposal to underline all the hyperlinks inside body copy and make them blue. I have no opinions on the correct link styles for these colour combinations. The Web Standards Project can work that out. The whole topic is a nice place to begin working on browser accessibility.
You the Web author absolutely do not have to produce your own sets of colour schemes. It isn’t your problem.
I didn’t invent the idea, but I popularized it in an article for A List Apart. The idea is your browser automatically converts a multicolumn page with dark text on a bright background to a single-column page with light text on a dark background. My esteemed colleagues at Nomensa in the U.K. did a user test. It seems that low-vision people are more or less equally happy if you convert a multi-column site to one or two columns, not just one.
The browser already knows how many columns there are on the page. It does. It can re-order them, sometimes badly but most of the time not. It’s pretty reasonable to assume that a div on the left-hand side that has a lot of links is going to be a navbar, for example, in an English-language site. It then follows that main content is going to be in the next one or two columns, with the rightmost column reserved for extras of some kind. Even if it’s wrong 10% or 20% of the time, it’s correct 80% or 90% of the time.
I no longer believe that a Web author should have to set up a zoom layout. It’s a browser issue and it should be built in.
Just a small addition: Sometimes you’re browsing with images off, or an image doesn’t load for a reason. A browser absolutely has to have a command to reload a specific image. Safari doesn’t, for example.
Because why? Because none of that is your problem.
I want everybody to take a solemn vow never to tell people to write headings or link text that make sense when pulled out of a document. This has been a completely incorrect idea since it first came up, and not only is it dead wrong, it defies the actual Web.
The idea is that some really cool adaptive technologies, and some total dogs like Jaws, let you pull up a list of headings or a list of links. Well, that’s great. And it’s seemingly harmless. It might even help: You can jump to a certain heading right away, or go to a certain link, though I don’t see how that one is really useful.
The problem is that HTML and XHTML documents are structured in a tree. A node can have siblings or parents or children. That’s why you can’t put a heading inside a paragraph, but you can have a heading followed by a paragraph.
There’s a reason we have six heading levels, and that reason is not just the semantics of a document, it’s the document tree. An h3 has to follow an h2 or another h3. Now, think back to the olden days. People would mix and match heading levels because the style for headings was too big and too bold. We told people to use CSS to regulate the style of headings and to use headings correctly.
Well, we can’t be a little bit pregnant: If we’re insisting that people use headings in the right order, we cannot also tell them to write heading text that makes sense in any order.
This is almost the stupidest advice in Web accessibility, and I don’t know why it hasn’t been killed off yet. If I am the writer of a page – and I mean writer, not author – then I have set up my headings at certain levels in a certain order because they must have those levels and order. It is solely my decision, not your decision and not Jaws’s decision. It’s based on document semantics.
There’s a corollary to this one. Some pedants want every heading on a page to have different text. And they absolutely insist, with foam pushing out of the corners of their mouths, that link text has to be different in every case. (Oh, but you can never use two different link texts to point to the same place.) Of course, this is nonsense, and it reveals their naïveté. I guess they don’t get out much and don’t read a lot of Web sites with product comparisons. (I cooked up an example page that reuses heading and link text for three different car models being compared.)
I’m sorry, but there really can be identical heading text several times on a page, sometimes with exactly the same heading level. And link text can be exactly the same, too.
I should really make a stronger point about link text. People who hate the Web always tell us that links should be grouped in little lists at the ends of paragraphs or documents. Because that’s supposed to be “accessible.” These people are enemies of our industry and need to be shunned.
A link is an inline element; you can style it to work as a block-level element, like in navbars that use CSS to look like buttons or tabs, but a link is fundamentally something you insert into running text. You the writer – again, not the author – have a reasonable expectation that people will actually read your text and understand the context of the link. Yes, people skim through Web pages, but people have to read your text if they want to understand the link.
As writers, we are not authorizing you or Jaws to pull out our link text and remix it. Why don’t you rearrange the sentences, too?
It’s your site and you can put links wherever you want. If somebody has some kind of expensive toy that takes your Web site and shakes it up like a pair of maracas, well, that’s their problem, not yours. To comply with Web standards, you have to write a well-structured document. Your document isn’t structured anymore if you’re encouraging people to firebomb your house and turn it into a pile of sticks. And people who think otherwise can stick it.
If your browser or adaptive technology cannot display or render the title attribute of a link or of anything else, then it’s broken. You the author are permitted by spec to add titles to nearly anything, and in common use you will mostly find title on hyperlinks.
Of course you can use the title attribute to add more information. If somebody comes along with a broken browser or screen reader or whatever, how is that your problem? If the complaint is that tooltips don’t hold enough text and disappear too fast, well, who said that titles had to be displayed as tooltips?
Also, what is the real problem here? If I misunderstand a link, I get a page I don’t want? Well, quit crying to mommy: Hit your Back button or press a key on your keyboard and you’re back where you started from. Really, this is hypertext, not Club Med, and things are going to go wrong now and then.
If people would limit themselves to cases where an unclear link text is really harmful, I’d be on their side. For example, I think that links to PDF files need to be super-explicit. I put “(PDF)” in the link text, I start the title attribute with PDF:, and I use the correct link type, type="application/pdf":
<a href="item.pdf"title="PDF: Fuel economy in hybrid and diesel vehicles, 2007"
type="application/pdf">
a new report (PDF)</a>
And anyway, a device should be able to tell from the filename extension that we’re dealing with a PDF. Linking to something like that is really linking to non-Web content, and you have to warn people.
That sort of thing has to be crystal-clear. Or maybe when you’re linking to porn, or when you’re linking to a page that automatically plays sounds or music. Sure. But linking to a normal Web page that somebody doesn’t expect? Give me a break.
I really wish people would get off our backs about these things. First of all, nobody is ever going to be able to agree on the definitions of those terms. But whenever there’s an argument over definitions, what’s really happening is an effort to redefine one concept as another concept. Maybe people want every initialism to be called an acronym, and every acronym an abbreviation, which means that you only have to use abbr in your markup.
It doesn’t matter. In the real world, we have abbreviations, acronyms, initialisms, symbols, notations, and more. HTML is simply inadequate to mark up everything under the sun. HTML doesn’t even have footnotes, for example. And you’re arguing over what’s an acronym and what’s an abbreviation? Please.
Besides, the entire discussion shows a lack of scholarship. The people with an axe to grind can only ever come up with computer terms as examples, maybe because they’re nerds. But even at my local public library I was able to find reference books like The Canadian Dictionary of Abbreviations by Thérèse Dobroslaviƈ, 1994. As a staunch defender of Canadian English, that’s what I’m gonna use here.
And some others from real life:
And the WCAG requirements do not actually achieve accessibility. You’re supposed to specify the expansion of an abbreviation or acronym the first time it appears. You can do it any number of ways.
And the requirement also ignores the fact that you can jump into a document at any point. You can easily miss the expansion that’s farther up in the document.
If you don’t understand an abbreviation or acronym, why is it the page author’s responsibility to solve the problem? You can’t Google it? You can’t look it up in the dictionary? Who told you that you had the right to understand every paragraph, sentence, word, syllable, fragment, and letter on a page?
Anyway, this all boils down to a failure of software: Screen readers should include well developed exception dictionaries. But of course they don’t. I mean, for years they couldn’t even differentiate between homographs reliably. Those are words that are spelled the same but pronounced differently. The big one is R-E-A-D: Is it “reed” or “red”?
Or how about one that’s familiar to everyone interested in accessibility, a skip-navigation link? If you use the link text “Skip to content,” be advised that some screen readers cannot even get that right. They say “skip to contént,” which isn’t even English.
We work in an industry in which we expect people with disabilities to shell out hundreds of dollars for software that will just barely put them on a level playing field. Then we find out that these screen readers cannot even read real-world text. Maybe it would help if the developers had writers or linguists on staff.
So of course it’s too much to ask for these products to have really good exception dictionaries. In English, abbreviations and acronyms are usually easy enough to spot, even if you use one of the antiquated British house styles and leave periods off many abbreviations. A lot of these things do have periods or hyphens, or they’re written in all caps or a strange mixture of upper and lower case, and they appear in predictable patterns inside sentences. Even some seemingly confusing uses aren’t that confusing. Here’s the main drag of the University of Toronto:
This is not as easy in other languages. An example I can give you is from Italian, for a legal company designation: SpA (Società per Azioni). Sometimes you write that as S.p.A., which helps, but other times you don’t, and it looks like “spa,” except that even a program as dumb as Jaws should be able to notice the lower-case p. (You find something vaguely similar with a British company designation, plc.)
Here’s one from German:
Do you think that examples like that can be handled really well by HTML markup?
I asked developers at Freedom Scientific and GW Micro to tell me a bit more about their exception dictionaries for abbreviations and acronyms. They didn’t.
How about VoiceOver on Mac? Well, it’s a joke.
The full list of pronunciation exceptions is 802.11b and g, two smileys, GIF, GUI, SMPTE, and SQL, for which it gives only one of two pronunciations (“sequel” and not “S-Q-L”).
I don’t have perfect advice on this topic. I only have partial advice. I think you should follow HTML semantics and use abbr for abbreviations and acronym for acronyms. But you really only have to do that for items that might be mispronounced. And I think you need to specify an expansion only if a reasonable reader won’t know what the short form is. That means if your site is about public health, you don’t have to expand “E. coli” or “C. difficile.”
I checked my own documents. On my personal Weblog, for example, I used acronym without expansion 149 times and with expansion 93 times. Most of the time I don’t expand acronym. I used abbr without expansion 46 times and with expansion 200 times. Most of the time I do expand abbr. I added a specific language code twice.
By the way, we’re solving this problem properly in accessible PDF. PDFs are binary files and can contain little databases. In fact, PDFs really are databases. So we’ve decided that abbreviations and acronyms will be internally linked to little lookup tables that the user may query if they’re confused. That means we can disambiguate “St. George St.” perfectly every time. HTML can’t do that. Maybe we should stop trying so hard.
Let me give you one of the little catchphrases of Web accessibility. And we really do have catchphrases.
“We can make a Web site work with zero hearing. We can make one work with zero vision. We can even make a Web site work with almost zero movement. But we can’t make a Web site work with zero cognition.”
That’s kind of unfair, right? It’s an exaggeration. Most people with disabilities using the Web do not have “zero” of any particular sense or ability. We deal a lot with totally-blind people using screen readers. Maybe too much, in fact. But most people have at least a little of the sense or ability left over that would cause them to need accessibility in the first place.
And that is of course still true of cognitive disabilities, including dyslexia. It isn’t true that these disabilities are always nicely isolated little deficiencies, like having a hard time reading print. There are often other cognitive deficiencies involved, like short-term memory loss. But when it comes to Web accessibility, we understand that having one of these learning disabilities merely means you have a learning disability, not that you can’t understand the topic we’re discussing or you can’t do anything else in your life. It’s one fact about you, but not the only fact.
My problem here is that advocates for people with cognitive disabilities don’t seem to be interested in isolating their advice the way the disabilities themselves are isolated within people. Having a learning disability isn’t everything about you; it’s just one thing. But advocates seem to think the Web is really only one big thing, and it must be completely made over to their specifications.
There seems to be an effort to apply cognitive-disability guidelines across the board. WCAG 1 doesn’t totally back that up, but the only real guideline that pertains to learning disabilities tends to be overapplied to the real Web.
WCAG Checkpoint 14.1 says “Use the clearest and simplest language appropriate for a site’s content.” People tend to overlook the last few words there: “appropriate for a site’s content.” They tend to write E-mails to site owners complaining that the writing of the site isn’t clear and simple enough.
Or, if they’re going beyond the WCAG guidelines, they write in to complain that there’s too much use of allusion or sarcasm, which are hard to understand.
If you’re advocating for increased accessibility for dyslexics or anybody else with a learning disability, then every site tends to look like a nail, and the only tool you have is a hammer.
We can ask that every picture on the Web have an alt text. We can ask for really good Web semantics, and that includes really good forms. We can ask for captioning and audio description on videos. But we can’t ask every site to “write clearly and simply.”
I’m not the first person to say this, but whenever other people bring it up, they tend to mention the original use of the Web, which was for a physics laboratory. Or they use computer technology itself as an example. But as with acronyms and abbreviations, that’s too facile.
If you think that every site on the Web can be written clearly and simply, maybe you need to look at Web sites that are narrowly focussed on a limited topic. So let’s look at one now. And that limited topic is gardening, which everybody who has so much as a square inch of land likes to do.
I looked at this page by the Royal Horticultural Society. It’s about a plant disease called sudden oak death, which sounds like a great name for a rock band.
Pathogens
Phytophthora ramorum (ramorum blight, popularly known as “sudden oak death”) and P. kernoviae.
The former occurs in Europe and in western USA. The latter is a previously unknown species occurring at only a few sites in the UK, mostly in Cornwall, where it was discovered during surveys for P. ramorum. Neither are native to Europe or the USA but their origins are unknown.
Problem
Leaf, stem and bark infections on various native and garden trees and shrubs. Both species are frequent on rhododendrons; viburnums are a major host of P. ramorum only. Bark canker caused by P. ramorum was recently discovered at a single site on Quercus petraea, the first record on a native English oak. Cankers on trees have been relatively rare and most are associated with heavy leaf infection in understorey rhododendrons.
That’s a site about gardening. You could clean it up a little. You could make the references easier to follow; you could avoid using terms like “the former” and “the latter.” But these organisms do not have everyday names. You would have to keep using the Latin designations just to accurately describe what’s going on with this pathogen. And even the common names of many plants are pretty big words – rhododendrums, viburnums.
This is a page that is probably impossible to make accessible to a wide range of people with cognitive disabilities. There is probably nothing you can do to make it really work. And it’s an informational site about gardening from a society endorsed by the royal family. You could barely come up with a more mainstream example.
And what are some other examples? Well, start with blogs. We’ve got millions of the things, and most of them are about expressing oneself. A lot of people who are bad writers just forge on ahead and create their own blogs. Why not? They can. Everyone has a printing press now.
I’m gonna go out on a limb here and say that, while we might insist on good HTML and proper alt texts and so on, which don’t interfere with personal expression in any serious way, we can’t go around and tell blog authors that they have to write in only a certain way.
It may be true that personal blogs by their nature are inapplicable to accessibility for people with cognitive disabilities. Not exempt, inapplicable. They’re just not the kinds of sites that should apply those guidelines.
How about news sites, including wire services? Sometimes you see the same wire story on ten different sites. News reports are often written quite simply, but first of all, there are words in there you can’t change, like geographical names or the actual legal names of certain criminal charges. And second of all, the sites that pick up a wire-service story may not have the right to change it substantially. They usually have the right to make small changes, like turning Fahrenheit temperatures into Celsius.
Or maybe transactional sites. A catalogue of items may have to use the names of those items.
Or literary sites. If you post your journalism or your fiction online, you shouldn’t have to rewrite it.
Those are just some examples of sites where accessibility for cognitive disabilities may be inapplicable.
The question is: Where are they applicable? If the title of this presentation is “When accessibility is not your problem,” when is it your problem?
I do have some ideas here.
I think if you have a Web application and you want to make it more accessible, and you make a so-called simple version as a way to do that, you should keep the so-called regular version. That’s because people grow more competent over time and they won’t always need handholding. Even people with learning disabilities appreciate shortcuts sometimes.
I think it’s way too hard to write clearly and simply even if you want to do it. I think the writing tools are terrible. Really, they’re nonexistent. You can learn to write just by writing, but this is the sort of thing where software should be helping you out. And I don’t mean the grammar checker in Microsoft Word. You need help learning to write simply. Plain English is harder than complicated English.
Next, if you want to use markup to make your complex writing accessible, maybe by including explanations of sarcasm and allusions, well, there’s pretty much nothing that would help for that. This is a perfect place for a microformat. You could use span or a div with a certain kind of class name, like metaphor or double-meaning. And you could style those differently if you wanted. This is a good place for the CSS cursor styles, like cursor: help.
I think Lisa Seeman down in Israel has been talking about improving the “authoring tools” in this way. We now have a way to do it pretty easily – microformats.
And it’s been my experience that nobody knows there are screen readers specifically for people with learning disabilities. A company that was founded by the genius who invented the reading machine, Ray Kurzweil, has a few products. (Ray Kurzweil doesn’t own the company now, and actually, the big thing he invented was optical character recognition that could read any font, not the part about reading text out loud.)
These products do a lot of useful things. They’ll read out words or sentences while they highlight them on the screen. They can isolate words or sentences so you aren’t overwhelmed by the amount of text.
Browsers could be improved. Apart from handling colour combinations for Web sites, what about the no-stylesheet view? What happens when you turn off CSS altogether? Of course that’s a misnomer, since what you’re really looking at is the browser’s default CSS. I think this sort of thing will happen more often with cognitively-disabled persons than others. They load up your site, and they try to read it, and they sit there kind of hanging by a thread trying to understand it. This groups is more likely to kind of give up on some sites and have to use a brute-force technique just to read it. But the typography of default stylesheets hasn’t really improved since Netscape 2.0.
Really, with the much better fonts we’ve got, I see no reason for everything to be Times Roman, with too much bold, not enough linespacing, and line measures as wide as the window. That could be cleaned up almost immediately at next to no effort. You could produce a better default stylesheet single-handedly. And there’s no reason why the onscreen default stylesheet has to have a bright white background. We could go back to light grey, sort of like Netscape 0.9. The print stylesheet could still have no background colour specified.
Posted: 2007.06.14 ¶ Updated: 2007.06.16, 2008.02.16