Blame - docs/accessibility/overview.md - chromium/src.git

blob: 8faef5c663ce22a621268a761fd472c373275351 [file] [log] [blame] [view]

dmazzoni	2f48975	2017-02-16 03:39:16	[diff] [blame]	1	# Accessibility Overview
				2
				3	Accessibility means ensuring that all users, including users with disabilities,
				4	have equal access to software. One piece of this involves basic design
				5	principles such as using appropriate font sizes and color contrast,
				6	avoiding using color to convey important information, and providing keyboard
				7	alternatives for anything that is normally accomplished with a pointing device.
				8	However, when you see the word "accessibility" in a directory name in Chromium,
				9	that code's purpose is to provide full access to Chromium's UI via external
				10	accessibility APIs that are utilized by assistive technology.
				11
				12	Assistive technology here refers to software or hardware which
				13	makes use of these APIs to create an alternative interface for the user to
				14	accommodate some specific needs, for example:
				15
				16	Assistive technology includes:
				17
				18	* Screen readers for blind users that describe the screen using
				19	synthesized speech or braille
				20	* Voice control applications that let you speak to the computer,
				21	* Switch access that lets you control the computer with a small number
				22	of physical switches,
				23	* Magnifiers that magnify a portion of the screen, and often highlight the
				24	cursor and caret for easier viewing, and
				25	* Assistive learning and literacy software that helps users who have a hard
				26	time reading print, by highlighting and/or speaking selected text
				27
				28	In addition, because accessibility APIs provide a convenient and universal
				29	way to explore and control applications, they're often used for automated
				30	testing scripts, and UI automation software like password managers.
				31
				32	Web browsers play an important role in this ecosystem because they need
				33	to not only provide access to their own UI, but also provide access to
				34	all of the content of the web.
				35
				36	Each operating system has its own native accessibility API. While the
				37	core APIs tend to be well-documented, it's unfortunately common for
				38	screen readers in particular to depend on additional undocumented or
				39	vendor-specific APIs in order to fully function, especially with web
				40	browsers, because the standard APIs are insufficient to handle the
				41	complexity of the web.
				42
				43	Chromium needs to support all of these operating system and
				44	vendor-specific accessibility APIs in order to be usable with the full
				45	ecosystem of assistive technology on all platforms. Just like Chromium
				46	sometimes mimics the quirks and bugs of older browsers, Chromium often
				47	needs to mimic the quirks and bugs of other browsers' implementation
				48	of accessibility APIs, too.
				49
				50	## Concepts
				51
				52	While each operating system and vendor accessibility API is different,
				53	there are some concepts all of them share.
				54
				55	1. The tree, which models the entire interface as a tree of objects, exposed
				56	to assistive technology via accessibility APIs;
				57	2. Events, which let assistive technology know that a part of the tree has
				58	changed somehow;
				59	3. Actions, which come from assistive technology and ask the interface to
				60	change.
				61
				62	Consider the following small HTML file:
				63
				64	```
				65	<html>
				66	<head>
				67	<title>How old are you?</title>
				68	</head>
				69	<body>
				70	<label for="age">Age</label>
				71	<input id="age" type="number" name="age" value="42">
				72	<div>
				73	<button>Back</button>
				74	<button>Next</button>
				75	</div>
				76	</body>
				77	</html>
				78	```
				79
				80	### The Accessibility Tree and Accessibility Attributes
				81
				82	Internally, Chromium represents the accessibility tree for that web page
				83	using a data structure something like this:
				84
				85	```
				86	id=1 role=WebArea name="How old are you?"
				87	id=2 role=Label name="Age"
				88	id=3 role=TextField labelledByIds=[2] value="42"
				89	id=4 role=Group
				90	id=5 role=Button name="Back"
				91	id=6 role=Button name="Next"
				92	```
				93
				94	Note that the tree structure closely resembles the structure of the
				95	HTML elements, but slightly simplified. Each node in the accessibility
				96	tree has an ID and a role. Many have a name. The text field has a value,
				97	and instead of a name it has labelledByIds, which indicates that its
				98	accessible name comes from another node in the tree, the label node
				99	with id=2.
				100
				101	On a particular platform, each node in the accessibility tree is implemented
				102	by an object that conforms to a particular protocol.
				103
				104	On Windows, the root node implements the IAccessible protocol and
				105	if you call IAccessible::get_accRole, it returns ROLE_SYSTEM_DOCUMENT,
				106	and if you call IAccessible::get_accName, it returns "How old are you?".
				107	Other methods let you walk the tree.
				108
				109	On macOS, the root node implements the NSAccessibility protocol and
				110	if you call [NSAccessibility accessibilityRole], it returns @"AXWebArea",
				111	and if you call [NSAccessibility accessibilityLabel], it returns
				112	"How old are you?".
				113
				114	The Linux accessibility API, ATK, is more similar to the Windows APIs;
				115	they were developed together. (Chrome's support for desktop Linux
				116	accessibility is unfinished.)
				117
				118	The Android accessibility API is of course based on Java. The main
				119	data structure is AccessibilityNodeInfo. It doesn't have a role, but
				120	if you call AccessibilityNodeInfo.getClassName() on the root node
				121	it returns "android.webkit.WebView", and if you call
				122	AccessibilityNodeInfo.getContentDescription() it returns "How old are you?".
				123
				124	On Chrome OS, we use our own accessibility API that closely maps to
				125	Chrome's internal accessibility API.
				126
				127	So while the details of the interface vary, the underlying concepts are
				128	similar. Both IAccessible and NSAccessibility have a concept of a role,
				129	but IAccessible uses a role of "document" for a web page, while NSAccessibility
				130	uses a role of "web area". Both IAccessible and NSAccessibility have a
				131	concept of the primary accessible text for a node, but IAccessible calls
				132	it the "name" while NSAccessibility calls it the "label", and Android
				133	calls it a "content description".
				134
				135	Historical note: The internal names of roles and attributes in
				136	Chrome often tend to most closely match the macOS accessibility API
				137	because Chromium was originally based on WebKit, where most of the
				138	accessibility code was written by Apple. Over time we're slowly
				139	migrating internal names to match what those roles and attributes are
				140	called in web accessibility standards, like ARIA.
				141
				142	### Accessibility Events
				143
				144	In Chromium's internal terminology, an Accessibility Event always represents
				145	communication from the app to the assistive technology, indicating that the
				146	accessibility tree changed in some way.
				147
				148	As an example, if the user were to press the Tab key and the text
				149	field from the example above became focused, Chromium would fire a
				150	"focus" accessibility event that assistive technology could listen
				151	to. A screen reader might then announce the name and current value of
				152	the text field. A magnifier might zoom the screen to its bounding
				153	box. If the user types some text into the text field, Chromium would
				154	fire a "value changed" accessibility event.
				155
				156	As with nodes in the accessibility tree, each platform has a slightly different
				157	API for accessibility events. On Windows we'd fire EVENT_OBJECT_FOCUS for
				158	a focus change, and on Mac we'd fire @"AXFocusedUIElementChanged".
				159	Those are pretty similar. Sometimes they're quite different - to support
				160	live regions (notifications that certain key parts of a web page have changed),
				161	on Mac we simply fire @"AXLiveRegionChanged", but on Windows we need to
				162	fire IA2_EVENT_TEXT_INSERTED and IA2_EVENT_TEXT_REMOVED events individually
				163	on each affected node within the changed region, with additional attributes
				164	like "container-live:polite" to indicate that the affected node was part of
				165	a live region. This discussion is not meant to explain all of the technical
				166	details but just to illustrate that the concepts are similar,
				167	but the details of notifying software on each platform about changes can
				168	vary quite a bit.
				169
				170	### Accessibility Actions
				171
				172	Each native object that implements a platform's native accessibility API
				173	supports a number of actions, which are requests from the assistive
				174	technology to control or change the UI. This is the opposite of events,
				175	which are messages from Chromium to the assistive technology.
				176
				177	For example, if the user had a voice control application running, such as
				178	Voice Access on Android, the user could just speak the name of one of the
				179	buttons on the page, like "Next". Upon recognizing that text and finding
				180	that it matches one of the UI elements on the page, the voice control
				181	app executes the action to click the button id=6 in Chromium's accessibility
				182	tree. Internally we call that action "do default" rather than click, since
				183	it represents the default action for any type of control.
				184
				185	Other examples of actions include setting focus, changing the value of
				186	a control, and scrolling the page.
				187
				188	### Parameterized attributes
				189
				190	In addition to accessibility attributes, events, and actions, native
				191	accessibility APIs often have so-called "parameterized attributes".
				192	The most common example of this is for text - for example there may be
				193	a function to retrieve the bounding box for a range of text, or a
				194	function to retrieve the text properties (font family, font size,
				195	weight, etc.) at a specific character position.
				196
				197	Parameterized attributes are particularly tricky to implement because
