Archive for February, 2011 RRRR’eturns

Friday, February 25th, 2011

My little hobby web site for tracking your luck with a large Canaidan coffee and donuts chain’s roll-up promotion is back!

My previous attempt was Drupal-based, and required an account. I was never very happy with the account requirement, and played with it being a facebook App but ultimately took the site down (described in this blog post). This time there’s no need for an account as it’s Twitter-based. This also helps with the promotional side of things.

I had hoped to partner with the – but that Twitter based iPhone App needed a technical update, and for other reasons, it’s now removed from the App Store. It’s too bad, but you don’t need anything beyond a Twitter account to enjoy

Simply tweet with the tag #RollUpTheRim to have your tweet listed on The site tracks results posted to Twitter in the format of wins/rims (and unofficially, a few other formats).

You can visit the main page for the latest, the scoreboard for the best and worst ratios There’s also a rapidly growing list of Twitter users who have tweeted with the hashtag #RollUpTheRim

The site is no longer Drupal-based, but some of the PHP from the Drupal module I wrote and the MySQL data structure were migrated to the new site which is otherwise built from scratch.

As many developers have indicated, working with‘s non-standard API is quite a joy. I was able to get things rolling (pun intended) quite quickly based on the simple twitter searches through Twitter’s search service’s RSS feed and looking-up someone’s Twitter details via an XML call is easy too.

What to Look for when Trying to Author Accessible Content: My List

Monday, February 21st, 2011

A picture of the HTML source of this blog post.I’ve assembled my list of things to look for when preparing content for the web with an eye to accessibility. I would like to add to this advice that I’ve always found that accessible web pages are the easiest way to create content that is well indexed by a search engine – as both serve the goal of helping a machine interpret the content better.

This list is written assuming that most modern tools that help construct content directly for the web help individuals create accessible content by default, and that this is the primary way content makes its way to the web. Tools like WordPress for blogs, or Learning Management Systems (LMSs).

Multimedia content is particularly challenging, as it can require the use multiple senses, and unless accommodations such as transcription or description are added, some individuals may not be able to access multimedia content.

Evan more than with most posts; I’d love to read your comments and suggestions about this list and these practices.

My Checklist for Preparing Accessible Content

This list was created by Matt Clare with resources from World Wide Web Consortium. [1] The W3C has a simular checklist document: [2]

Simple Formatting

Web Accessibility, in the context of the AODA

Monday, February 21st, 2011

The draft of the AODA Integrated Accessibility Standards is currently posted on the Ministry of Community and Social Services web site. The section on “Accessible websites and web content” subsection 4 was what I was most interested in. There were only minor changes from what was in the last draft that I saw, but the changes were significant.

Update: Friday April 1, 2011

Looks like the link is dead, but Google still has a copy:

Running key phrases through the Ministry’s search tool yields some really interesting results. Here is an example search.

What is the same is that it references the WWW Consortium’s Web Content Accessibility Guidelines (WCAG) 2.0

The draft AODA Integrated Accessibility Standards document applies to Ontario public web sites on the internet and in intranets (university LMS’ would be in either definition) and outlines targets for NEW content to be WCAG Level A accessible and then level AA and eventually ALL content to being Level AA.

The change is that there will be exceptions for online audio and video content. That is, content that would require Captions (Live) and Audio Descriptions (Pre-recorded) as outlined in the WCAG2 specification here

The WCAG2′s Captions (Live) and Audio Descriptions (Pre-recorded) requirements are unlike other content formatting previsions in the WCAG2 in that these are not items that content authors can simply modify how they format their content to achieve this high standard of accessibility. The Captions (Live) and Audio Descriptions (Pre-recorded) require many orders of magnitude more hours of labour to comply with than is often needed to produce the original artifact. To quote Stuart Robertson, webmaster, and contributor to at the 2009 Aiming for Accessibility conference at Guelph University “[the] Transcription requirement represent a serious disincentive to publish audio/video content to the web”.