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.
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:
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.