Category: WCAG 2.0

WCAG 2.0: Add Captions to Your Online Video

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.

WCAG 2.0: Well Formed (X)HTML is a Criteria for Success

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:

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.

Two More Great Web Accessibility Sessions in London This Week

Well in addition to her speaking at the RNIB yesterday, this week Shawn Lawton Henry will doing one of the sessions at the Web developers conference @media in London, England.  Her talk is entitled “Advancing Web Accessibility“, where she’ll look at WCAG 2.0 and how some of its techniques can be used right now.

@media in London also gets to hear from the one and only Joe Clark.  His talk is entitled, “When Web Accessibility Is Not Your Problem.”  Joe is going to talk about the role and responsibility of the authoring tool in user agent developers/vendors in the Web Accessibility process.

They both should be great talks.

Are any of you going to be live blogging the talks?  I unfortunately can’t be in London to attend.

WCAG 2.0: Do you have enough color contrast on your Web site?

Ever go to a Web site where you feel you have to squint to read the text because the color contrast is so bad. Having appropriate color contrast on your Web site is very important. You may lose a chunk of your audience if they can’t adequately read the text because of not enough contrast between background and foreground colors.

In the W3C’s Web Content Accessibility Guidelines (WCAG) 1.0, the only thing they say about having enough color contrast is in checkpoint 2.2:

2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].

The natural question would be, what does “sufficient contrast” mean? How can I measure that? It’s a checkpoint that I could easily shrug off an say, “Sure my sight as sufficient color contrast.”

In the latest drafts of WCAG 2.0, color contrast is a little bit more spelled out. Level AA Success Criteria 1.4.3 says:

1.4.3 Contrast (Minimum): Text (and images of text) have a contrast ratio of at least 5:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 3:1. (Level AA)

If you’re more ambitious, Level AAA Success Criteria 1.4.5 says:

1.4.5 Contrast (Enhanced): Text (and images of text) have a contrast ratio of at least 7:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 5:1. (Level AAA)

But what does it mean to have a contrast ratio of 5 to 1, 3 to 1, or 7 to 1? Well thats what development and evaluation tools are for. The tools can be built around the appropriate algorithms to tell us whether or not we have good color contrast on our Web site.

The Web Accessibility Tools Consortium has put out the Luminosity Contrast Ratio Analyser 1.1. This is a great tool to use at the beginning of the design process. You can enter color choices and see if there is enough color contrast to be in conformance with WCAG 2.0. Unfortunately the tool only currently works with Windows (sorry Mac designers.)

No after you have posted your site online, you should check again to make sure that all of your background and foreground colors have the appropriate contrast. Gez Lemon of Juicy Studio and participant in the WCAG Working Group has published his tool, the Colour Contrast Firefox Extension.

With the tool, you can go to any Web site and analyze all of the different background and foreground color contrast levels. A table with all of the different colors that are used will come up. It will point out exactly what needs to be fixed.

Shawn L. Henry is speaking on “What’s new, WCAG 2.0, and current issues” on June 5th in London

If you haven’t already heard,  the W3C WAI‘s Outreach Coordinator and recent author of “Just Ask: Integrating Accessibility Throughout Design” Shawn L. Henry is going to be in London on June 5th doing  a talk “What’s New, WCAG 2.0, and Current Issues” for a RNIB Web Access Center hosted event. She is going to be covering a wide variety of topics, everything from the latest on WCAG 2.0 to WAI-ARIA.  The event is FREE but you must RSVP.

I really wish I could be at the event but I can’t afford the trip across the pond.  I’m hoping that some of you will go and take a lot of notes and pictures.

Web Community Seems a Little More Positive on the Latest WCAG 2.0 Draft

I have been keep my eyes on the blogosphere for reaction and comments to the latest draft of the W3C’s WCAG 2.0.

It has been pretty quiet. Typically the blogosphere only gets in a frenzy when they have something to complain about.

There has also been a bit of positive feedback. Jack Pickard wrote the following…

It’s usable, it’s a vast improvement on the previous draft, and it’s an improvement on WCAG 1.0 as well.

Ok, it’s not perfect, not by a long chalk — it’s significantly lacking in relation to cognitive disability for example, and I’d like to see this improved before the final release — but it’s still pretty damn good nonetheless.

I agree with Jack. I think the latest version of WCAG 2.0 is a big step forward.

In an era of Web 2.0, having a set of Web accessibility guidelines that will be relevant and current with the times is CRUCIAL. Its our responsibility as the Web community to grab a tasty beverage, sit back with WCAG 2.0, and give it a read.

What are your thoughts? Do you think its an improvement? How could it be better?

Are you using a WCAG 2.0 Accessibility Supported Technology to make your Web site?

One thing that you won’t see in the latest draft of WCAG 2.0 is the concept of a baseline.  The community in unison pretty well dismissed the idea as not comprehensible.

It has been replaced with the idea of Accessibility Supported Web Technologies.  We all use different building blocks to put together our Web pages, whether it be HTML, DOM Scripting, AJAX, or Flash.   We need to use Web technologies which are going to support Web accessibility.  Assistive technologies (screen readers, screen magnifiers, braille reader, etc) have to be able to progrogrammitically assess the meaning on content which we’re trying to get across to the user.

