Objective
Currently in chromium, there are two areas of code that provide low-level operating system Accessibility APIs.
ui/accessibility/platform/*
content/browser/accessibility/browser_accessibility*
In order to reduce some complexity and code, we’d to remove code that interacts with the native accessibility APIs from content. This will also enable feature parity between Views and Chrome Content It will make supporting foreign accessibility trees easier (i.e. PDF could go directly to the browser rather than via its host web page), and we could maybe support remote desktop accessibility someday Finally, it'd allow us to do things like the COM proxy idea to avoid injected DLLs.
Overview
On the content/ side, there exists a class called BrowserAccessibility which is exactly one node in the accessibility tree. It provides a number of methods to find boundaries, walk the accessibility tree, and access internals. In addition, BrowserAccessibility has subclasses on each platforms that handle interacting with the host operating system. For example, on Windows, BrowserAccessibilityWin (a subclass of BrowserAccessibility) implements IAccessible2 et. al.
On the ui/ side, we also have a set of classes in ui/accessibility/platform/ which interact with the host operating system as well.
Eventual Goal
BrowserAccessibility would inherit from AXPlatformNodeDelegate and own a AXPlatformNode.
The code in ui/accessibility/platform becomes the ONLY implementation of platform-native accessibility APIs, but it has no understanding of things like renderers, frames, and other "how Chrome implements the web" details. It would understand web-specific things like live regions and some web-specific roles, but it wouldn't have to understand too many implementation details, just how to map those to native APIs.
The code in content/browser/accessibility becomes the glue code that maps the accessibility data we get from a web renderer, into a tree of AXPlatformNode objects that implement the native API on each platform. It knows about renderers and iframes and stuff like that, but it doesn't have much platform-specific code anymore.
No code outside of ui/accessibility/platform or content/browser/accessibility should be affected. In particular this is completely orthogonal to any changes to Blink code.
Comment 1 by bugdroid1@chromium.org
, Mar 23 2017