Sunday 05 May 2002

Netscape 4.x users. Enough already!

Burningbird has suffered The Attack of the Nagging Netscape Users:

I’ve had entries in my comments in addition to email that the images are overlapping the text when my new weblog is viewed in Netscape 4.7.

I can’t fathom why we are expected to jump through hoops to accommodate users of a browser that (depending on who you believe) commands 2-4% market share and that, as Joe Clark put it, “cannot interpret standard HTML or stylesheets, or, what is far worse, it disastrously misinterprets them.”

To make it worse, supporting Netscape 4.x users makes it far more difficult to create accessible sites. In an article titled To Hell With Bad Browsers, Jeffrey Zeldman summarizes the argument:

…consider the new laws about web accessibility. Separating style from content via HTML 4/XHTML and CSS can help you comply with these laws. Sticking with hacks and workarounds makes compliance that much harder. The temporary downside is that standards-compliant sites may not look great in older browsers. But most users can upgrade their browsers far more easily than people with disabilities can “upgrade” their eyes, ears, or limbs.

In another article (Why Don’t You Code For Netscape?) Zeldman answers the question that Netscape 4.x users are asking Burningbird:

Q. Your website looks nice in Internet Explorer 6, but really bad in Netscape 4.7… Please explain the logic of designing only for one browser.

A. Thanks for writing. We don’t design for only one browser. We design for all browsers and devices by authoring to W3C recommendations including XHTML 1.0 Transitional and Cascading Style Sheets.

As a result, A List Apart displays properly in Opera 5, Opera 6, MSIE5, MSIE5.5, MSIE6, Netscape 6, and Mozilla, while its text is available to any browser or Internet device, from Netscape 1.0 to Palm Pilots and web phones. as it appears in Netscape 4.79This site also displays properly in Opera 5, Opera 6, MSIE5, MSIE5.5, MSIE6, Netscape 6.2, and Mozilla. It doesn’t display properly in the beta version of OmniWeb, though perhaps it eventually will.

The illustration at the left shows how this site appears in Netscape 4.x (and earlier versions). Click on the image to see a full size screen shot.

Users of ancient browsers see the logo, site title & description, then the content, and finally the calendar & links. It doesn’t look pretty but the content’s all there, including the pictures. The structure of the page is obvious because the site name & description, entry dates, and post titles are formatted as Headings 1, 2, and 3 respectively. (I’m not saying I’m Jonny Fantastic—I got all this stuff from Mark Pilgrim.)

But, unlike Burningbird, I don’t get email about the images overlapping the text.

To accomplish this, I use the @import method

<style type="text/css" media="all">
@import "/css/styles.css";

to ensure that 4.0 browsers don’t see the style sheet and can’t botch the rendering of the page.

So why is it that Netscape 4.x users—who could easily upgrade to a standards-compliant browser—put their desire to use an obsolete browser above the needs of all other Web users? Not just above those with disabilities who benefit most from accessible sites, but above everyone who uses a modern browser. And why are they so frequently arrogant about it? As if using a tenth-rate browser is a mark of distinction.

Many years ago, I bought a copy of Helix, a graphical relational database for the Macintosh in which fields, relationships, calculations, queries, and layouts are represented by tiles that you drag around and connect. Developing a database in Helix was a bit like play mah-jong. I’ll never forget opening the manual and reading the first sentence:

If you don’t have a hard drive, you should run out and buy one.

It’s about time we said something similar to Netscape 4.x users:

If you wish to see this site as it’s meant to be viewed, you should download and install a standards-compliant browser.

Permalink | Comments (13)

Tuesday 11 June 2002

Thanks but no cigar

Commenting on my World Cup Game Tracker post, Kestrel identified herself as a blind computer user who, after hearing about the accessibility improvements in Flash MX, had visited the Macromedia site and tried to download the trial version.

The newest version of Flash might be accessible, but trying to figure out where the link was to download this wonder while using a screen reader was not possible.

John Dowdell from Macromedia Support left an apologetic reply—promising to follow up Kestrel’s problems and noting that “the Macromedia web team is working on a major set of enhancements to the site.”

The opportunity to enlist Kestrel as an accessibility consultant was too good to pass up so I asked her if she’d mind offering a critique of the World Cup Game Tracker and the Broadmoor Online Reservations Flash applications. Kestrel’s verdict:

I checked out the two web sites you included, the newstracker for the World Cup and the hotel. For all I know, both sites led to blank pages. No sounds, no text, no links. I tried both clicking on the link by hitting return and using the right click button on my JAWS keypad. This was using IE 6 and JAWS 4.02, both the latest versions, so if anything could be gotten from the experience, I should have gotten it. Whenever I run into this situation, I think of a slumlord slapping a coat of paint over a condemned building and calling it “newly renovated”. Sometimes I think web designers are the snake oil salesmen of the 21st century. When will these guys have to live up to some standards? It isn’t an accessibility issue anymore, it’s a usability issue. PONR!

These sites may be impressive and useful to sighted Web users but they are neither accessible nor usable. “When will these guys have to live up to some standards?” When enough of us care sufficiently to make accessibility a priority.

Permalink | Comments (2)

Accessibility not a priority?

Mark Pilgrim is determined to change your mind:

Since she was not born blind, Jackie understands sighted concepts like colors, and she still talks about colors with her mother in terms of things that were in her life “before”. The one thing she does not talk about is the car accident that killed her father and left her blind; it is only referred to indirectly by prepositions: “before” and “after”. “This is green like the walls of the living room before.” “It’s sort of like that pink sweater you wore before, only lighter.” And so forth.


Wednesday 12 June 2002

Shades of gray

30 days to a more accessible weblog (Day 2):

Michael sees the world in shades of grey. This is not a business cliche or a philosophical statement; he really sees the world in shades of grey. He has Achromatopsia, or complete color-blindness. All of his clothes are discretely labeled with letters, R for red, B for blue, DG for dark green, and so forth. His girlfriend has compiled a compatibility matrix that specifies which clothes he is allowed to wear together. He follows these instructions to the letter, so to speak, although he does not understand why they matter.


Thursday 13 June 2002

Someone who knows everyone

Day 3 and I’m beginning to realize how much I take for granted:

[Bill’s] one big computer-related indulgence was a keyboard extension that gives him a second set of arrow and PageUp/PageDown keys, so he can more easily reach them with his good hand. $29.99, with a $5 mail-in rebate, which he mailed in.


Friday 14 June 2002

Fresh off the boat

54 year-old eyes (Day 4):

Lillian likes Matt; he’s the nicest of the bunch, and he even once set her text size to “Larger” in Internet Explorer, so now her daughter’s weblog is actually large enough to be readable. She reads it every day. But when she asked Matt why she couldn’t make any larger, Matt launched into one of his geek tirades with lots of big technical words, got very frustrated, and finally said there was nothing he could do.

That’s because uses fixed pixel sizes for their text. But wait a minute, so do I! I’ve been meaning to do something about that.

Permalink | Comments (5)

Saturday 15 June 2002

Blind since birth

Jackie, Michael, Bill, Lillian. And now, Marcus:

Marcus also uses an ALVA at home, where he runs the text-only browser Lynx in a full-screen DOS window. He reads the web at home in much the same way that he reads his calls at work: in Braille, one line at a time. He hates screen reader software, and he wouldn’t hear it even if he had it, since he always has talk radio on at top volume from the minute he gets home until the minute he goes to sleep.

Plus a belated introduction. From next Monday, 25 tips for making our weblogs more accessible…


Monday 17 June 2002

Accessibility matters

As one might have expected, Mark Pilgrim’s accessibility case studies provoked a variety of responses.

Todd Fahrner

Mark Pilgrim’s been telling stories about Web accessibility at his shiny xhtml 1.1 blog all this week, and plans to keep it up. You’d think that sites like would be half as conscientious as Mark about such matters, but no.

Simon Willison

While I applaud his aims and greatly look forward to the series, I can’t help but feel that limiting the series to just bloggers is an unnecessary move. I expect most of the tips to be applicable to a wide array of sites and the web is crying out for a good resource for improving general site accessibility.

Ralph Brandi

Dave Winer says that Mark Pilgrim has noted that he’s got people ripping him apart for the series on his blog entitled “30 days to a more accessible weblog”. (I’ve seen some of the parodies, and they’re vicious. Funny, but vicious. And clueless.) That’s a real shame, because the kind of personas he’s creating are an excellent way to gain a better understanding of the kind of visitors your web site is going to get.


Christ Mark, could you get any more preachy? … Here’s my suggestion for day three:
“Gregory, who goes by Greg, is 21 years old. He is a junior at a large state university, and is a member of a fraternity.
“Greg cannot get laid. This is not a popular culture cliche or a philosophical statement; he really cannot find a girl who will have sex with him. He has “No Game…”


I’m not sure if you know this, but I’m colorblind. It’s really not a big deal, and doesn’t play a major part in my day-to-day life. I recently read this story on “Dive into Mark”. I’m not sure if this ‘Michael’ person actually exists, but if I were him I’d be pissed off about this article.

[next day] After yesterday’s post, I got a nice email from Mark. He changed his article on the fictional color-blind ‘Michael’. Now Michael just leaves images off because he doesn’t want to waste his bandwidth. Sort of makes the whole “colorblind” aspect of his character useless now though.

Peter van Dijck

This is too good not to link to… Describing case studies has too long been the stepschild of user research, numbers and graphs were long seen as the ultimate conveyors of truth (see Market research). Time to change that back. There is a lot of detail lost in the numbers and graphs, and a long time ago, the medical profession (for example) recognised that. They used to do detailed case studies; what happened to that practice?

Dave Winer

The hard work is unlocking the power for masses of people, people who couldn’t care less about ontologies, or semantic webs, or even accessibility. If you want all that stuff, you have to learn how to make products that work for people, and accomplish your goals, if you can figure out how…

