I saw a blog entry today about how to use wmode for z-ordering Flash in your HTML that reminded me about a topic I’ve been wanting to bring up. With Flash 8’s ability to use transparent and opaque on a much broader set of browsers, some of the issues with how wmode work are going to become more serious.

There are three major problems with wmode IMHO:

Speed
There is no big surprise here, but when you force Flash to composite the HTML layers above and below, you are adding additional processor load. The main reason I bring this up is that a lot of folks are starting to use wmode=opaque even when it is not needed. If you have gone to the trouble of optimizing your application, why would you slow it back down a bit without really strong need?

Accessibility
In talking with Yahoo!’s accessibility product manager, I’ve discovered a LOT of interesting quirks of the Flash player. By far, the most interesting of which is that use of wmode makes your movie invisible to screen readers. This seems to actually be a well-documented issue in the accessibility world. What amazes me is that it is considered a FEATURE!

After attending an internal presentation on Flash and accessibility, I really see what an important role there is to be played, and what an amazing opportunity there is for Flash developers in accessibility. The person giving the presentation is blind, and the opportunity to hear Flash through a screen reader was really amazing. Without thinking about accessibility, Flash movies are really horrible. With just a little thought, and use of the accessibility object (which is a huge asset for Flash), you can really make something fantastic. But since this is an entry about wmode, I will save this particular soapbox for another day.

At this point as major chunks of sites are moving to Flash, it is important that your applications are visible to people using screen readers. Perhaps a solution to this is to detect when a screen reader is in use then use the external interface to call a function that re-instantiates the flash movie with a default wmode. It seems reasonable to say that if a screen reader is in use that the z-ordering compositing isn’t as important. Anyone want to write a library for that?

Inconsistent Performance
SWFs using wmode actually perform slightly different from SWFs that have a default wmode. The difference is that when you are running as transparent or opaque, events are delayed until an onEnterFrame. If you are running at a slow frame rate and drive your movie with setInterval or use any number of other events, you are back to your slow frame rate. If you would like to see an example of the difference in the way it runs, take a look here (must use IE). The real kicker is that SWFs in IE have this bug. SWFs in Firefox are just fine.

While this does irk me just because one of the best things about Flash is its cross-everything consistency, It has caused a problem for a specific application I’ve worked on. At one point I needed to instantiate a lot of SWFs in HTML. Each instance running at its own framerate starts to bog down the machine at some point just from the processing power it takes to idle a lot of transparent 12 FPS SWFs. My proposed work around was to make the SWFs run at 1FPS or less, and then drive the file with setInterval. This would allow me animate the files at the appropriate frame rate when needed, but otherwise idle at a super low framerate. This works fantastically with a default wmode. With a transparent SWF, the Interval only fired once per second right along with the onEnterFrame.