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.
(In reply to Michael Weghorn from comment #2) > I plan to take a look at that sometime these days. Pending fix: https://gerrit.libreoffice.org/c/core/+/187327 (In reply to V Stuart Foote from comment #3) > 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. I'm still not sure I fully understand what you mean. Are you saying that e.g. clicking on the "All Four Borders" item in the "Presets" section results in the focus moving to the "User-defined" section for you? If that were the case, then I'd agree that Shift+Tab should move focus back to the item in "Presets". However, when I click on "All Four Borders", then it gets focus (as expected) and therefore Shift+Tab moving focus to the tabbar seems logical (just like plain Tab moving focus to the "User-defined" section). Does that behave differently for you? Or am I still misunderstanding what's going on? (Can you maybe attach a screencast in that case?)
(In reply to Michael Weghorn from comment #4) > Does that behave differently for you? Or am I still misunderstanding what's > going on? (Can you maybe attach a screencast in that case?) I think it is going to be fine reading through your fix in https://gerrit.libreoffice.org/c/core/+/187327 My steps have been that when I have NVDA running, I enable the Preferences -> Settings -> Vision tab checkboxes to show the highlighting for the system focus and navigation object, along with the Tools -> Speech viewer. Visual Focus of the UI into the "Border settings option pane" and differing soundings from mouse-over and click actions, obscured that the UI was still on the "Line arrangement option pane" even though event focus had moved into the Border settings. Then just different soundings sequence when <Shift><Tab> backward from the "Padding" option pane. As compared to click select into the Line arrangement and <Tab> forward backward from there. Simple <Tab> forward and backward between the panes sound/show each in sequence as expected.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bec0b0c3d7510d979b50b013b2025afeb2df158e tdf#167279 svx FrameSelector a11y: Don't send focus events when only selecting It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to V Stuart Foote from comment #5) > My steps have been that when I have NVDA running, I enable the Preferences > -> Settings -> Vision tab checkboxes to show the highlighting for the system > focus and navigation object, along with the Tools -> Speech viewer. > > Visual Focus of the UI into the "Border settings option pane" and differing > soundings from mouse-over and click actions, obscured that the UI was still > on the "Line arrangement option pane" even though event focus had moved into > the Border settings. > > Then just different soundings sequence when <Shift><Tab> backward from the > "Padding" option pane. As compared to click select into the Line arrangement > and <Tab> forward backward from there. Simple <Tab> forward and backward > between the panes sound/show each in sequence as expected. Thanks for the clarification. That's indeed the same underlying problem (incorrect focus events) as the one causing the wrong announcement and is fixed now.