This page is targeted at 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: GoalsChrome should be accessible to all users, no matter what their access needs. While there are a number of different challenges, we believe the following key areas are the most important:
- Keyboard access: it should be possible to accomplish any action easily without using the mouse.
- Low-vision support: support high-contrast themes and large font sizes.
Assistive technology support: Chrome should work with the most popular Mac and Windows screen readers, magnifiers, voice control programs, and more.
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.
Glossary
- Assistive technology (AT) - Defined by the Assistive Technology Act as "any item, piece of equipment, or product system, whether acquired commercially, modified, or customized, that is used to increase, maintain, or improve the functional capabilities of individuals with disabilities." Assistive technologies include screen readers and magnifiers.
- Screen reader - Software application that attempts to identify and interpret what is being displayed on the screen. This interpretation is conveyed to the user with e.g. text-to-speech or a braille output. Screen readers are a form of AT potentially useful to people who are blind, visually impaired, or learning disabled, often in combination with other AT such as screen magnifiers. Screen readers that work with Chrome now are:
- JAWS - the most popular Windows screen reader. Commercial.
- System Access to Go - a web-centric Windows screen reader. Commercial but free of charge.
- NVDA - a free and open-source Windows screen reader.
- VoiceOver - Apple's screen reader that comes with Mac OS X 10.4 and up and has improved in every version including 10.7 Lion.
- MSAA - Short for Microsoft Active Accessibility, a COM-based technology for the Microsoft Windows platform, standard since Windows 98. This is the core interface for exchanging information between Windows desktop applications and ATs, such as screen readers/magnifiers and often by automated test tools to confirm the presence of certain UI features. Making a web browser fully accessible usually requires supporting not only MSAA but also several other COM interfaces.
- IAccessible2 - an accessibility API that complements the IAccessible COM interface defined in MSAA. Developed by the Linux Foundation, it has recently been adopted by all of the major Windows screenreaders.
- WAI-ARIA - Short for Web Accessibility Initiative - Accessible Rich Internet Applications. WAI-ARIA describes how to add semantics and other metadata to HTML content in order to make user interface controls and dynamic content more accessible. For example, with WAI-ARIA it is possible to identify a list of links as a navigation menu and to state whether it is expanded or collapsed.
- WebKit - the open-source HTML layout engine that Chrome uses. The WebKit project was founded by Apple for its Safari web browser, originally based on the rendering engine used in the Konqueror web browser on Linux. Chrome adopted WebKit later and is now a major contributor. WebKit parses HTML and provides the internal representation of the DOM, but the web browser actually visually renders this layout on the screen. WebKit provides low-level accessibility support, but the web browser must handle communication between the DOM and the AT.
- Virtual Buffer - a buffer used by Windows screen readers to cache the web page DOM for fast random access. With most applications, it's best for a screen reader to cache as little as possible. Every time there's an event, the screen reader queries the application for fresh information about the current focused control and its position within the window hierarchy. This handles dynamically updating applications great. This doesn't work well for web content, because documents are just too large, with too many nodes in the DOM to query dynamically each time. To solve this, screen readers load the whole document once, then use their virtual buffer to read the screen. As a result, it's critically important for the web browser to notify the screen reader any time the web content changes in any way, otherwise the screen reader will be reading stale data.
Accessibility Bug Tracking
We use Chromium's issue tracker to keep track of bugs and feature development. You can keep track of Accessibility issues using the following links:
Screen Reader Detection
Chromium uses screen reader detection in order to enable certain accessibility features.
Mac OS X: Chromium determines if VoiceOver is running by checking the voiceOverOnOffKey flag from com.apple.universalaccess.
Windows: We do not use the SPI_GETSCREENREADER flag from SystemParametersInfo - we've found it to be unreliable; many users have it on even though they have no screenreader running. In addition, many MSAA API calls are made by tools other than screenreaders, but enabling full accessibility support carries a performance hit and a few subtle UI changes that non-screenreader users do not want. Instead, Chromium tests for the presence of a screenreader by calling 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 a screen reader is running, because only screen readers would be interested in immediately using MSAA (AccessibleObjectFromEvent) to find out information about a new system alert.
Forcing accessibility mode: To force Chromium to turn on accessibility even though it may not detect the presence of a screen reader, execute it with the --force-renderer-accessibility command-line flag. This works on all platforms. Consider using this if you want to test Chromium's accessibility support using accessibility testing tools.
Technical Design Specification and Implementation Roadmap
UI Keyboard Navigation
Chrome toolbars are completely accessible: everything is focusable via the keyboard on Windows or via VoiceOver on Mac OS X.
Large/Extra Large Fonts (Windows)
Changing system Font size to be Large Fonts or Extra Large Fonts (Start Menu > Control Panel > Display, Appearance tab) will increase the font size of the Chrome UI (tabs, location bar, menus, dialogs) appropriately.
Full Page Zoom
Chrome supports Full Page Zoom, available under Chrome's Page Menu (with the document icon) > Zoom > Larger/Normal/Smaller. Standard keyboard shortcuts are also support by hitting CTRL + PLUS_KEY (+), CTRL + MINUS_KEY (-) and CTRL + 0 to zoom in, out and reset the zoom level to default, respectively.
Assistive Technology Support
The majority of this section focuses on the accessibility of Chrome's web content area. The rest of Chrome's UI, including the toolbars, menus, and dialog boxes, is already accessible using any modern screen reader. For more information, see Accessibility for Chromium Developers.
Chrome's accessibility architecture is quite a bit more complicated than some tools. While it is true that WebKit provides great low-level accessibility support, it is not quite so simple to make it work with various platform APIs for assistive technology.
Chrome is the first "true" multi-process web browser. For security, the main browser UI is in a process called the Browser process, and the web pages are actually running and rendering in separate processes called Renderer processes (typically one per tab, but processes are shared between pages from the same site, or more when too many tabs are opened). 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 invisible and don't interact directly with the operating system (sending or receiving events or messages). As a result, the renderer processes cannot send or receive accessibility events. Initially, we tried to have Chrome forward all messages between the browser and renderer processes, but this proved to be far too slow. Our current solution is described below.
Chrome uses a cache of the accessible DOM tree in the browser process. This only happens if a screenreader is detected (see above).
When the renderer accessibility flag is on, the browser requests a complete accessibility tree from the renderer every time a page finishes loading. Each node in the tree contains a reference to an unique ID in the renderer, allowing it to associate every node with the corresponding WebKit node. When AT requests accessibility information, the response is served directly from the browser's cached accessibility tree. When the renderer changes anything on the page, it notifies the browser, and the browser notifies the AT.
This has proved to be the most reliable and effective solution out of many others we've tried. While it's possible that the AT is occasionally accessing slightly stale information from the browser cache, as soon as the browser finds out that anything has changed, it can notify the AT directly, which triggers it to interrupt and describe the new correct state. Also note this is conceptually the same as how graphics are drawn - the renderer redraws the page, then sends the updated bitmap to the browser process. At the time it's displayed, it could very well be out of date. Code LocationThe accessibility implementation can be thought of as a series of layers on top of the WebKit render tree. In order:
WebCore accessibility: third_party/WebKit/Source/WebCore/accessibility/
WebKit chromium port accessibility: third_party/WebKit/Source/WebKit/chromium/public/WebAccessibilityObject.h
Glue code, to serialize WebAccessibilityObject. webkit/glue/webaccessibility.h
Renderer accessibility - builds serializable trees from WebAccessibilityObject and sends them to the browser process, and listens for browser messages from assistive technology to control the page (focus a node, scroll the page, etc.): content/renderer/renderer_accessibility.h
Browser accessibility - a node that corresponds to one node in the WebKit accessibility tree and implements the platform-specific accessibility API for that node: content/browser/accessibility/browser_accessibility.h
Browser accessibility manager - handles the tree of browser accessibility objects and manages communication with the renderer process for this tab: content/browser/accessibility/browser_accessibility_manager.h
Render widget host view - this is the class that web content accessibility latches onto. The windows implementation listens for a WM_GETOBJECT message and constructs the accessibility tree in response, and the Mac implementation hooks up its tree of NSAccessibility subclasses as children of the render widget host view. Testing Tools - Windows This section covers some of the (free) testing tools that are commonly used in developing for MSAA on the client side.
Note that you may want to start Chrome with the --force-renderer-accessibility flag if you use these tools, otherwise Chrome may not turn on accessibility features because it doesn't detect a screen reader.
AccProbe is a standalone, Eclipse Rich-Client Product (RCP) application that provides a view of the Microsoft Active Accessibility (MSAA) or IAccessible2 hierarchy of a currently running application or rendered document and of the properties of the accessible objects of that application or document. It can also serve as an event monitor for tracking the events fired by these accessible objects. It is meant to combine the functionality of tools like Microsoft's Inspect32, AccExplore, and AccEvent into one easy-to-use application for accessibility testing and debugging. http://accessibility.linuxfoundation.org/a11yweb/util/accprobe/
AViewer: A standalone tool from the Paciello Group. One of the easiest to use and includes many modern APIs, but not comprehensive enough.
|