PS: The bit about accessibility is deliberately provocative. Think about it. People with disabilities don’t want accessibility, they want to use the Web. Different perspective.

The recurring themes?

  • It’s a pity the series is only aimed at webloggers.
  • I thought they were real people.
  • Case studies vividly explain the issues involved.

I think Mark’s approach has been exemplary. First, he ensured that his own site is accessible. Then, without any preliminary explanation, he dropped us into a series of well-written and engaging character sketches that, by personalizing the issue, provide the best reason for caring about accessibility. Most importantly, he has promised to follow up with a series of tips that we can immediately apply to our own weblog templates.

That the series is aimed at webloggers rather than a more general web audience seems OK. Better to start with a defined target audience and trust that the story will ripple out from there.

I’m aware that many bloggers believe they have an obligation to be truthful in their posts, but it’s irrelevant to me whether the personas are based on real people or not. I reject the illusion of “journalistic truth,” believing instead that a well-written fictional character is usually more engaging and believable than a “real person.”

Nor do I have any problem with the parodies. I’m committed to making my own site more accessible by implementing Mark’s tips as he publishes them. Yet I also believe that no issue, idea, or argument should be exempt from (even harsh) critical analysis—as long as the criticism is directed at the position, not the person holding the position. If we’re going to start granting exemptions for special issues or special people, we may as well admit that John Dvorak was correct when he implied that blogging is little more than a cross-linking mutual admiration society.

As for Dave Winer’s statement that “people with disabilities don’t want accessibility, they want to use the Web,” that’s not really a different perspective, that’s just Dave being provocative, as he admits. People with disabilities do want to use the Web and we can significantly enhance their Web experience by designing accessible sites. They may not want accessibility but they certainly need it.

Hats off to Dave Winer, though, for supporting a righteous cause. The traffic he directed to Mark Pilgrim’s site this week probably outweighed the flow from all the other links combined. As we embark on the adventure of making our weblogs accessible, Dave deserves the final word:

I support what [Mark’s] doing, his narratives of real-world case studies for accessibility are just what I wanted, to help me understand what the issues are, and what solutions exist.

Permalink | Comments (5)

Tuesday 18 June 2002

Accessibility tip 01: DOCTYPE

Seems like grammar is in the air. Mark Pilgrim’s first accessibility tip begins:

You start your sentences with a capital letter; start your HTML with a DOCTYPE. It’s just basic grammar.

Well, I’m off to a promising start. All my Movable Type templates begin with a DOCTYPE:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

Since I write most of my posts in Dreamweaver MX, I’ve noticed that the default Dreamweaver XHTML document actually starts with the line:

<?xml version="1.0" encoding="iso-8859-1"?>

(I think I removed this because it could mess up the RSS Auto-discovery mechanism. Or something. In any case, the character encoding is specified in a meta-tag in the document HEAD.)

And Dreamweaver’s HTML tag reads:

<html xmlns="">

whereas mine says:

<html xmlns="" xml:lang="en" lang="en">

No doubt, someone will explain whether the added lang=”en” attributes are necessary.

Uh-Oh! Here’s trouble!

After reading the W3C’s explanation of the various flavors of markup, I’ve realized I didn’t have to settle for XHTML Transitional.

XHTML 1.0 Strict - Use this when you want really clean structural mark-up, free of any tags associated with layout. Use this together with W3C’s Cascading Style Sheet language (CSS) to get the font, color, and layout effects you want.

XHTML 1.0 Transitional - Many people writing Web pages for the general public to access might want to use this flavor of XHTML 1.0. The idea is to take advantage of XHTML features including style sheets but nonetheless to make small adjustments to your mark-up for the benefit of those viewing your pages with older browsers which can’t understand style sheets. These include using BODY with bgcolor, text and link attributes.

But, before changing the DOCTYPE in my templates, I thought I’d check that my weblog index page still validated as XHTML Transitional. It doesn’t (although it used to). The W3C’s validator found dozens of errors, all related to links to other sites.

For example, in my previous post I included Steve Himmer’s link to the Amazon search results for “Georges Perec.”

<a href="">

The validator returned four errors associated with this URL:

  • Error: unknown entity “field-keywords”
  • Error: reference not terminated by refc delimiter (the “=” sign between “keywords” and “georges”)
  • Error: unknown entity “bq”
  • Error: reference not terminated by refc delimiter (the “=” sign between “bq” and “1”)

I understand that (quoting A List Apart) “DOCTYPEs are a key component of compliant web pages: your markup and CSS won’t validate without them” and “DOCTYPES are also essential to the proper rendering and functioning of web documents in compliant browsers like Mozilla, IE5/Mac, and IE6/Win.”

But if a link to a page at Amazon causes my weblog page not to validate, what’s to be done?

<later>Answer: escape the ampersands.</later>

Permalink | Comments (6)

Wednesday 19 June 2002

Accessibility tip 02: Language

“You know what language you’re writing in,” says Mark Pilgrim, “so tell your readers… and their software.”

Since I’m using XHTML 1.0 Transitional, my <html> tag should read:

<html xmlns="" lang="en" xml:lang="en">

It turns out I was already ahead of the game—I asked about this in my DOCTYPE post. And, as Dorothea Salo explains in the comments on that post, it’s another Belt & Suspenders solution:

HTML added the lang attribute to the tag long before XML came around… So doing both is another case of belt and suspenders. Non-XML-grokking HTML engines will grab the lang attribute; XML-grokking engines can grab either.


Thursday 20 June 2002

Accessibility tip 03: Doc title

I like the way Mark Pilgrim organizes his accessibility tips into sections:

  • Define the principle (today’s is “Every page of your weblog should have a unique and meaningful page title.”)
  • Explain who benefits from our implementing the tip (“Marcus benefits. Lynx displays the page title in the first line of output, so it’s always the first thing that Marcus reads in Braille.”)
  • Describe how to do it for each weblog template (“…if you are using the default [Movable Type] template, you don’t need to make any changes.”)
  • Provide links to further reading on the subject.

I made a couple of minor changes to my MT templates, such as adding the <$MTBlogDescription$> tag to the Main Index title. My <title> tags and the resulting page titles are listed below.

Main Index
<title><$MTBlogName$>: <$MTBlogDescription$></title>
Jonathon Delacour: The Heart of Things

Archive Index
<title><$MTBlogName$>: Archives</title>
Jonathon Delacour: Archives

Category Archive
<title><$MTBlogName$>: <$MTArchiveTitle$> Archives</title>
Jonathon Delacour: Japan Archives

Date-Based Archive
<title><$MTBlogName$>: <$MTArchiveTitle$> Archives</title>
Jonathon Delacour: June 2002 Archives

Individual Entry Archive
<title><$MTBlogName$>: <$MTEntryTitle$></title>
Jonathon Delacour: Accessibility Matters

Is there anything more pleasurable for the ambitious student than to be praised by the teacher? About my Individual Entry Archive title, Mark wrote:

Individual entry archive pages should include the name of your weblog, followed by the entry title. I don’t have separate pages for individual entries, but Jonathon Delacour does, and he gets this right. For example, his post of June 17, 2002, Accessibility matters, is archived on its own page with the title “Jonathon Delacour: Accessibility matters”.

I’m not going to let this go to my head nor am I resting on my laurels. Sooner or later I’ll be getting into serious trouble for using absolute font sizes (in pixels) instead of relative font sizes (using ems, keywords, or percentages). And I don’t think Mr. Pilgrim will be the slightest bit impressed if I say: “But sir, Zeldman told me to do it!”


Friday 21 June 2002

Accessibility tip 04: Navigation aids

In today’s accessibility tip Mark Pilgrim asks us to provide additional navigation aids to pages that can be viewed sequentially, such as those in a weblog’s daily or individual entry archives. I already have visible navigation aids (in the form of «Previous | Home | Next» links) on these pages—implemented with the usual a (anchor) tag.

However, Mark is suggesting that I use the link tag to add a duplicate set of navigation aids that, although “normally invisible to visual browsers like Internet Explorer, can be displayed in alternate browsers and help users navigate through [my] weblog.”

Adding the necessary code to my two Movable Type templates took less than a minute. All I then had to do was FTP the modified templates to the server and rebuild my site. Total time required? Less than 5 minutes.

Permalink | Comments (3)

Saturday 22 June 2002

Accessibility tip 05: Main content first

No problems for me today on the accessibility front—my CSS-based layout already displays the main content while the rest of the page is still loading. I have three positional DIVs:

  • header (logo, site name, site description)
  • content (weblog posts)
  • links (calendar, contents, recent entries, favorites).

My pages load in that order: header then content then links. As Mark said, the default Movable Type template gets it right. But I had no trouble building totally new templates based on a BlueRobot design. All you have to do is put the positional DIVs in the correct order.

I did check my site in the Lynx Viewer and it behaved as expected (kind of how it looks in Netscape 4.x but without any graphics). So it looks like an easy weekend for me. For those of you who don’t use CSS for positioning, get cracking on modifying your table code.


Tuesday 25 June 2002

Accessibility tip 06: Skip navigation

If you couldn’t hack your table-based template to present your main content first, Mark Pilgrim offers a compromise: allowing Lynx and JAWS users to skip over your navigation links entirely.

If your main content does comes first, this tip does not apply and Mark has given you a day off. I think I’ll use my day off to start work on the changeover from absolute to relative font sizes. Dorothea Salo has already made the switch and her site looks pretty spiffy so I might steal a leaf or two out of Dorothea’s style sheet.

Permalink | Comments (6)

Wednesday 26 June 2002

Accessibility tip 07: Use color safely

