Absalom Media provides leading edge technological solutions in the online marketplace, primarily dealing with web standards, usability and accessibility to our clients across the world. We have also produced definitive Joomla! & Mambo template tutorials, covering the art of CSS design. With a focus on web standards and high speed design, try us out today.
The hAccessibility dilemma
Written by
Lawrence
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
Third pass on JAWS, this time with this file:
Platforms
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.
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.
Platforms
- Firefox 2
- Internet Explorer 6
- Camino
- Safari
- 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.
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.
Share:
