1. Older people have difficulties with drop-down and multi-level menus, because their manual dexterity, eye-hand coordination and space perception decreases. Also some move the mouse when clicking, or tremble, hence it’s more likely they slip off the menu. Hell, that happens to me frequently!

   However, did you notice the Windows Start Menu is more forgiving when you slip off an item? There’s a little delay before the secondary level is hidden. Perhaps we need an event-capturing script tolerating a slip from the menu rather than the immediate reaction of the mouseout event.

2. Nested menus are more complex. According to Hick’s Law orientation in a multi-level menu can take longer than multiple clicks in a flat menu with good information architecture. See an earlier article for the math.

3. The navigation must be accessible by keyboard alone. The result should be the same, whether you hover over an item or tab to it. So check for the focus event and CSS pseudo-class. Don’t forget to test backwards tabbing (shift tab). By the way, mobile devices have no mouse either…

   The tab order should be consistent and logical, i.e. not jumping around on a page. Also the focused item should be visible, for example highlighted with the default 1px dotted border some browsers draw around it. Some people think this is ugly and remove the default border. That is a no-no.

   And if you really want desktop behavior, add support for the arrow keys (event.keyCode 37-40). Keep in mind though that screen readers have predefined functions for the arrow keys in combination with the ctrl, shift, or alt keys. In JavaScript those keys can be detected with the event.ctrlKey, event.altKey, and event.shiftKey properties. Also crossbrowser event delegation for focus or blur events can be a bitch, thankfully PPK has a solution.

4. Users of AT should have means to skip content. That’s possible with semantic markup: a menu as (nested) list(s) enables them to jump to the next block. Also there should be a few skip links at the beginning of the code pointing to important sections on the page, such as content, navigation, or search. Mobile users also profit from that technique (try surfing eBay with Opera Mini ).

5. Pages never link to themselves. When I click on a link (the menu being no exception) I expect to land on a different page. Therefore it’s confusing to land on the same page. This happened to me recently when I was filling out a form on my mobile phone and got the same page with an error message. It took me a while to realize where I was. It’s the same whether you have a tiny screen or a low screen resolution to see things larger when you are visually impaired: you only see a small part of the page, so it’s hard to realize when something unexpected happens.

6. You can add some semantic sugar with the ARIA role property. In this case <ul role="navigation"> would be appropriate. I strongly encourage you to use ARIA as it is widely supported by browsers and screen readers, enhances a disabled user’s experience, and doesn’t break old browsers. A most recent introduction has been written by Gez Lemon for the Opera Developer Community.

7. If a second level navigation is initially hidden with display:none it won’t be in the screen reader buffer. Therefore off-screen positioning is a better idea, else you need to update the buffer by writing random values into a hidden input field.

8. A common problem in menus is limited horizontal space. Text should be scalable, and it must not jut-out into other page elements when it is enlarged. Even normal text can break a narrow menu when you think of internationalization. In German there are many composite words. While building a website for a competing brand I came across a menu item on the Philips website for “male grooming.” The German word „Körperhaarpflegesystem” is guaranteed to blow every menu!

   Another common problem that prevents scaling in menus are text graphics. I know marketing just loves to see the corporate font in the main menu, but text in images can’t be scaled, people with visual impairments can’t change text and background colors for higher contrast, and Flash Image Replacement like sIFR still has accessibility issues, is known to distort fonts, is CPU intensive and slow. The bottom line is: don’t use text as images, make textual information text.

So much for accessibility. Besides there are a few technical issues to consider: mobile devices often have problems with JavaScript or with layers. Some proxies in large companies filter JavaScript for security reasons, so you can’t rely on the ubiquitous availability, your script has to be unobtrusive, and you can’t rely on noscript either. Don’t even think of creating a menu from JavaScript arrays.

Moreover there’s a well-known bug in IE6 responsible for showing select lists always in front of any layers (like your second level menu), regardless of a z-index. Thankfully there are plugins like bgiframe for jQuery to solve this. Multi-level menus can bloat the code, event handling can be CPU intensive (use event delegation). And if large amounts of menu code is at the beginning, the real content gets further behind and less relevant for search engines.

In conclusion, for an alleged quicker entry you pay with many disadvantages. Often drop-down menus just conceal a poorly planned information architecture. I would reconsider their usage.