In today’s accessibility tip Mark Pilgrim focuses on the color of link text. I wasn’t sure that my (not particularly bright) blue active links and my gray visited links contrasted sufficiently with the white page background. When I checked my site with VisCheck however, the links were easy to discern as was the difference between them. I’ve also chosen to leave my links underlined rather than making them bold or italic (which I prefer to reserve for emphasizing words or for book or movie titles). On my site underlining always means a hypertext link.

<edited>Well, as you can see, Professor Salo’s opinion that “underlined links are just plain ugly” persuaded me to abandon that practice. Now bolded blue text always means a hypertext link and I promise not to use underlining at all.</edited>


Thursday 27 June 2002

Accessibility tip 08: Use real links

Mark Pilgrim directs our attention to “the scourge of web design.” It’s the javascript: link, “a pseudo-link that executes a piece of Javascript code when you click on it.” In weblogs, including mine until today, this is commonly used to display comments in a separate (smaller) window. Unfortunately, anyone whose browser doesn’t support JavaScript couldn’t make a comment on any of my posts.

The default templates in Movable Type and Radio UserLand don’t rely on JavaScript but my templates are derived from older versions that I’ve subsequently modified. Happily, implementing Mark’s fix took less than ten minutes.

Searching the template code for “javascript” also revealed that I was using JavaScript to create a spam-proof email link. Clicking on the word “Contact” in my navigation panel automatically opens the visitor’s email client (via a mail:to link) and creates a new message with my email address inserted in the To: field. Since spammers harvest email addresses from these mail:to links, I was using the following JavaScript to encode my email address, using character entities rather than actual text:

<script type="text/javascript">
document.write('<a href="mailto:&#106;&#111;&#110;&#97;&#116;&#104;&#111;&#110;
&#110;&#101;&#116;" title="Send me an email message">Contact<\/a>');
// -->

But there doesn’t appear to be any reason to use a JavaScript document.write() command to accomplish this relatively simple task—or, if there is, I’m certain someone will quickly draw my attention to it. So I simply replaced the JavaScript with the encoded mail:to link:

<a href="&#109;&#097;&#105;&#108;&#116;&#111;&#058;&#106;&#111;
title="Send me an email message">Contact</a>

This also fixed a problem with Mozilla 1.0, caused by the escaped forward slash (<\/a>) in the link.

And no, in case you’re worrying, you don’t have to encode your email address manually. The fantomas mailShield™ will do it for you.

Permalink | Comments (12)

Friday 28 June 2002

Accessibility tip 09: Add link titles

Weblogs, by definition, link to other sites. Yet, as Mark Pilgrim points out, few bloggers take advantage of the fact that the anchor (<a>) tag can have a title attribute, whose value appears as a tooltip in visual browsers but can be presented in non-visual browsers too.
For example:

Using the title attribute of the anchor tag to describe the meaning and/or purpose of the link

Mark suggests which links might best benefit from titles. He also points to an AlertBox column by Jakob Nielsen called Using Link Titles to Help Users Predict Where They Are Going, in which Neilsen explains the importance of link titles and offers detailed guidelines for their use. Mark’s advice is a little simpler: don’t overindulge with link titles—in Web design, as in life, “all things in moderation.”

Permalink | Comments (2)

Saturday 29 June 2002

Accessibility tip 10: Define keyboard shortcuts

I had no idea that you could assign keyboard shortcuts to links and form fields in an HTML document. Today’s accessibility task was to define the following access keys:

  • Home page—Access Key 1
  • Skip to main contentAccess Key 2
  • Search boxAccess Key 4
  • FeedbackAccess Key 9

It’s been relatively smooth sailing for me until now, which I attribute mainly to a combination of CSS-positioning and Movable Type. Today I struck a snag or two.

When I tested the access keys in ie6win, only the Search Field (Access Key 4) worked. I checked back with Mark’s page and followed the link to Paul Bohman’s post on Access keys in IE6 (part of a discussion of accesskeys on the Web Accessibility Forum Mailing List). The last paragraph gives the answer:

By the way, I actually prefer the way that Netscape handles accesskeys. You don’t need to do anything extra to make them work. In Internet Explorer in Windows, you have to use the keyboard shortcut then you have to hit enter. The extra step severely reduces the efficiency of the technique, in my opinion.

Hitting the Enter key after pressing the Access Key did the trick. In Opera 6, none of the access keys worked whereas in Mozilla 1.0 they all worked (although the default “Google” text was not selected as it was in IE).

Access Key 1 (the Home Page) worked in Netscape 6.2 but I was unable to test the other two because my entire navigation panel has disappeared in Netscape 6.2! It’s all there in the source code so perhaps I’ve introduced some bug into the CSS but I have no idea what’s happened to it and it’s too late on a Friday night to investigate any further.

<edited>The problem was my recently introduced SiteMeter code. I moved it to just before the closing body tag and Netscape 6.2 happily displayed the navigation panel. Go figure.</edited>

I’ve summarized the results in the table below.

Support for accesskeys in different browsers
  Access Key 1
Home Page
Access Key 4
Search Field
Access Key 9
ie5win OK (requires Enter key) OK OK (requires Enter key)
ie6win OK (requires Enter key) OK OK (requires Enter key)
net6win OK OK OK
op6win No No No
moz6win OK OK (default text not selected) OK

Permalink | Comments (1)

Tuesday 02 July 2002

Accessibility tip 11: Don’t open new windows

Since Web users understand the Back button, writes Mark Pilgrim, don’t break it by using the <a target="_blank"> tag to force a link to open in a new window. That’s fine by me, though I didn’t realize that the target attribute of the <a> tag is deprecated in HTML 4.01 Strict and XHTML 1.0 Strict.

If you provide a “Links open new windows” checkbox, Mark recommends that you set it to be off by default. And don’t forget that (in Windows) right-clicking on a link offers the contextual menu choice: “Open in new window.” <edited>Or better still—as Mark Pilgrim suggests in the comments—Shift-clicking on the link offers an OS-independent way of opening a link in a new window.</edited>

Opening links in a new window is usually driven by a fear that, if the visitor follows a link to another site, They Might Not Return! Jakob Nielsen points out the self-defeating nature of this practice:

…it disables the Back button which is the normal way users return to previous sites. Users often don’t notice that a new window has opened, especially if they are using a small monitor where the windows are maximized to fill up the screen. So a user who tries to return to the origin will be confused by a grayed out Back button.

The only reliable way to ensure that visitors will return to your site is to offer them an engaging, regularly-updated experience.

Permalink | Comments (8)

Wednesday 03 July 2002

Accessibility tip 12: Define acronyms

Today’s accessibility tip recommends using the <acronym> tag to provide a tooltip that explains the meaning of an acronym or abbreviation. I’ve never thought of myself as an acronym exponent, at least not to the extent of Mark (“50 acronyms and abbreviations on this weblog last month”) Pilgrim.

But I took the trouble of looking back over last month’s posts and surprised myself with a quite respectable score of 29: HTML, XHTML, CSS, IE6, MT, IRC, FTP, U Blog, QDB, GMing, DMing, SBS, XML, DOCTYPE, W3C, WaSP, Wi-Fi, 802.11b, NYT, PONR, VCR, CEO, DTD, RSS, Bb, INFJ, INTP, ENFP. Believe it or not, the acronym I used most in June turned out to be AKMA. (Put it down to my desire to catapult our illustrious pastor to the top of the Teoma results list—and to the fact that Bb spent much of the month preparing to move then moving house.)

I also modified my screen and print style sheets to produce the dotted underline (in all browsers) and to automatically spell out acronyms when printing from Mozilla and Opera.

In the course of adding the acronym definitions to all the items listed above I discovered that Dreamweaver has not just an Acronym object but an Abbreviation object too. Curious about the difference between them, I checked the examples at They turned out to be less than helpful.

Although the OED defines an acronym as “a word formed from the initial letters of other words,” incorrectly identifies WWW and SNCF (the French National Railway) as abbreviations rather than acronyms. At least they get abbr. correct (yes, it stands for abbreviation). On second thoughts though, I think that U Blog and Bb might be abbreviations. And I’ve noticed that IE6 doesn’t recognize abbreviations though Opera and Mozilla do. Well, at least we’re having fun.

Permalink | Comments (8)

Thursday 04 July 2002

Accessibility tip 13: Give your calendar a caption

OK, now it’s getting serious. Captions on the calendar, no less. Making Mark Pilgrim’s code change took little more than a minute (courtesy of Movable Type). “It’s easier to read in your template, saves a few bytes in your page, looks exactly the same in visual browsers, and is more accessible.” And it does “look exactly the same as it did before”—dark red and bold—because Mark included the class="calendarhead" style I’d already defined in my style sheet. We’re not done with the calendar, though; there’s more promised for tomorrow.


Friday 05 July 2002

Accessibility tip 14: Use real table headers

As I’d suspected, more work to do on the calendar table (though replacing a slab of table header code, copying a template file to the server, and rebuilding the index page hardly qualifies as “work” where I come from). But using real calendar table headers yields a significant payoff for the blind user:

Adding proper headers to the calendar allows screen reader software to associate the table header (day of the week) with the table data (day of the month), and it reads them together. “Thursday 4, Thursday 11, Friday 12, Saturday 13.”

Mark has tweaked my curiosity about how to make general data tables more accessible so I’ll follow up by reading the references he provides at the end of today’s post.

Permalink | Comments (1)

Saturday 06 July 2002

Accessibility tip 15: Provide table summaries

The last task in making the calendar accessible is providing a summary of the table for screen readers and speech browsers. Mark Pilgrim suggests “Monthly calendar with links to each day’s posts” as appropriate summary text and that’s what I added.

However, a check of the calendar links revealed a problem: the link associated with each day did not point to the posts for that day but to an individual post made on that day. In other words, the link for Friday 5 July was:

instead of the expected:

This was because I have my Preferred Archive Type set to Individual (so that by default my permalinks to point to individual entries). I needed to modify the MT link code from:

<a href="<$MTEntryLink$>"><$MTCalendarDay$></a>


<a href="<$MTEntryLink archive_type="Daily"$>">

So now the table summary not only exists, it’s accurate too.

And while I was making these changes to the Main Index template, I updated my blogroll entry to point to Euan Semple’s new MT-based weblog. It’s at The stopwatch is on, Euan. Let’s see how long it will take you to customize your templates and style sheets.

Permalink | Comments (8)

Tuesday 09 July 2002

Accessibility tip 16: Ignore spacer images

Mark Pilgrim writes:

Lots of people use transparent spacer images to control the layout of their weblog in visual browsers. You may use as many as you like, but you need to explicitly specify an empty alt attribute on each spacer image so that non-visual browsers know to ignore them.

No siree Bob (sorry, Mark). No spacer images in this neck of the woods. No smoke or mirrors either. Just pure and natural CSS (well, 95% pure, anyways).

Getting that out of the way frees me up to talk about another accessibility issue that cropped up last week: making data tables accessible.

Dreamweaver MX has an Accessibility preference setting that allows you to “Show Attributes” when inserting form objects, frames, media, images, and tables. With this preference turned on for tables, once you’ve chosen the basic table attributes (rows, columns, width, border, cell padding, cell spacing) the following dialog appears:

Dreamweaver MX: Table Accessibility Options Dialog

This makes it a snap to add a caption, include a summary, and set the headers for any data table I create. I’ve modified the accesskeys compliance table accordingly.


Wednesday 10 July 2002

Accessibility tip 17: Use real lists

Though I was already using “real list markup” for my blogroll and other links, I was using a definition list (<dl>) with the definition term (<dt>) as the heading and multiple definition descriptions (<dd>) as the list items. Although the HTML specification allows multiple terms and descriptions, an unordered list is probably more suited to lists such as a blogroll.

Following Mark Pilgrim’s suggestion, I converted my Contents, Recent Entries, and Favorites to unordered lists—turning the list bullets off with a list-style: none declaration and removing the indenting with a zero left margin.

This recreated the look of the original (definition list) blogroll in Internet Explorer 5 & 6 and Opera 6 but not in Netscape 6.2 and Mozilla 1, where the list items remain indented and my navigation panel now looks vile. Definition lists with a zero left margin worked in Netscape and Mozilla so I’m not sure what’s going on. Hopefully someone can suggest a fix; otherwise it’s back to the definition list for me.

<later>Professor Salo solved the problem: define the padding-left as zero, as well as margin-left. She also tactfully mentioned that she’d “Found the fix on one of the links in Mark’s tip today.” As in:

Which raises the issue of why—instead of having a nervy turn—didn’t I read either or both those articles? I guess that’s a question better directed to a psychotherapist than an accessibility guru. Alternatively, it could just be that I believed false information about how different browsers handle lists and indentation or failed to think things through sufficiently well. I do know one thing though: I’m really angry about how the various browsers use different default values for margin and padding of lists.</later>

Permalink | Comments (6)

Thursday 11 July 2002

Accessibility tip 18: Provide text equivalents for images

“The most important day of the series,” writes Mark Pilgrim and yes, it’s the crucial alt text:

Every single image on every single page of your site should have a text equivalent, so-called “alt text”, specified in the alt attribute of the <img> tag.

Not much to do here. I modified the alt text for the XML icon, as Mark suggested and changed the alt text for the ideograph in my banner from “Kokoro kanji” to “Site logo: xīn, the Chinese character for heart.” The latter change produced a brief moment of excitement—that perhaps only Professor Salo will appreciate—since it prompted me to find the correct “i with a macron” character (ī) for xīn. The Evolt Simple Character Entity Chart doesn’t have macron characters but they’re available at the Māori Spellchecker site. (I wonder now whether I’m being too smart by half. Do only Windows 2000 & XP and Mac OS X understand Unicode? It’s difficult to tell: on a Windows 98 machine it looks fine whereas on my old PowerPC running System 8.6 the macron appears after the “i” instead of above it.)

After my difficulty in manipulating list margins, I thought it prudent to do some addtional reading. I found the most useful of Mark’s references to be that provided by WebAIM (it includes recordings of the screen reader IBM Home Page Reader 3.0 reading the images). About alt text they say:

The general rule for the content of an alt attribute is that the alt attribute should provide a brief description of the function of the image. It is important to note here that that alt attribute should describe the function of the image which is not necessarily the same as a description of the appearance of the image…

Alternative text for images should be as succinct as possible. A good rule of thumb is to keep the alt attribute less then 15 words long. The reason for this is that users accessing the content with a screen reader or refreshable brailler will get the alt tag whether they want it or not. So if you add a very long description of the an image that the user has no interest in, they will still be forced to listen to the entire alt tag before proceeding on. If you need a longer description of the image, you should use the “longdesc” attribute or a “D” link to provide the content.

Mark might be referring to the longdesc attribute when he says: “We’ll discuss complex images on Friday.”

Permalink | Comments (3)

Friday 12 July 2002

Accessibility tip 19: Provide text equivalents for image maps

An ultralite day for me on the accessibility front since I don’t use client-side image maps. If I did, however, I’d follow Mark Pilgrim’s instructions to ensure that “every image map and every clickable area of the image map [had] a text equivalent.”


Saturday 13 July 2002

Accessibility tip 20: Use real horizontal rules

Today’s accessibility tip deals with using horizontal rules properly as dividers between weblog posts. I don’t think I’ve used a horizontal rule since mid-1995, in the days when Web pages still had gray backgrounds. I suspect I may feel the same antipathy towards the <hr /> tag that Professor Salo has for the <br />. For me, sufficient structural and visual differentiation is provided by the “Posted 12:10 AM | Comments (2)” paragraph at the end of one post and the (red) Heading 3 post title at the beginning of the next. So, another easy day (though I await with some trepidation what Mark has in store for me next week).

Permalink | Comments (3)

Sunday 14 July 2002

Say goodbye to LONGDESC

Mark Pilgrim has granted us a dispensation from adding the LONGDESC attribute to our images on the grounds that, while it is important, it’s “outside the scope of this series; it’s just too much work.”

As usual, Mark leads by example, in this case providing long descriptions for a number of photographs in his albums. For example, the description of Dora, futzing with sprinklers reads:

This is Dora, futzing with the sprinkler in the front lawn. She is squatting down, attempting to drive the sprinkler head into the ground and get it at the right angle so it will water as much of the front lawn as possible from one location. Over the course of the next two hours, she will futz with this and other such sprinklers, on this and other such lawns, to no avail. Sprinklers suck. We need an irrigation system, but we can’t afford one.

It strikes me that this is not so much a description as a story and, as Mark admits, writing engaging stories about pictures is not a trivial undertaking:

Creating separate long descriptions really adds a lot to the photo album (even for people who can see just fine), but it’s a *lot* of work, and I just can’t recommend it as a “fire and forget” kind of tip.

Jeff Ward photograph: Brak'n'Tune, Bakersfield, California 1990ishI thought immediately about the long description one might write for Jeff Ward’s photograph, Brak’n’Tune, Bakersfield, California 1990ish. It’s impossible—for anyone who knows the work of Walker Evans and of Jeff’s admiration for Evans’ work—not to see an immediate connection between Jeff’s picture and the Corrugated Tin Façade photographed by Evans in Moundville, Alabama in the summer of 1936.

Walker Evans photograph: Corrugated Tin Façade, 1936My LONGDESC for the Ward image might draw attention to: the structural and compositional similarities between the pictures, the tonal reversal (pale building and mid-gray foreground vs. mid-gray building and pale foreground), the electricity wires, the way that the drooping shadow in the Ward photograph references a similar shadow on the right of the Evans image… and, best of all, the fact that the ribbed surface of the main door of the Brak’n’Tune center subtly echoes the corrugated surface of the Richard Perkins structure.

But that’s just a formalistic game. Fun to play, and ultimately pointless.

Even so, it’s still true that there’s a story associated with each image, as their was with Mark’s picture of Dora futzing with the sprinkler. It’s just that I’m not well qualified to tell those stories.

Commenting on another post about this issue, Kris wrote:

…you don’t need to describe the image literally. Try to describe a piece of art made by Mondriaan, do it literally and you will soon find out that it makes little sense. Same would go for a lot of other artists. What you can describe however, through use of the LONGDESC attribute for instance or linking to other resources of information, is the artists notes on the piece, critiques, analysis, historical context. Things that would make sense to someone who is not able to see green or red lines, yet can understand the concept of pattern and rhythm when layed out to them. I think these sources even benefit people who do have eyesight.

But, as Jeff Ward might say, there are images that submit readily to description, and others that resist it. Jeff’s clear preference (and mine) is for photographs that replace, rather than augment, the written word. As Jeff did actually say, “Captions and such partially destroy the reason for using an image to begin with.” More pragmatically, I’d argue that the time spent in describing such photographs would better spent in making new ones, or in writing words that images can only inadequately illustrate.

So thanks Mark, for letting us off the hook. And I promise not to forget the ALT text.

Permalink | Comments (2)

Monday 15 July 2002

Out, damned pixels! out, I say!

The problem of making my text resizable has been hanging over me like upcoming exam. I know that sometime this week Mark Pilgrim is going to hand out a test paper containing just one problem:

Given that you will no longer be controlling the text size in your weblog with absolute font sizes (i.e. pixels), submit a style sheet that allows readers of your weblog to resize all the text in each of the major browsers.

Today I spent a few hours cribbing from every available online source (no names, no pack drill) and I think I may have settled on an idiosyncratic mix of ems and percentages that meets the requirements. No doubt we shall soon see how theory translates into practice.

Permalink | Comments (9)

Tuesday 16 July 2002

Dick and Jane see Spot run

In a comment on my post about making the text on my site resizable, Kris wrote:

As a frequent lurker of alt.html, I often read not to specify any font sizes at all, except for headings when really desired. I suggest if your efforts betray you, this is plan B then.

To which I replied:

Kris, I don’t like the idea of not specifying body text sizes one little bit. The end result almost always looks like a “See Spot Run” reading primer.

Kris responded:

“The end result almost always looks like a ‘See Spot Run’ reading primer.”
Perhaps. The real pain may actually be the “letting go”. : )

