Flash and keyboard access across browsers

A question I’m frequently asked by developers is why keyboard access for the Flash is not fully supported across browsers. Opera, Safari, Firefox and Chrome all have problems enabling keyboard users to tab into and out of Flash content while Internet Explorer works fine.

The issue

Plugin support typically needs an API that acts as a doorway connecting the plugin, browser and user. IE gets round this by using ActiveX – itself a closed propitiatory format – so users can tab into and out of the Flash. Of course keyboard access within the Flash content itself is handled by Adobe and is now considered to be keyboard accessible. So it’s really support for entering and leaving the plug-in with keyboard that is the issue.

The browser fix

Ideally there needs to be a standardized API that can be used across industry to enable plugin support across browsers. The most common  API is Netscape Plugin Application Programming Interface (NPAPA). First developed for Netscape it has subsequently been implemented in other browsers including Opera, Safari, Firefox, Konqueror, Google Chrome, and some versions of Microsoft Internet Explorer.

The kind of access NPAPI supports includes scripting, printing, full screen plugins, windowless plugins and content streaming but is not as powerful as ActiveX, and is still evolving – in particular tabbing into and out of the Flash movie.

Help is at hand however.

There is currently a proposal to solve the issue of Flash support being lead by Mozilla, Adobe, Opera, Apple, IBM and Sun which has now been accepted. Implementation will depend on collaboration between all stakeholders including plugin vendors and of course Adobe.

Aside from the the plugin API solution is there an alternative quick fix for Flash support in Opera?

There have been some discussions internally but it seems there is no quick fix that will completely, and satisfactorily, address the issue. There are two ways that NPAPI plugins can work. The first (default) is called “windowed”. This is essentially an OS window rendered on top of the browser. Keyboard input is therefore direct and not via the browser.

There are a couple of drawbacks with “windowed” however. Firstly it can pose security issues. Secondly it’s not a complete keyboard access solution because while getting focus into the plugin is possible getting focus out is not. This is key and really negates the point of being able to tab into the Flash Player because as a keyboard only user you’ll only get stuck there.

The second mode is called “windowless”, where the browser controls more of the plugin rendering. Here keyboard input goes via the browser (possibly depending on OS) and in turn is intercepted. The drawback with this solution is that real world support is limited as most plugins do not support this mode, and for those who do it’s not that widely used due to performance issues.

By far the best and most secure solution is standardising the NPAPI API so that it works across browsers with all plugins. Better not just for Opera but the web in general.

In terms of a solution for Opera it seems the fixes available now fall far short of what we would want to give our users. The good news however is that to implement support once the plugin API is ready should be fairly straight forward.

The developer fix

So where does this leave you as a developer, and more importantly your users? There is a hack you can use to give Flash keyboard access using a method in your Flash movie to focus a chosen element. You can then create a text link that calls this method to “skip into Flash”. This isn’t something I’ve tried and tested and I’d be interested to hear comments from anyone who has.

Update –  As Andrew Kirkpatrick points out there is another way to give Flash focus using the SWFFocus class. While the technique showcased discusses this in the context of Firefox I did a quick test in Opera 10 Beta and Safari 4 but had no luck accessing the content.

But I suppose the real question is why hack what you can already do using existing technologies supported across all browsers? Don’t get me wrong, I like Flash and have two thumbs up at Adobe for the work they have done to make it accessible, but if I’m building a site using Flash and knowingly locking out all non-IE users then I can’t use it.

As Christian Heilmann points out much of what Flash does can be done with existing technologies supported in the browser:

Using the DOM and JavaScript I can create HTML elements that work with all kind of assistive technology. Instead of hoping that keyboard users can access my Flash content I use what browsers already have – links, buttons and form fields – to interact with the it.

WAI-ARIA is also a core way to build screen reader accessible and tabbable web apps and widgets. Added to this the HTML5 <video> element will soon give us native support for video across browsers; something that Flash is used for extensively today.

So there are ways and means now to avoid the keyboard trap that Flash content poses for keyboard only users plus there is work to provide a universal solution in the form of the proposed plugin API. But for now I’d personally always opt for the standards based cross browser solution so as to ensure happy users and avoid additional work and hacks.

8 thoughts on “Flash and keyboard access across browsers

  1. Thanks for that Andrew, I’ve updated the post. From my quick test it looks like it works in Opera and Safari too. Do you know when there will be movement on the cross browser plug in solution for keyboard access in Flash by any chance?

  2. Pingback: flash | Happypixel

  3. Pingback: fernmuendlich (Maik Wagner)

  4. Pingback: ScreenOrigami (Sandra Kallmeyer)

  5. While testing Flash-based eLearning courses using Voice Recognition software, the issue we encountered was getting initial focus into the Flash object. We added “tabindex” and “seamlesstabbing” param nodes to the HTML object embed code, which allowed Firefox to assign focus to the Flash object instead of skipping over it. Your post led us down the road to this solution. Thanks!

  6. Pingback: Dickinson Disney: not down with the kids » iheni :: making the web worldwide

  7. The biggest problem with keyboard access into Flash objects is that it is necessary to click onto the object with the mouse first, before it can be accessed with the keyboard. Once the object is clicked with the mouse then keyboard access usually works fine (assuming the Flash object itself is accessible of course). Remember the “click to activate” tooltips in Internet Explorer (back in 2006-2007)?

    As far as I know the whole problem has a completely different reason: Legal battles over patent infringements. The small company Eolas claimed to have the patent on interactive web content and sued pretty much every large technology company or web content provider for silly amounts of money (see e.g. http://en.wikipedia.org/wiki/Eolas). Microsoft initially came up with the “click to activate” workaround (implemented in 2006 – see “Effects on other browsers” in above Wikipedia article) and other browsers followed with similar workarounds. Microsoft did eventually agree a settlement with Eolas and then were able to remove the requirement for the mouse click from Internet Explorer. That’s the reason keyboard access in IE is seamless since then. Other browser manufacturers refused to pay Eolas so couldn’t implement a similar fix so far.
    Good news though: Earlier this year Eolas lost a court case where these patents were declared invalid (see http://www.thestar.com/business/article/1128920–eolas-patent-trial-relax-the-internet-is-saved). I’m not sure if Eolas have appealed but if this court ruling is confirmed then hopefully this requirement for mouse clicks can finally be removed by all the remaining browser manufacturers!

    FYI: There is a “hack” for older versions of Opera to remove the requirement for the mouse click, but I don’t think it works with recent versions of Opera: See http://my.opera.com/XAntares/blog/xanocta for full details on this.

Comments are closed.