Did I forget something? What’s your opinion on drop-down menus? Love them or hate them?

A couple of years ago this would have put some distance between us, but who would have thought that information technology would one day close the humane gap, too? His death touched me, for several reasons. Just two weeks ago I had the chance to meet Sharron Rush and Glenda Sims, who worked with John, and what’s more, he was their friend. At an accessibility award ceremony of Knowbility I was able to get a fair impression how much the accessibility community means to the people in Austin and how much they cherish their friends. Being a friend of Sharron and Glenda he must have been a very special person.

Also in the social web death is no longer distant. I wasn’t aware that this is a direction I’m not only exposed to, but that my computer screen, the bringer of information, also brings emotions at unexpected moments. People around the world were blogging about John Slatin’s forthcoming death, and there is a very intimate portrayal of his last moments on his own blog. But it is the second time that this happens to me. In September 2006 the science fiction author John M. Ford died. Until then I only knew a few of his novels and one of the funniest role-playing adventures ever, the award-winning Yellow Clearance Black Box Blues. But then I learned what a person he was. Why people loved him. That he was always accessible, always funny, always kind. He made an impact. He touched people’s life.

In my former career as an Emergency Medical Technician I have seen various facets of death. I’ve seen the grim reaper, but I also know why before the discovery of antibiotics pneumonia was also known as “the friend of old men.” Death can be very peaceful, a welcome friend, and I’m not afraid of it. I don’t believe in an afterlife, but I love the response John M. Ford’s spouse gave to a question once asked at a convention: “how many angels can dance on the head of a pin?” She replied: “I’m pretty sure it’s too difficult to get an accurate count at the moment because they keep laughing at something Mike says, and then a bunch of them fall off.” I do believe that people live on through their deeds, by the impact they had, by the people whose life they touched. They live on as long as there’s someone who remembers them. John Slatin — and John “Mike” Ford — will be remembered, for a very long time.

Get involved

The John Slatin Fund Accessibility Project matches accessibility experts with companies that would like a brief review of their site for accessibility. In return, the site owner is asked to contribute a minimum of $500 to The John Slatin Fund. The John Slatin Fund was established to help John’s beloved Anna offset the medical expenses incurred during John’s long illness. The goal of this project is to raise $25,000 for that purpose. Furthermore there’s an option to donate directly to John’s family via Paypal.

First he was giving an update on his workover of WCAG 1.0 under the label of “the WCAG samurai,” something he announced a year ago in his article at A List Apart, To Hell with WCAG 2.0. A few anonymous people he will not disclose finished their collective update, also there were two peer reviews of the final paper without the reviewers knowing about each other. Clark said he hasn’t read the reviews either, so this was kind of a premiere.

Then he talked almost an hour about a couple of things that shouldn’t be your concern (in his opinion) as a web developer:

• Pixel units: per definition, pixels are relative units as required by the specifications. Blind people do not care anyway if text is resizable, zoom readers have their screen magnification software. But he misses the point when he concludes that therefore resizable text is not an accessibility issue because disabled users don’t have trouble with it. Accessibility doesn’t only affect severely disabled persons, it begins with elderly people who need to adjust the font size. And as long as IE6 is around on a considerable number of desktops, it is our problem to enable text resizing. We cannot just shrug our shoulders and put the blame on a certain browser vendor. Although we can get rid of those resize buttons on web pages. That is really a matter of browser vendors and user education. Patrick Lauke proposed to put such an explanation on the default page of newly installed browsers.
• Link text being used out of context: Clark showed an example of a fictitious car sales page with recurring links to the car’s features. Of course the features link of one car is different than the features link of another, but you can clarify that ambiguity through a link title. A list of links on a page is a well known and appreciated feature of screen reader software, why should we cease to support that? But one thing I agree on is using an anchors type attribute to clarify that a linked document is a PDF. Though to my knowledge screen readers don’t make use of that attribute.
• Abbreviations, acronyms, initialisms: We cannot cover all cases, and there are cases like “DVD” or e. coli where there is no written out meaning of an acronym, or an abbreviation that is so common that it is neither needed nor any help to give the full meaning. But I strongly disagree of dropping the whole concept of contextual help for abbreviations with the argument that cognitive disabled users won’t get it anyway.