Now I understand the concept of non-attachment as well as anyone. (One friend told me not so long ago that another had described me as “kind but detached”—which I thought was perhaps the greatest compliment I’d ever been paid, but that’s another story.) Rather, what struck me was the implication that, since weblogs are really about writing, the size of the text is inconsequential, that worrying over the font size is little more than a bourgeois affectation.

But first, let me make it quite clear that I’m not even sure this was what Kris meant. The smiley at the end indicates that the remark is wryly humorous. In other words, I could easily be projecting my paranoia onto Kris, whereas his/her comments on my posts have invariably been thoughtful and constructive. So I apologize to Kris in advance, but…

Humor me.

When I started building Web pages, the prevailing orthodoxy was that the author was responsible for the structure of the document and the reader controlled the display. Design didn’t come into the picture. Not for long. Designers, rightly appalled by the ugliness of most Web sites, stretched and bent HTML in order to create visually appealing sites.

CSS and accessibility represent, to some extent, an attempt to redress the worst excesses of the design faction by reasserting the importance of document structure whilst also providing designers with the tools for creating attractive sites.

Where do bloggers fit into this? What is the nature of weblog design?

As far as I can figure, bloggers approach the design problem in one of three ways:

  • A relatively small number engage a designer to create their weblog templates.
  • Many happily accept the default templates provided with their blogging software.
  • The rest tinker with those default templates or build new ones.

Weblogs from the first two categories are hardly ever visually offensive. Those of us in the third category create designs which, although not always professional, say a great deal about our personalities and visual preferences. Strangely, I’d never thought about this but I’m now aware of how much I enjoy and admire the designs of the weblogs I visit regularly. Sure, a weblog is primarily about the texts and images that make up the daily posts. But the look-and-feel of each blog communicates so much about the author’s attitudes and intentions.

I have an unbounded admiration for the designer’s pixie dust and I’d never consider working on a paid Web project without a designer. Yet it never occurred to me to solicit expert assistance for my weblog—creating one’s own design seemed like an integral part of the process. I started my blogging career with a dramatic “white text on a dark gray background” design that many visitors found difficult to read. I changed it. Over a few iterations it turned into the current design, which fits the following criteria:

  • I do not want a liquid layout (i.e. I don’t want the content area to resize dynamically) because I want an optimum line length of 50-70 characters at “normal” magnifications.
  • I want the navigation plus content to fill the 800 pixel width screen resolution specified by about 50% of Web users (although the site looks best on a 1024 pixel wide display).
  • I want the site to be accessible and to load quickly (thus CSS for positioning and text formatting).

I don’t kid myself that it’s a spectacular design but I do think it’s attractive (in a spare kind of way) and it’s functional. The size of the text isn’t a trivial issue since it directly influences the line length, which (together with the typeface) is a key factor in readability. Plus there’s the elusive issue of “balance.” Even though I’m not a designer, I know that the site looks crappy when the text is much larger or smaller than the 12 pixel Verdana I’ve specified.

In the interests of accessibility I’m happy to relinquish control over the text size to the individual user. But I do want visitors, first time round, to view my intended design. I guess I’m happy for Spot to run; I just don’t want to hang round with Dick and Jane to watch him.

Permalink | Comments (4)

Accessibility tip 21: Use relative font sizes

Finally, the time has come to implement relative font sizes. I’ve written about it enough and now the text is resizable. I prefer how the site used to look but I don’t have the time, energy, or inclination to fuss with things anymore. Shōganai, it can’t be helped.

Permalink | Comments (4)

Wednesday 17 July 2002

Accessibility tip 22: Use real headers

“Think of your weblog as an outline,” writes Mark Pilgrim. (I can think of someone who’s going to love that idea.)

Now mark up your weblog as an outline, using real <h1>, <h2>, <h3> tags. Screen readers rely on these tags to interpret the structure of your pages. Your pages do have a structure, but without proper header tags, screen readers can’t find it.

A day off for me, since I’m already using the markup Mark recommends. Although this doesn’t apply to template-generated weblogs, it continues to amaze me how many designers use graphical headings (i.e. GIFs) thereby ensuring that their sites fall even lower in Google’s ranking.

Permalink | Comments (3)

Thursday 18 July 2002

Accessibility tip 23: Label form elements

While forms present a special challenge for blind users, the <label> tag makes them a lot easier to use by allowing you:

to associate a form label with any kind of form input element: text box, multi-line text area, checkbox, radio button, whatever. This allows screen readers to intelligently announce what a particular input element is, by reading the label.

The changes to my Movable Type templates took a little longer this time: as well as modifying my Comment Listing, Comment Preview, and Comment Error templates, I had to make the same changes to the Individual Archive Template, since I have inline comments on those pages. (That’s a great reason for specifying Individual as the Preferred Archive Type. It means that your post and any comments appear on the same page.)

In the future, when creating forms in Dreamweaver MX, I’ll take advantage of the Accessibility preference setting that displays an Accessibility Attributes dialog whenever you insert a form element.

Dreamweaver MX: Input Tag Accessibility Attributes dialog

Permalink | Comments (1)

Friday 19 July 2002

Accessibility tip 24: Make everything searchable

“Every weblog needs a site search. Period.”

Well, that’s unambiguous. I already had a Google search box—configured to search the domain—“above the fold” on my main index page but Mark Pilgrim recommends putting it on every page, with a proper label and access key. So that’s what I’ve done.

The site search is another of those accessibility features that benefits everyone:

Jackie, Michael, Bill, Lillian, Marcus, and pretty much everyone else in the world benefit from a well-implemented site search. Especially on a weblog, where content is primarily organized chronologically, it’s very frustrating to try to find a specific post that’s scrolled off the main page.

Thus a search facility goes part of the way to addressing the problem of impermanence that Burningbird raised in her farewell post.

Permalink | Comments (3)

Saturday 20 July 2002

Accessibility tip 25: Create an accessibility statement

It’s Day 30 of 30 days to a more accessible weblog and time to explain to others what we’ve done. Mark Pilgrim suggests that:

If you’ve implemented any of the tips in this series, create an accessibility statement that lists the accessibility features of your site.

I’ve implemented all the tips in the series so I was relieved that he also said:

Feel free to use the accessibility statement for as a template, including structure, wording, and links to further reading.

And that’s exactly what I’ve done. Interestingly, having comments enabled prevents my pages from being Bobby-approved. A new window opens without warning when a visitor clicks on a Comments link on either the index and monthly archive pages (although the comments are inline with the rest of the page content on the individual archive pages). Bobby also reports the following errors (caused by the onClick event handler associated with the Comments link and the fact that there are multiple Comments links on the index and monthly archive pages):

This page does not meet the requirements for Bobby AA Approved status. Below is a list of 2 Priority 2 accessibility error(s) found:

Make sure event handlers do not require use of a mouse. (12 instances)
Lines 48, 70, 88, 98, 173, 192, 210, 256, 268, 277, 289, 310

Do not use the same link phrase more than once when the links point to different URLs. (8 instances)
Lines 88, 173, 192, 268, 277, 310, 448, 450

I could probably do something tricky to change the Comments link to Comments on <$MTEntryTitle$> but that would still leave the onClick event handler problem so I guess I’ll live with my Bobby-unapproved status.

Finally, thanks to Mark Pilgrim for providing a wonderful 30-day learning experience. I’ve learned an enormous amount.

Permalink | Comments (6)


This is the official accessibility statement for It is based largely upon the accessibility statement for Mark Pilgrim’s weblog. If you have any questions or comments, feel free to email me.

Access keys

Most browsers support jumping to specific links by typing keys defined on the web site. On Windows, you can press ALT+accesskey; on Macintosh, you can press CONTROL+accesskey.

The home page and all archive pages can be reached by using the following access keys:

Access key 1
Home page
Access key 4
Search box
Access key 9
Access key 0
Accessibility statement

Standards compliance

  1. The home page and archives would be Bobby AAA approved, complying with all priority 1, 2, and 3 guidelines of the W3 Web Content Accessibility Guidelines, if the same link phrase was not used more than once when the links point to different URLs (unavoidable in a weblog that has comments enabled).
  2. The home page and archives are Section 508 approved, complying with all guidelines of the U.S. Federal Government Section 508 Guidelines.
  3. The home page and archives validate as XHTML 1.0 Transitional.
  4. The home page and archives use structured semantic markup. For example, on pages with more than one day’s posts, H2 tags are used for day titles, H3 tags for individual post titles, and H4 for subheadings within posts. JAWS users can skip to the next day using ALT+INSERT+2, or the next post with ALT+INSERT+3.

