Andy Mabbett reminded me that it’s been a year since James Craig and I published hAccessibility— a look at the accessibility problems inherent in some unsemantic design patterns used in some microformats.
The main problem is that the title attribute of the abbr element is misued to “hide” machine data, such as in this example.
<abbr class="dtstart" title="20070312T1700-06">
March 12, 2007 at 5 PM, Central Standard Time
</abbr>
For screenreader users who have elected to have their assistive technology expand abbreviations, the human date is replaced by the unintelligible string “Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six”, which makes it inaccessible.
We were accused of spreading fear and doubt, told we were wrong and we must prove our case to an openly hostile microformats crowd. The burden of proof was so great that we decided to have a life instead.
Mike “Isolani” Davis resurrected the issue this weekend. He takes issue with the microformatters’ assertion that the scenario I describe above is not a problem because most screen reader users do not change their default settings.
I agree with Mike about this (although I don’t think Jeremy is the bad guy).
Many users do not know or use all the features of the software. Given the mental load of browser, Web site, and assistive device, it should not be surprising that many of our participants did not know all the features of the screen reader software
…
Most of our JAWS participants regularly used the Links List (Insert-F7). A few regularly checked the Window Title to see what page they were on (Insert-T). Only a few used the Headings List (Insert-F6) or moved from heading to heading by pressing H inside a document. No one used the JAWS command, N, to skip links. No one jumped directly to a form on a page. Only one of our participants, a JAWS trainer, used the Virtual Viewer (Insert-F1), a JAWS feature that displays a description of a Web page, so that the user can immediately find out how many headers, tables, links, and other screen elements are on a page.
While this might be taken as supporting the idea that no-one really configures a screenreader (extrapolating from the conclusion that few even know the out-of-the-box features, let alone buried configurationm options), note that the paper also suggests “to make screen readers read an acronym or abbreviation as letters rather than attempting to read it as a word, use the <ACRONYM> and <ABBR> tags”, although doesn’t mention the expansion of abbreviations.
To be perfectly frank, I’m sick of the whole subject now. Even if it is unlikely that someone expands abbreviations (and I don’t believe it is unlikely), it is still very possible that someone using an assistive technology in the wild might want to expand an abbreviation, and hence find a microformat inaccessible.
Some in the microformats community want to find a way round this and work to make hCalendar and associated specs useful to all. I applaud those people. James, Patrick and I are working with those people.
Yet there are others who I know genuinely care about webstandards and semantics, and who would never dream of laying out a page with tables, and yet who are are nevertheless entirely happy to risk inaccessible content rather than amend their specifications to completely remove that risk.
My old mate and wrox refugee, Pete Fletcher, is an odd one. His latest project is “Sneezecount“, which sees him counting his sneezes, recording the time, date, location, relative strength of the sneeze and what he was doing at the time.
We were vaguely pleased with ourselves at work a couple of weeks ago when we noticed that a Google search on some of our keywords brought back our site as the first search result, and given us an extended entry that includes a matrix of links to pages within the site. These google sitelinks (as the SEO industry calls them) can help you achieve brand domination through keyword ownership.
It’s interesting to wonder how Google chooses the sitelinks. I think that it sorta-automatically gives a sitelink to pages that seem like they’re “contact us” or “about us”, which makes sense. But from my experience from my personal site and work site, some of the other sitelinks seem pretty arbitrarily chosen: they weren’t all from the main navigation elements, nor did they figure at all in the top 50 most-visited pages in the site. When it gave this site some sitelinks (gone after the last googledance, I notice) it included a link to a page which I’d recently removed, so I had to sort that out by reinstating the page, in order that the embarrassing 404 didn’t squander the extra credibility that sitelinks gave me.
It’s wise to check out your sitelinks for their usability, too. Here’s a cautionary tale. I got the go-ahead to attend An Event Apart, Boston in June, so went to book the ticket. Being unsure of the URL, and because I was already on google.com, I searched for An Event Apart.
Up popped the results, complete with a handy sitelink going straight to Boston:
I immediately clicked that sitelink, and sighed with disappointment to see that it was sold out. After food, I hit upon the idea of emailing Eric Meyer and asking him if there were any standby tickets. Being the courteous gentleman that he is, he responded that it wasn’t sold out and that was I perhaps looking at the Boston 2007 page? Being a gracious chap, he didn’t call me a Knucklehead McSpazatron.
And that was indeed the cause. The sitelink that Google provided goes to last year’s page (ditto for Chicago), so I was able to navigate to the homepage, find the pages for this year’s conferences and book my place.
But it was lucky that I’m pushy enough to bother Eric, or I would just have told my boss that it was sold out and been none the wiser.
The moral: regularly egosurf; check your sitelinks, and as soon as something like this occurs, go to Google webmaster central where you can block inappropriate sitelinks if they appear.
It would be nice if Google could provide a metatag which marked a particular page as ineligble for consideration as a sitelink, in the same way as you can tell it not to index or cache. That way, you could take preventative action and template your “archive” or “past events” pages so they never become sitelinks.
I work in the legal sector, so occasionally read the industry magazine Internet Newsletter for Lawyers. Last month they had an article bigging up the wonders of SharePoint, so I wrote in to the editor asking why they hadn’t mentioned its accessibility problems. The editor asked me to write them an article; as their mag is subscription-only, I reproduce it here.
Inspired by Gez Lemon, I’ve signed up as a volunteer accessibility reviewer for the John Slatin fund.
I never met John, but I had a lot of respect for his accessibility work and personal bravery. His death from leukaemia leaves his family with gigantic medical bills, so his friends have set up the John Slatin Fund Accessibility Project to try to raise $25,000 to help his widow.
The John Slatin Fund Accessibility Project matches accessibility experts with companies that would like a brief review of their site for accessibility. In return, the site owner is asked to contribute a minimum of $500 to The John Slatin Fund. The John Slatin Fund was established to help John’s beloved Anna offset the medical expenses incurred during John’s long illness. (Source).
So if you know of any company who is looking for an expert accessibility review, please point them to the information for companies.
