Home arrow Services arrow News arrow Design arrow The hAccessibility dilemma

The hAccessibility dilemma

Published on Monday, 30 April 2007
The accessibility community, which I remain part of, is somewhat abuzz with the discussions surrounding the use of the abbreviation element as part of microformat calendar dating, post dating and review dating. This is due to the reliance on abbreviations inside the date-time design pattern. So what does this mean ?
As this site runs a variant on the date time design pattern in order to negotiate Internet Explorer 6's lack of visibility for the abbreviation element, will a simple, essentially "spacer gif" spanned element work around the limitations of both parties to reach common grounding ?

That's what I'm unsure of. As my skillset covers the accessibility community and the microformats community, it becomes a little hard to differentiate as to what the adequate solution should be. I think I'm stuck between a rock and a hard place.

To throw me even more leftfield, I've also got my own testing of this site in terms of screen readers and how they are negotiating the variant date time. In my initial testing two days ago (which I forgot to record the audio feed from, more on this below), I had JAWS 8 in advanced verbosity, Window Eyes 6 and Firevox all happily parsing the content. As this site is gratuitiously marked up in hAtom, each time I author a post, the same algorithm prebakes the publishing and article modification dates according to hAtom spec, with that additional spanned element.

Initial Results

  • Firevox: Reads the date of this article as "Monday Thirtieth April Two Thousand Seven":  MP3 and OGG captures.
  • JAWS 8: Reads the date of this article as "Monday Thirtieth April Two Thousand and Seven": MP3 and OGG captures.
  • Windows Eyes: Reads the date of this article as "Monday Thirty April Twenty Oh Seven": MP3 and OGG captures.
  • VoiceOver: To be recorded and uploaded.

Third pass on JAWS, this time with this file:
  • JAWS 8: Reads the date as "Two thousand and seven dash zero four dash thirty tee eight oh six twenty eight zed":  MP3 and OGG captures.
So we have confirmed behaviour of the issue inside JAWS 8.  The version I'm running is JAWS 8.01163U, in case people want to test against it.

Platforms
  • Firefox 2
  • Internet Explorer 6
  • Camino
  • Safari
Methodology
  • Turn everything on.. in order to capture the most verbose output possible, including titles
  • Read the entire document. Note any differences that occur.
  • Select author, published date and first sentence of article. Set screenreader to repeat, just in case there is a discerpancy between screen reader behaviour.
Conclusions

As I've now confirmed the results, I can see why it's happening. The first pass of a document by JAWS doesn't pick it up the date time pattern (at least in my case), yet when you isolate the date time pattern and scroll to the date itself using SHIFT and DOWN ARROW, it reads out the ISO formatted date structure, even with a separate spanned element.

JAWS has a subtle nuance in that if you select a specific text area and specify that it read only that block, it disables expanded abbreviations, which then explains my first and second pass results with it.
blog comments powered by Disqus
 

“We help clients see their future.”

 :: 

Welcome to Absalom Media

Delivering web accessible websites

Absalom Media seeks to deliver industry best practice website usability and design for your budget.

As we are upgrading systems, login has been disabled.

Account management

As we are upgrading systems, account management has been temporarily disabled

What are you looking for?

Connect

Join us on Facebook

Follow us on Twitter

Talk to us on Skype

Generated in 0.47980 Seconds