Congratulations to Dennis Lembrée and Ross Johnson for the 2 year anniversary episode of Web Axe - Practical Web Accessibility Tips.

For a special feature, the following web experts were gracious enough to send me input on their thoughts about recent events and trends in the world of web accessibility:

• Mark McKay
• Joe Dolson
• Roger Johansson
• Patrick Lauke
• Jared Smith
• Ross Johnson

And here’s the transcript of my portion of the podcast:

Hi, this is Patrick Lauke for Web Axe.

For me the most significant development of the last year has been the way in which accessibility discourse in general has widened beyond the narrow confines of WCAG 1.0.

Although for very simple sites WCAG 1.0 is still quite valid, it’s ill equipped to deal with the reality of today’s web.

Rich internet applications, flash sites, complex javascript and AJAX, even widespread use of PDFs…as a developer, if you’re just sticking with WCAG 1.0, most of those are simply out of the question.

It’s true that in most situations you should really try to offer simple HTML/CSS based alternatives…but it’s not an either/or proposition anymore. For instance, it’s not purely a case of having a non-javascript accessible version of your site, since screen reader users don’t necessarily have javascript disabled by default. And in fact, judicious use of javascript can enhance the usability and accessibility of a site, even for these users…if it’s done properly.

I’d say that the development of technologies such as ARIA plays a key role here. As more and more browsers and assistive technologies take advantage of ARIA, we’ll hopefully see some of the major problems that javascript and AJAX can cause for particularly screen reader users being mitigated or maybe even completely eliminated.

Underpinning all of these developments, I would say that WCAG 2.0’s tech-agnostic, results driven approach, which ditches the “only use W3C technologies” dictum in favour of “accessibility supported technologies” holds great promise. It can provide a solid, extensible framework that’s valid today and in the future.

Based on the latest draft, WCAG 2.0 is indeed moving in the right direction…so my wish for this coming year is to see a stable version of the new guidelines.

And to really help web authors understand how WCAG 2.0 can be applied in practice, I also hope that the technology-specific, non-normative supporting documents for WCAG 2.0 will get some much needed attention…as that’s what most web authors will need, and refer to, in their practical day-to-day work.

And with that out of the way, I just want to say congratulations on your two year anniversary and keep up the good work. Cheers.

So I was reading this post on copyblogger entitled Does Telling Someone to Click Here Actually Matter? and I could feel the old blood a-boiling as the article dismissed all the work that many people in the accessibility circuit have put in so far in trying to get people not to use the damn phrase. Now, I could have vented off in the comments section, but then I decided to do something more constructive.

If you absolutely must use the phrase ‘click here’ because all your evidence or beliefs or hunches suggest it has the greatest effectiveness for click-through, please don’t do it at the expense of accessibility (that is for screen reader users as well as the obvious search SEO/advantages). You can use CSS to achieve your aims and keep the link phrase as something useful for screen reader users and search.

The solution is basically this:

<p><a href="#" class="clickhere"><span>Click here</span> to learn about widgets </a></p>

… using this CSS (or variant thereof):

body {color:#000;}
a{color:#006;font-weight:bold;}
a:hover,a:focus{color:#090;}
a.clickhere, a.clickhere:hover, a.clickhere:focus {text-decoration:none;color:#000;font-weight:normal;/* to match body color and weight */}
a.clickhere span {text-decoration:underline;font-weight:bold;color:#006;}
a.clickhere:hover span, a.clickhere:focus span {color:#090;;text-decoration:underline;font-weight:bold}
code {color:#00FF33;background:#000;padding:2px;}

It will produce a visibly underlined click here but the rest of the text ("to learn about widgets") will match the body text. This will not help fully sighted users who are just scanning through the document picking out links visually, though - they will still see only ‘click here’, ‘click here’. So it’s a compromise, but sometimes that’s what you have to do in battle!

You can view a page with a working example (that does not clash with this site’s own style sheets) here. Or perhaps I should write click here to view a working example.

My esteemed colleague Patrick Lauke is a firm believer in not providing widgets on individual web pages to do things such as resizing text on a page - on the basis that it’s site-specific and doesn’t teach the user how to change the font size for other web sites that don’t provide these controls.

This issue pops up time and time again, and it has done again on another forum where the phrase ‘teach a man to fish’ has appeared once more. It got me thinking, maybe it would be best to show the user how to change the font size rather than simply describe it. With that in mind, I put together some video clips, joined them together in iMovie and did a voice-over to explain how it’s possible. Here’s the end result (actually, this is version 2, which takes on board some of the comments in this post):

I’m interested to hear your feedback. Is this useful? Could you see people wanting to embed this on their accessibility page?

So, if you like this, blog about it, link to it, embed it in your accessibility statement if you think it could be useful to the user.

<object width="425" height="350"><param name="movie" value="http://www.youtube.com/v/54iSS7KVcos"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/54iSS7KVcos" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>

And if people do think a video tutorial for this kind of thing is useful, what else could we cover off on the accessibility front, specifically how the user can change their browser without requiring site-specific page widgets (e.g. teach the user how to change background and foreground colours). Over to you for any suggestions you may have on that front.

A transcript of the video is available here.