Details
-
Bug
-
Resolution: Fixed
-
P2: Important
-
6.9.0 FF
-
None
-
Debian testing, qtbase self-compiled from git dev as of commit 0231f33ad121a85368bb3f43273973b9632735dc
-
-
a19d66385 (dev), 32b0ff212 (6.8), 51ba0d995 (6.7), 978870bb1 (tqtc/lts-6.5)
Description
Using QFrame in an application results in wrong accessible roles being reported on the accessibility layer (AT-SPI2) on Linux: It is reported with role ATSPI_ROLE_FRAME, which means [1]:
> A top level window with a title bar, border, menubar, etc.
However, that does not fit for QFrame, which is semantically rather a container for other widgets. Having a non-top-level widget report the AT-SPI framerole is misleading, and could e.g. confuse screen readers.
Steps to reproduce:
1) compile and run the attached sample program
2) start Accerciser
3) check the accessibility hierarchy of the app in Accerciser
Actual result:
Besides the QMainWindow which is (expectedly) reported as a "frame" on AT-SPI layer, there are more children with the frame role. (s.a. attached screenshot)
Expected result:
Only the QMainWindow which is actually a top-level window/frame should report that role on AT-SPI2 level.