Clark’s disputable (unfortunately not at the session because of a lack of time) arguments will certainly be addressed on the Royal National Institute of the Blind’s blog, so watch their space for a controversial debate. I will also try to get I got also a shot of a hilarious illustration of Joe Clark that Kristiaan Thivessen drew next to me.

The first model is rather technical. There are checklists for the criteria of WCAG 1.0, sometimes with a detailed discussion why and how something is tested. Tests can be automated or conducted by experts. Still there is no guarantee that passing the tests will result in accessible, easy to use websites. This approach is output-driven, but not tested with real users. The complex nature of the tests make them incomprehensible for clients who have to rely on the claims of their agency.

Examples for a technical approach are the German Federal Ordinance on Barrier-Free Information Technology (BITV), the French General Reference for Accessibility of Administrations (RGAA), or the European Unified Web Evaluation Methodology (UWEM).

The second generation is user-centered. Web development is a process, and in the end there should be an accessible website that does the job: users can find information, accomplish a task, buy stuff. This is contextual accessibility. Besides expert reviews and conformance inspections this approach involves testing with disabled users to provide evidence for accessible sites. Often these accessibility laws go beyond WCAG and recommend best practices, demand accessible authoring tools according to ATAG, or provide considerations for choosing a content management system.

Examples for contextual and holistic accessibility laws are the British Guide to Good Practice in Commissioning Accessible Websites (PAS 78; PDF, 906 KB), the Guidelines for Swedish Public Sector Web Sites, or the Dutch Web Guidelines.

In their paper about Accessibility 2.0, Kelly et al. pointed out a few other flaws of the WCAG approach. For example the guidelines should be the result of a transparent, evidence based process. Therefore we need more research like that of the German Aktion Mensch, a study about the accessibility of Web 2.0 applications. Automation should be de-emphasized. Accessibility as the ultimate goal for users should be acknowledged, also the role of context and the relevance of diversity. We need to develop best practices and make sure they find their way into education. A new WCAG version is a chance to bring contextual accessibility into legislation, standards, and policies.

I will address that in a Web Standards Project meeting tomorrow in London. What are your suggestions? Are you familiar with the details of the Dutch or Swedish guidelines? How about the accessibility laws in your country? Are they technical or contextual? Who is involved in creating those policies? Kelly’s paper lists a lot of publications about disabled users — are your aware of any others?

Speakers

• Richard Schwerdtfeger (IBM)
• Marian Oosting (anderslezen.nl)
• Chris Heilmann (Yahoo!)
• Miguel González-Sancho (European Commission)
• Michael Cooper (W3C WAI)
• Dominique Hazaël-Massieux (W3C Mobile Web Initiative)
• Dave Wilton (Legal & General)

Richard Schwerdtfeger works for IBM and is a member of the W3C WAI and the HTML working group, among others. I assume he had been invited because the organizers only knew him for having developed IBM Home Page Reader back in the 1990ies. But his current work involves the W3C working drafts for Accessible Rich Internet Applications (ARIA) and other core technologies that his team developed in cooperation with vendors of Assistive Technologies (AT, e.g. screen readers) and the Mozilla Foundation.

There’s a paradigm shift in the usability and accessibility of Web 2.0 applications. ARIA adds meaning, importance, relationships, fills the gaps in (X)HTML, and increases usability for all users through familiar navigation models from desktop applications.

From Marian Oosting (anderslezen.nl) I learned about DAISY. It’s a library standard mostly used for talking books for the blind. Based on MP3 and the W3C XML standard SMIL, it combines strong compression with superior navigational features. Quite intriguing to use that format for audio books, and since 2006 it’s becoming available and more attractive for non-disabled users. For example, talking books are quite popular with elderly people who constitute about 60-80% of public library users.

In his presentation Chris Heilmann (Yahoo!) emphasized the need to ask people with impairments because they use assistive technologies in other ways than a non-disabled developer might foresee. Don’t assume, integrate their advice!

Miguel González-Sancho (European Commission, Information Society Directorate General) presented the European programs for e-Accessibility, e-Aging, and e-Inclusion. ICT is becoming essential for socio-economic participation, yet 40% of the European population is left behind. Functional limitations and disabilities increase due to aging. About 20% or 100 million of the European population is concerned. Thus accessibility is gaining relevance and becomes a social imperative.

