Related: Issue 811277

The way a VoiceOver user would access an outline view is not via cursor up / down. They would first interact with it using VO-Shift-Down - even though this is not strictly necessary. Then, VO-Up/Down should move through the outline rows and VO-Backslash should expand / collapse the currently selected row.
In the current implementation I observe that VO-Up/Down don't work. VO-Backslash also doesn't work.
By using the Accessibility Inspector tool I noticed the following missing roles and attributes:
1. There are objects with a role of NSAccessibilityRowRole and a subrole of NSAccessibilityOutlineRowRole. There are as many objects as there are rows. This is correct. However, the outline row objects are not enclosed in an outline view, NSAccessibilityOutlineViewRole.
2. The following attributes are missing from the outline row objects:
NSAccessibilityDisclosedByRowAttribute
The row disclosing this row (id).
NSAccessibilityDisclosedRowsAttribute
The rows disclosed by this row (NSArray).
NSAccessibilityDisclosingAttribute
A flag that indicates whether a row is disclosing other rows (NSNumber).
NSAccessibilityDisclosureLevelAttribute
The indentation level of this row (NSNumber).

Note: this bug was found by dsexton@ and leberly@ while testing the UI currently in M66 and above. 
Using macOS Sierra 10.12.6 with VoiceOver 7.0.
Google Chrome 66.0.3349.0 (Official Build) canary (64-bit) (cohort: 64-Bit) compared to 
Google Chrome 64.0.3282.167 (Official Build) (64-bit) (cohort: Stable)

The NextAction date has arrived: 2018-02-23

Related (but not dupe): Issue 811277

Since this is a regression in accessibility, we should target the fix for before M66.

MacViews triage: per conversations with the a11y team, I'm kicking this to Target-67. It *is* a regression, but not a bad one, since the non-VO navigation for TreeViews still works.

Pls mark the bug as fixed if CL is landed in trunk and nothing else is pending. Thank you.

This is P1 for M68. When do we expect this to fix before M68 Beta?

Back to Elly since I've hit a wall with this and down to P2 since this UI is still keyboard navigable.

MacViews triage: calling this WontFix.

1) The current behavior is usable, if not great;
2) Fixing this seems to be extremely difficult;
3) The system frameworks we need to understand to fix it appear impenetrable.