It seemed useful to find out how well sIFR works with assorted screen readers. So I created two test pages:
And ran tests with the following screen readers
The test pages are very simple. Each contains two headings which have been replaced with sIFR. The second heading contains a link. For the record, the font in the sIFR 2 page is Carolingia; in the sIFR 3 page, it's Centabel Book. In each test, I instructed the screen reader to read the entire HTML document, and tested each of the following points:
Here's how they fared. I have provided MP3 recordings of each test. I've provided separate tables for sIFR 2 and sIFR 3, but the results were identical in each case. The screen reader software is the determining factor here, rather than sIFR.
| Screen Reader | Tag Announcement | Flash Announcement | h1 text | h2 text | Link Announcment | Glitches | Recording |
|---|---|---|---|---|---|---|---|
| JAWS 5 | Pass | Fail | Fail | Fail | Pass | Reads the h2 text when it's supposed to read the h1 text, and vice versa, and does so twice for each. Announces Flash movies start and end. Audio thoroughly scrambled. | MP3 |
| JAWS 8 (IE) | Pass | Fail | Fail | Fail | Pass | Reads the h2 text when it's supposed to read the h1 text, and vice versa, and does so twice for each. Announces Flash movies start and end. Audio thoroughly scrambled. | MP3 |
| JAWS 8 (Firefox) | Pass | Pass | Pass | Pass | Pass | None | No recording due to lack of time. |
| FireVox 3.2 | Pass | Pass | Pass | Pass | Pass | None | MP3 |
| Opera 9.21 | Fail | Pass | Pass | Pass | Fail | Does not identify link. | MP3 |
| Safari 2.04 | Fail | Pass | Pass | Pass | Fail | Does not identify link. | MP3 |
| Screen Reader | Tag Announcement | Flash Announcement | h1 text | h2 text | Link Announcment | Glitches | Recording |
|---|---|---|---|---|---|---|---|
| JAWS 5 | Pass | Fail | Fail | Fail | Pass | Reads the h2 text when it's supposed to read the h1 text, and vice versa, and does so twice for each. Announces Flash movies start and end. Audio thoroughly scrambled. | MP3 |
| JAWS 8 (IE) | Pass | Fail | Fail | Fail | Pass | Reads the h2 text when it's supposed to read the h1 text, and vice versa, and does so twice for each. Announces Flash movies start and end. Audio thoroughly scrambled. | MP3 |
| JAWS 8 (Firefox) | Pass | Pass | Pass | Pass | Pass | No recording due to lack of time. | |
| FireVox 3.2 | Pass | Pass | Pass | Pass | Pass | None | MP3 |
| Opera 9.21 | Fail | Pass | Pass | Pass | Fail | Does not identify link. | MP3 |
| Safari 2.04 | Fail | Pass | Pass | Pass | Fail | Does not identify link. | MP3 |
Note: JAWS 8 also reads from Mozilla Firefox, and it handles sIFR perfectly fine. I didn't make a recording of those two tests, due to lack of time. Also, although JAWS on Firefox handled my test case perfectly, it inexplicably announces "Flash Movie Start Flash Movie End" on my course page, but only for the level-one heading at the top of the page. The H2 and H3 elements in the content area and the sidebar worked perfectly. The flash announcement is kind of odd, but at least it didn't read the text twice.
It's been a month and a half since I did the initial round of testing. It took a while to get legit copies of JAWS 8. I no longer have JAWS 5, which is good, because it stunk.
In the intervening time, I've discovered a fix for the problem in Internet Explorer and JAWS. However, it required me to alter the sIFR javascript. As Andrew Kirkpatrick noted on his blog, JAWS doesn't read Flash movies embedded using the Flash Satay method at all, not even announcing their presence. That's a bug if screen-reader users need to be able access your Flash movie, but a feature for sIFR, since the Flash is purely decorative anyway.
I experimented, and found that a slightly modified version of the Flash Satay method works well with sIFR. You don't need to use the advanced flash-movies-embedding-other-flash-movies bit; the same effect can be achieved by modifying the HTML which sIFR serves up to Internet Explorer. Here's an example:
<object type="application/x-shockwave-flash" data="movie.swf" width="400" height="300">
<param name="movie" value="movie.swf" />
</object>
Basically, get rid of the classid attribute on the object element, and add instead a type attribute specifying the MIME type of the movie and a data attribute specifying the location of the movie file. When I modified the compressed sIFR source directly on my course page, the movie displays fine in IE, and JAWS doesn't report the existence of a Flash movie. It just reads the alternate content supplied by sIFR. So, the alt text is invisible to viewers, and the Flash movie is inaudible to listeners. Everybody gets all the content, with zero intrusion. Perfect!