E-mail List Archives
Re: insight about weird flash
From: Andrew Kirkpatrick
Date: Nov 30, 2009 7:05AM
- Next message: Al Sparber: "Re: insight about weird flash"
- Previous message: Tania: "Re: unexplained code changes"
- Next message in Thread: Al Sparber: "Re: insight about weird flash"
- Previous message in Thread: Chris Hoffman: "Re: insight about weird flash"
- View all messages in this Thread
Unfortunately there is no perfect solution for this yet. The problem is that Flash Player uses MSAA for the accessibility API, and MSAA requires a window id. So, if there is no window for the Flash Player (in the windowless modes, transparent and opaque) then we don't have a good way to pass the accessibility information through. There are some new ideas that we're investigating to address this since this issue is coming up more than ever.
In the meantime, I'm sure that developers can come up with more and better ideas than I can, but here's my take on a couple of common situations:
1) dynamic drop down menus that open up and need to cover other content when open. If the content that the menu needs to cover is Flash, then the WMODE needs to be opaque or transparent, but this is a problem for screen reader users. In this situation something needs to give.
a. If your menus are set up such that a click to the top menu item (the one in view when the menu is closed) takes the user to a page that contains the sub-menu links then you could take advantage of the Flash Player's ability to detect the presence of a MSAA client (e.g. a screen reader) and change the menus so that they don't open for that audience only.
b. Alternatively, you could load the page with WMODE=window only when an assistive technology user is using the site. You can't change wmode dynamically however, once there is no window you can't make it appear without reloading the page, so these options are easiest within a site where users are logged in and can provide preferences.
c. Authors could also provide a link to view the Flash content in a separate window, although this won't work for all types of Flash content.
In my opinion, I prefer to detect for AT users and reload the page, maintaining the data that the user is an AT user throughout their experience on a site.
2) JS-based dialogs - two options that I can think of off the cuff.
b. For more complex dialogs, again you can detect the AT user in Flash and then instead of creating the floating dialogs, just insert the content into the page in a logical location.
I do understand that these represent extra work and removing the "extra work" tax on accessibility to the greatest extent possible is desirable and will make more content accessible because it won't require as much of a resource investment. However, for now this is where WMODE is at. If anyone has other workarounds, let me know, I'm interested in hearing about them.
Senior Product Manager, Accessibility
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Chris Hoffman
Sent: Friday, November 27, 2009 11:53 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] insight about weird flash
On Mon, Nov 23, 2009 at 12:20 PM, Al Sparber < <EMAIL REMOVED> > wrote:
> From: "Andrew Kirkpatrick" < <EMAIL REMOVED> >
>> [summary: Setting the wmode of a Flash object to "window" will allow it to be detected by assistive technology, while setting it to
>> "transparent" or "opaque" will hide it from AT.]
> What then does someone do when needing to have positioned content appear on
> top of a Flash piece?
I'm curious about this too. I have run into a couple of instances
where positioned content (such as a modal dialog) has had Flash
content in the background show through, and have found/been told/read
on the Internet that setting the Flash object's wmode to "opaque" or
"transparent" would keep that from happening. But if that will make
the content inaccessible, what should we do?
Can we switch the wmode to "opaque" when the dialog is displayed, and
then reset it to "window" when the dialog is dismissed?