In “Web Accessibility in the Future” Michael Cooper (W3C WAI) was rather giving the big picture and avoided to announce a release date for WCAG 2.0. Although the updated version will definitely play an important role in the future of accessibility, so does the development of a common Accessibility API or authoring interfaces that generate accessible content (ATAG). Think of user contributed content where the authors are usually unaware of accessibility requirements. Moreover, professionalization of accessible design, programming, and manual and semi-automated evaluation will gain importance. We must keep an open eye on developing technologies (MathML?, Second Life?), advocate accessibility in early stages, and keep accessibility awareness in legislation and society.

Dominique Hazaël-Massieux (W3C Mobile Web Initiative) talked about the mobile web, of course. There are more mobile phones than computers, they are cheap, and about 80% of the world population has mobile network coverage. Mobile access is everywhere, will become ubiquitous. There are some limitations like the tiny screen, the lack of a proper keyboard, diversity is large and access slow. In fact mobile and impaired users have so many challenges in common that Dominique estimates an accessible website already meets half the requirements of the Mobile Web Best Practices. Bad news for militant accessibility advocates who keep emphasizing the differences between accessibility, universal access and device independence.

Dave Wilton from the large British financial services supplier Legal & General gave some real world examples why it literally pays to become accessible:

There are nine million people with disabilities in the UK. If 1% just bought a £300 policy, his company will make £27 million: “The cost of making the site accessible pales into insignificance.” If people can’t buy from Legal & General, they will go to their competitors. In surveys, helpdesk and logfile analyses they found 10% of their visitors don’t make it past the home page. That’s equivalent to slamming the door into the faces of 20,000 visitors each month. 30% never open a PDF file. Besides, every third Briton is older than 50, and as we have heard before, the incidence of disabilities increase with age. There are not only people with cognitive impairments, but also 3 million people who speak English as a second language, 1.5 million people lacking basic language skills, and 5.2 million adults who have sub-GCSE level English.

Next time somebody tells you “disabled people are not our target group” show ‘em these results:

• Online traffic surged with a 50% increase in natural search engine listings.
• The number of visitors receiving quotes increased by 100% within three months.
• The new content management system cut site maintenance costs by 66% with an annual saving of £200k.
• Without changing products or prices, conversion rates improved substantially, ranging between 26% and 300% increase with an average of 200% (something Jakob Nielsen seconds).
• The entire project delivered 100% return-on-investment (ROI) within just 12 months.
• Customer satisfaction was improved (not one accessibility complaint!)
• It was great PR!

• Introduction
• Differences between WCAG 1 and WCAG 2
• What’s wrong with WCAG 2?
• Discussion
• Conclusion

Introduction

His article “To Hell with WCAG 2” was an eye-opener. Joe Clark expressed his angriness about the W3C, its slow, lobby-driven, bureaucratic processes, the gruelling internal fights within working groups and the Web Accessibility Initiative (WAI) in particular. The WCAG 2.0 Working Draft was a disappointment, basically unreadable, impossible to understand, and failing in major issues after five years in the making (WCAG 1 took a little longer than two years to become a finalized standard).

At that time I hadn’t read WCAG 2 yet. Joe Clark’s passionate article was a revelation, and all the blogs I read agreed with him. Perhaps I wasn’t the only one who hadn’t read the working draft by then. Because now I have, and while there are some valid points in his inflammatory speech, there are also major flaws.

Did you know that, contrary to Joe Clark’s beliefs, validating code is a requirement? That semantic markup is enforced? Other issues are totally overrated, like claiming a decent tab order was equal to the “prohibition of CSS layouts.” But more on that later.

His assault on the W3C set a spark to the tinderbox, and suddenly we heard concerns confirming the bad state of the Consortium from respected celebs like Jeffrey Zeldmann, Molly Holzschlag, Eric Meyer, Björn Höhrmann, and Tim Berners-Lee, to name a few.

Clark’s public criticism might be seen as a bold and important step. However, actually calling group members “arrogant and ignorant,” hanging up during conference calls and allegations like “some teenagers have greater understanding of valid, semantic markup than the Working Group” (ibid.) hurts the cause. If you search the WAI mailing list for more contributions from Joe Clark, you will immediately notice his egocentric, cynical, and often insulting style. He criticizes ignorance and harassment within that working group, but he’s part of the problem.

