Bug 115974

Summary:	Web Inspector: FKA: The DOM tree display should provide full keyboard accessibility
Product:	WebKit	Reporter:	Victor Tsaran <vtsaran>
Component:	Web Inspector	Assignee:	Nobody <webkit-unassigned>
Status:	NEW ---
Severity:	Normal	CC:	cfleizach, inspector-bugzilla-changes, jcraig, keeganstreet, vtsaran, webkit-bug-importer
Priority:	P2	Keywords:	InRadar
Version:	528+ (Nightly build)
Hardware:	All
OS:	All

Description Victor Tsaran 2013-05-11 19:19:32 PDT

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.

Comment 1 Radar WebKit Bug Importer 2013-05-15 07:03:02 PDT

<rdar://problem/13899158>

Comment 2 James Craig 2013-06-26 12:16:25 PDT

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.

Comment 3 Timothy Hatcher 2013-07-01 14:48:45 PDT

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

Comment 4 James Craig 2013-07-01 16:51:31 PDT

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.

Comment 5 Timothy Hatcher 2013-07-02 10:51:51 PDT

What is affected other than VoiceOver?

Comment 6 Victor Tsaran 2013-07-02 22:45:24 PDT

(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.

Comment 7 James Craig 2013-07-02 23:47:23 PDT

(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.

Comment 8 Timothy Hatcher 2013-07-03 11:13:48 PDT

(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!