Steps: 1. Open Writer 2. Expand Special Character group button 3. Navigate characters with Tab or arrows Results: In 6.4, characters were read. In 7.0, could not navigate anymore with the keyboard In 7.1, could navigate with keyboard but characters weren't read anymore Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Same in recent master build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 42364fbfafaa95773c073cc080142b64ec1786fb CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Using Ubuntu 20.04 with GNOME 3.36.8 and Orca 3.36.2-1ubuntu1~20.04.2
Drive by comment: * The upcoming stable version of Orca is 45.x * Previous version: 44.x * Previous version: 43.x * Previous version: 42.x * Previous version: 41.x * Previous version: 40.x * Previous version: 3.38.x * Previous version: 3.36.x There have been a ton of changes made over the years (plural) to Orca after the version you are testing with. While I have no objection to the LO community ensuring accessibility with outdated versions of Orca, it might be worth testing to see if the problem has already been fixed though a change in Orca. (P.S. I'm the Orca maintainer)
Stéphane: I think it might be useful you upgrade Ubuntu to have more recent version of software like Orca. There's also a ppa repo for Orca where you can download more recent Orca versions, see https://launchpad.net/ubuntu/+source/orca
I can reproduce on Debian testing with Orca 44.1-2 and LO git master. NVDA 2023.1 on Windows just says "option pane" for any character, which isn't much better. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d1d07992a89ba503f1d457a8f79926063f4d3f9c CPU threads: 12; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d1d07992a89ba503f1d457a8f79926063f4d3f9c CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_DE); UI: en-US Calc: threaded
I cannot confirm with Orca 44.2, Ubuntu 22.04, LO 7.5.5. After expand Special characters I can Arrow Down over 100 rows and Arrow Right to a character, Tab to the Insert button and press Enter. Most of the characters have no clear name to tell what they exactly are. Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 4; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: nl-NL (nl_NL.UTF-8); UI: nl-NL Ubuntu package version: 4:7.5.5~rc2-0ubuntu0.22.04.1~lo1 Calc: threaded
Created attachment 188894 [details] Screenshot of the toolbar popup (In reply to Milton from comment #4) > I cannot confirm with Orca 44.2, Ubuntu 22.04, LO 7.5.5. After expand > Special characters I can Arrow Down over 100 rows and Arrow Right to a > character, Tab to the Insert button and press Enter. Most of the characters > have no clear name to tell what they exactly are. Are you talking about the special charactes *dialog* (which can be opened e.g. via "Insert" > "Special Characters" or selecting the "More Characters" button in the toolbar popup that this bug is about). I'm attaching a screenshot of the toolbar item that this is about. Are the characters right in there also announced for you when moving focus?
(In reply to Milton from comment #4) > I cannot confirm with Orca 44.2, Ubuntu 22.04, LO 7.5.5. After expand > Special characters I can Arrow Down over 100 rows and Arrow Right to a > character, Tab to the Insert button and press Enter. Most of the characters > have no clear name to tell what they exactly are. Yes, looks like you used the dialog and not the toolbar dropdown. I had noticed that issue with some characters being read out instead of being described (and therefore e.g. punctuation characters being ignored) but that should be handled in a different report.
Yes you are right. I can through menu Insert > Special characters but not through the tool bar by pressing F6 twice and arrow right to Special characters.
The "Recent Characters" and "Favorite Characters" in the Special Characters *dialog* are also not announced, only those in the "table"/grid view above. Pending Gerrit change to set the accessible name: https://gerrit.libreoffice.org/c/core/+/155757 With this in place, both Orca and NVDA announce characters in the dialog. NVDA also announces the character in the toolbar popup, but Orca doesn't do so yet; that needs further analysis.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5b7d9f21ef74601f4893dd07e8e3f2bf34427eb0 tdf#156699 sfx2: Extract helper method to get char value + name It will be available in 24.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8c4fa83191e6df5d823386cca2adc30dbbc9e297 tdf#156699 a11y: Set a11y name for SvxCharView It will be available in 24.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 case it is helpful to figure out a solution: bibisected with linux-64-7.0 repo to first bad commit 8091bc8471a23a54ddad81eb85f06a643aa6f54b which points to core commit: commit 94c1f5cfb96a826220b64608cf0ada76d3bdde31 author Caolán McNamara Mon Jan 13 09:14:39 2020 +0000 committer Caolán McNamara Tue Jan 14 11:51:06 2020 +0100 rework SfxCharmapCtrl to be a PopupWindowController Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86664 (In reply to Michael Weghorn from comment #8) > [...] but Orca doesn't do > so yet; that needs further analysis. Confirmed that Orca still doesn't read them in: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2902ab24ecc5ffbf4907ea83b2028508b9de6364 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: es-MX (en_AU.UTF-8); UI: en-US Calc: threaded
Still reproducible with current master (as of 5f15f953f34eef1e165af4f935fab6533fd49bc6) and orca 48.1-1 in Debian testing. state-changed:focused events are apparently sent, but ignored by Orca due to some issue with the top-level window not having the active state. Might be worth checking whether one of one of ("popup", "application window") is considered the top-level while the other one has the active state set, or the state is missing altogether. From Orca debug log: 16:01:07.394919 - EVENT MANAGER: Dequeueing object:state-changed:focused for [drawing area: 'YEN SIGN'] in soffice (gtk 3.24.49) (1, 0, 0) 16:01:07.394947 - EVENT MANAGER: Dequeued object:state-changed:focused for [drawing area: 'YEN SIGN'] in soffice (gtk 3.24.49) (1, 0, 0) priority: 3, counter: 524 vvvvv START PRIORITY-3 OBJECT EVENT OBJECT:STATE-CHANGED:FOCUSED (queue size: 19) vvvvv 16:01:07.395306 - AXObject: Treating soffice as not supporting collection. 16:01:07.395627 - EVENT SOURCE: app='soffice (gtk 3.24.49)' name='YEN SIGN' role='drawing area' id='favchar2' description='' help='' states='enabled, focusable, focused, has-tooltip, sensitive, showing, visible' relations='' actions='' interfaces='Component' attributes='toolkit:gtk' text='' path=[-1, 0, 0, 1, 0, 2, 0, 43, 0, 0, 0, 0, 0, 0, 1, 14] 16:01:07.395640 - SCRIPT MANAGER: Active script is: soffice (module=orca.scripts.apps.soffice.script) 16:01:07.395653 - FOCUS MANAGER: Locus of focus is [drawing area: 'EURO SIGN'] 16:01:07.395673 - EVENT MANAGER: Getting script for event for [application: 'soffice'] [drawing area: 'YEN SIGN'] 16:01:07.395686 - SCRIPT MANAGER: Getting script for [application: 'soffice'] [drawing area: 'YEN SIGN'] 16:01:07.395704 - SCRIPT MANAGER: Script is app script soffice (module=orca.scripts.apps.soffice.script) 16:01:07.395713 - EVENT MANAGER: Script for event is soffice (module=orca.scripts.apps.soffice.script) 16:01:07.395730 - EVENT MANAGER: Processing object:state-changed:focused: script for event is active 16:01:07.395744 - FOCUS MANAGER: Locus of focus is [drawing area: 'EURO SIGN'] 16:01:07.395755 - TABLE NAVIGATOR: Last navigation event (None) was last key event: False 16:01:07.395778 - AXUtilitiesRelation: [drawing area: 'YEN SIGN'] flows from: [] 16:01:07.395791 - AXUtilitiesRelation: [drawing area: 'YEN SIGN'] flows to: [] 16:01:07.396081 - SCRIPT UTILITIES: [frame: 'Untitled 1 — LibreOfficeDev Writer 26.2 [5f15f953f34eef1e165af4f935fab6533fd49bc6]'] is top-level object for: [drawing area: 'YEN SIGN'] 16:01:07.396335 - SCRIPT UTILITIES: [drawing area: 'YEN SIGN'] is in frame [frame: 'Untitled 1 — LibreOfficeDev Writer 26.2 [5f15f953f34eef1e165af4f935fab6533fd49bc6]'] and dialog None 16:01:07.396355 - AXObject: Clearing AT-SPI cache on [frame: 'Untitled 1 — LibreOfficeDev Writer 26.2 [5f15f953f34eef1e165af4f935fab6533fd49bc6]'] Recursive: False. Reason: Checking if window can be the active window 16:01:07.396550 - AXUtilities: [frame: 'Untitled 1 — LibreOfficeDev Writer 26.2 [5f15f953f34eef1e165af4f935fab6533fd49bc6]'] from [application: 'soffice'] lacks active state TOTAL PROCESSING TIME: 0.0016 ^^^^^ FINISHED PRIORITY-3 OBJECT EVENT OBJECT:STATE-CHANGED:FOCUSED ^^^^^
(In reply to Michael Weghorn from comment #12) > state-changed:focused events are apparently sent, but ignored by Orca due to > some issue with the top-level window not having the active state. Indeed. This quick hack in Orca (on top of main as of 36c65394e0ec085175c5a45341f89527084cf068) to drop that check makes it announce the popup + focus changes in there: diff --git a/src/orca/ax_utilities.py b/src/orca/ax_utilities.py index 98a738037..f01ada61c 100644 --- a/src/orca/ax_utilities.py +++ b/src/orca/ax_utilities.py @@ -121,10 +121,10 @@ class AXUtilities: app = AXUtilitiesApplication.get_application(window) tokens = ["AXUtilities:", window, "from", app] - if not AXUtilitiesState.is_active(window): - tokens.append("lacks active state") - debug.print_tokens(debug.LEVEL_INFO, tokens, True) - return False + #if not AXUtilitiesState.is_active(window): + # #tokens.append("lacks active state") + # debug.print_tokens(debug.LEVEL_INFO, tokens, True) + # return False if not AXUtilitiesState.is_showing(window): tokens.append("lacks showing state")
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3afb46a3a2b178ba2ccb698d5e2b7a8f017a331c Resolves: tdf#156699 Contents of toplevel toolbar popups not read by Orca It will be available in 26.8.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.
I'm not entirely convinced this is the right approach, but it does work for me. The whole popup thing looks trivial but is an endless source of pain. I think its no coincidence that it tends to be GtkPopovers that are limited to existing inside their parents that are the artifacts we see in gtk applications of now.
Fix verified with current master. Thanks, Caolán! Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 87c68c17afc4c7b9d2fd2164f91b0df8bbb20155 CPU threads: 32; OS: Linux 6.18; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded