Apache OpenOffice (AOO) Bugzilla – Issue 122455
[sidebar] confusing object sequence in panels disrupts keyboard navigation of UI--some re-sequencing required
Last modified: 2022-10-28 12:54:16 UTC
Effective use of keyboard requires consistent movement between objects in the UI. Mouse movement and click actions of the GUI gloss over any underlying break in linear sequence of objects accessed with keyboard only navigation/selection. Characterize the disjointed movement as either 1). faulty UX layout of functional organization of toolbar widgets, i.e. wrong sequence moving from tool to tool. Or 2)., UI structural flaw in flow from element to element in the Deck, Panels or Tab bar. Working on Windows 7 sp1, 64bit AOO400m2(Build:9701) - Rev. 1489073 2013-06-03 13:48:37 (Mo, 03 Jun 2013) Have not review 100% of current sidebar implementation but as examples: Type 1). -- inconsistent UX layout, movement correct but object sequence not logical Writer -> Properties deck -> Paragraph panel the Line Spacing toolbar is present in the midst of the decimal value rollers toolbars for the Indent and Spacing Above/Below would make more sense--better sequence--to group Line spacing and its space above/below paragraph roller toolbars before the Spacing toolbar, and to group the Indent toolbar and its roller tollbars following the line spacing. Type 2). -- inconsistent keyboard movement to unexpected UI elements Writer -> Styles & Formatting deck (i.e. sidebar integration of the <F11> frame) keyboard navigation w/<F6> moves to Deck title bar, and <TAB> into Styles & Formatting panel lands immediately in a the Paragraph Styles tree list. Necessary to <TAB> <TAB> to cycle to the Styles & Formatting toolbar and gain cursor <LEFT>,<RIGHT> navigation in that tool bar. Would expect to enter the Panel landing on the Toolbar to be able to cursor navigate to desired Style & Formatting toolbar button, and select it to enter its tree list. That is what seems to be the default behavior, but does not occur in this panel. Keyboard behavior of <ESC>, <F6>, <TAB>, <ENTER>, and cursors <UP>,<RIGHT>,<DOWN> & <LEFT>, should be consistent on all instances of the Deck, for each Panel and associated Toolbars and widgets, as well as for the Tab bar. While re-sequencing of panels to group related tools with reasonable keyboard progression will improve the UI. And finally cleaning up any faulty keyboard navigation from imbedded menu/panel objects like those introduced with the Style & Formatting <F11> panel are now necessary to make side fully keyboard navigable.
(In reply to V Stuart Foote from comment #0) > Type 1). -- inconsistent UX layout, movement correct but object sequence not > logical > > Writer -> Properties deck -> Paragraph panel > the Line Spacing toolbar is present in the midst of the decimal > value rollers toolbars for the Indent and Spacing Above/Below > > would make more sense--better sequence--to group Line spacing and its > space above/below paragraph roller toolbars before the Spacing toolbar, > and to group the Indent toolbar and its roller tollbars following the line > spacing. > A bit more regards this aspect. The widget placement in the GUI does group the toolbars graphically. But keyboard navigation <TAB>, <Shift><TAB> does not follow the graphical grouping. So toolbars are reached out of sequence within the panel. That is, in the Properties -> Paragraph panel, the GUI has Spacing tools grouped vertically--Increase/Decrease toolbar, Above Paragraph, Below Paragraph and Line Spacing-- on the left. And on the right GUI widgets for Indent tools grouped vertically as well--Increase/Decrease/SwithHanging, Before Text, After Text, First Line. But as is, keyboard navigation proceeds Spacing tool -> Indent tool-> Spacing tool -> Indent tool... Keyboard navigation "sequencing" should follow logical/functional grouping of the GUI widgets.
"af" committed SVN revision 1490300 into trunk: 122455: Change tab order of paragraph panel. Cleanup.
Hm, somehow my comment got lost (or I dreamed that I wrote it). Re 1: I completely agree that the tab order in the paragraph panel is better by-column than by-row. Re 2: The tab order in the "Styles and Formatting" panel is more a question of UX design than one of accessibility. The tab order is defined under the assumption that a style selection in the main list control is made more frequently than switching between different style 'types' (paragraph, character, and so on). I have no reason to believe that this assumption is wrong. Therefore I will not change the tab order in this panel (until I get convinced otherwise :-) Re general problems of tab order: I don't have the time to check each panel. But I am willing to make the necessary changes if somebody else has a concrete proposal, like the one for 1). Fixed the tab order in the paragraph panel and am therefore setting the status of this bug to resolved/fixed.
(In reply to Andre from comment #3) > Re general problems of tab order: I don't have the time to check each panel. > But I am willing to make the necessary changes if somebody else has a > concrete proposal, like the one for 1). > Understand, was planning on more systematically working through the entire UI. Will update/reopen with any additional keyboard navigation issues I find. > ... I have no reason to believe that this assumption is wrong. > Therefore I will >not change the tab order in this panel (until I get > convinced otherwise :-) Regards GTK wrapper navigation of the Styles & Formatting panel. Understand it comes in as baggage with the existing frame <F11>, but the sidebar focus "navigation" landing in the panel with the Paragraph toolbar and its tree list active seems inconsistent for keyboard use of the sidebar. Inconsistency impacts accessibility. So while it does not matter too much for GUI users of mouse navigation, for keyboard navigation it would be more consistent to land on the Panel title -> and <TAB> onto toolbar buttons (Paragraph would be expected as it is the first on the toolbar), rather than dropping directly into the Paragraph tree list. And landing focus on the Toolbar buttons then makes cursor navigation between the Paragraph, Character, Frame, Page, List styles consistent. Again GUI users are not affected as they point and click--keyboard users, especially for AT require consistent behavior. Not clear to me how much of the Styles and Formatting panel is simple wrapper of the <F11> GUI frame, but there do seem to be keyboard navigation UX issues in existing GUI as well.
(In reply to V Stuart Foote from comment #4) > (In reply to Andre from comment #3) > > > Re general problems of tab order: I don't have the time to check each panel. > > But I am willing to make the necessary changes if somebody else has a > > concrete proposal, like the one for 1). > > > Understand, was planning on more systematically working through the entire > UI. Will update/reopen with any additional keyboard navigation issues I find. Great. I was hoping you would. > > > ... I have no reason to believe that this assumption is wrong. > > Therefore I will >not change the tab order in this panel (until I get > > convinced otherwise :-) > > Regards GTK wrapper navigation of the Styles & Formatting panel. Understand > it comes in as baggage with the existing frame <F11>, but the sidebar focus > "navigation" landing in the panel with the Paragraph toolbar and its tree > list active seems inconsistent for keyboard use of the sidebar. > Inconsistency impacts accessibility. > > So while it does not matter too much for GUI users of mouse navigation, for > keyboard navigation it would be more consistent to land on the Panel title > -> and <TAB> onto toolbar buttons (Paragraph would be expected as it is the > first on the toolbar), rather than dropping directly into the Paragraph tree > list. > > And landing focus on the Toolbar buttons then makes cursor navigation > between the Paragraph, Character, Frame, Page, List styles consistent. Again > GUI users are not affected as they point and click--keyboard users, > especially for AT require consistent behavior. > > Not clear to me how much of the Styles and Formatting panel is simple > wrapper of the <F11> GUI frame, but there do seem to be keyboard navigation > UX issues in existing GUI as well. You are right. It the panel is basically just a wrapper. Change the tab order of one and you change the tab order of the other as well. But this is not just a technical problem. Keyboard accessibility is not only an accessibility issue (in the sense of section 508). It is feature for all people who use the keyboard to accelerate their work. We have to find a compromise between consistency and speeding up your work flow. Maybe this is something that we should discuss on the dev list?
(In reply to SVN Robot from comment #2) > "af" committed SVN revision 1490300 into trunk: > 122455: Change tab order of paragraph panel. Cleanup. verify the navigation order of paragraph panel is more "reasonable" with r1490908 build on Linux 64-bit AOO400m2(Build:9701) - Rev. 1490898 2013-06-08_04:09:38 - Rev. 1490908