Bug 115974 – Web Inspector: FKA: The DOM tree display should provide full keyboard accessibility

• Status: NEW
• Component: Web Inspector

[Victor Tsaran]

Currently, it is impossible to navigate the DOM display tree with a keyboard and a screen reader. In particular, the behavior should be:
1. Up and down arrows move between siblings.
2. Right arrow expands the tree branch exposing its children.
3. Left arrow collapses the branch.

Nice to haves:
1. HOME key takes to the top of the tree.
2. END key takes to the bottom of the tree.
3. Page-up takes to the top of the current branch.
4. Page-down key takes to the bottom of the branch.

[Radar WebKit Bug Importer]

<rdar://problem/13899158>

[James Craig]

This should go in line with standard HIG for full keyboard access on Mac.

• Spacebar to activate focused element.
• Escape to dismiss views that are "cancelable."
• Return to activate any "default" button in the current view.
• Tab and Shift+Tab to navigate linearly.
• Arrow keys to change the selection of any managed focus widgets like trees or listboxes.
• Left/Right arrows to expand/collapse nodes where appropriate.
• maybe more.

[Timothy Hatcher]

We do support up/down left/right with the desired behaviors. VoiceOver just does not follow along.

[James Craig]

Full Keyboard Access (and Zoom, and VoiceOver) doesn't follow along because .focus() isn't called at the right times. VoiceOver will also need some additional properties changed to get correct behavior (aria-level, aria-expanded, etc) but this problem affects more than just VoiceOver.

[Timothy Hatcher]

What is affected other than VoiceOver?

[Victor Tsaran]

(In reply to comment #5)
> What is affected other than VoiceOver?

Pretty much any assistive technology that relies on the actual keyboard focus is affected. See Comment4 for more information.

[James Craig]

(In reply to comment #5)
> What is affected other than VoiceOver?

As Victor mentioned, third-party assistive technologies like ZoomText and SwitchXS rely on system keyboard focus events, as does VoiceOver and other built-in interfaces like full keyboard access, and even Zoom when you enable the “Zoom follows keyboard focus” setting.

[Timothy Hatcher]

(In reply to comment #7)
> (In reply to comment #5)
> > What is affected other than VoiceOver?
> 
> As Victor mentioned, third-party assistive technologies like ZoomText and SwitchXS rely on system keyboard focus events, as does VoiceOver and other built-in interfaces like full keyboard access, and even Zoom when you enable the “Zoom follows keyboard focus” setting.

Ok, that makes sense. Thanks!