Developer Beware: Using Flash to Detect Screen Readers

Posted on Monday, 28 April 2008 by Steve Faulkner

The facility to detect some Assistive Technology by using Flash has been around since ActionScript 1.0 and Flash Player 6. The method has usually been referred to as a way to ‘detect screen readers’. Unfortunately this method, using the ActionScript Accessibility.isActive method, is not a ‘screen reader’ detector.

The Accessibility.isActive method documentation is quite clear on this

Indicates whether an accessibility aid is currently active and the player is communicating with it. Use this method when you want your application to behave differently in the presence of a screen reader or other accessibility aid.

What it actually detects is the presence of software that is accessing accessible information via the Microsoft Active Accessibility (MSAA) API. Assistive Technology that makes use of MSAA includes, but is not limited to, JAWS and Window Eyes screen readers, Zoomtext and Magic magnifiers and Dragon Naturally Speaking text to speech software.

There is currently no method available to detect what type of software is being used, only that it makes use of MSAA. It is obvious that alternative content, which may be appropriate for screen reader users could reduce the accessibility for magnifier or text to speech software users, who have different content view and interaction requirements.

Furthermore, this method works on Internet Explorer and Firefox under Windows, but any Assistive Technology that is not being used on Windows or not using MSAA, or the user is browsing with browsers other than IE and Firefox, will not be detected.

Problematic use – an example:

A recent use of “screen reader” detection that I encountered illustrates the dangers and limitations of this method: A Flash based interactive video makes use of “screen reader” detection to provide an alternative interface and content to screen reader users. The regular version includes an audio track, whereas the “screen reader” version removes the audio track and replaces it with a hidden text stream. If a screen reader is detected, the user is presented with a message informing them that if they want to use the version with audio, they need to close the current page, turn off their assistive technology and re-open the page. This means that users must turn off the software they require to access the page in the first place.

Andrew Kirkpatrick on the use of Accessibility.isActive

I talked with Andrew Kirkpatrick, Senior Product Manager, Accessibility for Adobe Systems about the use of this method, here is what he had to say:

“It is accurate to say that a Flash application can detect when an MSAA-using screen reader is running, but the Flash application won’t know if the isActive flag is set by a screen reader or other assistive technology or even by an MSAA testing tool. Developers may still make effective use of the ability to detect potential screen reader use and to offer choices to users. Adobe’s goal is to provide developers the ability to author one version of an application that works for all users rather than resorting to specialized experiences for separate audiences.”

So, while isactive has the potential to be useful in providing choices to users, it must be used with caution. Don’t make assumptions about users based on the isactive flag. Provide extra options, but do not remove options, which can force users to jump through hoops to avoid an inferior experience.

Related Reading

Thanks to Gez Lemon and Andrew Kirkpatrick, for their advice and input.


About Steve Faulkner

Steven is the Senior Web Accessibility Consultant and Technical Director, TPG Europe. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C HTML Working Group and the W3C Protocols and Formats Working Group. He is an editor of several specifications at the W3C including HTML 5.1, Using WAI-ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains www.HTML5accessibility.com

Comments

  1. That’s rather an odd way to look at things. On Windows, for particular browsers, may be a bit short sighted, too.
    What happens when “UI Automation” takes hold? Will MSAA implementation constructs have to be rewritten? Probably.
    Detecting assistive technology and offering different content for that technology, always sounds like double the effort. This is rarely sustainable or sustained.
    More effort should be directed toward doing it once and doing it well. Flash can be coded so it is more accessible as long as all the rights bits are in place.
    It would be much better if authors concentrated their efforts on making their output more accessible inherently than trying to detect if an essential user agent (some people don’t like it when I call JAWS a user agent) is running.
    As with anything related to accessibility, making something more accessible to people with disabilities will improve the user experience for the majority of the users.

    I like Flash, really. I think it is a dynamic, interactive, useful technology. It can greatly enhance the user experience for some people with differing abilities, especially in a learning environment.
    Sadly, I see the way it is being used today and I’m reminded of the days of that new internet thingy in the late 1990′s.
    Anyone remember “Hamster Dance”? Now available in Flash!

  2. That’s true – it is not a safe way of detecting screeen readers – but on the other hand it is all we got to detect *any* assistive technnology. So instead of making assumptions and cater a *different* experience to “screen readers” this can be used to stop progressive enhancement as we know when Accessibility.isActive that we are in unknown or more complex territory.

    An example would be an Ajax app not updating parts of the application when we know assistive technology is in use but reload the whole view instead. Thus we don’t need to hack around with hidden form element updating or asking the user to refresh by hand. We need to try to automate as much of the process as possible, as far too many customers do not want to spend extra time and effort on creating an accessible fallback but would be OK to have a progressively enhanced interface, as that is a one-off payment.

  3. I’m using this method in Falsh-based projects as a means to provide additional functionalities in Flash/Flex.

    For instance, the Datagrid component in Flex is technically accessible, in the sense of “I can read it with a screen reader”, but very inconvenient in real life, as has been reported by the blind people I work with (using Jaws 8+ on Windows).

    So we detect if MSAA is triggered and then provide an additional “see this in HTML format” button so as to give MSAA-enabled users a way to have a plain old, easily-used HTML table in lieu of Datagrid if they need a cell-by-cell reading granularity that the Datagrid does not really fulfill well.

Comments are closed.

Recent Posts

See all posts in the blog archive

Sarah Horton’s approach fit into the style of the organization so well…kudos to TPG for having UX in the mix in such a valuable way.

Becky Reed, Sr. Director User Experience, Healthwise