This is a short list of issues and bugs that I have come across when working towards accessible Flash sites. These are all focused on the Flash Player in the Browser. This is not complete and I hope that if you have come across an issue that you could leave a comment. I will keep adding to this list as I find more issues and will, happily remove items that are fixed. If there are any known workarounds please leave a comment. These issues prevent Flash from being as Accessible as it could be.
No tabbing between Flash and HTML elements:

This occurs in plug-in based browsers such as Firefox, Safari, Opera, etc. This is not an issue in Internet Explorer. This needs to be solved by the Browser manufactures.
Wmode settings can affect tabbing and keyboard access:
The use of wmode=”transparent” and wmode=”opaque” can interfere with keyboard interactions and prevent the user from tabbing into a SWF.
Wmode settings interfere with MSAA:

The use of wmode=”transparent” and wmode=”opaque” prevents Assitive Technology from receiving information from a SWF. This means that a SWF will essentially be hidden from a screen reader. This is a limitation of the windowless mode and MSAA.
MSAA does not work in Firefox:
This is relevant to all plug-in based browsers on Windows. This is now in public Beta on Adobe Labs.
Updates not sent to Assitive technology:

It is not yet possible to send an update to Assitive Technology like a screen reader. The updates will only happen when a button is clicked or when the return key is used. Once a page has loaded the content is stored in the virtual buffer. When the content changes it is not possible to force the virtual buffer to display the new content. This is a common problem and is not only in the Flash world but also with AJAX. This functionality needs to be introduces by AT vendors such as Freedom scientific and GW Micro.
35 ResponsesLeave a comment ?
[...] Niqui Merret has compiled a great list of Flash accessibility related issues on her blog. Some of these issues have clunky workarounds – like not using the wmode setting (I did say clunky) – so if you’re creating or using Flash content, be sure to check out this list to make sure you’re not unintentionally harming the accessibility of your project. [...]
[...] Accessibility and Flash expert Niqui Merret has compiled an Accessibility in Flash bug and issue list, detailing the current issues as she sees them in her work. Comments, suggestions for the list and workarounds to the listed items are solicited. [...]
First, thank you for compiling these. I’ve been buggered by them too, and didn’t think of making a public list. That’s silly me.
Re: wmode issues. It seems that the idea is that when a flasher does use wmode, they have a graphic approach to Flash. Thus they are assumed to not have made the accessibility effort needed. Thus it’s better to hide it entirely rather than insert this (most of the time) potentially blocking piece of content.
As for reading order with tabIndex: I’ve tried many times to make it cleanly, and have never gotten a good result (Flash 8 and 9, Flex 2, JAWS 6.2 and 7.1). I never get a reading order different from Flash’s default computed reading order.
I’ve rad all I could online, asked on several lists (some public like WebAIM, some internal to my company), and have never received a hint as to how to do it properly – or even been shown one Flash that works properly.
(maybe this is not the place to launch a discussion, let me know if it’s not the case, or feel free to edit my comment out, thanks)
Actually, I was told when I wrote the article, “Flash, DHTML and Accessibility, that the current implementation of wmode is not correct… and at that time, the thinking was that it would likely be fixed. That’s been a while now, without a change, so I have no idea what the current thinking is at Adobe.
The problem is, Flash basically sits “above” the browser page (for lack of a better explanation), so using transparent–or better yet, opaque–wmode is the only way to get DHTML elements to overlay a Flash movie. This is especially important with a javascripted menu system. But as you say, you then can not tab in and out. Fixing wmode would likely fix that issue, but I imagine it would then ruin the way many of us have been exploiting wmode to allow menus to drop over a Flash movie. I recommend to people that wmode should only be used when the Flash element is purely decorative and not a problem to skip.
It’s a conundrum…
some references to the Firefox and Flash accessibility in todays (06/08/2007)) archive of the Mozilla Dev Accessibility list see the thread here
[...] En el blog del Web Standards Project mencionan un artÃculo de Niqui Merret (en inglés), especialista en Accesibilidad y Flash donde trata de recopilar errores que se ha ido encontrando a la hora de desarrollar Flash accesible los cuales son provocados por el reproductor Flash del propio navegador. [...]
(Cross posted to WSP article)
The keyboard issues with Flash plugins are an old known bug in Firefox. As Mozilla’s accessibility module owner I’m embarrassed by it. Clearly it should be possible to make Flash content fully accessible in Firefox! I would call this our biggest section 508 issue — see our VPAT describing our accessibility compliance at http://www.mozilla.com/en-US/firefox/vpat-2.html
Mozilla hired a contractor to do the very complex work, but he stopped before finishing. Now it’s too late in the release cycle for Firefox 3 to get the fix, especially since there is still no one available and qualified to do the work.
Why is it complex? Because of cross platform issues with plugins. The plugin API has to be changed in a way friendly to 4 kinds of plugins, so that the both the browser and plugin can hand over keyboard navigation to the other. And, as Andrew said, work also needs to be done on the plugin side. In addition, Mozilla, Opera, Safari, Adobe and others need to agree on the API.
It was hard enough to get someone working on it, and then he disappeared without a word. Frustrating to say the least! I will push to get Mozilla Corporation to put someone on it after Firefox 3.
In the mean time if anyone knows someone with the time, inclination and Mozilla coding skills to do the work, feel free to contact me (aaronleventhal@moonset.net) about the issue. For more info and some initial code to deal with the issues you can visit the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=348279
Aaron Leventhal
Mozilla accessibility module owner
IBM accessibility architect
Niqui,
There are a couple of points that I\’d like to clarify on your list:
1) Using WMODE set to transparent or opaque does indeed hinder access. If the player is set to display in one of the “windowless” modes, the player is not displayed in an HWND; and if the player is not displayed in an HWND it can\’t send information via the Microsoft Active Accessibility API (MSAA) since MSAA requires an HWND.
2) You write that “It is not yet possible to send an update to Assistive Technology like a screen reader”. This isn\’t really accurate – updates to the MSAA tree can and do occur all the time. What I think you are commenting on is that the AT doesn\’t respond the way you want. There are substantial challenges for the AT vendors who need to decide on rules for how they select the type of informational changes that merit a reaction. This is only a concern in JAWS\’s “virtual PC cursor mode” or Window-Eyes “browse mode”, since in those modes the screen reader is interacting with an off-screen model of the Flash content and there is cost associated with every update of the MSAA tree. I do agree that the “live region” model is interesting and it has not escaped notice as potentially contributing to a solution to this concern.
Most issues that I see associated with the “AT updates” comment come from developers who say “how come I can\’t move the screen reader focus?”. The fact is that you can move the focus in forms mode, and AT chooses to not respond to the focus change in the other mode as a way to help their uses maintain control. Sometimes this works well for the AT user, other times it doesn\’t. The solution is to show examples of where it doesn\’t to us and to the AT vendors so we can work together to ensure that the interaction model improves. If you have examples, please send them along.
One of the annoyances for me is the patchy support for the main movie accessibilityProperties.name and description, they don’t get read in Jaws (however they used to, I’m not sure when/which version it changed).
Jaws encounters allot of slowdown when browsing Flash content. Flash content is usually highly animated, requiring a fair deal of processing power – when there’s movement on the screen Jaws can start to stutter, sometimes freezing completely.
One solution is to limit animation when MSAA is in use, however I don’t see this as very sustainable… the Accessibility.isActive() property is only true for when MSAA is in use (from what I’ve read: http://livedocs.adobe.com/flash/8/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00001895.html) – this limits us to specifying screen-reader only behaviour on Windows, and there is the danger that this behaviour will be triggered for those who might not require or want it: http://en.wikipedia.org/wiki/Microsoft_Active_Accessibility
(You can create hidden labels and objects that only a screen reader will read and be able to interact with, and optionally disable access to any other objects (which sometimes makes Flash easier to use with a screen reader than HTML!). That’s not what I’m getting at here though – behaviour, not content).
Along with ‘Flash does not take the high contrast settings on Windows’, there’s the lack of support for Windows DPI settings. I’m not sure if this is the same as text resizing in your browser which is also an issue (flexible layouts can be made easily enough).
@Stephane Deschamps
I’ve been quite successful with the reading order in the past. The only thought that comes to mind is to make sure that you have not assigned the same tabIndex to multiple objects as that can cause errors.
@Stephanie Sullivan
Funny how over the years it has turned into a feature
I am beginning to think that it may have been called a feature by the people who don’t like Flash and want to hide it.
@Aaron Leventhal
Thanks for sharing this with us. I think it has been a great help in understanding not only where the issue is but also to know that you are aware of it and working towards a solution. It sounds like you have had some bad luck and unfortunately the user is the one who losses out.
Thanks, Niqui.
If you see performance degradation affecting an external app, then make sure that framerate is set at a reasonable level. Lots of greedy developers crank it up as high as they can go, effectively asking the computer to refresh the screen scores and scores of times per second. Most machines can’t do that… particularly if you’re running lots of alpha blends simultaneously. They’ll try, though.
(Such excessive framerate demands are particularly egregious in banner ads. Complaining to the advertiser, to the ad network, and to the hosting site would have more of an effect for bad advertising choices.)
Disney animation showed at 24fps, two-up… effective framerate of 12 frames per second. Animation smoothness depends more on deformation, loss-of-detail, anticipation and other animation principles, than it does on asking all computers to try to play things at 100% cpu.
jd/adobe
This is an extremely useful and informed discussion and has helped clarify my understanding of the issues.
At the beginning Niqui in the section on ‘No tabbing …’ suggested that this is a problem with plug-in browsers but not with IE 7. I have looked at the IE 7 VPAT (see https://www.microsoft.com/industry/government/section508.mspx )and it seems to suggest that the problem exists. In fact the wording is nearly identical to the Firefox VPAT 2. Have I missed something?
Thanks to Aaron for the link to the Firefox 2 VPAT. Is there anyway of making this easier to find? I tried Googling and searching Firefox help but to no avail.
Niqui, how about adding the one about hyperlinked text within TextFields not being keyboard-accessible? One Adobe really need to address IMHO.
ooh and another one: The Accessibility Panel allows you to set accProps on stuff but then you can’t change them using said panel. If you insert a new keyframe and then modify the accProps in the panel, those changes are completely ignored. Once you’ve set accProps, the only way to change them is by using ActionScript.
I notice the issue with tabbing on some flash sites that display flash in full screen mode. But wouldn’t this be an easy fix using flash and javascript?
I don’t really know in detail but I’d assume that you could setup an event listener in flash to detect when a user clicks “Ctrl+T”, it’ll call a javascript function that switches to another tab.
[...] Flash and Accessibility [...]
@Thomas
It sounds like the “patchy support” that you refer to is a JAWS issue more than a Flash Player issue. I have not encountered it in my testing.
If you are building apps that require a large amount of the processor and are slowing down and/or crashing JAWS then I would suggest disabling some of the processes that are visual effects only when MSAA is active.
@Matt
Thanks for the TextFields issue. I have updated my list to add it in.
I have not encountered the Accessibility Panel issue that you described.
@Ptah
This can be fixed in JavaScript and there are people who are working on fixes but this really should be fixed at the root of the problem and not by workarounds.
[...] This isn’t a panacea for all Flash’s accessibility ills – the Flash Player is still lacking support for accessibility layers on other platforms, for example – but, when coupled with the ability to get video subtitles included in the H.264 feature, it is an encouraging step in the right direction for Adobe. [...]
@Matt and @Niqui
While I agree that a FlashPlayer-native way of adding keyboard access to hypertext links in dynamic TextFields is much needed and long-overdue, I thought I’d share the various ways I’ve developed to workaround the issue:
AS1: http://proto.layer51.com/d.aspx?f=1209
AS2: http://www.majordan.net/test/flashlinks/
AS3/Flex: http://www.majordan.net/test/inlinelinksapp/
Cheers,
Michael
The main challenge I have with Flash is that the reading order for screen readers is very linear. It would be extremely helpful if I could have different regions announced in my Flash movie, much the way headers are read in HTML. The workaround is to “hide” areas and “show” areas as the user interacts with the movie, but providing this is extremely tedious and requires a fair amount of Actionscript coding.
Another challenge I see is that JAWS has two methods for reading the Flash content: virtual mode and forms mode. It is difficult to know which mode is better to use for navigation in a flash movie. In virtual mode all of my dynamic text boxes are read, but in forms mode the dynamic text boxes are only read if they are tab-enabled. The problem with tab-enabling my text boxes is anyone who is not using a screen reader now has to tab through them to get to various buttons in my movie. How have others dealt with this?
@Kal Gieber
You could use Accessibility.isActive() (or in AS3 Accessibility.active) to determine whether items should be tab-enabled or not.
@Michael
Good point. I check for the presence of the screen reader with Accessibility.isActive() and then tab-enable the text boxes accordingly.
If you set the tab index of a dynamic text box in the accessibility panel, does that automatically tab-enable the text box?
Kal
Hi Niqui, thanks for this very useful article.
You mention that you can only send updates to ATs on click of a button or hitting the Return key, but I can’t seem to figure out how to do that even. Is it related to the undocumented Accessibility.sendEvent() method? I’m testing with JAWS 7.10 and AccExplorer 2.0 and neither update when I call sendEvent() or updateProperties(). However, a manual refresh of the AT picks up changes in my SWF. I’ve thought for a while that this was impossible, but can I be wrong? (Please prove me wrong!)
With updateProperties(); you should get the refreshed results. I think you might be doing something wrong.
You mentioned that on click of a button also, you are unable to get the results.
I hope you followed these steps.
on(press)
{
one_btn._accProps=new Object();
one_btn._accProps.name=”Accessible Name Changed”;
Accessibility.updateProperties(); // Now the above changed property will take effect
}
Now check if the name has been changed or not by pressing ctrl+F5(with Jaws on), You should get the updated name.
Have a look at best practices for flash at: http://www.adobe.com/resources/accessibility/best_practices/best_practices_acc_flash.pdf
Believe me its not hard to make flash accessible. Patience is the key, keep testing..
@Kal Gieber
According to you, “in forms mode the dynamic text boxes are only read if they are tab-enabled”
My observation is dynamic text boxes are not read out anyways when in forms mode. Also, when Screen reader is not on, tab dosn’t go to the dynamic text fields even if we have tab enabled them.
Gurus, is my observation right?
Kal, if the movie is full of components then it’s good to navigate in forms mode. But if movie has more text then i think one should go with the virtual mode.
Vivek
Flash Accessibility Developer
@Lego Joe
Sorry can’t give you any good news on that one. The updates that I am referring to is a refresh of the virtual buffer in screen readers and the equivalent in other AT. Currently there is no way to force that refresh.
@Vivek Gaikwad
Thank you for your comment. Could you please give a link to a working example of updating the virtual buffer from Flash. I think you are misunderstanding what the actual issue is. The short cut that you are using is a manual refresh of the virtual buffer and is fine in a testing environment but we really don’t want to have to make our users do the refresh themselves. We need to be able to send through the updates when the content changes. I have an example of the issue as a part of my test cases. MSAA properties update test case. You will note that once the movie has finished playing then the SWF will move to the next screen and display new text. The virtual buffer will not update and the screen reader will not get the correct information.
Niqui, had a look at the link provided by you. The only thing flash(or JAWS) don’t do is, it doesn’t inform the user that the screen(or content) is changed. But JAWS gets the updated text, if i move my arrow keys to get the information, i get the updated text.
Also, are you loading a new SWF? or only the text is changing in the same SWF?
Vivek
Flash Accessibility Developer
[...] Accessibility and Flash expert Niqui Merret has compiled an Accessibility in Flash bug and issue list, detailing the current issues as she sees them in her work. Comments, suggestions for the list and workarounds to the listed items are solicited. [...]
The virtual buffer is not being refreshed from Flash (inform the user that the content has changed). This is a bug and should be fixed. Anything we do to update the virtual buffer is a work around/hack. The point of this article was to highlight the areas where either Adobe or AT vendors could improve accessibility in Flash.
Hello Niqui,
What if we want to give alt (screen reader should read it) to an SWF file embedded in HTML?
When I give accessible name to the entire flash movie, and publish it as HTML, I expect screen reader to pick this name as an alt for the SWF, which doesn’t happen. I’ve tested this with JAWS 7. Also, tried with JAWS 9 release. It doesn’t work.
If I check this with inspect 32, it shows perfect results, it identifies the flash movie and shows the name provided for the movie as an alt. Initial thought was it might be a bug in JAWS 7 and will get solved in future release as Andrew said. But, JAWS 9 too showing the same results. Have you encountered this anytime?
peace, veiky
Hello Niqui,
I’m glad I stumbled upon your blog, looks like a fantastic resource! I am a web developer (HTML/CSS/JS) for an interactive marketing agency that is mad about flash. Most of our flash developers/designers are in the dark about accessibility, so I am trying to ramp up on flash/flex and in particular the accessibility considerations so that I can inform them on such.
I’m actually working on a paper for school on accessibility in RIAs, and I’m at a point in my research where I have more questions than answers. One thing I was wondering about, and maybe you can offer some insight: WAI-ARIA mentions using live regions to make AJAX applications accessible. (AJAX live regions allows text to be spoken without giving it focus. This is good in that it means that users can be informed of multiple updates without losing their place within the content.)
My other stumbling point is at which point this would need to be supported… obviously, the flash player would need to understand these roles/states, but is that enough, or would the browser also need to be aware of it? That is.. would flash on FF be “more” accessible than on IE? Or is WAI-ARIA really a browser thing, not a flash thing?
Any thoughts you have would really be appreciated.. I think I will probably post this same list of questions/stream of consciousness on my own blog, in hopes of garnering some feedback!
~Andrea
[...] Trying to figure out the scope for my capstone, I’ve done some reading on WAI-ARIA, which seems to focus on helping making AJAXy-applications accessible via roles and states. However, we really work more with flash and flex at work, and I want to figure out how to push accessibility via those mediums as well. I came across a great resource at niquimerret.com, a girl geek who is passionate about both Flash and Accessibility. Perfect! I read a post she’d made on accessibility “bugs” in flash, and left her a long rambling comment on some of my questions about flash and accessibility. I figured I may as well leave it here as well in the hopes of garnering some additional responses… [...]
[...] How do I get rid of this annoying border? I want the flash movie to just start going when it is loaded, without me clicking on the movie first. Can someone please help me with the html code Answer: There are several approaches to this problem the old way was to use <embed>. This approach has been deprecated and should no longer be used. You are on the right track with the object tag. Here is an article with different methods compared and contrasted. http://alistapart.com/articles/flashembe…; I find that I like the UFO best. When using Flash there are other concerns you should be aware of. http://niquimerret.com/?p=94 Answer: i think the version u r using of IE not suppoted this coding,because this coding is well displayed in firefox Answer: I think that is normal when using IE browser. Answer: Because your IE don`t support "object".You can copy the code into Dreamweaver.Dr will prompt you to convert "object" to a new label that your IE support. [...]
I’ve noticed that if you have one of Flash’s User Interface components, such as the combo box or alert, in your Flash project you are not able to tab to objects inside other movie clips. This occurs even if the component resides in your library and not on the stage. It has something to do with the Focus Manager for the components. I’m still using Flash 8, so I don’t know if this has been fixed in CS3.
[...] For more information about the limitations of Flash Player’s Accessibility features, see Niqui Merret’s blog post from last year, Accessibility in Flash bug and issue list. For information related to web accessibility and laws in various jurisdictions around the world, see Policies Relating to Web Accessibility. In time, accessibility laws will become stronger, and it’s important that Flash Player provides better support early so that developers can prepare. Posted by Josh Tynjala on May 5, 2008 [...]