Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2385683003:
docs: add accessibility overview (Closed)
|
Created:
4 years, 2 months ago by Elly Fong-Jones Modified:
4 years, 2 months ago CC:
chromium-reviews, aboxhall+watch_chromium.org, nektar+watch_chromium.org, yuzo+watch_chromium.org, je_julie, dmazzoni+watch_chromium.org, dtseng+watch_chromium.org Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
Descriptiondocs: add accessibility overview
BUG=
Committed: https://crrev.com/1ab91d65d198efe994410e0143ca942dcffd0a5f
Cr-Commit-Position: refs/heads/master@{#423229}
Patch Set 1 #
Total comments: 22
Patch Set 2 : fixes #Messages
Total messages: 17 (5 generated)
Description was changed from ========== docs: add accessibility overview BUG= ========== to ========== docs: add accessibility overview BUG= ==========
ellyjones@chromium.org changed reviewers: + dmazzoni@chromium.org, nektar@chromium.org
nektar, dmazzoni: ptal? :)
Great! I added comments to parts that I thought were wrong or needed clarification, but it's fine with me to check this in and then we can all keep iterating https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md File docs/accessibility.md (right): https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newcode1 docs/accessibility.md:1: # Accessibility Overview Thanks for writing this. Can you please link to this from https://www.chromium.org/developers/design-documents/accessibility? It doesn't seem redundant with any existing docs but we should cross-link https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:14: 3. *Commands*, which come from accessibility software and ask the interface to I think we call this "actions" most often in the code It might be good to give examples of each of these https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:21: Blink constructs an accessibility tree (a heirarchy of [WebAXObject]s) from the heirarchy -> hierarchy https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:24: kinds: [AXNodeObject], which represents a [Node] in the accessibility tree, Two things are unclear in this description: 1. AXLayoutObject is a subclass of AXNodeObject, so the vast majority of nodes will be AXLayoutObject 2. There are other subclasses, not just those two. I think this is the best high-level summary: 1. AXObject is the abstract interface, it has some common code but can't be instantiated 2. Most AXObjects are AXNodeObjects and wrap a node 3. Most AXNodeObjects are AXLayoutObjects that wrap a layout object AND a node 4. There are a few subclasses of AXLayoutObject for specific elements like tables 5. The remaining AXObjects are subclasses of AXMockObject for things like a slider thumb or a menu list popup that need to exist in the accessibility tree but don't correspond to an actual object elsewhere in Blink https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:26: LayoutObjects are more or less Nodes with CSS applied; AXLayoutObject exists LayoutObjects are a lot more than that. There are a lot of passes that happen after a change to the DOM tree. One of the first is style resolution, but that's a prerequisite for Layout, but otherwise not related. You can get a DOM node's style without layout, so Nektarios is wrong about that. The layout pass takes the DOM and the style resolution and builds or updates the layout tree, which contains the complete tree of how to layout all of the page content on the page. It handles things like line wrapping, overflow, etc. Stages after that include building the layer tree, paint tree, and compositing tree, etc., which accessibility mostly ignores One thing to note is that there are some LayoutObjects that don't correspond to nodes, for example "anonymous blocks" that just wrap and group a bunch of related inline elements. They're super annoying to deal with https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:50: On the browser side, these IPCs are received by [BrowserAccessibilityManager], They're actually received by RenderFrameHostImpl, which owns the BAM - this is important because on Chrome OS we forward the accessibility events directly to extension processes like ChromeVox, bypassing BAM entirely https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:53: 1. Combining AXNodeData trees into a tree of [BrowserAccessibility] objects. To clarify a bit, this is handled by AXTree, and BrowserAccessibility wraps each AXNode in the AXTree for the platform-specific implementation https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:57: This is done by [AXTreeCombiner]. Actually AXTreeCombiner isn't used for this. Rather, the BrowserAccessibilityManagers all link to each other and present one big composed tree. https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:69: Views generates a tree of AXPlatformNodes corresponding to the tree of Views. Sort of the other way around, each View creates a NativeViewAccessibility, which is used as the delegate for a AXPlatformNode that represents a node in the accessibility tree https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:70: This is implemented in [NativeViewAccessibility] and is mostly straightforward. The un-straightforward part is how the web tree is grated onto the views tree https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:79: ## The chrome layer I'd call this the "Chrome OS" layer, since that's the only place where we currently use the automation API.
Thanks Dominic. It would be better if we improved some of the descriptions too, to give more details. Like, why is a AXObjectCache needed? What is the lifecycle of an AXObject? What are some of the other caches we have, like a cache of node IDs in AXTree. How is testing performed? <quote> The accessibility tree is also exposed via the [chrome.automation API], which gives extension </quote> extension -> extensions -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
Let's check this in and then I'll take another pass at it, trying to expand on everything. Do we want one long doc, or lots of docs? On Fri, Sep 30, 2016 at 12:54 PM 'Nektarios Paisios' via Chromium-reviews < chromium-reviews@chromium.org> wrote: > Thanks Dominic. It would be better if we improved some of the > descriptions too, to give more details. > Like, why is a AXObjectCache needed? What is the lifecycle of an > AXObject? What are some of the other caches we have, like a cache of > node IDs in AXTree. > How is testing performed? > <quote> > The accessibility tree is also exposed via the [chrome.automation API], > which gives extension > </quote> > extension -> extensions > > -- > You received this message because you are subscribed to the Google Groups > "Chromium-reviews" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to chromium-reviews+unsubscribe@chromium.org. > > -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org.
dmazzoni: ptal? :) https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md File docs/accessibility.md (right): https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newcode1 docs/accessibility.md:1: # Accessibility Overview On 2016/09/30 19:34:46, dmazzoni wrote: > Thanks for writing this. > > Can you please link to this from > https://www.chromium.org/developers/design-documents/accessibility > > It doesn't seem redundant with any existing docs but we should cross-link As soon as it's landed, I can update that site to link to it. https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:14: 3. *Commands*, which come from accessibility software and ask the interface to On 2016/09/30 19:34:46, dmazzoni wrote: > I think we call this "actions" most often in the code Done. > It might be good to give examples of each of these I added some synthetic examples of these things. https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:21: Blink constructs an accessibility tree (a heirarchy of [WebAXObject]s) from the On 2016/09/30 19:34:46, dmazzoni wrote: > heirarchy -> hierarchy I have been making this typo my entire life :( https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:24: kinds: [AXNodeObject], which represents a [Node] in the accessibility tree, On 2016/09/30 19:34:46, dmazzoni wrote: > Two things are unclear in this description: > > 1. AXLayoutObject is a subclass of AXNodeObject, so the vast majority of nodes > will be AXLayoutObject > > 2. There are other subclasses, not just those two. > > I think this is the best high-level summary: > > 1. AXObject is the abstract interface, it has some common code but can't be > instantiated > 2. Most AXObjects are AXNodeObjects and wrap a node > 3. Most AXNodeObjects are AXLayoutObjects that wrap a layout object AND a node > 4. There are a few subclasses of AXLayoutObject for specific elements like > tables > 5. The remaining AXObjects are subclasses of AXMockObject for things like a > slider thumb or a menu list popup that need to exist in the accessibility tree > but don't correspond to an actual object elsewhere in Blink > > Done. https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:26: LayoutObjects are more or less Nodes with CSS applied; AXLayoutObject exists On 2016/09/30 19:34:46, dmazzoni wrote: > LayoutObjects are a lot more than that. There are a lot of passes that happen > after a change to the DOM tree. One of the first is style resolution, but that's > a prerequisite for Layout, but otherwise not related. You can get a DOM node's > style without layout, so Nektarios is wrong about that. > > The layout pass takes the DOM and the style resolution and builds or updates the > layout tree, which contains the complete tree of how to layout all of the page > content on the page. It handles things like line wrapping, overflow, etc. > > Stages after that include building the layer tree, paint tree, and compositing > tree, etc., which accessibility mostly ignores > > One thing to note is that there are some LayoutObjects that don't correspond to > nodes, for example "anonymous blocks" that just wrap and group a bunch of > related inline elements. They're super annoying to deal with Done. https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:50: On the browser side, these IPCs are received by [BrowserAccessibilityManager], On 2016/09/30 19:34:46, dmazzoni wrote: > They're actually received by RenderFrameHostImpl, which owns the BAM - > this is important because on Chrome OS we forward the accessibility > events directly to extension processes like ChromeVox, bypassing BAM > entirely Done. https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:53: 1. Combining AXNodeData trees into a tree of [BrowserAccessibility] objects. On 2016/09/30 19:34:46, dmazzoni wrote: > To clarify a bit, this is handled by AXTree, and BrowserAccessibility wraps each > AXNode in the AXTree for the platform-specific implementation I think I rewrote this to make more sense. https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:57: This is done by [AXTreeCombiner]. On 2016/09/30 19:34:46, dmazzoni wrote: > Actually AXTreeCombiner isn't used for this. Rather, the > BrowserAccessibilityManagers all link to each other and present one big composed > tree. Done. https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:69: Views generates a tree of AXPlatformNodes corresponding to the tree of Views. On 2016/09/30 19:34:46, dmazzoni wrote: > Sort of the other way around, each View creates a NativeViewAccessibility, which > is used as the delegate > for a AXPlatformNode that represents a node in the accessibility tree Done. https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:70: This is implemented in [NativeViewAccessibility] and is mostly straightforward. On 2016/09/30 19:34:46, dmazzoni wrote: > The un-straightforward part is how the web tree is grated onto > the views tree Done. https://codereview.chromium.org/2385683003/diff/1/docs/accessibility.md#newco... docs/accessibility.md:79: ## The chrome layer On 2016/09/30 19:34:46, dmazzoni wrote: > I'd call this the "Chrome OS" layer, since that's the only place > where we currently use the automation API. Done.
On 2016/09/30 19:59:18, dmazzoni wrote: > Let's check this in and then I'll take another pass at it, trying to expand > on everything. > > Do we want one long doc, or lots of docs? Lots of docs is better than one super-detailed doc. Getting an understanding from an "overview" doc is a lot easier than synthesizing the same understanding out of a detailed doc. > On Fri, Sep 30, 2016 at 12:54 PM 'Nektarios Paisios' via Chromium-reviews < > mailto:chromium-reviews@chromium.org> wrote: > > > Thanks Dominic. It would be better if we improved some of the > > descriptions too, to give more details. > > Like, why is a AXObjectCache needed? What is the lifecycle of an > > AXObject? What are some of the other caches we have, like a cache of > > node IDs in AXTree. > > How is testing performed? We can add these to other docs. > > <quote> > > The accessibility tree is also exposed via the [chrome.automation API], > > which gives extension > > </quote> > > extension -> extensions I don't think so - "extension JavaScript" sounds more correct to me.
lgtm
The CQ bit was checked by ellyjones@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== docs: add accessibility overview BUG= ========== to ========== docs: add accessibility overview BUG= ==========
Message was sent while issue was closed.
Committed patchset #2 (id:20001)
Message was sent while issue was closed.
Description was changed from ========== docs: add accessibility overview BUG= ========== to ========== docs: add accessibility overview BUG= Committed: https://crrev.com/1ab91d65d198efe994410e0143ca942dcffd0a5f Cr-Commit-Position: refs/heads/master@{#423229} ==========
Message was sent while issue was closed.
Patchset 2 (id:??) landed as https://crrev.com/1ab91d65d198efe994410e0143ca942dcffd0a5f Cr-Commit-Position: refs/heads/master@{#423229}
Message was sent while issue was closed.
On 2016/10/05 18:31:06, commit-bot: I haz the power wrote: > Patchset 2 (id:??) landed as > https://crrev.com/1ab91d65d198efe994410e0143ca942dcffd0a5f > Cr-Commit-Position: refs/heads/master@{#423229} Following up: this is now linked off of https://sites.google.com/a/chromium.org/dev/developers/design-documents/acces... and I think the rendered markdown looks rather nice: https://chromium.googlesource.com/chromium/src/+/master/docs/accessibility.md
Message was sent while issue was closed.
Looks great! On Thu, Oct 6, 2016 at 5:44 AM <ellyjones@chromium.org> wrote: > On 2016/10/05 18:31:06, commit-bot: I haz the power wrote: > > Patchset 2 (id:??) landed as > > https://crrev.com/1ab91d65d198efe994410e0143ca942dcffd0a5f > > Cr-Commit-Position: refs/heads/master@{#423229} > > Following up: this is now linked off of > > https://sites.google.com/a/chromium.org/dev/developers/design-documents/acces... > and I think the rendered markdown looks rather nice: > > https://chromium.googlesource.com/chromium/src/+/master/docs/accessibility.md > > https://codereview.chromium.org/2385683003/ > -- You received this message because you are subscribed to the Google Groups "Chromium-reviews" group. To unsubscribe from this group and stop receiving emails from it, send an email to chromium-reviews+unsubscribe@chromium.org. |