Katie Dektar	4a165e1b	2017-09-27 16:15:13	[diff] [blame]	198	of Chromium's multi-process architecture. More on this below.
				199
				200	### Tools for inspecting the Accessibility tree
				201
				202	Developers can inspect the accessibility tree in several ways:
				203
				204	* By navigating to [chrome://accessibility/](chrome://accessibility)
				205	and inspecting a tree directly. Note that you may want to enable the
				206	'Internal' option. Click 'show accessibility tree' for a particular tab,
				207	then click again to refresh that tree.
				208	* Using the [https://developer.chrome.com/extensions/automation](
				209	Automation API).
				210	* Installing the [https://github.com/google/automation-inspector](
				211	Automation Inspector Chrome extension).
				212	* Or by using native tools:
				213
				214	- Android: UIAutomatorViewer
				215	- macOS: Accessibility Inspector
				216	- Windows: Inspect, AViewer, accProbe (and many others)
				217
dmazzoni	2f48975	2017-02-16 03:39:16	[diff] [blame]	218
				219	## Chromium's multi-process architecture
				220
				221	Native accessibility APIs tend to have a functional interface, where
				222	Chromium implements an interface for a canonical accessible object that
				223	includes methods to return various attributes, walk the tree, or perform
				224	an action like click(), focus(), or setValue(...).
				225
				226	In contrast, the web has a largely declarative interface. The shape
				227	of the accessibility tree is determined by the DOM tree (occasionally
				228	influenced by CSS), and the accessible semantics of a DOM element can
				229	be modified by adding ARIA attributes.
				230
				231	One important complication is that all of these native accessibility APIs
				232	are synchronous, while Chromium is multi-process, with the contents of
				233	each web page living in a different process than the process that
				234	implements Chromium's UI and the native accessibility APIs. Furthermore,
				235	the renderer processes are sandboxed, so they can't implement
				236	operating system APIs directly.
				237
				238	If you're unfamiliar with Chrome's multi-process architecture, see
				239	[this blog post introducing the concept](
				240	https://blog.chromium.org/2008/09/multi-process-architecture.html) or
				241	[the design doc on chromium.org](
				242	https://www.chromium.org/developers/design-documents/multi-process-architecture)
				243	for an intro.
				244
				245	Chromium's multi-process architecture means that we can't implement
				246	accessibility APIs the same way that a single-process browser can -
				247	namely, by calling directly into the DOM to compute the result of each
				248	API call. For example, on some operating systems there might be an API
				249	to get the bounding box for a particular range of characters on the
				250	page. In other browsers, this might be implemented by creating a DOM
				251	selection object and asking for its bounding box.
				252
				253	That implementation would be impossible in Chromium because it'd require
				254	blocking the main thread while waiting for a response from the renderer
				255	process that implements that web page's DOM. (Not only is blocking the
				256	main thread strictly disallowed, but the latency of doing this for every
				257	API call makes it prohibitively slow anyway.) Instead, Chromium takes an
				258	approach where a representation of the entire accessibility tree is
				259	cached in the main process. Great care needs to be taken to ensure that
				260	this representation is as concise as possible.
				261
				262	In Chromium, we build a data structure representing all of the
				263	information for a web page's accessibility tree, send the data
				264	structure from the renderer process to the main browser process, cache
				265	it in the main browser process, and implement native accessibility
				266	APIs using solely the information in that cache.
				267
				268	As the accessibility tree changes, tree updates and accessibility events
				269	get sent from the renderer process to the browser process. The browser
				270	cache is updated atomically in the main thread, so whenever an external
				271	client (like assistive technology) calls an accessibility API function,
				272	we're always returning something from a complete and consistent snapshot
				273	of the accessibility tree. From time to time, the cache may lag what's
				274	in the renderer process by a fraction of a second.
				275
				276	Here are some of the specific challenges faced by this approach and
				277	how we've addressed them.
				278
				279	### Sparse data
				280
				281	There are a lot of possible accessibility attributes for any given
				282	node in an accessibility tree. For example, there are more than 150
				283	unique accessibility API methods that Chrome implements on the Windows
				284	platform alone. We need to implement all of those APIs, many of which
				285	request rather rare or obscure attributes, but storing all possible
				286	attribute values in a single struct would be quite wasteful.
				287
				288	To avoid each accessible node object containing hundreds of fields the
				289	data for each accessibility node is stored in a relatively compact
				290	data structure, ui::AXNodeData. Every AXNodeData has an integer ID, a
				291	role enum, and a couple of other mandatory fields, but everything else
				292	is stored in attribute arrays, one for each major data type.
				293
				294	```
				295	struct AXNodeData {
				296	int32_t id;
				297	AXRole role;
				298	...
				299	std::vector<std::pair<AXStringAttribute, std::string>> string_attributes;
				300	std::vector<std::pair<AXIntAttribute, int32_t>> int_attributes;
				301	...
				302	}
				303	```
				304
				305	So if a text field has a placeholder attribute, we can store
				306	that by adding an entry to `string_attributes` with an attribute
				307	of ui::AX_ATTR_PLACEHOLDER and the placeholder string as the value.
				308
				309	### Incremental tree updates
				310
				311	Web pages change frequently. It'd be terribly inefficient to send a
				312	new copy of the accessibility tree every time any part of it changes.
				313	However, the accessibility tree can change shape in complicated ways -
				314	for example, whole subtrees can be reparented dynamically.
				315
				316	Rather than writing code to deal with every possible way the
				317	accessibility tree could be modified, Chromium has a general-purpose
				318	tree serializer class that's designed to send small incremental
				319	updates of a tree from one process to another. The tree serializer has
				320	just a few requirements:
				321
				322	* Every node in the tree must have a unique integer ID.
				323	* The tree must be acyclic.
				324	* The tree serializer must be notified when a node's data changes.
				325	* The tree serializer must be notified when the list of child IDs of a
				326	node changes.
				327
				328	The tree serializer doesn't know anything about accessibility attributes.
				329	It keeps track of the previous state of the tree, and every time the tree
				330	structure changes (based on notifications of a node changing or a node's
				331	children changing), it walks the tree and builds up an incremental tree
				332	update that serializes as few nodes as possible.
				333
				334	In the other process, the Unserialization code applies the incremental
				335	tree update atomically.
				336
				337	### Text bounding boxes
				338
				339	One challenge faced by Chromium is that accessibility clients want to be
				340	able to query the bounding box of an arbitrary range of text - not necessarily
				341	just the current cursor position or selection. As discussed above, it's
				342	not possible to block Chromium's main browser process while waiting for this
				343	information from Blink, so instead we cache enough information to satisfy these
				344	queries in the accessibility tree.
				345
				346	To compactly store the bounding box of every character on the page, we
				347	split the text into inline text boxes, sometimes called text runs.
				348	For example, in a typical paragraph, each line of text would be its own
				349	inline text box. In general, an inline text box or text run contians a
				350	sequence of text characters that are all oriented in the same direction,
				351	in a line, with the same font, size, and style.
				352
				353	Each inline text box stores its own bounding box, and then the relative
				354	x-coordinate of each character in its text (assuming left-to-right).
				355	From that it's possible to compute the bounding box
				356	of any individual character.
				357
				358	The inline text boxes are part of Chromium's internal accessibility tree.
				359	They're used purely internally and aren't ever exposed directly via any
				360	native accessibility APIs.
				361
				362	For example, suppose that a document contains a text field with the text
				363	"Hello world", but the field is narrow, so "Hello" is on the first line and
				364	"World" is on the second line. Internally Chromium's accessibility tree
				365	might look like this:
				366
				367	```
				368	staticText location=(8, 8) size=(38, 36) name='Hello world'
				369	inlineTextBox location=(0, 0) size=(36, 18) name='Hello ' characterOffsets=12,19,23,28,36
				370	inlineTextBox location=(0, 18) size=(38, 18) name='world' characterOffsets=12,20,25,29,37
				371	```
				372
				373	### Scrolling, transformations, and animation
				374
				375	Native accessibility APIs typically want the bounding box of every element in the
				376	tree, either in window coordinates or global screen coordinates. If we
				377	stored the global screen coordinates for every node, we'd be constantly
				378	re-serializing the whole tree every time the user scrolls or drags the
				379	window.
				380
				381	Instead, we store the bounding box of each node in the accessibility tree
				382	relative to its offset container, which can be any ancestor. If no offset
				383	container is specified, it's assumed to be the root of the tree.
				384
				385	In addition, any offset container can contain scroll offsets, which can be
				386	used to scroll the bounding boxes of anything in that subtree.
				387
				388	Finally, any offset container can also include an arbitrary 4x4 transformation
				389	matrix, which can be used to represent arbitrary 3-D rotations, translations, and
				390	scaling, and more. The transformation matrix applies to the whole subtree.
				391
				392	Storing coordinates this way means that any time an object scrolls, moves, or
				393	animates its position and scale, only the root of the scrolling or animation
				394	needs to post updates to the accessibility tree. Everything in the subtree
				395	remains valid relative to that offset container.
				396
				397	Computing the global screen coordinates for an object in the accessibility
				398	tree just means walking up its ancestor chain and applying offsets and
				399	occasionally multiplying by a 4x4 matrix.
				400
				401	### Site isolation / out-of-process iframes
				402
				403	At one point in time, all of the content of a single Tab or other web view
				404	was contained in the same Blink process, and it was possible to serialize
				405	the accessibility tree for a whole frame tree in a single pass.
				406
				407	Today the situation is a bit more complicated, as Chromium supports
				408	out-of-process iframes. (It also supports "browser plugins" such as
				409	the `<webview>` tag in Chrome packaged apps, which embeds a whole
				410	browser inside a browser, but for the purposes of accessibility this
				411	is handled the same as frames.)
				412
				413	Rather than a mix of in-process and out-of-process frames that are handled
				414	differently, Chromium builds a separate independent accessibility tree
				415	for each frame. Each frame gets its own tree ID, and it keeps track of
				416	the tree ID of its parent frame (if any) and any child frames.
				417
				418	In Chrome's main browser process, the accessibility trees for each frame
				419	are cached separately, and when an accessibility client (assistive
				420	technology) walks the accessibility tree, Chromium dynamically composes
				421	all of the frames into a single virtual accessibility tree on the fly,
				422	using those aforementioned tree IDs.
				423
				424	The node IDs for accessibility trees only need to be unique within a
				425	single frame. Where necessary, separate unique IDs are used within
				426	Chrome's main browser process. In Chromium accessibility, a "node ID"
				427	always means that ID that's only unique within a frame, and a "unique ID"
				428	means an ID that's globally unique.
				429
				430	## Blink
				431
				432	Blink constructs an accessibility tree (a hierarchy of [WebAXObject]s) from the
sashab	b498325a	2017-05-17 01:18:46	[diff] [blame]	433	page it is rendering. WebAXObject is the public API wrapper around [AXObject],
				434	which is the core class of Blink's accessibility tree. AXObject is an abstract
dmazzoni	2f48975	2017-02-16 03:39:16	[diff] [blame]	435	class; the most commonly used concrete subclass of it is [AXNodeObject], which
				436	wraps a [Node]. In turn, most AXNodeObjects are actually [AXLayoutObject]s,
				437	which wrap both a [Node] and a [LayoutObject]. Access to the LayoutObject is
sashab	b498325a	2017-05-17 01:18:46	[diff] [blame]	438	important because some elements are only in the AXObject tree depending on their
dmazzoni	2f48975	2017-02-16 03:39:16	[diff] [blame]	439	visibility, geometry, linewrapping, and so on. There are some subclasses of
				440	AXLayoutObject that implement special-case logic for specific types of Node.
sashab	b498325a	2017-05-17 01:18:46	[diff] [blame]	441	There are also other subclasses of AXObject, which are mostly used for testing.
dmazzoni	2f48975	2017-02-16 03:39:16	[diff] [blame]	442
				443	Note that not all AXLayoutObjects correspond to actual Nodes; some are synthetic
				444	layout objects which group related inline elements or similar.
				445
				446	The central class responsible for dealing with accessibility events in Blink is
				447	[AXObjectCacheImpl], which is responsible for caching the corresponding
				448	AXObjects for Nodes or LayoutObjects. This class has many methods named
				449	`handleFoo`, which are called throughout Blink to notify the AXObjectCacheImpl
				450	that it may need to update its tree. Since this class is already aware of all
				451	accessibility events in Blink, it is also responsible for relaying accessibility
				452	events from Blink to the embedding content layer.
				453
				454	## The content layer
				455
				456	The content layer lives on both sides of the renderer/browser split. The content
				457	layer translates WebAXObjects into [AXContentNodeData], which is a subclass of
				458	[ui::AXNodeData]. The ui::AXNodeData class and related classes are Chromium's
				459	cross-platform accessibility tree. The translation is implemented in
				460	[BlinkAXTreeSource]. This translation happens on the renderer side, so the
				461	ui::AXNodeData tree now needs to be sent to the browser, which is done by
				462	sending [AccessibilityHostMsg_EventParams] with the payload being serialized
				463	delta-updates to the tree, so that changes that happen on the renderer side can
				464	be reflected on the browser side.
				465
				466	On the browser side, these IPCs are received by [RenderFrameHostImpl], and then
				467	usually forwarded to [BrowserAccessibilityManager] which is responsible for:
				468
				469	1. Merging AXNodeData trees into one tree of [BrowserAccessibility] objects,
				470	by linking to other BrowserAccessibilityManagers. This is important because
				471	each page has its own accessibility tree, but each Chromium window must
				472	have only one accessibility tree, so trees from multiple pages need to be
				473	combined (possibly also with trees from Views UI).
				474	2. Dispatching outgoing accessibility events to the platform's accessibility
				475	APIs. This is done in the platform-specific subclasses of
				476	BrowserAccessibilityManager, in a method named `NotifyAccessibilityEvent`.
				477	3. Dispatching incoming accessibility actions to the appropriate recipient, via
				478	[BrowserAccessibilityDelegate]. For messages destined for a renderer,
				479	[RenderFrameHostImpl], which is a BrowserAccessibilityDelegate, is
				480	responsible for sending appropriate `AccessibilityMsg_Foo` IPCs to the
				481	renderer, where they will be received by [RenderAccessibilityImpl].
				482
				483	On Chrome OS, RenderFrameHostImpl does not route events to
				484	BrowserAccessibilityManager at all, since there is no platform screenreader
				485	outside Chromium to integrate with.
				486
				487	## Views
				488
				489	Views generates a [NativeViewAccessibility] for each View, which is used as the
				490	delegate for an [AXPlatformNode] representing that View. This part is relatively
				491	straightforward, but then the generated tree must be combined with the web
				492	accessibility tree, which is handled by BrowserAccessibilityManager.
				493
				494	## WebUI
				495
				496	Since WebUI surfaces have renderer processes as normal, WebUI accessibility goes
				497	through the blink-to-content-to-platform pipeline described above. Accessibility
				498	for WebUI is largely implemented in JavaScript in [webui-js]; these classes take
				499	care of adding ARIA attributes and so on to DOM nodes as needed.
				500
				501	## The Chrome OS layer
				502
				503	The accessibility tree is also exposed via the [chrome.automation API], which
				504	gives extension JavaScript access to the accessibility tree, events, and
				505	actions. This API is implemented in C++ by [AutomationInternalCustomBindings],
				506	which is renderer-side code, and in JavaScript by the [automation API]. The API
				507	is defined by [automation.idl], which must be kept synchronized with
				508	[ax_enums.idl].
				509
				510	[AccessibilityHostMsg_EventParams]: https://cs.chromium.org/chromium/src/content/common/accessibility_messages.h?sq=package:chromium&l=75
				511	[AutomationInternalCustomBindings]: https://cs.chromium.org/chromium/src/chrome/renderer/extensions/automation_internal_custom_bindings.h
				512	[AXContentNodeData]: https://cs.chromium.org/chromium/src/content/common/ax_content_node_data.h
				513	[AXLayoutObject]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/accessibility/AXLayoutObject.h
				514	[AXNodeObject]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/accessibility/AXNodeObject.h
sashab	0cd996b	2017-05-17 07:31:46	[diff] [blame]	515	[AXObjectImpl]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/accessibility/AXObjectImpl.h
dmazzoni	2f48975	2017-02-16 03:39:16	[diff] [blame]	516	[AXObjectCacheImpl]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/accessibility/AXObjectCacheImpl.h
				517	[AXPlatformNode]: https://cs.chromium.org/chromium/src/ui/accessibility/platform/ax_platform_node.h
				518	[AXTreeSerializer]: https://cs.chromium.org/chromium/src/ui/accessibility/ax_tree_serializer.h
				519	[BlinkAXTreeSource]: https://cs.chromium.org/chromium/src/content/renderer/accessibility/blink_ax_tree_source.h
				520	[BrowserAccessibility]: https://cs.chromium.org/chromium/src/content/browser/accessibility/browser_accessibility.h
				521	[BrowserAccessibilityDelegate]: https://cs.chromium.org/chromium/src/content/browser/accessibility/browser_accessibility_manager.h?sq=package:chromium&l=64
				522	[BrowserAccessibilityManager]: https://cs.chromium.org/chromium/src/content/browser/accessibility/browser_accessibility_manager.h
				523	[LayoutObject]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutObject.h
				524	[NativeViewAccessibility]: https://cs.chromium.org/chromium/src/ui/views/accessibility/native_view_accessibility.h
				525	[Node]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Node.h
				526	[RenderAccessibilityImpl]: https://cs.chromium.org/chromium/src/content/renderer/accessibility/render_accessibility_impl.h
				527	[RenderFrameHostImpl]: https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_impl.h
				528	[ui::AXNodeData]: https://cs.chromium.org/chromium/src/ui/accessibility/ax_node_data.h
				529	[WebAXObject]: https://cs.chromium.org/chromium/src/third_party/WebKit/public/web/WebAXObject.h
				530	[automation API]: https://cs.chromium.org/chromium/src/chrome/renderer/resources/extensions/automation
				531	[automation.idl]: https://cs.chromium.org/chromium/src/chrome/common/extensions/api/automation.idl
				532	[ax_enums.idl]: https://cs.chromium.org/chromium/src/ui/accessibility/ax_enums.idl
				533	[chrome.automation API]: https://developer.chrome.com/extensions/automation
				534	[webui-js]: https://cs.chromium.org/chromium/src/ui/webui/resources/js/cr/ui/