Last updated: April 30, 2007
JAWS makes an effort to understand dates and times and their context. Unfortunately, you cannot rely on JAWS making perfect sense of your text. If you include useful commas to separate the elements of your dates and times, they should be read out in an understandable fashion. It may also make your dates and times easier to understand for everybody.
The information on this page currently focusses on JAWS, but further tests with other software should follow shortly.
If you think about it, and keep in mind that software is only as clever as its programming, it would be very easy to write our Web pages in a way that confuses screen reader software. Think about the simple difference between your typical English and American date formats. 05/09/2007 could be 9th May or 5th September depending on the date format you normally use.
Side note: People who say that numerical dates are more usable than using text are wrong, in my mind anyway. The argument is that, say, through using the name of a month in place of its numerical representation, a date becomes dependent on the language you are using. By that logic, numerical dates are better for internationalisation. Unfortunately, the simple difference between the typical English and American date formats throws a spanner in the works. Something to think about; surely, if your content is dependent on language, there should be no problem with your dates being dependent on language too, even in your URLs?
Continuing then, "5 September 07" may be read as "five September (the) seventh" or "fifth (of) September seven". Neither of these are particularly useful, but the first case would just be wrong. More correctly, perhaps it should be spoken as "fifth (of) September zero seven" or "fifth (of) September oh seven", but without specifying the year in full, software may be at a loss as to how to pronounce the text.
There may be a solution…
If you include commas in your dates and times to separate the elements in a sensible fashion, screen readers should read them out in an understandable fashion. Take a look at the tests below for examples.
Now, you might take issue with me at this point. By inserting commas into our dates and times, are we, as Web designers and developers, having to make up for the shortcomings of screen reader software? Well, yes. You could blame the software vendors for coding their products with poor algorithms. I do hope that vendors will try harder to fix such problems in their screen readers. However, many of the vendors don't seem interested in implementing models based on Web Standards, while standards-based tools and techniques could provide simple solutions that will always work as intended (see Test 7: using Microformats below). I do not understand why they seem content to make life hard for themselves.
Blame aside, the simple solution of placing commas in dates is something that can be done to improve the situation now. Over and above that though, I believe there is a usability benefit for everyone in choosing a sensible date format. And that is what I am testing for here.
JAWS 7.10 (default) reads these as: