First I talked about the term of disability in a changing social and political context, then I lead to the demographic trend, hence to accessibility as an economic imperative. I showed a few barriers and techniques in practical examples as “virtual wheelchair ramps” and ended with an outlook on the challenges we currently face in the W3C HTML Accessibility Task Force.

The slides are currently available only in German at Slideshare where they can also be downloaded (15 MB). I will further adapt the slides and translate them for a Mozilla P2PU course in September, I appreciate your patience. There are also notes in the powerpoint file for a more detailed description.

But the story continues: beginning in the winter semester I’ll have a lectureship once a week at the university, teaching organic frontend development with contemporary techniques.

1. <object type="application/x-shockwave-flash" data="http://www.youtube.com/ v/ VideoID" width="480" height="360">
2. <param name="movie" value="http://www.youtube.com/ v/ VideoID" />
3. <param name="quality" value="high" />
4. <param name="allowFullScreen" value="true" />
5. <!-- Fallback content -->
6. <a href="http://www.youtube.com/ watch? v=VideoID">
7. <img src="http://img.youtube.com/ vi/ VideoID/0.jpg" width="480" height="360" alt="[Video title]" />
YouTube Video
8. </a>
9. </object>

Please note that there are spaces in the code above to allow linebreaks. If you copy and paste you need to remove those.

Here is an example:

1. What are the issues of accessibility in HTML 5?
2. What is the canvas element?
3. What is the difference between video built in natively in the browser or provided through a Flash plugin?
4. Why are people in the HTML 5 working group so nasty to each other?
5. Why is accessibility important in an emerging standard?
6. Can’t accessibility be added later?
7. What is the state of support of HTML 5 in browsers?
8. When can we start to use HTML 5?
9. What can geolocation do for accessibility?
10. Does assistive technology support HTML 5 features?

So please vote for it now, and while you’re at it, show your love to some other accessibility and web standards proposals as well. </thxkbay>

You can see and download the slides at Slideshare (German). As I promised to write a detailed post about ARIA enhanced tab navigation for the Webkrauts web standards advent calendar (think of a German version of 24 ways) you will be able to enjoy an English tutorial soon. Never mind the references to Chris in the slides — I had to choose an example from my flickr pictures, and I believe there are too many presentations already with kittens.

The conference was surprisingly innovative: I half expected a crowd of suits as the event was co-organized by the Austrian Ministry of Health, Family and Youth, instead there were many young faces and a fair percentage of women. Things I have learned (and tweeted about) include:

• As of January 2009, websites sponsored by the Austrian Ministry of Health will only receive funding when they are accessible. That doesn’t come as a surprise as a European Ministerial Declaration in 2006 announced that accessibility and best practices could become mandatory in public procurement in 2010.
• Artur Ortega showed examples of Dirk Ginader’s accessibility features for Yahoo! Finance, including two input fields where the labels were dynamically updated after a currency was chosen. So a screenreader read “convert pound sterling to euros” instead of “convert currency to currency.”
• One reason for JavaScript enhanced HTML controls for Flash objects like Yahoo! video is that the Flash object cannot get tab focus when the wmode param is set to opaque or transparent. Still without that param it is impossible to tab into a Flash object in Firefox 3. Or did I overlook something?
• Designer Maria Putzhuber quoted an interesting delusion: 70% of designers believe that visitors are almost always able to maintain orientation while in fact just 10% of the visitors are able to achieve this. What do you think is the reason?

Deutsche Fassung

A little known W3C standard is the Platform of Internet Content Selection (PICS). You can tell from the poor layout that it’s a very old standard — in fact all of its parts are from 1996 and 1997. OMG, that’s ancient! That’s even older than HTML 4, CSS, or the Web Content Accessibility Guidelines!

PICS is a system for self-labeling. That raised some concerns about censorship in 1998, but governments who really want to censor their population’s internet access have found more effective ways to block content (I, for one, can recommend Tor as a countermeasure, also available as a Firefox extension, though I cannot guarantee your government approves it). So what remains is a meta element with information about your website, accompanied by a machine readable RDF/XML file.

1. <link rel="meta" href="/pics-label.rdf" type="application/rdf+xml" title="ICRA PICS label" />
2. <meta http-equiv="pics-label" content='(pics-1.1 "http://www.icra.org/pics/vocabularyv03/" l gen true for "http://learningtheworld.eu" r (n 0 s 0 v 0 l 1 oa 0 ob 0 oc 0 od 0 oe 0 of 0 og 0 oh 0 c 1))' />

Since in the nineties internet progress was driven by porn, PICS is mostly about child protection, although it can be used to describe a machine readable privacy statement and other things as well. Think of an early predecessor of the Semantic Web. Or in microformats it would be hPorn. Well, I assume very few of you run xxx sites, so why am I wasting your time with this post?

