Was checking resents for interaction with NVDA 2015.1.2 36913 With move to vertical tabs noticed the Paragraph... -> Borders tab has some odd keyboard movements in the Line Arrangement widget. The list of 'Presets' indicates "five", but Cursor <L,U,R,D> movements position fire event in the graphical picker and don't sound the preset list. Scraping with mouse shows tooltips for the presets. No Borders All Four Borders Left and Right Borders Only Top and Bottom Borders Only Left Border Click selection on any of the presets triggers the graphical picker, but in a weird way. <Tab> advances to 'Padding' so not trapped. But then a <Shift><Tab> after a preset click selection moves back to the dialog's Tab bar. While <Shift><Tab> after advancing to Padding, moves back to graphical picker AND then back to the Presets. @Michael, does this behave as you'd expect? Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c771c2431453414d4a7a9b730032fc77b78f437f CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 25.2.4.3 (X86_64) / LibreOffice Community Build ID: 33e196637044ead23f5c3226cde09b47731f7e27 CPU threads: 28; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to V Stuart Foote from comment #1) > Was checking resents for interaction with NVDA 2015.1.2 36913 > > With move to vertical tabs noticed the Paragraph... -> Borders tab has some > odd keyboard movements in the Line Arrangement widget. > > The list of 'Presets' indicates "five", but Cursor <L,U,R,D> movements > position fire event in the graphical picker and don't sound the preset list. Interestingly, announcement with Orca is fine with the qt6 VCL plugin on Linux, but not with gtk3 or with NVDA on Windows. The correct object:active-descendant-changed event for the newly active "Presets" item seems to be followed by incorrect object:state-changed:focused events for the newly active borders in the "User-defined" graphical display of currently active borders, causing those to be announced by the screen readers. I plan to take a look at that sometime these days. For the other aspects you mention: > Scraping with mouse shows tooltips for the presets. > > No Borders > All Four Borders > Left and Right Borders Only > Top and Bottom Borders Only > Left Border > > Click selection on any of the presets triggers the graphical picker, but in > a weird way. Is that a separate issue? If so, can you please be more specific what happens (something on screen reader/a11y level only or would you also expect something else visually?) and what you'd expect? (Feel free to say you can only answer that question once the other issue mentioned above is fixed.) > <Tab> advances to 'Padding' so not trapped. But then a <Shift><Tab> after a > preset click selection moves back to the dialog's Tab bar. While > <Shift><Tab> after advancing to Padding, moves back to graphical picker AND > then back to the Presets. That seems logical to me, as the tab order is * Tab bar * "Presets" * graphical picker labelled "User-defined" * "Left" spinbox in the "Padding" section What you describe in my understanding matches that Tab moves forward, Shift+Tab moves backward one step in that chain. Or am I missing something? Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bc58a54d513702bc07906627dce073f05d7978fd CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: qt6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
(In reply to Michael Weghorn from comment #2) > > Interestingly, announcement with Orca is fine with the qt6 VCL plugin on > Linux, but not with gtk3 or with NVDA on Windows. The correct > object:active-descendant-changed event for the newly active "Presets" item > seems to be followed by incorrect object:state-changed:focused events for > the newly active borders in the "User-defined" graphical display of > currently active borders, causing those to be announced by the screen > readers. > I plan to take a look at that sometime these days. Thanks as always! > > For the other aspects you mention: > > > Scraping with mouse shows tooltips for the presets. > > > > No Borders > > All Four Borders > > Left and Right Borders Only > > Top and Bottom Borders Only > > Left Border > > > > Click selection on any of the presets triggers the graphical picker, but in > > a weird way. > > Is that a separate issue? If so, can you please be more specific what > happens (something on screen reader/a11y level only or would you also expect > something else visually?) and what you'd expect? > (Feel free to say you can only answer that question once the other issue > mentioned above is fixed.) > Same issue I'd say. The tooltips are expected just preset/tooltip not sounded. While the result of clicking on presets matches behavior of the cursor movements--same wrong element of user-defined gets focus and event sounding. So not weird, just wrong in the same way. > > > <Tab> advances to 'Padding' so not trapped. But then a <Shift><Tab> after a > > preset click selection moves back to the dialog's Tab bar. While > > <Shift><Tab> after advancing to Padding, moves back to graphical picker AND > > then back to the Presets. > > That seems logical to me, as the tab order is > > * Tab bar > * "Presets" > * graphical picker labelled "User-defined" > * "Left" spinbox in the "Padding" section > > What you describe in my understanding matches that Tab moves forward, > Shift+Tab moves backward one step in that chain. Or am I missing something? > But if you click select one of the presets, the cursor focus jumps to its associated user-defined position. <Shift><Tab> from there moves cursor focus up to the Borders tab. While it should not move down into the user-defined to begin with, it just seems weird that leaving it moves over the presets bar to the Borders tab name. As compared to clicking directly on one of the user-defined edges where a <Shift><Tab> does move to the Presets bar.