Strange sIFR / screen-reader bug

I was writing a little accessibility article for .net magazine about text-replacement techniques, including sIFR. I was blithely saying that "yea, don't worry, it's fine" with a couple of caveats. But, rather than rely on memory I did a quick test, and discovered something strange.

Bob Easton has a useful test case page, with which I tried in everything I had to hand:

The image replacement techniques were generally fine with a couple of small bugs, most of which don't appear on Mezzoblue list. Having them as links seems to be problem, and increased font size does seem to be an issue for the Gilder/Levin method unless you start with a small text size.

Problem

When I got to the sIFR method (scalable Inman Flash Replacement), the Windows based screen readers read out the heading twice. I also checked on the official example page as well, just to be sure it wasn't an old example.

Things may have changes since the sIFR method was introduced, but now most Windows based screen readers (i.e. not VoiceOver) are quite happy to read out the Flash. You get something like:

Flash movie start. Heading level 3, scalable Inman Flash Replacement. Flash movie end. Heading level 3, scalable Inman Flash Replacement.

Solution?

There are two broad ways around it:

  1. Hide the Flash content from screen readers.
  2. Hide the 'hidden' content from screen readers.

I did try (and succeed) in creating an example that hides the actual text from the screen reader, but that's probably the wrong way to go.

Given that there are still quite a few user-agents (e.g. VoiceOver) that don't cope with Flash, it would be better to leave the text as available as it is, and make the Flash inaccessible. I assume setting wmode to transparent would do that, wouldn't it?