The Chromium Projects
 
Search this site

Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license, and examples are licensed under the BSD License.

The Chromium OS designs and code are preliminary. Expect them to evolve.
For Developers‎ > ‎Design Documents‎ > ‎

Accessibility

A

Contents

  1. 1 Definitions of terms
  2. 2 Design and Implementation Roadmap
    1. 2.1 UI Keyboard Navigation
      1. 2.1.1 Chrome toolbar
      2. 2.1.2 Keyboard shortcuts
    2. 2.2 Display Options
      1. 2.2.1 Large/Extra Large Fonts (Windows)
      2. 2.2.2 Full Page Zoom
    3. 2.3 Assistive Technology Support
      1. 2.3.1 Implementation Roadmap - Windows
      2. 2.3.2 Synchronous IPC for Accessibility
      3. 2.3.3 Focus events
  3. 3 WAI-ARIA Support
    1. 3.1 WAI-ARIA Roles
    2. 3.2 aria-labelledby and aria-describedby
  4. 4 Current Issues
    1. 4.1 Unclaimed
    2. 4.2 Ongoing
  5. 5 Testing Tools - Windows
    1. 5.1 Installation
    2. 5.2 Inspect
    3. 5.3 Event Watcher
Browser support for accessibility is an area where any application will benefit of getting the basics right from the start are huge, especially for those users that rely upon them for any access whatsoever. However, there are also benefits to be had for our power users (for instance, in terms of quick keyboard navigation), and a more easily navigable UI, in general.

This is an ongoing documentation of the outstanding accessibility issues and improvements, and suggestions and outlines of solutions where appropriate. The document is also a good tracking source for design decisions, and the reasoning and roadmap that lead to the current state-of-affairs. As accessibility progresses in Chrome and WebKit, this document will be subject to frequent changes and updates.

Volunteers with an interest in improving any of the listed issues are always much needed. Please contact Jonas Klink (klink@chromium.org) for further information.











Definitions of terms

  • 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.
  • MSAA - Short for Microsoft Active Accessibility. It is a COM-based technology for Microsoft Windows platform. This technology provides a standard, consistent mechanism 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. MSAA has been available as an add-on since Windows 95 and built into subsequent Windows releases.
  • 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.

Design and Implementation Roadmap

UI Keyboard Navigation

Chrome toolbar

