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.
a. For simple dialogs/popups, when an AT user is on the site, use the standard JavaScript dialog windows instead.
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.
Thanks,
AWK
Andrew Kirkpatrick
Senior Product Manager, Accessibility
Adobe Systems
<EMAIL REMOVED>
- 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