Navigation aids

  1. All archive pages have rel=previous, next, up, and home links to aid navigation in text-only browsers and screen readers. Netscape 6 and Mozilla users can also take advantage of this feature by selecting the View menu, Show/Hide, Site Navigation Bar, Show Only As Needed (or Show Always).
  2. Full access to monthly and category archives is also available through the archive page.
  3. The home page and all archive pages include a search box (access key 4).


  1. Many links have title attributes which describe the link in greater detail, unless the text of the link already fully describes the target (such as the headline of an article).
  2. Whever possible, links are written to make sense out of context. Many browsers (such as JAWS, Home Page Reader, Lynx, and Opera) can extract the list of links on a page and allow the user to browse the list, separately from the page.
  3. Link text is never duplicated (except, as noted above, in the case of comments); apart from this exception, two links with the same link text always point to the same address.
  4. There are no javascript: pseudo-links. All links can be followed in any browser, even if scripting is turned off.
  5. On the index and monthly archive pages, clicking on a Comments link opens a new window. On the individual archive pages (the default for archives) the comments are inline with the rest of the page content.


  1. All content images used in the home page and all archives include descriptive ALT tags.
  2. Purely decorative graphics include null ALT tags.

Visual design

This site and all its archives use cascading style sheets for visual layout.

  1. A default stylesheet is used that does not depend on JavaScript.
  2. The default stylesheet uses only relative font sizes, compatible with the user-specified text size option in visual browsers.
  3. If your browser or browsing device does not support stylesheets at all, the content of each page is still readable.

Accessibility references

  1. W3 accessibility guidelines, which explains the reasons behind each guideline.
  2. W3 accessibility techniques, which explains how to implement each guideline.
  3. W3 accessibility checklist, a busy developer’s guide to accessibility.
  4. U.S. Federal Government Section 508 accessibility guidelines.
  5. 30 days to a more accessible weblog, Mark Pilgrim’s tutorial that explains these guidelines and how to implement them. It’s best to start at the beginning.

Accessibility software and services

  1. Bobby, a free service to analyze web pages for compliance to accessibility guidelines.
  2. HTML Validator, a free service for checking that web pages conform to published HTML standards.
  3. Web Page Backward Compatibility Viewer, a tool for viewing your web pages without a variety of modern browser features.
  4. JAWS, a screen reader for Windows. A time-limited demo is available.
  5. Lynx, a free text-only web browser.

Related resources

  1. WebAIM, a non-profit organization dedicated to improving accessibility to online learning materials.
  2. Designing More Usable Web Sites, a large list of additional resources.

Accessibility books recommended by Mark Pilgrim

  1. Joe Clark: Building Accessible Websites. Mark tech-edited this book and says that it’s excellent—comprehensive but not overwhelming.
  2. Jim Thatcher and others: Constructing Accessible Web Sites. Mark says that this book is

    less comprehensive than Joe’s book, but goes into greater depth in the topics it covers. Gives screenshots of how various screen readers and alternative browsers interpret various tags and markup. Also has an amazing chapter on the current state of legal accessibility requirements.


Friday 16 August 2002

Accessibility rocks!

It’s just before eleven on Friday night and I’m knackered. I’ve spent much of the week preparing for a two hour presentation on web accessibility, which I delivered this morning. It turned out well (naturally Mark Pilgrim’s name was mentioned frequently). Interesting that, in Australia at least, the issue of accessibility is a real eye opener to even knowledgeable Web developers. But, with the experience of implementing all of Mark’s tips from 30 days to a more accessible web site plus plenty of background research, I think I managed to do justice to the subject. In any case, the audience stayed until the end and asked plenty of smart questions, so they were clearly engaged by the subject.

I spent some time discussing Maguire v. SOCOG (Sydney Organising Committee for the Olympic Games), since it is (as Constructing Accessible Web Sites describes it) “the first fully adjudicated case in the world on the issue of constructing accessible web sites.” Mr Maguire was awarded AU$20,000 when SOCOG failed to make the Sydney Olympic web site fully compliant by the start of the 2000 Olympic Games.

One of the people in the group today told me that he heard a news item about Mr Maguire’s complaint while listening to the car radio in the lead up to the Sydney Games. In addition to finding it hard to believe that a blind person would want to use the web, he was also suspicious that Mr Maguire was simply trying to extract some money from a high profile organization. For anyone who isn’t aware of the need for web accessibility, these are entirely understandable responses.

I heard about the case then too and recall being amused by SOCOG’s excuse that making the site accessible would require a developer to work eight hours a day for just over a year and that another AU$2.2 million of infrastructure would also be required. Even though I knew only a little about accessibility at the time, I knew enough about web development to realize that the SOCOG case was flimsy.

So, hats off to Mark Pilgrim for all the time and energy he poured into 30 days to a more accessible web site and to the CEO and his head of web development who invited me to prepare the presentation for their staff. It felt great today to be able to spread the word a little further.

Permalink | Comments (2)

Monday 14 October 2002

IBM socks it to blind Australians. Again.

Since most sighted people—Web developers and users alike—find it difficult to imagine how blind people or those with impaired vision actually “use the Web,” in my presentations on accessibility I’ve found it valuable to demonstrate a screen reader, namely IBM’s Home Page Reader. When a general audience can hear a Web page being read and see me use the various keyboard commands to navigate a site, it has a profound effect on those who have never considered Web accessibility or who have dismissed it as either trivial or a nuisance.

  • The screen reader in action illustrates in the most vivid and immediate way the importance of the Web for the blind and the sight-impaired.
  • The experience of “putting on a blind Web user’s shoes” makes everyone aware of the challenges faced by those who cannot see the Web that most of us take for granted.

From the moment the screen reader’s mechanical voice fills the room, I feel the atmosphere begin to shift. Consequently, in the second part of my presentation—when I explain Mark Pilgrim’s techniques for creating an accessible site—I am speaking to people who are truly engaged. I can almost hear the developers thinking: this is not so hard, it’s not going to cost an arm and a leg, we can do this stuff…

Until now I’ve used the trial version of Home Page Reader. But the trial period has expired and I’m presenting again tomorrow. So this morning I logged on to the IBM site to purchase a real copy. The downloadable version is available from this page on IBM’s US site:

00P7833 Home Page Reader V3.0 English Program Package Digital Delivery

US$117.00 equals AU$214.40 at today’s exchange rate.

I couldn’t proceed with the purchase because the order form insisted that I enter a five-digit US Zip code instead of my four-digit Australian postal code. Instead, I found the same downloadable version on this page on IBM’s Australian site:

00P7833 Home Page Reader V3.0 English Program Package (Digital Delivery)

Same product code, same product, and there’s every chance that the download is on the same server… but Australians have to pay a 59% surcharge. The cost of goods is identical, as is the delivery cost, and the credit card transaction fee must be similar, if not identical. A 10% premium might be justifiable, but almost 60% is unpardonable.

Yet why should we be surprised? IBM gained notoriety during the Sydney Olympics for creating an inaccessible Web site for SOCOG, the Australian organization responsible for staging the games. Joe Clark, author of Building Accessible Websites, describes IBM’s contradictory attitude towards Web accessiblity in his excellent summary of the Macguire vs. SOCOG case:

To reiterate, in the case of Maguire vs. SOCOG, the little person won. While the Sydney Organizing Committee for the Olympic Games acted in an arguably unprofessional and certainly a dismissive manner, the allegedly substantive reasons it advanced for denying accessibility were conclusively repudiated by Australian authorities and expert witnesses.

Curiously, IBM, SOCOG’s Web contractor, maintains an accessibility Web site and a full-time staff who do nothing but work on software, hardware, and Web accessibility. IBM has a reasonably salutary record in accessibility products, having developed IBM Home Page Reader, a screen-reader analogue specialized for surfing the Web. Yet its partnership with SOCOG gave the appearance of a corrupting influence, making IBM complicit in SOCOG’s actions in denying accessibility to blind users of its site.

No doubt IBM Australia’s spin merchants will be able to justify why it costs so much more to deliver exactly the same electrons to an Australian IP address.

Update. This story has a happy ending.

Permalink | Comments (4)

Tuesday 05 November 2002

IBM does the right thing for blind Australians

Newspaper headline: IBM backflip over blind software

My first foray into consumer advocacy has been spectacularly successful. Three weeks ago—in a post titled IBM socks it to blind Australians. Again.— I pointed out that IBM Australia were charging AU$341 for Home Page Reader (Digital Delivery) whereas blind or vision-impaired US residents could buy the same product for AU$214.40 (US$117). I emailed the weblog link to Bernard Lane, an IT journalist at The Australian, who had interviewed me earlier in the year for an article on Googlewhacking.

Bernard, who has a weblog called Milon’s memory, a living obituary, promised to contact IBM, ask for an explanation of the price difference, and perhaps write a story. This morning he advised me by email that the story was in today’s paper (and in the online edition).

And guess what? IBM Australia have cut the price!

Contacted by The Australian IT more than a week ago, IBM Australia did not offer any explanation of the price difference beyond saying its prices generally were influenced by “currency exchange, local taxes, customisation and support, as well as the cost of doing business”.

Asked whether GST applied to a product expressly for the blind or whether the local download had been customised or came with support, IBM said it was “examining what factors influence the pricing of Home Page Reader and whether current pricing is appropriate”.

Yesterday a check of the IBM Australia website revealed the price had been cut, without announcement or explanation, from $341 to $233, a figure comparable to the US download cost.

I called Bernard Lane, logged on to the IBM Australia Web site and purchased my $233 copy of Home Page Reader, then walked up to the newsagent to buy a copy of The Australian while the 40MB installer downloaded.

So… thanks to Bernard Lane and The Australian for following up my post. And thanks to IBM Australia for doing the right thing by matching the US price for Home Page Reader. Weblogs rock! Or, as Dorothea might say, “Woot!”

Permalink | Comments (6)

Monday 16 December 2002

Building Accessible Websites, by Joe Clark

Building Accessible Websites comes highly recommended. In late October, Mark Pilgrim wrote:

Joe Clark’s Building Accessible Websites is now shipping. I was one of the technical editors for this book; having read it thoroughly, twice, I can assure you that it is the most comprehensive and most well-written web accessibility book in existence. Every web designer should read it. If you can only afford one web accessibility book, buy Joe’s book. (If you can afford two, buy Joe’s book and Jim’s book, reviewed here.)