So the next question you’d ask is how do you know if a Web Technology supports Accessibility?  The document gives some general guidance but nothing that a layman could easily assess.   I’d assume that all W3C Technologies support Web accessibility.

Shouldn’t the W3C create a list of accessibility supported Web technologies?  I’d think so.  Well they’ve passed that job off on us.  According to the Understanding WCAG 2.0 document, “Anyone can create a publicly documented list of “Web Technologies and their Accessibility Support.”

With so many new Web technologies being created all the time, maybe the W3C doesn’t want to be in the position of holding the official list of what is and what is not accessible.  Maybe the Web Standards Project (WaSP) and their Accessibility Taskforce would be a good keeper of this list.

I just don’t feel comfortable with developers (generally people not that familiar with assistive technologies) judging whether or not a Web technology supports accessibility.  I’d like to see some other organization with more expertise in that area step up.

WCAG 2.0 is Technology Independent

One of the first things that you’ll notice when you start reading WCAG 2.0 is that it is “technology independent.”  Well what does that mean?  The guidelines and success criteria are not tied to any particular Web technology.  They apply to all technologies (HTML, CSS, Images, Flash, JavaScript).

Within the main WCAG 1.0 document, there is practical advice for how to make your Web site accessible.  For example, Guideline 5 is “Create tables that transform gracefully.”  you’re not going to see practical advice like this at this level of WCAG 2.0.

To get the practical advice that deals with one technology or the other, you have to look one level deeper at the supporting material like Understanding WCAG 2.0 or Techniques and Failures for WCAG 2.0. The main WCAG 2.0 guidelines document acts more as the foundation for the other practical techniques that you’ll find.

I think having WCAG 2.0 be technology independent is pretty smart.  It seems like every couple of months some new Web technology is announced.  There is some new way for Web content to be authored and experienced.

It would have been hard if practical advice would have been woven into the main WCAG guidelines, like in WCAG 1.0.  It would have to be ever evolving and ever changing.  Within the main WCAG 2.0 document, the guidance is more abstract and high level so that it can apply to just about everything.

What do you think of WCAG 2.0 being technology independent?

“Call for Review: Updated WCAG 2.0 Working Draft”

Please check this out:

W3C WAI Director Judy Brewer’s “Call for Review: Updated WCAG 2.0 Working Draft“…

Dear All,

The Web Content Accessibility Guidelines Working Group (WCAG WG) invites you to comment on an updated draft of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0), published on 17 May 2007. WCAG 2.0 addresses accessibility of Web content for people with disabilities.

The updated WCAG 2.0 Public Working Draft incorporates changes in response to comments received on the 27 April 2006 WCAG 2.0 Last Call Working Draft. Because there were a number of substantive changes, WCAG 2.0 has returned to Public Working Draft status. We expect to advance WCAG 2.0 to a second Last Call Working Draft after this Public Working Draft.

W3C/WAI encourages you to review this document and submit comments on any issues which you feel could present a barrier to adoption and implementation of WCAG 2.0. The Working Group seeks feedback on the following points for this draft:

– Are the guidelines and success criteria clear? If not, can you
suggest clearer wording?
– Are there any success criteria that you feel are not
implementable or testable? If so, how could they be improved?
– Are there any success criteria that you feel would not improve
accessibility as written, or that might hinder it? If so, how could they
be improved?

Comments on this Working Draft are due by 29 June 2007. The Working Group requests that comments be made using the online or downloadable comment form available at
http://www.w3.org/WAI/WCAG20/comments/
If this is not possible, comments can also be sent to
public-comments-wcag20@w3.org . The archives for this list are publicly available. (Please note that if you submitted comments during the 2006 Last Call Working Draft review period, you will be receiving an email with a response to your individual comments.)

The following document provides an overview of all the WCAG 2.0 documents:
* Overview of Web Content Accessibility Guidelines (WCAG) 2.0 Documents
http://www.w3.org/WAI/intro/wcag20

The primary document for review is:
* Web Content Accessibility Guidelines 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20070517/

A key tool for reviewing and working with WCAG 2.0 has also been updated:
* WCAG 2.0 Quick Reference
http://www.w3.org/WAI/WCAG20/quickref/20070517/

These supporting documents have been updated as well:
* Understanding WCAG 2.0
http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20070517/
* Techniques for WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/

A summary of changes to WCAG 2.0 since the previous draft will be available:
http://www.w3.org/WAI/GL/2007/05/change-summary

Information on how WAI is developing WCAG 2.0 is available:
* How WAI Develops Accessibility Guidelines through the W3C Process
http://www.w3.org/WAI/intro/w3c-process

Additional information about the WCAG Working Group is available:
http://www.w3.org/WAI/GL/

Feel free to circulate this message to other lists; please avoid
cross-postings where possible.

Please let us know if you have any questions. Thank you in advance for your comments.

Loretta Guarino Reid, Co-chair of WCAG WG, and Computer Scientist, Google Inc.
Gregg Vanderheiden, Co-chair of WCAG WG, and Director of Trace R&D Center,
University of Wisconsin-Madison
Michael Cooper, W3C Team Contact for WCAG WG
Judy Brewer, Director, Web Accessibility Initiative, W3C

NOTE: I plan on doing a thorough review of this draft of WCAG 2.0 and publishing my thoughts on this blog.  Make sure you’ve read WCAG 2.0 also so we can start a conversation.