Meanwhile some things seem to go right at the W3C: the I18N activity led by Richard Ishida, or the quick embracing of Microformats, Web Forms, Widgets and Gadgets, and the XHTML 1.1 Role Attribute Module.

The latter has to be seen in context with IBM’s contribution to the Mozilla source code for DHTML accessibility. To implement that important technique, IBM has proposed an extension of the HTML specification to allow a negative tabindex. Joe Clark overstates that simple extension as “IBM actively promoting a DHTML technique that breaks the HTML specification.”

Differences between WCAG 1 and WCAG 2

WCAG 2 introduces four basic principles of accessibility. Content must be POUR:

1. Perceivable
2. Operable
3. Understandable
4. Robust

The guidelines are organized around these four principles, and checkpoints for the guidelines are now called success criteria. Each success criterion comes with an extended commentary, techniques to meet the guidelines, and common failures. That’s more comprehensive than version 1 and leaves less room for ambiguity.

The success criteria for each guideline are organized into three levels, though not all guidelines contain success criteria at every level. Levels are like WCAG 1 priorities, but they are more precise. WCAG 1 checkpoints had only one priority allocated, while a success criterion with multiple levels can be more differentiated.

In the past programming a website to conform to level triple-A was an almost impossible and disproportionate effort. Besides guidelines always have room for interpretation, so it is possible that experts disagree if a criterion has been met. Therefore the working group was pragmatic enough to grant triple-A conformance if at least 50% of all level 3 criteria are fulfilled.

Techniques for a website are defined in a public baseline, like “the specification that this content relies upon is: XHTML 1.0 (Strict). The specifications that this content uses but does not rely on are: JavaScript 1.2, CSS 2.” You can specify any reasonable technique, there’s no longer a preference for W3C techniques — if Flash is accessible enough and sufficient for the job, you don’t have to use SMIL. More on the baseline concept later. In the same way your conformance claims and conformance scope are published.

Since the working group tried to be as generic as possible, some terms changed. They speak of “web units” instead of “pages”, because web units include things like Ajax applications, which wouldn’t be covered by the term “page.” You get used to the terms fairly quick.

The guidelines were extended to be less ambiguous and include more cases. Deeply hidden within the documents are some true gems, for example accessible CAPTCHA or accessible Ajax. Wonderful!

What’s wrong with WCAG 2?

The information is yet too scattered among different documents, which makes it hard to read and comprehend. However, the working group notes it’s still work in progress, and they want to create separate files for each success criterion as well as a navigation structure. That sounds like the commented German accessibility guidelines, so I’m positive that the end-result will be more usable.

I must admit it could also be more readable. A professional copywriter could help, but I can imagine the exact wording of each success criterion was probably a big issue in WAI meetings, so the stakeholders won’t give up so easily just for enhanced readability.

Speaking of comprehension and easy reading, severe flaws can be found in the cognitive department. “Making text content readable and understandable” is a joke. Guidelines for context and orientation, navigation, and comprehension have been more or less dropped since WCAG 1.

We’ve come a long way to understand these features are not for cognitively challenged people alone, but they are basic requirements for all of us. Young people with insufficient reading skills, elderly who are new to the Internet — we all benefit from features like breadcrumb paths, a consistent navigation with clear wording, well written text, or relevant search results. These guidelines spell usability! We can’t allow having them removed!

Discussion

His article raised critical awareness for the last-call W3C working draft, which lead to the extension of the comments period. Still the degree of concern and fear didn’t need to be raised. Many issues are exaggerated, distorted by omission, or plain wrong. Let’s discuss them in detail:

1. 1. Definitions of “page” and “site”

   Exactly what a “page” is, let alone a “site,” will be a matter of dispute.

   Agreed. Although everybody knows what these terms mean, a formal definition is missing. But there are more important issues. That’s a typical Joe Clark.

