Description: Orca now listens for document:page-change event and announces the new page number. It would be nice for this to work with LO Writer documents. Steps to Reproduce: 1. Launch Orca (built from its main branch; not a stable release version) 2. In a multi-page Writer document, move from page to page Actual Results: Orca does not announce the number of the newly-shown page. Expected Results: Orca announces the number of the newly-shown page. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.4.1 (X86_64) Build ID: 60(Build:1) CPU threads: 48; OS: Linux 6.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Sounds reasonable. Some first thoughts and a question: (In reply to Joanmarie Diggs from comment #0) > Orca now listens for document:page-change event and announces the new page > number. It would be nice for this to work with LO Writer documents. For reference, Orca commit adding that feature: commit 6f16c0036c4896d578cb80aaf4041c805efe9457 Author: Joanmarie Diggs Date: Fri Feb 9 11:40:55 2024 +0100 Listen for and preent document:page-changed events Note that very few apps currently fire this event. Evince appears to be the exception; not the rule. But we can ask (at least) LO Writer to start doing so. The discussion in tdf#158029 has more infos/thoughts/links regarding support for the AT-SPI Document interface (currently only supported by GTK 3, but ideally any solution should also work with GTK 4 and Qt). Writer's a11y tree currently doesn't have pages (Paragraphs are direct children of the doc.) but we might get away with that for the use case described here, as a page object doesn't seem to be needed (just an integer referring to the page number). ## Concept/Definition of "current page" (In reply to Joanmarie Diggs from comment #0) > 2. In a multi-page Writer document, move from page to page > > (...) > > Expected Results: > Orca announces the number of the newly-shown page. Writer currently seems to have 2 different concepts of a "current page": 1) page in the view, for which there's interestingly already a `SwCursorShell::FirePageChangeEvent` method that gets called, but doesn't do anything, as `ACCESSIBLE_LAYOUT` is never defined (and if it were, the code wouldn't compile): void SwCursorShell::FirePageChangeEvent(sal_uInt16 nOldPage, sal_uInt16 nNewPage) { #ifdef ACCESSIBLE_LAYOUT if( Imp()->IsAccessible() ) Imp()->FirePageChangeEvent( nOldPage, nNewPage ); #else ... From a first look/test, this seems to refer to the topmost currently visible page, as displayed in the status bar (e.g. 4 when "Pages 4 and 5 of 5" is displayed there) and therefore roughly gets called whenever the topmost visible page changes. e.g. scrolling down until the first page of the document is no longer visible -> new current page is 2, independent of where the cursor is 2) The page that the cursor is currently on, which is currently already exposed by a11y object attributes on the Writer document object: "page-number", "page-name" Do you have a suggestion to which of these the "current page" from the AT-SPI Document should refer? (IIRC, NVDA currently announces 2) when the cursor moves to another page.) ## LO-internal + LO platform bridges Could either introduce a new interface or handle that only in the platform bridges, e.g. support AT-SPI Document when the document role is used and certain attributes are set. If 2) is used for the "current page", handling attribute-changes to "object:attribute-changed:page-number" could then be forwarded as document:page-change in addition. Likewise for a still-to-be-added object attribute in the case of 1). Actually, we currently don't have events for attribute changes, but that could be useful to add, see also https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/144 and the Orca issue referenced from there. In general, Orca could even process the corresponding object::atribute-changed event directly (e.g. in the soffice script) to announce the new page even without the Document interface being present (yet) and the document:page-change event getting sent. ## Qt Qt interestingly already has a `QAccessible::PageChanged` event type (s. https://doc.qt.io/qt-6/qaccessible.html ) which is not used anywhere and not mapped to anything in the AT-SPI bridge at the moment, though). Since I didn't see any equivalent of the AT-SPI Document iface for other platforms, it might be non-trivial to argue for adding a dedicated interface to the Qt a11y API. But maybe an alternative might be to use specific object attributes (if support for these gets added, s. suggested https://codereview.qt-project.org/c/qt/qtbase/+/517525 ) and then let the AT-SPI adaptor support the Document interface when the object has a document role and supports the relevant attributes of the Document interface (page number, page count, locale, and a set of not further specified "document attributes", which could either each be a separate attribute in the suggested QAccessibleAttributesInterface or by adding e.g. a QAccessible::Attribute::DocAttrs attribute that's a QHash, and thus would allow setting arbitrary key-value pairs again.) ## Gtk 4 s. tdf#158029 and https://gitlab.gnome.org/GNOME/gtk/-/issues/6197 Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ad4a06692b05c4312c1c7c8a8ff38cf12422e692 CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
(In reply to Michael Weghorn from comment #1) > Actually, we currently don't have events for attribute changes, but that > could be useful to add, see also > https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/144 and the Orca issue > referenced from there. Reading the remaining orca git log, I noticed the mention of the AT-SPI side for this actually being implemented now. :-) So only the LO side (+ toolkits other than ATK) + mapping to AT-SPI is currently still missing. AT-SPI commit and issue in whose context this was implemented: https://gitlab.gnome.org/GNOME/at-spi2-core/-/commit/8b49d96e15ce246b6078e28685e22ca1b1416017 https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/153