Joe Clark's Building Accessible WebsitesWhen Joe emailed me to ask if I’d be interested in reviewing his book, I readily agreed—I have a strong interest in website accessibility (largely triggered, I confess, by the experience of making my own site accessible by implementing the tips in Mark’s series, Dive Into Accessibility: 30 days to a more accessible web site). Joe also agreed to answer a series of questions about the book and, more generally, about accessibility. I’ll publish this extended interview in a series of posts over the next few days.

The structure of Building Accessible Websites is much as one might expect. After briefly explaining how he intends the book to be read, Joe Clark runs through “some typical objections to providing accessibility, blowing them out of the water one after another,” then lists a number of active reasons for making one’s site accessible. He outlines the various kinds of disability (hearing-, vision-, mobility-, and learning-related), explains how disabled people use computers, and defines both accessibility and the structure of accessible pages.

Having mapped out—in five relatively brief chapters—the nature and extent of the problem, Clark gets down to the nitty-gritty: how to make images, text & links, navigation, type and color, tables & frames, stylesheets, forms & interaction, and multimedia (including Flash) all accessible.

The chapters on images and navigation are much longer than any of the others, reflecting Clark’s belief that addressing these two issues—even at a basic level—will make a site “vastly more accessible” to two large disability groups: the blind and visually-impaired and the mobility-impaired. (Clark’s Slashdot interview, which appeared last week, is essential reading for anyone interested in accessibility.)

These how-to chapters are all structured similarly. For example, Chapter 6, The Image Problem, covers:

  • the three levels of accessibility for uncomplicated image types (the alt, title, and longdesc attributes);
  • variations in browser support for each attribute and workarounds;
  • problem image types including advertising, animated GIFs, bullets, charts & graphs, exploded drawings, hit counters, maps, pictures of text, porn, image portfolios, rollovers, sliced graphics, spacer images, and webcams);
  • succinct advice on implementation; and
  • a supplementary section with more hints on making online ads accessible.

A section titled Bottom-Line Accessibility Advice concludes each chapter. For example, the advice for images is:

Basic accessibility
Use alt texts on absolutely every image without exception.
Intermediate accessibility
Add titles to images in increments no smaller than a page: Either all graphics on a page contain titles or none.
Advanced accessibility
Write long descriptions for the rather more intricate images.

In the last two chapters, Clark discusses certification & testing and outlines some “future dreams.” Finally, he provides appendices on accessibility & the law and language codes, a bibliography, and a colophon (describing the making of the book). In addition, the entire text of the book is included on the accompanying CD-ROM, making it easy to search the book’s contents and to check the code samples—you simply copy the code into an editor then view it in a browser.

Although I hope by this point I’ve convinced you that Building Accessible Websites is comprehensive and full of practical advice, those are not the only reasons the book is worth buying and reading. Mark Pilgrim is absolutely correct when he says: “Joe’s an incredible writer; he can explain the most esoteric topics in a way that anyone can understand.” And it’s not just that he writes with great clarity and elegance. A large part of the book’s appeal is Clark’s refusal to pull any punches:

Usability is a good predictor of accessibility, since usable sites are put together by intelligent, thoughtful people (not necessarily paid experts), and that is exactly the group that pays heed to access without being pushed and prodded. But we should not expect a one-to-one relationship. Usable sites can be inaccessible (e.g., an E-commerce site where every navigation button is an image without a text equivalent). Conversely, accessible sites can be unusable - e.g., Jakob Nielsen’s, which is so outlandishly undesigned as to make it hard to find anything, not to mention dozens or hundreds of pages at the World Wide Web Consortium itself, where we similarly drown in accessible data.

Frequently provocative, Joe Clark is also remarkably pragmatic. For example, it’s almost an orthodoxy in Blogaria that table-based layouts are inferior to those that use CSS-positioning. Not so, argues Clark:

The use of tables for layout has never been prohibited by the Web Accessibility Initiative. You are not creating an inaccessible page if it contains tables used for layout. You have committed no sin—necessarily. You will not be forced to turn in your trackball and badge while WAI Internal Affairs conducts an investigation. But you are not off the hook: You must code tables properly, which, for layout tables, is not difficult at all.

He is similarly relaxed about pictures of text:

For small amounts of text (typically, text rendered as graphics is used for navigation buttons), enter the complete text into alt; you can add explanatory details to title if you wish. (Example: alt=”Contact” title=”Contact information, job listings, and feedback page”.) Accessibility purists may hate this entire approach, but I simply do not see any harm whatsoever in limited bits of text rendered as graphics since it is dead simple to make those graphics accessible. I use pictures of text myself.

Though I nearly fell off my chair when I read Clark’s advice on headings:

The Web Content Accessibility Guidelines tell us to use heading elements in strict numerical order—<h1></h1>, then, if necessary, <h2></h2> through <h6></h6> in that sequence. That dictum suits androids and Vulcans quite well, but here in the real world you can skip intervening levels and you don’t have to start at <h1></h1>. I am telling you that you can defy the WCAG in this limited way. You must not, however, use heading elements in anything but ascending order.

Call me a Vulcan—or an android—but this makes no sense to me at all. The usual reason given for starting with (say) <h3></h3> is that <h1></h1> is too big, black, and ugly. Yet you can easily define the appearance of any element with CSS so the <h1></h1> can be as small, brightly-colored, and pretty as you like. More importantly, assigning <h1></h1> to the first heading on a page will assist in securing a higher Page Rank in Google. And why would you want to skip intervening heading levels? In other words, what’s the advantage in defying the WCAG in this case?

I was also surprised at Clark’s advice concerning resizable text, particularly when I recall the angst that accompanied my switch from pixel-based to relative font sizing. Clark argues that anyone with significant visual impairment will be using screen magnification software, thus rendering the font-size argument irrelevant. While I can see his point, I still believe that it’s worth accommodating normal-vision people who find small type difficult to read, even if it is “too low-level for this book to worry about.”

So, what’s that then? A couple of quibbles in over 400 pages. Mark Pilgrim was right: Building Accessible Websites is the book to buy. (Jim’s book, to which Mark also referred, is Constructing Accessible Web Sites by Jim Thatcher et al.) It’s a fine book, packed with useful information. But, because it has eight authors, it lacks the most appealing quality of Joe Clark’s book: the sense of being guided through the subject by an informed, literate, entertaining, and—above all—iconoclastic expert who absolutely fulfills his own aspirations for the book:

You will, I hope, find the book quite readable. I have this fantasy that Building Accessible Websites will be as enjoyable to read as a well-written cookbook. (What, you’ve never read a cookbook while reclining in bed, far removed from the kitchen?)

I’m not a great reader of cookbooks (I’m not much of a cook, for that matter, though I discovered tonight I can cook a trout to perfection). But I did find myself reading Joe Clark’s book in bed and almost everywhere else in my house—as well as on the train and in a couple of my favorite restaurants. Building Accessible Websites is a considerable achievement: a thorough practical guide to Web accessibility that’s also a pleasure to read.

Permalink | Comments (5)

Tuesday 17 December 2002

Conversation with Joe Clark: 01

Yesterday I reviewed Building Accessible Websites, the new book by Toronto journalist, author, and accessibility consultant, Joe Clark. Today and for the next couple of days I’ll be posting Joe responses to a series of questions about the book, his background, and accessibility in general. If you’d like to learn even more, then visit Joe’s Media Access website, “the starting point for everything you ever wanted to know about captioning, audio description, Web accessibility, and related topics.” Now, on to the first question:

Would you describe how and why your interest in Web accessibility developed?

Actually, I’ve been interested in what is now known as accessibility for over 20 years.

I credit Geoff Freed at WGBH for having brought up the topic of Web accessibility, which I believe was about five years ago and in the context of a design competition for a symbol to identify accessible Web sites. (Not a very good idea, obviously, since sites should simply be accessible and all the candidate designs, including the winner, were poor examples of graphic design, but it got me started.)

I then began reading. Really, that’s all you can do to start. At the time, I had a lot of knowledge of accommodation for blind or deaf people and a smattering of other accessibility expertise, but I knew nothing about accessible Web development, and pretty much no one else did, either—remember, the Web Content Accessibility Guidelines were not released until 1999.

I have a history that parallels other people’s, but I start from a different place. I used to think captioning was terrifically interesting (it’s the field I started out with) but audio description was too weird and extraneous. I now consider description the greatest thing since sliced bread. Then I added Web accessibility to my range of interests, and, having given up on a definition of accessibility that restricts itself to disabled people, I have since read everything I can about two very old accessibility forms related to language, subtitling and dubbing. So it was a series of upgrades and a few cases of overcoming denial. I think people new to the field will have similar experiences— they find out about topic X, maybe can handle that topic but think Y is just too weird to worry about, and later, over time, come to understand that X and Y are important and so is Z, a topic they had not imagined before. (Web accessibility, PDF, and Flash could sit in for X, Y, and Z in that example.)

Had you met some disabled Web users, perhaps while working on a particular Web site? Did your commitment to accessibility increase over time or was there a sudden flash of understanding that this was a crucial issue?

No, there were no galvanizing, life-changing meetings with disabled people or anything like that.

Has your understanding of accessibility changed in unexpected ways during the period you researched and wrote your book?

No, not really, except in the few topics that required a lot of factual research, like colourblindness and the exact populations of disabled people online. I now know quite enough about both topics to stupefy people at dinner parties. The HTML code and the many dozens of illustrations needed some looking up, too. But I mostly wrote the book off the top of my head.