2. 2. Valid (X)HTML

   A future website that complies with WCAG 2 won’t need valid HTML — at all, ever. (More on that later.) You will, however, have to check the DOM outputs of your site in multiple browsers and prove they’re identical.

   Not true. Success criterion 4.1.1 in plain English demands that IDs must be unique and elements properly nested. One technique to ensure that is validation. How was it possible that Joe Clark missed such an important point? Had he actually read his printouts, or was he just summarizing his correspondence with the working group?

   However, it is true that a comparison of DOM outputs is seen as an alternative technique to ensure proper nesting or well-formedness. That won’t work. Even valid code doesn’t result in identical DOM outputs in multiple browsers. Take for example line-breaks and code indented with tabs (white-space): Mozilla counts these as text-nodes, while IE ignores them in the DOM tree. Besides it would be a tremendous effort to compare the trees manually. Would somebody please create a validation tool with different browser engines under the hood?

3. 3. Table layout

   You can still use tables for layout. (And not just a table — tables for layout, plural.)

   Of course we know the disadvantages of table layout, and they are a pain to every standardista. From a pure accessibility standpoint they are tolerable as long as they can be linearized and semantic markup like <th> isn’t misused. But speaking semantically, isn’t a <td> supposed to represent tabular data?

4. 4. Blinking elements

   Your page, or any part of it, may blink for up to three seconds. Parts of it may not, however, “flash.”

   Everybody hates the infamous blink tag because it makes text unreadable. But I don’t think that’s what they are speaking of. It’s more like in banner ads, or in Ajax notifications. For three seconds I can live with that. The difference between blinking and flashing is the frequency; the latter can result in epileptic seizures. Simply avoid anything between three and fifty flashes per second.

5. 5. Baseline technologies

   You’ll be able to define entire technologies as a “baseline,” meaning anyone without that technology has little, if any, recourse to complain that your site is inaccessible to them.

   Not true. Baselines have to be reasonable. If they are not reasonable, others, including your government, can set a baseline.

   There are a couple of examples for reasonable baselines, like “only technologies that have been widely supported by more than one accessible and affordable user agent for more than one release” for a government site. More examples can be found in the …

6. 6. Conformance claims

   If you wish to claim WCAG 2 compliance, you must publish a checklist of declarations more reminiscent of a forced confession than any of the accessibility policies typically found today.

   Hmm, which of the following do you think is clearer?

   1. 

   2. On 5 May 2006, “G7: An Introduction” http://telcor.example.com/nav/G7/intro.html conforms to W3C’s WCAG 2 Conformance Level Double-A. The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3. The baseline for this claim is UDBaseline#1-2006 at http://UDLabs.org/baselines#1-2006.html. The specification that this content “relies upon” is: XHTML 1.0 (Strict), and Real Video. The specifications that this content “uses but does not rely on” are: JavaScript 1.2, CSS 2.

   My vote goes for the WCAG 2 conformance claim. Include this elegantly as a RDF file within a <link> (something missing in this working draft), and I’m a happy developer.

7. 7. Conformance scope

   You’ll be able to define entire directories of your site as off-limits to accessibility (including, in WCAG 2’s own example, all your freestanding videos).

   That’s true. But you can’t exclude integral parts of a process, like parts of a shop, though further definition would be required which parts can be excluded and which can’t. It becomes clearer when you take an example where the scope is set with a date:

   Materials with creation or modification dates before 31 December 2006 conform to WCAG 1.0 Level Double-A. Materials with creation or modification dates after 31 December 2006 conform to WCAG 2.0 Level Double-A.

   I can imagine cases where new content does conform to WCAG 2, while nobody bothers to touch really old content somewhere deep in the archives. So scoping is a practical issue: rather have conformance for the new and important parts than none at all.

8. 8. Video

   Not that anybody ever made them accessible, but if you post videos online, you no longer have to provide audio descriptions for the blind at the lowest “conformance” level. And only prerecorded videos require captions at that level.

   Joe Clark was dubbed the king of closed captions, so from his point of view WCAG 2 must be a step backwards: audio descriptions for prerecorded video are required on level 2, on level 1 either audio descriptions or a transcript will be sufficient. Audio descriptions for live video content were dropped in November 2005, and captions for live videos are level 2.

   WCAG 1 was very vague and didn’t make distinctions between live and prerecorded video. Everything had to have audio descriptions on the lowest level. The WCAG 2 approach doesn’t go that far. Although this might be disappointing, it is more differentiated and more reasonable.