The current way to set the focus to the toolbar is by using the shortcut SHIFT+ALT+T. That will bring focus to the first visible and enabled (non-greyed out) button, starting from the far left. The keyboard focus (as seen by Windows and Chrome focus handlers) never leaves the toolbar itself (to avoid introducing more items in the tab order). However, as the user navigates the interface, highlighting as well as tooltips change accordingly, and assistive technology is notified (on Windows' platforms) through a call to NotifyWinEvent to respond accordingly. For tooltips, the same tooltip is displayed as for a mouse-over.

Navigation is handled by using left and right arrow keys, and buttons/menus can be triggered by Enter or Space keys. For speedy navigation and ease of use, navigational focus can only be on visible and enabled buttons, and navigation skips the location edit box (as it has its own shortcuts, and would also eat the arrow keystrokes). Since the toolbar is small enough, to avoid confusion, navigation does not wrap around at the edges.

Status: All functionality in the toolbar should be accessible from the keyboard alone (please report any bugs, if found).



Chrome toolbar accessed with keyboard alone

Keyboard shortcuts

The currently supported keyboard shortcuts can be explored in the Google Chrome Help Center for keyboard shortcuts.

Display Options

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

Implementation Roadmap - Windows

  • MSAA (Microsoft Active Accessibility) information for UI views
    1. Extend View class to be self-aware of its accessibility information (Name, Role, Default Action, Keyboard Shortcut), and provide accessors and mutators.
      • The Name property should be a programmer-defined, localized string naming the object (e.g "Reload" for the Chrome toolbar reload button).
      • The Role property should be any of the MSAA Object Roles, as appropriate. If a standard Win32 library widget is used in accordance with its default behavior, the Role will most likely be correctly set by default.
      • The Default Action property should be a programmer-defined, localized string stating the object's default action (e.g "Press" for a regular push button).
      • The Keyboard Shortcut property should be a programmer-defined, localized string stating the keyboard shortcut (if any) connected to the object.
    2. Have UI elements derived from views::View override the appropriate functions.
    3. Initiate UI View elements with accessibility name, role etc, where instantiated.
    4. The IAccessible interface is implemented for views by the ViewAccessibility class. Each view that has children which are also exposed as nodes in the MSAA hierarchy (the MSAA hierarchy should contain everything in the UI that can/should be able to receive keyboard focus, as well as their parents and ancestors, all they way up to the root node) has its own implementation of the ViewAccessiblity class. However, it is important to note that leaf nodes (that have no children in the MSAA hierarchy) should be handled by their parent's ViewAccessibility. To maintain platform indepence, each view has an instance of ViewAccessibilityWrapper, which on Windows (lazily) creates and stores a ViewAccessibility (see below).
    5. Have the Chrome UI frames handle WM_GETOBJECT, returning the ViewAccessibility for the root view (or create one if there is none). See the "Browser" section below, in the "MSAA for web content" section, for more information on WM_GETOBJECT generation and handling.
    6. Keep View class platform-independent by having a wrapper class (ViewAccessibilityWrapper) to create an instance of our custom IAccessible implementation on request. Pointer created lazily and will be reused for future requests, as the IAccessible interface itself will remain static (until the UI changes), but the contained information is accessed dynamically upon request.
    7. Handle WindowFromAccessibleObject call to retrieve the HWND containing the current View.
    8. IAccessible for the omnibox is implemented in the AutocompleteAccessibility class, and its WM_GETOBJECT call is handled in AutocompleteEditViewWin.
            Status: All of the above steps (1-7) are currently implemented and live.
  • UI Keyboard navigation and MSAA events - For UI elements that are not naturally included in the keyboard navigation (e.g. tab order), but still need to be available for the user to interact with, we need to take some action (as outlined below). Default widgets, such as standard menus (e.g. the menus in the Chrome toolbar) and dialog boxes built on Win32 widgets, will in many cases come with a default keyboard navigation, focus tracking and MSAA implementation. Obviously, this should be verified by the developer.
    1. Make all of actionable UI reachable via keyboard (toolbar, info bars, bookmark bar etc). Involves ensuring that all actionable UI elements have keyboard navigation and enabling them to receive keyboard focus.
      1. Add capability for UI element to receive keyboard focus (for instance by including it in the tab order, or providing an intuitive keyboard shortcut).
      2. Change the appearance state of the UI element, to signify it has keyboard focus (often duplicating what mouse-hover event handlers are doing).
      3. Have tooltip display, if this is displayed on mouse-hover.
      4. Make sure Enter key, Arrow keys, and any other keystrokes are handled appropriately for the object in question.
    2. Trigger the correct MSAA event (OBJ_FOCUS) through NotifyWinEvent to announce keyboard focus changes to the client (e.g. assistive technology). The event needs to be sent along with a child id, which in the Chrome UI uniquely identifies to view receiving focus. Currently, that id system is piggybacking on using the ViewID enumerators.
            Status: All of the above (1-2, with sub bullets) are implemented and live for the Chrome toolbar. For status of other UI elements, see "Current Issues" section below.
  • MSAA for web content  - Due to the multi-process architecture of Chrome, the MSAA implementation here is a bit more complex than normally required. The common scenario (in a single-process architecture) is that there is a server (i.e the browser) and a client (i.e. a screen reader). The client will be given direct access to the interface pointer exposed by the server, and will release it when no longer needed. Here, however, we are dealing with a more complex scenario, best approximated by a server (WebKit) to client (Glue) to server (Browser) to client (i.e. a screen reader) interaction. The outline of how this is implemented is below.
    • Browser
      1. Receive and handle WM_GETOBJECT in RenderWidgetHostWin::OnGetObject. This request can essentially come in the following scenarios.
        1. WinEvents is a mechanism that allows the operating system and servers to notify clients when an accessible object changes. To specify which events each client want to receive they call SetWinEventHook. With SetWinEventHook, a client registers to receive one or more events and sets a hook function to handle the specified events. When the client's hook function is called, it receives a number of parameters that describe the event and the object that generated the event. To gain access to the object that generated the event, the client hook function calls AccessibleObjectFromEvent. 
        2. AccessibleObjectFromWindow and AccessibleObjectFromPoint can also be called by the client, to request accessibility information for a paricular window or point.
        3. When a client calls AccessibleObjectFromWindow or any of the other AccessibleObjectFromX APIs that retrieve an interface to an object, Active Accessibility sends the WM_GETOBJECT window message to the applicable window procedure within the appropriate application. To provide information to clients, servers must respond to the WM_GETOBJECT message.
        4. For further information, see Retrieving an IAccessible Object.
      1. If there is no root BrowserAccessibility, create an instance and assign it id 0. The id is used to link the IAccessible implementation on the Browser side to its counterpart on the Renderer side. The BrowserAccessibility class implements the IAccessible interface for the Browser side of each object in the web content MSAA hierarchy.
      2. Each IAccessible function is implemented in BrowserAccessibility to contain input and output validation, but otherwise pass the request for MSAA information through to BrowserAccessibility::RequestAccessibilityInfo.
      3. The request will be passed on to the BrowserAccessibilityManager (a singleton class), who keeps a hashmap of IAccessible instances already requested and instantiated.
      4. A Chrome IPC message (ViewMsg_Accessibility_In_Params) is composed from the input parameters, and sent through the appropriate RenderWidgetHost (found through lookup in the manager's hashmap) as an IPC::SyncMessage. This seemingly simple messaging contains some tricky details, which are further covered in the Synchronous IPC for Accessibility section just below.
      5. The message arrives in the Glue layer, where it is handled by WebAccessibilityManager. If the returned information from the Renderer MSAA (through Glue) requires that a new instance of BrowserAccessibility is created, this is done through BrowserAccessibilityManager::CreateAccessibilityInstance.
    • Glue
      1. The Glue layer itself contains no notion of IAccessible (or anything else platform-specific). WebAccessibilityManager has a cache of GlueAccessibilityObjects, which implements WebKit's AccessibilityObjectWrapper, and as the name implies serves as a wrapper around AccessibilityObject. Each instance of the GlueAccessibilityObject is distinguished by an accessible id (passed along with every IPC message). Note that the creation of the GlueAccessibilityObjects is driven by the Renderer side (except in the case of the root, which is handled as a special case), and the lookup in the cache should always be successful (if not, we fail gracefully).
      2. WebAccessibilityManager then resolves what information is being needed from the Browser side caller, and passes the input parameters from the received IPC message into the matching function of the GlueAccessibilityObject retrieved from the cache.
      3. Output parameters are collected, and any newly created Renderer GlueAccessibilityObject is cached, and assigned a new accessible id. The id is passed back to the Browser side, alongside with the output parameters.
    • Renderer (WebKit)
      • The WebKit IAccessible implementation resides in the AccessibleBase class. However, Chrome is bypassing the use of this class to stay platform-independent (it contains a lot of COM), and talks directly to the AccessibilityObject. This class contains a number of accessor functions that make it easy to retrieve relevant information from the DOM.
            Status: Due to some current instability related to the MSAA for web content (particularly seen on Vista Tablet PCs), this part of the code currently has to be turned
                        on by running chrome.exe with the flag "--enable-renderer-accessibility". As these issues stabilize, the flag will be removed and the MSAA for web content
                        on by default.

Synchronous IPC for Accessibility

Given that MSAA has at the core a synchronous client-server behavior, whereas the multi-process architecture of Chrome requires the UI to remain responsive at all times, there are some interesting issues to explain further in this area.

When the Browser sends the IPC::SyncMessage for requesting accessibility information from the Renderer (as explained step-by-step in the "MSAA for web content" section above), it sends it synchronously and waits for the Renderer up to a timeout (which is currently set to 500ms, based on an average of upper limit response times for WebKit MSAA, with some padding).  The message is being sent with SyncMessage::EnableMessagePumping() set, which allows the UI to stay responsive, while waiting.

If all is well, and a response is received before the timeout is hit, we return the result to the client requester. If however the timeout expires before a reply has come back, BrowserAccessibility will return a generic failure message (E_FAIL)  to the client, and then fail gracefully for this request.

Focus events

As of revision 16499, focus events have been available for the web content. As a focus change occur in WebKit, the focused AccessibilityObject is retrieved from the renderer, and the active RenderView will send off a focus change IPC message. When received on the Browser side, the BrowserAccessibilityManager will raise the appropriate platform-specific event (for Windows and MSAA that's EVENT_OBJECT_FOCUS). The AT will receive the focus change event, and issue a WM_GETOBJECT request for the specified child id.

Status: This behavior has been verified to work with the NVDA screen reader (on Windows XP). Work is currently under way to ensure that it also performs as expected with the JAWS screen reader.

WAI-ARIA Support

WAI-ARIA Roles

ARIA roles supported in Chrome depend on a variety of factors. Firstly, the support needs to be implemented in WebKit. A good place to start looking at ARIA roles in WebKit is in WebCore/accessibility/AccessibilityRenderObject.cpp. The ARIA roles' mapping is maintained here in the static function createARIARoleMap(), and determined and exposed through various other functions in this class and others (AccessibilityRenderObject::determineAriaRoleAttribute() etc).

The AccessibilityRole exposed from WebKit is determined in AccessibilityRenderObject::determineAccessibilityRole(), which in Chrome then feeds into the mapping in GlueAccessibilityObject, in static function SupportedRole(). Here a mapping is maintained from the WebCore role to a WebAccessibility::Role, which in turn is handled by the Browser side, and mapped back to a platform-specific role for output. In the case of Windows, this mapping is to a MSAA Object Role, which is performed in BrowserAccessibility::MSAARole().

Below is a comparison of the current 59 possible ARIA role values (excluding abstract roles), the expected mapping to MSAA role values, and the currently reported MSAA role value in Chrome (tip-of-tree). This being work in progress in WebKit, there are still a lot of red fields, but the set of greens will keep expanding in the near future. Updates will be posted to this page, and can be tracked under issue 19982.

A reported role of 'client' in this table means that the ARIA role had no effect and MSAA role is set to default value (unless set to any other value by e.g. the tag itself). A recent full comparison of how the other browsers stack up can be seen at the Paciello Group Blog.

WAI-ARIA Role values exposed via MSAA
ARIA Role Expected MSAA Role Chrome - Reported Role
alert alert client X
alertdialog dialog client X
application application application
article document document
banner None client X
button push button push button
checkbox check box check box
columnheader column header column header
combobox combo box client X
complementary None client X
contentinfo None client X
definition None client X
dialog dialog client X
directory list client X
document client document
grid table table
gridcell cell cell
group grouping grouping
heading heading client X
img graphic graphic
label text client X
link link link
list list client X
listbox list list
listitem list item client X
log log? client X
main None client X
marquee animation? marquee? client X
math equation client X
menu popup menu popup menu
menubar menu bar client X
menuitem menu item menu item
menuitemcheckbox menu item menu item
menuitemradio menu item menu item
navigation None client X
note None client X
option list item list item/menu item
presentation no object exposed client X
progressbar progress bar progress bar
radio radio button radio button
radiogroup grouping grouping
row row row
region grouping grouping
rowheader row header row header
search None client X
separator seperator separator
slider slider slider
spinbutton spin box client X
status status bar status bar
tab page tab client X
tablist page tab list client X
tabpanel property page client X
textbox editable text editable text
timer timer client X
toolbar tool bar tool bar
tooltip tool tip tooltip
tree outline client X
treegrid outline client X
treeitem outline item client X

NOTE: WebKit treats ARIA role values "option" and "menuitem" in a somewhat special way. Both roles may map to different OS roles, depending on the parent element. For "option", if the parent is a menu, the exposed OS role is menuitem, and if it's instead a listbox, the role exposed is that of listitem. For any other parent role, "option" has no effect (exposed role is client). In a similar manner, ARIA role "menuitem" only gets exposed as OS role menuitem, if the parent node has roles grouping or menu.

aria-labelledby and aria-describedby

Chrome currently supports (in dev channel version) both the aria-labelledby (in fact, the American spelling of aria-labeledby is also supported) and aria-describedby properties. When specified, MSAA's (on Windows) get_accName will return the text value of the DOM nodes specified through the id list in the aria-labelledby attribute. For aria-describedby, get_accDescription will return the text value of the specified nodes, preceded by the string "Description: " (in order to facilitate detection for some screen readers).

Current Issues

This list is roughly prioritized with the most important issues listed toward the top. However, some tasks are uncoupled and can be worked on independently.

Unclaimed

  1. New Tab Page - Design a sensible abstraction for visually impaired users.
See also the UI elements below in the Ongoing section, marked as orange, marked with *, not bold and red and bold for more issues needing attention.

Ongoing

  • UI Keyboard Navigation (klink) - Users with for instance low mobility or low vision do not use the mouse as an input device. Therefore, all functionality provided by Chrome should be easily accessible and navigable using the keyboard alone. This can be accomplished using tab stops and standard keyboard shortcuts, where applicable. Also, the functionality exposed through menus as well as a keyboard shortcut should have its shortcut displayed in the menu.
    • Status: The current state of the keyboard bindings and support for the Microsoft Active Accessibility COM-library (used by Assistive Technology). The Chrome toolbar is currently in good shape (green, no * or bold), whereas some of the simpler dialogs (orange, marked with *, not bold) are in need of smaller fixes, and the bottom dialogs (red and bold) are up for grabs.
      • Chrome Toolbar
        • Access toolbar by keyboard shortcut SHIFT + ALT + T
        • Keyboard navigation in place with left/right arrows
        • Activate buttons with Space/Enter.
        • Access menus with down arrow/Enter/Space, and navigate them with up/down arrows (activate menu item with Enter).
        • Access context menus (aka right-click menus) by hitting VK_APPS or SHIFT + F10 (only works on buttons that have context menus).
        • Tooltip (same as triggered upon mouse hover) will be displayed as keyboard focus moves around.
        • MSAA information exposed correctly for all toolbar and submenu elements.
      • Bookmark Bubble * - issue 9601
        • Issue - Name edit box reported as role client, which is the default role, when none is provided by the programmer. Expected behavior: get_accRole should return ROLE_SYSTEM_TEXT.
        • Issue - The labels connected to the form fields are not programmatically connected to the corresponding field. Expected behavior: get_accName for each form field will return the label string.
        • Issue - The string value contained in the Name field is reported as the name, not the value. Expected behavior: get_accValue will return the string currently contained in the field.
        • Issue - Hitting Enter on 'Remove' link will not remove bookmark (Space works as expected though).
        • Issue - No visual feedback when keyboard focus is on the 'Remove' link.
      • Edit Bookmark Dialog * - issue 9604
        • Issue - Name and URL edit boxes reported as role client, which is the default role, when none is provided by the programmer. Expected behavior: get_accRole should return ROLE_SYSTEM_TEXT.
        • Issue -The labels connected to the form fields are not programmatically connected to the corresponding field. Expected behavior: get_accName for each form field will return the label string.
        • Issue - The string value contained in each field is reported as the name, not the value. Expected behavior: get_accValue should return the string currently contained in the field.
      • Find In Page * - issue 9606
        • Issue - Edit box reported as MSAA role client, which is the default role, when none is provided by the programmer. Expected behavior: get_accRole should return ROLE_SYSTEM_TEXT.
        • Issue - The form field has no label programmatically connected to it. Expected behavior: get_accName for the form field will return the label string.
        • Issue - The string value contained in the field is reported as the name, not the value. Expected behavior: get_accValue will return the string currently contained in the field.
      • Report Bug or Broken Web Site dialog * - issue 9614
        • Issue - Page URL edit box reported as role client, which is the default role, when none is provided by the programmer. Expected behavior: get_accRole should return ROLE_SYSTEM_TEXT.
        • Issue - Description textarea reported as role client, which is the default role, when none is provided by the programmer. Expected behavior: get_accRole should return ROLE_SYSTEM_TEXT.
        • Issue - The labels connected to the form fields are not programmatically connected to the corresponding field. Expected behavior: get_accName for each form field will return the label string.
        • Issue - The string value contained in the 'Bug type' combobox is reported as the name, not the value. Expected behavior: get_accValue should return the value currently selected in the combobox.
        • Issue - The close button (X) in the top-right corner does not expose any MSAA name. Expected behavior: get_accName for the button returns 'Close'.
        • Issue - MSAA focus cannot get to the 'Send screen shot of current page' checkbox.
      • Clear Browsing Data dialog * - issue 9616
        • Issue - No labels for form fields.The labels connected to the form fields are not programmatically connected to the corresponding field. Expected behavior: get_accName for each form field will return the label string.
        • Issue - MSAA focus cannot get to the checkboxes.
      • Import bookmarks and settings dialog * - issue 9617
        • Issue - The labels connected to the form fields are not programmatically connected to the corresponding field. Expected behavior: get_accName for each form field will return the label string.
        • Issue - MSAA focus cannot get to the checkboxes.
      • Bookmarks Manager * - issue 9619
        • Issue - Search edit box reported as role client, which is the default role, when none is provided by the programmer. Expected behavior: get_accRole should return ROLE_SYSTEM_TEXT.
        • Issue - No label for edit box, which means that there is none programmatically connected to the corresponding field. Expected behavior: get_accName for each form field will return the label string.
        • Issue - Organize and Tools menus are not keyboard accessible.
        • Issue - No way to Import/Export bookmarks from the keyboard alone (the menus are not keyboard accessible, but the options in the Organize menu appear in the context menu for each option. However, Import/Export does not).
      • Options * - issue 9621
        • Issue - No labels for checkboxes and radiobuttons, which means that there is none programmatically connected to the corresponding field. Expected behavior: get_accName for each form field will return the label string.
        • Issue - MSAA focus cannot get to the checkboxes or radiobuttons.
        • Issue - CTRL + (SHIFT) + TAB will not switch tabs.
        • Issue - Blue labels to the left does not get picked up when tabbing around, which means that they are not programmatically connected to the corresponding field. Expected behavior: get_accName for each form field will return the label string (as appearing in each blue label).
      • Omnibox * - issue 9605
        • Issue - No visible focus tracking on suggestion dropdown list.
      • History 
      • Bookmark bar
      • Info bars
      • JavaScript Console
      • Task Manager

  • UI Support for Access Technology (klink) - Some of our users rely on the use of some type of Access Technology (AT). This includes screen readers, screen magnifiers and other tools, that work with information correctly exposed by the application to convey information to the user. In the case of the Chrome UI, one or several custom implementations of the Microsoft Active Accessibility COM-library might be appropriate.
    • Status: MSAA support implemented for
      • Toolbar + all buttons contained within (see above)
      • Location edit box
      • Web content - still needs MSAA events.
  • WAI-ARIA Support (klink) - Handle WAI-ARIA widgets and live regions. For Windows, widgets should be reported to the assistive technology as their MSAA equivalents. For example, a span element with the role of slider should be reported as a ROLE_SLIDER in MSAA. Live regions are trickier as they are a newer concept and are not used by existing desktop applications. In Firefox, Fire Vox is currently the only assistive technology that supports live regions and that is done straight from the DOM, not through an accessibility interface. We should explore sending the content from live region events through MSAA roles which might be a fairly close match (status bar is a possible candidate).
    • Status: Supporting whatever ARIA is currently implemented in WebKit, and exposed through their MSAA. Documentation of this support is under way.
  • High Contrast (senorblanco) - The High Contrast mode in Windows (Start Menu > Control Panel > Accessibility Options, Display tab) is used by for instance low vision users. Currently, applying this mode to Chrome only changes the font size of the Omnibox and other parts of the UI, leaving the rest of the UI and Renderer content unaffected.
    • Status: Issue tracked in Issue 92, and owned by Stephen White.

Testing Tools - Windows

This section covers some of the (free) testing tools that are commonly used in developing for MSAA on the client side. Screenshot examples are given using the Internet Explorer Google Toolbar, but the principles remain the same when testing for Chrome UI features.

Installation

  1. To download: Navigate to the Active Accessibility 2.0 SDK Tools page, and download the inspect32.exe (Inspect) and accevent32.exe (Event Watcher) tools.
  2. The tools:
    • The Inspect tool is suitable for navigating the UI, tracking focus and investigating what information gets exposed to the AT.
    • The Event Watcher tool is primarily suitable for verifying that the correct events are being generated for the benefit of the AT.

Inspect

  • As said, this tool is especially useful to verify keyboard navigation alongside with focus tracking (in the eyes of AT), and investigate the information exposed. To do so, use the following steps:
    1. In the Options menu, make sure that only 'Watch Focus' is checked and that all other 'Watch x' options are unchecked. It is also useful to check the 'Show Highlight Rectangle', as this will make focus tracking easier.
    2. Set focus (using keyboard, preferably, or mouse) to your intended starting point, and use the keyboard alone to navigate the UI.
    3. Verify that the yellow highlight rectangle (indicating what currently has focus in the eyes of the AT) moves along with navigation as expected.
    4. Looking at the Inspect tool, verify the information exposed to the AT (see screenshot below).
    5. If any part of the information exposed is faulty or missing, you may have to supply your own MSAA implementation.

Please verify the following:

  1. Name - This is extremely important, as this string is what for instance gets read out by the screen reader for this feature.
  2. Value - Not all controls (e.g. push buttons) have a value. If it does (e.g. edit box), the current value of the control should appear here.
  3. Role - The role conveys to the AT user what the expected behavior of the control is, therefore very important.
  4. State - Ensure that the current state of the control is reflected here (e.g. checked/unchecked, hottracked etc).
  5. Kbshortcut - This should hold a string describing the keyboard shortcut associated with the control.



Event Watcher

  • The Event Watcher tool is somewhat more stable than Inspect, if your main goal is to track events, and information connected to those. To do so, follow these steps:
    1. In the Options menu, choose Settings..., and under 'Events' section clear all events except: OBJ_FOCUS, OBJ_SELECTION, OBJ_STATECHANGE, OBJ_VALUECHANGE (include any other if you have specific interest in that particular event), and Apply.
    2. Under 'Object Properties' section, you can select those properties you want exposed, connected to the event (the most important ones are Name, Value (if applicable), Role, State and Keyboard Shortcut).
    3. If you want events only from a specific hWND (and possibly its descendants), you can filter this at the bottom of the Settings screen.
    4. If any part of the information exposed is faulty or missing, you may have to supply your own MSAA implementation.

The information made available through the above settings is pretty much equal to that of Inspect (see above section), and either tool can be pretty much interchangeable used, based on preference.