In my experience, both site owners and Web developers complain about the amount of work required to make a site accessible. Given your belief that “lawsuits are the worst way to achieve accessibility, particularly in the U.S., with its poisonous atmosphere,” what could precipitate the shift in thinking so that site owners take pride in the fact that their site is accessible and Web developers regard the ability to build accessible sites as a “cool,” highly-desirable skill?

Managers and clients are gonna have to be educated about what valid HTML is and why it’s mandatory. Content-management systems are gonna have to be updated to produce valid HTML and to fail to mangle existing valid HTML.

Then we will have achieved something vaguely resembling an understanding of standards compliance. Accessibility is one of the standards sites must comply with, and you gain a lot of accessibility automatically just through valid HTML.

Then, some years later, after many more valid-HTML sites are deployed than we could presently point to (nearly every valid-HTML site today is an individual Weblog site and not a commercial venture), these standards-compliant, accessible, well-designed sites will stand as proof of what I’ve been telling everybody for ages—not only can you have all three of those at once, you *must*.

In the meantime, firing all the boy-racer HTML programmers who think they’re tough shit would be a good place to start. They’re jumped-up script kiddies; it was quite telling that my submission of well-written, copy-edited text in a valid HTML document was an absolute first for Slashdot. This is a clientele that does not know what the Shift key does or how to debug two nested ordered lists. (The latter is an actual example from a site I worked on. The concept of closing a paired tag had never occurred to them, so they could not find the error in the sequence <ol><li><ol><li></ol>.)

And of course we’ll also have to fire the boy racers’ clueless Dockers-wearing manager dweebs, who consider themselves old-timers because they got online in 1998 (!) and whose entire experience of the Internet is the commercial Web as rendered through Internet Explorer for Windows. These people cannot even *spell* “W3C” and still think banner ads have not been given a fair shake.

If we could rid the Web-development ecosystem of life-sapping parasites like these—essentially, everyone who is immature and/or has *bad taste*—then we stand a good chance of making valid, standards-compliant Web development the norm rather than the exception.

Permalink | Comments (10)

Wednesday 18 December 2002

Conversation with Joe Clark: 02

In the Slashdot interview you say that the two most significant accessibility features a Web developer can implement would be to make “all your images accessible including, crucially, adding alt="" to every spacer GIF and every other meaningless graphic” and to place visible “skip-navigation links on top of every navbar with, say, ten or more links.”

Let’s assume that we’re already doing that. What other (three? eight?) accessibility features will make a substantial impact, in order of importance?

Corollary of Point 2: Make sure your site makes sense when “linearized,” to use the buzzword. It is easiest to understand linearization in the case of table-based layouts. Turn borders on in your table, print out your page, and then cut out each table cell in strict left-to-right order based on your <tr> elements. (You kind of have to understand the underlying HTML to linearize properly, with with cellspan and rowspan values.)

Now place these in a single column in that strict order. Voilà: You have just linearized your site. For certain adaptive technologies like screen readers, linearized reading is *one possible* reading order. Visitors can override the reading order (as by skipping table cells), but if you just sit there and let the thing read, it does so in a linear or sequential manner.

For CSS-based layouts, the advice is not clear-cut. It is not widely understood that screen readers do not directly interpret underlying HTML. (There may be specific technical exceptions, but that is the thrust.) The order of inheritance is HTML → browser → screen reader → speech and/or Braille. The browser in nearly all cases is IE for Windows for various historical reasons, though Netscape 6 and 7 are said to work passably well with screen readers. Ordinarily the advice I’d give for CSS layouts is to make sure the page makes sense if the <div>s on the page are read in the order encountered in source code, but in practice the browser interprets and renders the page, which the screen reader then reads. I do not have firsthand knowledge of how linearization applies to such layouts, if at all.

Forms: Correct form markup is a bother but is quite necessary. The HTML elements for accessible forms, including <label>, <fieldset>, and <optgroup>, and the ubiquitous title attribute, are not conceptually difficult but are a tad tedious to add ot every single form element of every single page. Unfortunately, there’s no way around it. For the screen-reader user, it is rather difficult to conceptualize where one is located in a form without these elements. I would also add that screen-reader support for forms isn’t as good as it should be. For various technical reasons that may or may not be surmountable, putting yourself in forms mode in a screen reader turns off certain other modes. It’s difficult to get around, but not by any means impossible if the form is coded correctly. <optgroup> is pretty nifty, though its limitation of a single level of grouping is a pain. Adding a title to every single form element is helpful, even in graphical browsers.

You may have to fiddle with stylesheets for an acceptable visual appearance—for <fieldset> especially—and keyboard access could use some attention in complex forms, which are the next problem. Don’t put forms in tables unless you absolutely have no choice whatsoever. Suddenly the screen-reader user must deal with simultaneous forms mode *and* tables mode. Placing a label for a field (like “Name”) in a cell adjacent to that field is unnecessary and leads to a great deal of confusion.

People use tables for forms so that online forms look like printed forms—that is, they use as much of the “paper” as possible, because “paper” is expensive. But online we have unlimited screen real estate, at least in the vertical dimension. HTML forms, at root, yearn to be vertical, not horizontal. Do not flout their natural desires. Do not attempt to overlay the design of printed forms onto online forms.

Next, don’t be posting Flash or PDF without using those formats’ built-in accessibility features. That’s my advice. But it is difficult to heed because there is so little documentation of those features; they’re a bit limited at present; and the software interfaces, especially for PDF, are tremendously inconvenient (and essentially unavailable on any platform other than Windows).

Mark Pilgrim linked to a First Monday article called Users with Disability Need Not Apply? Web Accessibility in Ireland, 2002, describing it as “not encouraging.” What was your reaction to this article by Barry McMullin?

This seems like a reasonable way to use an automated checker tool (in this case Bobby, which I have described as “dumb as a mule,” but any such software is going to be that dumb) to quickly gauge the spread of obvious and indisputable accessibility errors, which are pretty much the only kind that a software tool can even spot, let alone fix.

It would be interesting to carry out a further qualitative study of the small number of sites that passed Bobby tests and a number that did not, this time using qualified accessibility experts (not necessarily me, of course). A longer and more ruminative explanation of what’s right and wrong with those sites would make it clearer to people new to the field, and to nonbelievers, that accessibility may be relatively simple but it is not always obvious and requires human interpretation. The downside, of course, is that people tend to want issues like this cleaned up by computers themselves without human intervention (like publishing a file using a content-management system), but that is simply unrealistic.

A study like this is useful in pointing out the scale of the problem, even with its limitations.

Permalink | Comments (8)

Thursday 19 December 2002

Conversation with Joe Clark: 03

Betsie is the filter program used by the BBC to create automatic text-only versions of some of its websites (e.g. the BBC News site and the Betsie version). You make it quite clear in the book that you believe text-only versions of websites should be discouraged (the biggest myth is that “the most accessible sites are text-only”). Therefore I’m wondering what you think of an automated tool like Betsie (produced by the BBC in association with the Royal National Institute for the Blind).

I’m sure it was created with the best of intentions. Radio-Canada appears to have emulated the BBC in this respect. It seems like the kind of small programming assignment a well-meaning person would put together: The programmer takes the issue seriously and makes a concerted effort to do something about it. Unfortunately, what the programmer actually does is questionably useful, and after it’s all finished, the BBC pretty much figures it’s handled the problem and can get back to its real work. (In fairness, BBC accessibility tends to be OK.)

I wish people would put more effort into providing reconfigurable interfaces, with, say, navbars placed at the bottom of the page to get them out of the way. Rearranging information for convenience is infinitely better than eliminating information, which is what creating a text-only page does. It essentially says “We’re going to destroy our content to save it for you, the disabled viewer.”

In a number of places throughout the book you take the WCAG and WAI to task for their unrealistic, unimaginative, pedantic, design-hostile (my words) attitudes. Have you had much (any?) contact with other “accessibility professionals”?

Mm, sort of. I have some friends in town.

Are you aware of how they regard your book?

Oh, probably the same way they regard me, and my colleagues have shown no hesitation whatsoever in posting and talking to the press to tell the world what they really think of me, which does not actually *matter*, since they don’t have to like me to work with me.

Have you been invited by the WAI people to speak at any of their meetings or functions?

No. In fact, I cannot even remember being specifically asked to write or improve the Web Content Accessibility Guidelines, and when I dare to provide expert criticism anyway the reaction is comparable to handing Superman a chunk of Kryptonite. But again, I’m not going to put words in their mouths when they are quite free to advance their own opinions.

Are the companies who develop content management systems—apart from blogging tools—way behind in thinking about accessibility

The larger CMSs are a kind of protection racket: You buy our system for six figures, and then you keep paying us every year to maintain your license, and also you’ll have to hire a person trained in our ways to keep your system up and running. Fail to do any of that and your entire site crashes. It’s extortion, really, and high-end CMSs are dogs in so many ways—they can’t produce valid code, their URLs are appalling, and they are difficult to use. In essence, big CMSs are mainframe systems, with the same need for constant nursing and non-stop tending by codependent system administrators as those old mainframes.

So of course you can’t expect these products to work well with accessible sites. It’s not impossible, but it’s another complication.

Meanwhile, it’s the freebie and small-time CMSs, like Movable Type and LiveStoryboard and Macromedia Contribute, that produce at least passable valid code and enable accessibility features. If nothing else, you can add features to a page and the CMS won’t destroy them when untrained users add content.

If you were Chief of Software Engineering for the Entire Universe, what kinds of changes would you like to see implemented in both Web authoring tools and content management systems?

It’s simple and sweeping: You couldn’t put out an inaccessible product. Now, the exact degree of accessibility and the disability groups covered would perhaps be up to discussion (as ever, learning-disabled people are difficult to accommodate), but the idea of releasing an inaccessible product should be unthinkable the way releasing a product that misspells the company name is unthinkable.

Permalink | Comments (7)

© Copyright 2007 Jonathon Delacour