Strange sIFR / screen-reader bug

Posted in Accessibility, Front-end code, PDF / Flash.

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:

  • Firefox 3 with zoom, and regular text-size changes.
  • Safari 3 with text-size changes.
  • IE 6 & 7.
  • Opera 9.5.
  • JAWs with IE7.
  • Windows Eyes with IE7.
  • VoiceOver 2.0 with Safari.

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?

8 contributions to “Strange sIFR / screen-reader bug”

  2. I’ll have a go tomorrow, but please bear in mind, some (including the Mac one) don’t support flash at all, so it would be better to hide the Flash…

  3. Setting wmode transparent would indeed stop screen readers from accessing the Flash content, however you would also want to turn off accessibility of the Flash itself in case screen readers were able to get around that particular wmode bug in the future.

    I believe sIFR wraps the original content with the Flash tag, this could potentially cause problems for screen readers, especially if wmode transparent is being used. A more robust solution might be to place the tag before the content, then make that content transparent while overlaying it over the Flash, maintining the clickability of links and selection of text (some of the more usability orientated problems!)

  4. Hi Mark, I get the same results for the two I have to hand:

    • Jaws reads the headings in the Flash, and the regular replaced heading.
    • VoiceOver doesn’t see the Flash at all.

    Does Tom’s suggest have legs?

  5. Disabling Flash accessibility may be a nice trick, if it forces the screen readers to read the alternate HTML content.

    Tom, sIFR puts the original content in an element after the Flash movie. This element is then made 0x0 px and positioned at the top left of the screen.

  6. The consistent thing is that the screen readers do read the HTML, it’s the Flash that isn’t consistent, so the best to hide.

  7. I see, in that case it shouldn’t take much work to reposition the original content over the Flash.

    Besides screen reader access, another accessibility issue is with links, when using a keyboard there is no way of seeing your focus (as the content is out of sight). It might be possible using JavaScript to show the hover state in Flash when the link gets focus.

Comments are closed.