Because the PICS standard is most convenient when your website is not pornographic. The standard provides a way to label your website and distinguish between pictures of naked people as Greek ancient sculptures, in an educational or journalistic context, or as mere porn. But despite the name it’s not only suitable for rating pictures, it’s for text content or user-generated content as well, among other criteria. Plus the PICS label is recognized by Google, so it’s not about rushing ahead and self-censoring to please our overlords, it’s a measure to maximize the target audience and avoid mislead traffic. I believe a few of your clients may appreciate that. For example although this post uses quite a few trigger words, PICS provides a way to tell search engines and cybersitting software about the true nature of this article. I love that ability!

Also ARIA became a bit of a buzz since only three days before Microsoft announced support for it in Internet Explorer 8. So there is partial support in Firefox 1.5, more in Firefox 2.0, and full support including liveregions for dynamically updated content in Firefox 3.0. Also Opera 9.5 has it. It can be used today as it doesn’t break old browsers, they will simply ignore the new attributes. Don’t hesitate, you can do good with it right now.

In the meantime Aaron Leventhal and his fellows were busy negotiating with members of the HTML5 working group to find a way of implementation without namespacing. So as of Firefox 3.0 it will be <img role="checkbox" aria-checked="false" /> instead of the previous namespaced notation aaa:checked="false".

Microsoft also thought about addressing the new attributes in the DOM, alas they did it the old proprietary way instead of sitting at a virtual or real table with the other browser vendors and thinking of a common way to do this. Opera’s Anne van Kesteren and the participants at the Browser Wars panel at SXSW were picking heavily on that subject. I believe the IE team got the message, but for the moment I would suggest to ignore the non-standard DOM attributes.

Thanks again to Gez, Becky, Lisa, and Shawn for their input and help. You made this a first-class experience!

Further reading

• W3C WAI-ARIA Overview
• Mozilla Developer Center ARIA FAQ
• A List Apart: Accessible Web 2.0 Applications with WAI-ARIA

South by Southwest (SXSW) is a huge conference for interactive media as well as a film and music festival in Austin, Texas, March 7-11, 2008. Every year it attracts the best designers and developers, and there is an immense number of panels to choose from. Exactly 128, out of which 80 are chosen from an open submission process.

Gez Lemon and I plan to run a panel called “Get Rich, Remain Accessible,” naturally about WAI ARIA (Accessible Rich Internet Applications). Gez wrote a great article about ARIA liveregions, and I wrote that article at A List Apart, so it’s the perfect team. Together we would like to present:

1. The accessibility problems introduced by the current trend of web applications,
2. new ways to add semantic meaning, communicate importance, define relationships, and give focus to elements using WAI-ARIA,
3. how to limit the impact of these problems whilst WAI-ARIA is gaining support by user-agents, and techniques that work right now.

It would be nice if you took the time to vote for us at the SXSW panel picker application. The voting process is open until 11:59 pm, September 21. If you push our presentation to the top 80 you will ensure Gez and I actually make every effort to attend the conference as we will get free tickets for ourselves. Spread the word …

The W3C’s standards draft for Accessible Rich Internet Applications (ARIA) addresses those limitations. It provides new ways of communicating meaning, importance, and relationships, and it fills gaps in the (X)HTML specifications and increases usability for all users by enabling navigation models familiar from desktop applications. Best of all, you can start using ARIA right away to enhance the accessibility of your websites.

I held talks about the upcoming standards in Cologne and Frankfurt, which resulted in writing a blog entry about the topic that eventually became an article for A List Apart.

Update: there’s also a German translation of the article at Barrierekompass.

If you’d like to learn more I’ll be speaking at the BarCamp in Frankfurt on April 21-22, and the Infopark Internet Congress in Berlin on May 11th.

Objectives of the WaSP ILG include

• information and discussion about web standards and accessibility, particularly with regard to localization,
• outreach through blogs, books, articles, presentations, code, design, vision and leadership,
• translation and internationalization of documents and resources,
• keeping an eye on web trends.

There are and will be local geek meetings called “WaSP Cafés,” perhaps on a smaller scale than barcamps or other unconferences, but with the same attitude to share, discuss, learn, and get feedback.

I must admit the WaSP ILG website is a little jammed with multilingual texts where language negotiated content would be more appropriate, also the ILG is not yet featured on the front page, and there are a few minor accessibility flaws like pages linking to themselves or the logo being a background image. But I’m convinced these issues will be addressed soon. After all, the group is only six weeks old, and currently a lot of people are actively participating at SXSW.

• 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.