Oatmeal Stout - Justin Thorp’s Web 2.0 blog

If you’ve been reading this blog for a while, you know that one topic I’m passionate about is making the Web accessible to people with disabilities.  We all depend on the World Wide Web Consortium’s (W3C) guidance via the Web Content Accessibility Guidelines to help us through the process.

Well… WCAG 2.0 has just advanced to the next stage of the standards development process, Candidate Recommendation. What they need you to do is to go use it.

This weekend, get together with your friends and convert all of your sites and your blogs to being WCAG 2.0 conformant.  It won’t take that much work.  When you’re done, write about how it went.

Have you converted yet?  What do you think?  Let’s make our sites accessible so everyone can use them and access them.

CNET TV has recently shown a great deal of leadership in the online video space by starting to provide captions for their video. This is great news! I know it’s not easy to caption video… this is a big move for them. I hope more video shops (like Revision 3) will follow their move and start providing captions.

There is a chunk of the W3C’s Web Content Accessibility Guidelines (WCAG) 2.0 that deals with captioning. Success Criteria 1.2.1 says…

1.2.1 Captions (Prerecorded): Captions are provided for prerecorded synchronized media, except if the synchronized media is an alternative to text and is clearly labeled as such . (Level A)

Shawn Henry of the W3C’s Web Accessibility Initiative recently wrote a blog post entitled “Is WCAG 2.0 almost done?!” Well after reading the document, I say let’s advance the Web Content Accessibility Guidelines (WCAG) 2.0 to it’s next stage.

Like Shawn, I’ve been following the development of WCAG 2.0 for a while and I think that this is one of the working group strongest drafts yet.

I’m going to start using WCAG 2.0 when making Web sites.  Will you join me?

Well today the World Wide Web Consortium has just published the Web Content Accessibility Guidelines (WCAG) 2.0 as a Last Call Working Draft. For those of us who’ve followed the development of WCAG 2.0, getting things to this stage is definitely a long time coming and we’re all very excited to see what the WCAG Working Group has come up with.

According to the WAI document “How WAI Develops Accessibility Guidelines through the W3C Process…“, Last Call Working Draft means the following:

When a Working Group believes it has addressed all comments and technical requirements, it provides the complete document for community review and announces the Last Call. For example, see the WCAG 2.0 Last Call Announcement and Extention e-mail. (Note that after the Last Call comment period, it can take weeks or months for a Working Group to formally address all comments, document the resolutions, and make necessary changes.) If there are substantive changes, the technical report would go through another Last Call Working Draft before moving to the next stage.

According to the Call for Review, “The WCAG Working Group hopes that it has resolved all substantive issues with this draft, and looks forward to progressing to the next stages in completing WCAG 2.0.”

Sweet!

If you’re going to review WCAG 2.0, make sure that you also check out the following updated documents…

• WCAG 2.0 Quick Reference
• Issues and Changes to WCAG 2.0: A Summary of Issues, Revisions and Rationales on WCAG 2.0 Working Drafts

I’m going to be doing a detailed review of WCAG 2.0. I’ll be publishing my thoughts here as soon as I get time to sit down with the document.

Stay tuned…

With the W3C working on HTML 5, many times I have wondered how I could get more involved. Do I want to get work to add me to the working group and get the 1000 emails a month? Should I start reading the spec and post about it on my blog? Reading the HTML 5 draft spec by myself interests me about as much as trying to read War & Peace. (I think they’re about the same size.)

What about HTML 5 reading parties? We could really do it for any of the W3C Specifications like WCAG 2.0 or CSS 2.1. We could get 5 to 10 people together with a couple cases of beer or nice bottles of wine. If people didn’t want to drink alcohol, we could meet at a coffee shop. We’d each take part of the spec and start reading it.

It’d be a fun and whole lot less intimidating way of jumping head first into the future development of the lingua franca of the Web, HTML.

At the end, we could have some collective notes that we could post on our blogs or maybe one big blog.

So… any of you interested? I’d buy the wine or the first round of coffees.

If you haven’t heard, there has been the following update about the W3C’s Web Content Accessibility Guidelines (WCAG) 2.0…

The WCAG Working Group received many constructive comments on the 17 May 2007 Drafts. They separated the comments into about 450 issues, ranging from minor edits to technical issues. In the first two weeks of July, the Working Group had eight half-day worksessions where they addressed about 150 of those issues and started work on another 100. It will likely take 3 to 4 months to address all of the issues and prepare the next draft.

The Working Group will respond to each comment. Once the comments have been addressed, the Working Group plans to publish a second WCAG 2.0 Last Call Working Draft to provide for review of the completed edits before moving on to the next stages. The next stages are described in How WAI Develops Accessibility Guidelines through the W3C Process.

Yesterday, the web magazine A List Apart posted an article from Gian Sampson-Wild, “Testability Costs Too Much,” where she makes the claim that the requirement of having every success criteria within the W3C’s Web Content Accessibility Guidelines 2.0 be testable is too steep of a requirement.

I completely disagree.  Success criteria that can’t be tested shouldn’t be included in a document that is supposed to give guidance.