9. 9. Audio

   Your podcasts may have to be remixed so that dialogue is 20 decibels louder than lengthy background noise. (You don’t have to caption or transcribe them, since they aren’t “multimedia” anymore. […]

   I agree not many people have the equipment to correctly measure a difference of 20 dB(A), but as a rule of thumb any dialogue should be easy to understand. Having my own program on a free radio station I can dig that. But there’s another major point Joe misses: although technically audio only is not multimedia, it still has to be transcribed.

10. 10. Skip links

    You can put a few hundred navigation links on a single page and do nothing more, but if you have two pages together that have three navigation links each, you must provide a way to skip navigation.

    Skip links are good, I don’t mind to have them everywhere. But in WCAG 1 “a few hundred navigation links” would have been required to be structured with subheadlines to enhance understanding. That’s the real issue here!

11. 11. Offscreen positioning

    You can’t use offscreen positioning to add labels (e.g., to forms) that only some people, like users of assistive technology, can perceive. Everybody has to see them.

    Although the intent of that criterion clearly is to make structure available to screen readers through semantic markup, the sentence Joe Clark refers to could be interpreted the way he does. Here’s the original:

    The purpose of this success criterion is to ensure that when such relationships are perceivable to one set of users, those relationships can be made to be perceivable to all.

    That’s not really new. Think of zoom readers with tab navigation via keyboard. If you place content offscreen, it can be quite irritating if an element gains focus and still is not visible. Good practice would require at least changing the element’s position to a visible area when it gets :focus. Although labeling forms, like in Joe’s example, can be achieved without offscreen positioning since the title attribute is deemed sufficient.

12. 12. Tab source order

    CSS layouts, particularly those with absolutely-positioned elements that are removed from the document flow, may simply be prohibited at the highest level. In fact, source order must match presentation order even at the lowest level.

    Death to any order columns! Death to the Holy Grail! I can understand the feelings some have towards that, but again it’s nothing new. In fact, in Germany’s eAccessibility law it was implemented as a priority 2 feature, not 3. The tab navigation shouldn’t be irritating and jump across the page, so take care of your source order.

13. 13. Idioms, acronyms, and pronounciation

    Also at the highest level, you have to provide a way to find all of the following:

    1. Definitions of idioms and “jargon”
    2. Expansion of acronyms
    3. Pronunciations of some words

    While for English developers marking-up foreign-language passages might be an exception with an unusual amount of “fanatical care” to achieve this, people in countries like Japan or Germany, where you have many anglicisms especially in technical texts, had a long time to get accustomed to it.

    In fact, according to WCAG 1 any language changes had to be identified as a priority 1 requirement, while in WCAG 2 only the document’s primary language is level 1, and only passages or phrases within the text are level 2, not single words. This is an incredible work reduction. Considering screen readers make a subtle pause before language switches that can get annoying in texts with many foreign words, it is also an improvement for those users.

14. 14. Alternate documents

    You also have to provide an alternate document if a reader with a “lower secondary education level” couldn’t understand your main document. (In fact, WCAG 2 repeatedly proposes maintaining separate accessible and inaccessible pages. In some cases, you don’t necessarily have to improve your inaccessible pages as long as you produce another page.)

    Again, that’s an old friend, and it’s emphasized that an alternate version “is a fallback option and is not preferable to making the content itself accessible.” So what? If a technical document for a specific target audience can’t use very simple language, it is common to provide a text summary for people with lower reading skills. That doesn’t mean we forget about accessibility and start publishing nothing but alternate text versions again.

Conclusion

Joe Clark takes some points, but on a closer look his article leaves a bitter taste as another tool for enforcing his point of view on the Web Content Accessibility Working Group. Okay, probably most of us who care about web standards today have been nerds as teenagers. But then again most of us have quit playing Dungeons and Dragons and got some social life. We don’t spend hours in front of our TV and write angry nitpicking letters to the CBC. We don’t harass W3C working groups, and when they won’t be intimidated, we do not found our own. Be gentle and play with the other kids.

If you want reform then do it from the inside — the subtlety of subversion is more effective than revolution.

Comment on Eric Meyer’s blog

WCAG 2 is not so spoiled, there’s still plenty of opportunity to make your constructive critique heard until the working draft becomes a recommendation.

Thanks to the Frankfurt Webmontag for the inspiration to write down and extend the things I mentioned in my lecture about WCAG 2 on 14 August 2006.