Issue 123633

Summary: [ia2] Impress: Focus weirdness with slide layouts list after creating a presentation/slide
Product: General Reporter: James Teh <jamie>
Component: accessibilityAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Normal    
Priority: P3 CC: issues, vsfoote
Version: 4.1.0-dev   
Target Milestone: ---   
Hardware: PC   
OS: Windows, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 121767    

Description James Teh 2013-11-05 03:48:18 UTC
Str:
1. Create a blank presentation.
Result: According to accessibility, focus lands in the slide layouts list.
2. Press right arrow to select a different layout.
Expected: A different item in the layouts list should be focused.
Actual: The presentation document accessible gets focused.
3. From the Insert menu, select Slide.
Result: According to accessibility, focus lands in the slide layouts list.
4. Press right arrow to select a different layout.
Expected: A different item in the layouts list should be focused.
Actual: Nothing happens.

It seems that keyboard focus and accessibility focus don't match here. If you press f6 when this occurs, you land in the menu bar, which suggests keyboard focus is actually on the presentation itself. I'm not sure about visual focus. It's possible this is actually a keyboard UI bug and not an accessibility API implementation bug, in which case it should possibly be moved into a more appropriate component.
Comment 1 V Stuart Foote 2013-11-12 21:52:44 UTC
On Windows 7 sp1 64-bit with NVDA 2013.2 active
AOO410m1(Build:9750)  -  Rev. 1540658
Rev.1540658

Confirming this behavior, and also noting occurrence of multiple keyboard traps where <TAB> and Cursor <U,D,L,R> or <ESC> keys alone can not navigate out of the multiline editable text blocks. <F6> movements can reposition focus and text caret.   But mouse movements and clicks are required to navigate and complete text entry into editable text blocks. 

Also, when new text based slides are inserted, the prominent "click to add text" comments visible in the slide layouts are not exposed to AT and do not sound.

For these inserted slides the IAccessible role shows as Shape - editable while the MSAA accName & accRole sometimes show rootPane and other times clientArea with several differing accNames.

In short, it is very unusable from keyboard only navigation and input.
Comment 2 James Teh 2013-11-13 01:23:19 UTC
(In reply to V Stuart Foote from comment #1)
> Confirming this behavior, and also noting occurrence of multiple keyboard
> traps where <TAB> and Cursor <U,D,L,R> or <ESC> keys alone can not navigate
> out of the multiline editable text blocks.
I haven't seen this one. Escape always seems to exit them for me. Perhaps this should be filed as a separate bug with specific str.

> Also, when new text based slides are inserted, the prominent "click to add
> text" comments visible in the slide layouts are not exposed to AT and do not
> sound.
They are exposed, but they're a child of the shape. This is consistent with the OO convention of representing individual paragraphs as separate objects. In some ways, this isn't ideal, but ATs already need some specific code to deal with this for Writer, so this too will probably just be something that needs to be handled in ATs.