Google Chrome Frame – accessibility black hole

Posted on Wednesday, 23 September 2009 by Steve Faulkner

See update 07/2012: Google Chrome accessibility update

Google have released Chrome Frame a plugin-in for Internet Explorer “that seamlessly brings Google Chrome’s open web technologies and speedy JavaScript engine to Internet Explorer.” What it also does is seamlessly bring Google Chrome’s lack of support for assistive technologies to Internet Explorer.


If a page is viewed through Google Chrome Frame in Internet Explorer no content is available to the user of assistive technology (AT). This can be illustrated using the Microsofts accexplorer tool:

An example page viewed without Google chrome frame:
When not using Google Chrome Frame, all of the content is available in Internet Explorer to assistive technology via the MSAA Accessibility API.
view of the accessible content tree displayed using accexplorer when a page is viwed in internet explorer. All of the content is available.

The same example page viewed using the Google Chrome Frame plug-in:

No content is available to assistive technologies via the MSAA accessibility API. Effectively the whole page becomes invisible to users of AT.

view of the accessible content tree displayed using accexplorer when a page is viwed in internet explorer using Google chrome frame. None of the content is available.

Why would a user of AT install Google Chrome Frame?

Like other people it is presumed users of AT want the opportunity to take advantage of the latest technologies and powerful new features Google Chrome provides, and may want to install the plug-in if they are prompted to do so to access site content.

What does the lack of support for AT in Google Chrome Frame mean?

Users of AT are locked out of taking adavantage of “Google Chrome’s open web technologies and speedy JavaScript engine” until Google makes its Google Chrome Browser and Google Chrome Frame plug-in fully support assistive technology.

Further Reading

Google Chrome 2.0 Accessibility Improvements?


About Steve Faulkner

Steve 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 HTML5accessibility

Comments

  1. Any idea how hard this is for Google to correct? Flash is a plugin and I believe it’s capable of passing info to MSAA. And Webkit browsers must pass the MSAA info. So I guess this is an oversight that can be fixed?

  2. According to Adobe who use Webkit for Air apps, it’s not accessible when in Air either because of Webkit. However, it is on the radar, and when it updates I would assume that Google *could* provide that information.

  3. Hi Grant, I hope it is, support for AT in Google Chrome has been on thier ‘to-do list’ since the beta release, Google Chrome is now on version 3, how long to users of AT have to wait to enjoy the benefits?

  4. Hi Alastair, webkit are working on their support for exposing information to accessbility APIs on windows, just as Google have been working on the same for Chrome. They have been working on these issues, problem is that it does not appear to be a priority. Google have been aware of the accessibility deficiencies in Chrome since it was in beta, now its up to version 3 and there is still not practical improvement for users of AT or users that require high contrast modes.

  5. Hi Rob, Webkit based browsers currently have limited support for exposing MSAA information. Google are working on support, but assistive technology users should not hold their breath, unless Google decide to make support for assistive technolgies and accessibility in general a priority goal for Chrome development.

  6. Great post Steve, however I fear the usual tactic of saying “It’s inaccessible! Don’t use it!” may not work this time… the benefits provided to web developers by Chrome Frame will probably be too great to ignore.

    For example, my colleagues and I usually spend 50% of our time on any given project making it work in IE. Fixing that is a big, big (very big) deal.

    Google need to get their act together and make Chrome accessible. Until they do so, is there any reason we can’t assume users of AT will be savvy enough not to install the plugin? Especially if we provide a warning that installing it may adversely affect AT?

  7. Hi Ben, I am not saying “It’s inaccessible! Don’t use it!” to developers. I am suggesting:

    • It’s a reason for users of AT not to use chrome frame if they use IE, as it does not work for them, same as Google Chrome itself .
    • It’s a reason for developers to warn users that installing chrome frame will have bad effects on some pages and provide no positive effects if they use AT.
    • It’s a reason for users of AT to use Firefox if they can.
    • It’s a reason for Google to get off their collective arses and use their substantial resources to make providing assistive technology support in Google Chrome and chrome frame a priority rather than a “nice to have” somewhere down the line…

Comments for this post are closed.

Amazing. You accomplished in a matter of months what we were not able to do in years with teams of people. We now are on the way to having a fully usable interface for all our clients, regardless of their ability.

Gary Moulton, Accessibility Program Manager, Yahoo!