Other than most of the a11y implementations for vcl
classes, VCLXAccessiblePopupMenu etc. do not
make use of any VCLXWindow (i.e. UNO/toolkit wrapper of a
vcl::Window) and thus do not depend on the toolkit
module, which the accessibility module depends on.
Therefore, there's also no need to use the accessible
factory to create them (which is needed when toolkit
classes are involved to avoid a dependency cycle).
Move those classes from the accessibility module to
vcl and add a new method Menu::CreateAccessible and
move the logic from AccessibleFactory::createAccessible
there. Drop the now unnecessary factory methods
previously used for those classes.
No change in behavior intended (yet), but this
also simplifies the code involved for the
tdf#164093 scenario.
Change-Id: Ie3f6f1a02bf6662206d31383473cdc868e1f9164
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177812
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This method from the unpublished XAccessibleExtendedComponent
interface is not used by any of the a11y platform bridges, and
I don't know of any platform a11y API that would need it.
In order to report character/font attributes, there is the
XAccessibleText interface and its
XAccessiText::getCharacterAttributes method instead, which
actually gets used by the platform a11y bridges.
Therefore, drop this method to simplify code, and also decouple
the accessibility module a bit further from the toolkit
module without having to reorganize code further.
(VCLXFont from the toolkit module currently gets used in
various implementations.)
Change-Id: I06ea3cc5998a13927b3f869877b28f03ac07c89b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177809
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The "The role is always AccessibleRole::COMBO_BOX." comment
for VCLXAccessibleBox::getAccessibleRole is misleading,
as the actual implementation can also return AccessibleRole::PANEL.
Change-Id: I15b089e168aa7ec0701eacc8630023123f3a10dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177313
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It will be reused in another method in an upcoming commit.
Change-Id: Ie6b4559e268d9340b5b13844c906232c6ff38a6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177312
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Instead of having a purely virtual
VCLXAccessibleBox::IsValid that all subclasses
implement the same way, deduplicate this by
moving the implementation to the VCLXAccessibleBox
base class.
Change-Id: I354bf3d0be6751a165b373c06b951c6f0b63480b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177252
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Was previously changed the other way around in
commit 28c89e58d9
Date: Wed Aug 30 15:16:01 2023 +0200
use concrete type for OAccessibleMenuBaseComponent::m_aAccessibleChildren
for no apparent reason.
Change-Id: I0d0c6627134bcef8ac9732cc8a5213ab266afbf7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168005
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
... which is only used in the next line anyway.
Change-Id: I3bb038cfba3b3b31df45ca316242d54442db7220
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168004
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
When the text of an editable combobox is changed
(e.g. using the up/down keys), the Orca screen
reader on Linux announces the newly inserted text.
This has been the case for other GTK or Qt
applications for a while, and with recent Orca
commit [1]
commit 3a9e6b8d7b16bf2fc7919868cfd1a16e44422710
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri May 10 10:16:58 2024 +0200
soffice: Use default logic for editable combobox value change
, the same logic is used for LibreOffice as well.
For the gtk3 VCL plugin which has a custom combobox
implementation using native GTK widgets, this generally
works since
commit 9f078ed7b6
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue May 7 10:04:16 2024 +0200
tdf#160971 gtk3 a11y: Set role for custom editable combobox
However, the qt6 VCL plugin uses the VCL combobox
implementation, and only the actual difference between
the text of the previous and current entry was sent
in the TEXT_CHANGED event, resulting in Orca only
announcing those letters that were added/changed,
e.g. just "ans Narrow" when changing the font in the
Writer formatting toolbar from "Liberation Serif"
to "Liberation Sans Narrow".
This doesn't really make clear what entry is selected.
Align the a11y event with what GTK and Qt do
and set the full old and new entry texts in the event.
To do that, add a new virtual
`VCLXAccessibleTextComponent:PreferFullTextInTextChangedEvent`
that defaults to false to keep the previous behavior as default,
and override it for `VCLXAccessibleEdit` to return true
in the case that the edit is the subedit of a combobox
(the parent has a combobox role).
Use this in `VCLXAccessibleTextComponent::SetText` to
determine whether to notify just of the changed characters
or to send the whole old/new text.
With this in place, Orca also announces the whole new
entry text (e.g. "Liberation Sans Narrow" for the above
example) when using the qt6 VCL plugin.
(It currently additionally announces an extra "Selection
deleted" when switching entries, as the text selection
also changes, but that aspect is to be handled separate
from this change here.)
[1] 3a9e6b8d7b
Change-Id: I240aa0ad5ac9585e007d67a8c69e305cf1f38185
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167479
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Just use `comphelper::OAccessibleTextHelper` directly
where `AccessibleTextHelper_BASE` is a typedef for that.
There are other `AccessibleTextHelper_BASE` typedefs with
a different meaning elsewhere in the codebase, which are left unchanged.
Change-Id: I323a2b103eccfcfc4f726caffa73e586decf6d65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163960
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, the accessible name and the text of the item
were considered to be the same, and fallbacks to still
get something else for the accessible name in case
of no item text (to use the quick help text or the item
window's accessible name instead) were implemented directly in
`VCLXAccessibleToolBoxItem::implGetText`.
However, `VCLXAccessibleToolBoxItem::implGetText` is also
used by the implementations for the methods from the
`XAccessibleText` interface and that one is clearly about
text displayed on screen, so using e.g. the quick help/tooltip
text doesn't make sense then.
Let `VCLXAccessibleToolBoxItem::implGetText` only handle the
actual item text and move the fallbacks to a new helper
method `VCLXAccessibleToolBoxItem::implGetAccessibleName`
instead that is only used when the actual accessible name
is wanted.
Change-Id: Icc394022d036ca619622cee1390e28ab15014be1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163959
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
`VCLXAccessibleToolBoxItem::implGetText` was just calling
`VCLXAccessibleToolBoxItem::GetText`, and both of them
were used from different places.
Just move the implementation to `VCLXAccessibleToolBoxItem::implGetText`
right away, drop `VCLXAccessibleToolBoxItem::implGetText` and adjust
callers to unify this.
Change-Id: I0f4a4652f9e1259826a566d42b4b6998fc8ac7db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163958
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add reporting for the new CHECKABLE a11y state introduced in
commit d6c6472bbe
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Nov 13 15:53:44 2023 +0100
tdf#123864 a11y: Add new AccessibleStateType::CHECKABLE
for `VCLXAccessibleMenuItem`.
`MenuItemData::HasCheck` looks like it already provides
what's needed to say whether an item is checkable, therefore
add a `Menu::IsItemCheckable` that makes use of this and
and a `VCLXAccessibleMenuItem::IsCheckable` that
makes use of that in turn.
Extend `VCLXAccessibleMenuItem::FillAccessibleStateSet` to
use the latter to report the CHECKABLE state accordingly.
Change-Id: Id23196ef2527a71a338102a5143a8bd6fd41db84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160902
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use a vector of `rtl::Reference<VCLXAccessibleListItem>`
for the children instead of a vector of
`css::uno::Reference<css::accessibility::XAccessible>`
and casting in various places.
Change-Id: I1d0e72a7c844a685d762069002d747cf5e7d02dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156525
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
`VCLXAccessibleList` is the owner of the
`VCLXAccessibleListItem`s held in that vector,
so I see no reason to hold them by weak reference,
which according to the doc in
`udkapi/com/sun/star/uno/XWeak.idl` is to avoid
affecting the lifetime of the objects:
> <p>The sense of weak references is to hold a reference to an object
> without affecting the lifetime of the object. That means that a weak
> reference may become invalid, at any time, if the referenced object dies.
> </p>
Quite the contrary, it is actually responsible for the
lifecycle of the list item a11y objects and should dispose
them when itself gets disposed, which will be added
in a subsequent commit.
Change-Id: I57fe3367f1199cd0c24f006f6e25a1e9c930c154
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156521
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The text is at least often used for the accessible name of
text controls (e.g. the MultiLineEdit case in tdf#104833).
Therefore, also check whether the a11y name has changed
from the previously remembered one in
`VCLXAccessibleTextComponent::SetText` and send
a NAME_CHANGED event if it has.
This e.g. makes sure that the a11y name for the multi line
edit in the update dialog is updated on Windows
and NVDA properly announces it when it receives focus.
(It now correctly announces "LibreOfficeDev 24.2 is up to date."
instead of the obsolete cached name "Checking...").
Also see how `VCLXAccessibleTextComponent::ProcessWindowEvent`
calls `VCLXAccessibleTextComponent::SetText` when processing
`VclEventId::WindowFrameTitleChanged` and this comment in
`Window::SetText` mentions that `VclEventId::WindowFrameTitleChanged`
is used to notify about a11y name changes:
// #107247# needed for accessibility
// The VclEventId::WindowFrameTitleChanged is (mis)used to notify accessible name changes.
// Therefore a window, which is labeled by this window, must also notify an accessible
// name change.
Change-Id: I2f15fe78324b14c3bbeae943cb87384007e21618
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156411
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Don't rely on the `VCLXWindow` of the control
being a `VCLXEdit`, but use the `Edit` control
directly, as is already done in other methods
of this class.
This is in preparation of using
`VCLXAccessibleEdit` as the a11y class
for `MultiLineEdit` as well, which derives
from `Edit`, but its component interface class,
`VCLXMultiLineEdit` does not derive from `VCLXEdit`.
Already add reporting of the
`AccessibleStateType::MULTI_LINE` state instead of
`AccessibleStateType::SINGLE_LINE` to
`VCLXAccessibleTextComponent::FillAccessibleStateSet`
if the window type is `WindowType::MULTILINEEDIT`.
Add a small helper function,
`VCLXAccessibleEdit::isEditable` to use instead
of `VCLXEdit::isEditable`, which does the same.
Interacting with the single line edit from
the sample dialog in attachment 189287 in tdf#104833
in Accerciser still behaves as expected (and the
text can still be edited when removing the
readonly flag from the control).
Change-Id: I8218db61feb07605f6ea5309f26eebd38312458a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156400
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Send a `AccessibleEventId::ROLE_CHANGED` event
when the accessible role of a menu item changes
(s. how `VCLXAccessibleMenuItem::getAccessibleRole`
takes into account `MenuItemBits::RADIOCHECK` and
`MenuItemBits::CHECKABLE` to determine the accessible
role for the underlying menu entry).
This fixes the issue of obsolete values for roles being
used, which was uncovered by the upcoming
Change-Id I1a047864ce8dc1f1bc3056ad00159f7fd5e5b7d3
("vcl gtk3: Introduce AT-SPI2 tests for the GTK3 accessibility layer").
With this in place, the workaround for tdf#155625 in
the upcoming gtk3/AT-SPI tests is no longer necessary
and `make CppunitTest_vcl_gtk3_a11y` with
https://gerrit.libreoffice.org/c/core/+/153069 patch set 11
still passes after dropping the workaround:
diff --git a/vcl/qa/cppunit/a11y/atspi2/atspi2.cxx b/vcl/qa/cppunit/a11y/atspi2/atspi2.cxx
index bbcd263fee0c..762401181bf4 100644
--- a/vcl/qa/cppunit/a11y/atspi2/atspi2.cxx
+++ b/vcl/qa/cppunit/a11y/atspi2/atspi2.cxx
@@ -264,9 +264,6 @@ void Atspi2TestTree::compareObjects(uno::Reference<accessibility::XAccessible> x
* be represented with a round trip. */
const auto nLORole = mapToAtspiRole(xLOContext->getAccessibleRole());
auto nAtspiRole = pAtspiAccessible.getRole();
- // FIXME: workaround for https://bugs.documentfoundation.org/show_bug.cgi?id=155625
- if (nLORole == ATSPI_ROLE_CHECK_MENU_ITEM && nAtspiRole == ATSPI_ROLE_MENU_ITEM)
- nAtspiRole = nLORole;
CPPUNIT_ASSERT_EQUAL(nLORole, nAtspiRole);
/* name (no need to worry about debugging suffixes as AccessibilityTools::nameEquals does, as
* that will also be part of the name sent to ATSPI) */
Change-Id: I0d88a7eda592f5ee9abf368ce1d5feb6611b9971
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154947
Reviewed-by: Colomban Wendling <cwendling@hypra.fr>
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
`VCLXAccessibleEdit::ProcessWindowEvent` takes care
of sending a `TEXT_CHANGED` event. In the case of
`SVTXAccessibleNumericField`, numeric values are
handled, so send a `VALUE_CHANGED` event in addition.
This makes Orca with the qt6 VCL plugin announce
the new value when e.g. changing the page width
using the arrow up key in the "Format" -> "Page Style"
dialog.
For Accerciser, an additional fix is needed so the
value gets updated there in the interface view when
the a11y object is selected. Pending MR: [1]
[1] https://gitlab.gnome.org/GNOME/accerciser/-/merge_requests/25
Change-Id: Id911f50664df7220bc58204bc3477c5306a1da33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150422
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>