This page is targeted at Chrome developers, third-party assistive technology developers, and highly-technical users. For general information about Chrome accessibility, see the following user experience documents:
If you're a Chrome developer and you just want to make sure your feature is accessible without learning all about the gory details, see:
For information about how accessibility code is tested, including how to write new tests or debug test failures, see:
Chrome should be accessible to all users, including those with special access needs. While there are a number of different challenges, we believe the following key areas are the most important:
Improving accessibility support often helps not only users with disabilities, but also for power users. Whenever possible, we prefer to design Chrome so that everyone can share the same accessible interface, rather than special modes for accessibility.
Volunteers with an interest in improving accessibility are welcome (both for testing and development). Please join the chromium-accessibility list for further information.
For performance reasons Chromium waits until it detects the presence of assistive technology before enabling full support for accessibility APIs.
Windows: Chrome calls NotifyWinEvent with EVENT_SYSTEM_ALERT and the custom object id of 1. If it subsequently receives a WM_GETOBJECT call for that custom object id, it assumes that assistive technology is running.
Mac OS X: Chromium turns on or off accessibility support based on whether it sees a client, such as VoiceOver, has set the AXEnhancedUserInterface attribute on the main application window.
Traditionally, assistive technology on Windows used the window class name as a way to identify a known browser and adapt accordingly. However, this means assistive technology needs to be updated whenever Chrome needs to change its window class name, and it also means that other Chrome-based browsers wouldn't be detected.
If you must use the window class name, please accept any class name that begins with "Chrome", rather than detecting the current window class name.
As a more robust alternative, Chrome 28 and higher supports IAccessibleApplication, and it returns strings of this form:
Note that there are other Chrome-based browsers. Any Chrome-based browser will have "Chrome" as its toolkitName, so ideally you should use the toolkit name as the way to enable custom support for Chrome accessibility.
The applicationVersion and toolkitVersion are the browser user agent, the same one sent to web servers with each web request. That's a way to get more information about the exact Chrome version dynamically.
Chrome's multi-process architecture is different from that of any other browser. For security, the main browser UI is in one process, and web pages are run in separate renderer processes (typically one per tab). The Renderer processes are the only ones with a representation of the webpage's DOM and therefore all of the accessibility information, but the renderer processes are specifically not allowed to interact with the operating system (sending or receiving events or messages) - in particular, the renderer processes cannot send or receive accessibility events.
As a result, Chrome uses a cache of the accessible DOM tree in the browser process. For performance reasons, this only happens if assistive technology is detected or if it's explicitly enabled (see above).
Chrome has a built-in page you can access to view accessibility internals and toggle accessibility support on or off on a per-tab basis. Just visit this url:
On Windows, we recommend testing with a combination of AccProbe and AViewer (they each have their strengths). To use AccProbe, you may need to have a JRE 6 installation and pass it as a command-line option: (e.g., accprobe.exe -vm "C:\jre6\bin\javaw.exe") and disable Java auto-updates (http://www.java.com/en/download/help/javacpl.xml) which will trash your JRE 6 installation.
On Mac, we recommend testing with Accessibility Inspector.