Use High Contrast
AAPL493.42  chart+0.00
2012-02-10 16:00

Google Chrome for Mac Disregards Accessibility

1 June, 2010 @ 11:02 am by Lioncourt

Last week, Google released Chrome for Mac, its web browser product. Despite being built on the open source WebKit HTML rendering engine, which itself provides accessibility support for the Mac OS X platform with VoiceOver, Google’s final release provides no accessibility to web content whatsoever. Indeed, apart from menus and a handful of standard controls, Google has apparently not given any consideration to accessibility in Chrome.

In the past, Google has provided fairly good support for accessibility with screen readers, but that reputation has begun to slip in recent years, as the Internet giant has expanded its offerings and let its accessibility efforts slip.

The fact that the rendering engine Google is using offers native support for OS X accessibility, and Google either broke, disabled, or chose to remove that support, does not bode well for the future of accessibility in other Google products, where ensuring access will be inherently more difficult.

6 Responses to “Google Chrome for Mac Disregards Accessibility”

  1. Don Morris asserted:

    Since when has “accessible” come to mean “usable by the blind and deaf”? (Apologies to those I’ve left out, or if I’ve used a term that — today — is offensive.)

    When you say that “Google’s final release provides no accessibility to web content whatsoever”, one would think that Chrome can’t be used by anyone.

  2. Lioncourt mentioned:

    In the context of the article, I believe it is clear that “accessibility” is referring to access to persons with disabilities, which is an accepted usage of the term. In my opinion, the sentence you site would only be confusing to someone taking it entirely out of the context of our post, this web site, and the subject being discussed.

  3. pkasting articulated:

    I’m a developer on the Google Chrome team.

    I agree with you that accessibility is important. In fact, I don’t think you’d find anyone on the team who disagrees. When you say that Google “broke, disabled, or chose to remove” accessibility support, you’re not correct; the truth is more complicated.

    The Chromium codebase uses WebCore as its rendering engine. Unlike the current version of Safari, which is single-process, Chromium is a multi-process browser. In particular, the rendering processes, where the WebCore code actually runs, operate inside a sandbox with no access to the user. All communication is done via IPC to a browser process that asynchronously interacts with the user.

    In this model, support for a screen reader is not so simple as using the existing support in WebCore. The screen reader needs to interact with the browser process, which in turn needs to talk to the renderer process. Doing this in a secure, performant way that still makes both the browser and the screen reader work properly is a very difficult task.

    Someone is currently working on precisely this task, but we didn’t want to delay the release of milestone 5 for the Mac (or other OSes) until this was done. The relevant tracking bug, if you’d like to star it to receive updates, is at http://code.google.com/p/chromium/issues/detail?id=27112 .

  4. Jon articulated:

    I work in education and I completely understood the point of this article in regards to accessibility. When dealing with content online in education, especially the delivery of online courses, we need to be section 508 compliant. Since Google has decided to ignore accessibility, we certainly will not be recommending its use to our students.

  5. Lioncourt interjected:

    @pkasting:
    Thanks for taking the time to comment. I believe that, whatever the technical explanation, our description of the situation was still reasonably accurate. Google’s implementation of the browser breaks accessibility, which ever way you slice it. However it is justified, all end users see is a wholly inaccessible product at launch. I really hope that all you say is true, and that a fully accessible version of Chrome for Mac is in our near future, but I don’t believe Google is providing its developers, like yourself, with the proper resources to do accessibility correctly, or even well. The Android OS, for instance, has limited access, and that access is clumsy at best. I don’t blame the developers on the ground.

  6. pkasting articulated:

    I’m not sure what justification you have for saying that Google is not providing our team the proper resources to do accessibility. I speak only about the Chromium project, of course (Android is an entirely separate project), but there’s certainly no stinginess or resource shortage where we wish we had more support for accessibility and can’t get it.

    You are correct that users see a product that currently lacks screen reader support no matter what the explanation is, but to characterize this as somehow being due to us “not giving any consideration to” or “disregarding” accessibility is simply factually wrong, and I believe the main thrust of your article is an attempt to characterize trends and attitudes, not to report on the (obvious) fact that web content in Google Chrome is not currently accessible. So no, I would not agree that your description was “reasonably accurate”.

    If you’d like to have more points of view than just my own, you’re welcome to ask the development community anything you’d like about accessibility or any other topic. We’re an open-source project and have multiple different contact points (mailing lists, IRC channels, etc.) that you can find at http://chromium.org/ .

Post a Response

You must be logged in to post a comment.