I was going to use the metaphor that Jeffrey Zeldman jumped on.  If someone says don’t speed in your car because it will hurt people, thats fine but how do I know what speeding is.  It’s a toothless and unenforceable law.   But if you say that I can’t go above 65 mph or 100 kph, that is a testable and  enforceable law.

I can’t tell a developer to do something unless I know specifically what I’m asking of them.  Just giving some one general advice isn’t going to work.  It is going to be interpreted a variety of ways.  This leads to fragmentation of guidance and  inconsistent implementations which don’t help anyone.

If the principle of testability of the success critieria is inconsistently applied within the document, I think thats a legitimate concern.  Commenting on the latest WCAG 2.0 Working Draft closes on Friday.

Doesn’t taking out testability dilute the guidance that we’re really want and asked for?  Am I missing something?

Yahoo! has been posting so many great videos on Web Accessibility. While in London, Web Accessibility expert and W3C staffer Shawn Lawton Henry stopped by Yahoo to talk about the Web accessibility guidelines that the World Wide Web Consortium (W3C) is working on. It’s a great talk. Check it out.

(Photo of Shawn Lawton Henry by Richard Ishida.  Taken at the 2007 @media conference in London, UK. )

I recently read some obscene statistic about the HUGE amount of video that is getting uploaded to the Web everyday. It’s a probably safe bet to say that the majority of that online video doesn’t have any captioning.  This is a big problem for people who are deaf or hard of hearing and are trying to understand the message of your video.  According to Gallaudet University, about 8.6% of the American population or 20+ million people have some form of hearing problems.

Captioning takes time and its not easy. I wish there was a magic button that you could press and captions would magically appear on the videos you were making.

Regardless, the W3C’s Web Content Accessibility Guidelines (WCAG) 2.0 has the Success Criteria 1.2.1 which says:

1.2.1 Captions (Prerecorded): Captions are provided for prerecorded multimedia, except for multimedia alternatives to text that are clearly labeled as such.

Well authoring tool vendors and developers have responded to our call for better tools.

In the latest version of Adobe Flash CS3, there is integrated captioning functionality. According to Adobe Accessibility Engineer Andrew Kirkpatrick, the new functionality makes “delivering captioning in Flash really easy.” While, I haven’t seen this at work. I’m pretty excited that Adobe has made this a priority.

There is also MAGpie, the free open-source tool from WGBH’s National Center for Accessible Media.  If you already have the transcript for your video, you can quickly turn the transcript into the xml file format you need to make captions for your online video.  I have seen it in action.  It’s not super seamless but it gets the job done.

The US Library of Congress has started to integrate the use of MAGpie and Flash video to provide captioning for some of their videos.  Check out the videos for the MacDowell Exhibit. (Full Disclosure: With my government contracting job, I work at the Library of Congress full time.)

One of the most interesting tools I have seen is dotSub.  You can submit your video to the service and then you or any of the members of the service can transcribe and caption the video.  Once you have the initial captioning done,  the captions can be translated into many languages.  This is all done through the wisdom and knowledge of the community.

Lee Lefever did it with his Wikis In Plain English video.  dotSub really worked for him.  Not only was he able to get his video transcribed and captioned in English.  It was also subtitled into a dozen other languages.  His video is now accessible to people with auditory disabilities where it wasn’t before.

Every Web standardista should be happy to hear that well-formed (X)HTML is a requirement at Level A for the W3C’s latest draft of the Web Content Accessibility Guidelines (WCAG) 2.0. Success Criteria 4.1.1 says

4.1.1 Parsing: Content implemented using markup languages has elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications. (Level A)

This means that you have to follow the rules when writing the markup for your Web site. The possible techniques for meeting this success criteria are:

• G134: Validating Web pages
• Fully conforming to specifications
• Ensuring that Web pages can be parsed by using one of the following techniques:
  • H74: Ensuring that all id attribute values are unique for the document AND that opening and closing tags are used according to specification (HTML)
  • H75: Ensuring that all id attribute values are unique for the document AND that the Web page is well-formed (HTML)

There is more then one possible technique that would be possible for fulfilling this success criteria. You don’t have to do them all, just one.

One option, as notated in the first technique listed, is that you have valid HTML. You should be able to go to the W3C validator and get the big thumbs up.

Probably the best option, as noted in the second technique listed, is that you write your HTML according to the specification. This is more then just well formed markup. This means you should have meaningful and semantic markup, as specified by the specification.

The final option - the fall back option - is just having well-formed markup, as notated by the last two techniques. You’re HTML tags should properly nest with each other and that every open tag that needs a closed tag has one.

I’m guessing this final option is there for those who don’t want to lose their accessibility conformance because they have an errant miswritten ampersand that shows up somewhere (having worked at a large organization on their web team, this happens often).

I’m good with these options. In the end we are requiring of people that they use well-formed markup, which is a big part of the battle against tag soup.

What do you think?

One accessibility expert wrote in 2006 that…

Even if valid HTML everywhere all the time is unattainable, the fact remains that, in 2006, we have never had more developers who understand the concept and are trying to make it real on their own sites. WCAG 2 undoes a requirement that, were it retained, could be perfectly timed now.

Please share your thoughts.