Bug 86661 - Incorrect usage of ATK_ROLE_TEXT
Summary: Incorrect usage of ATK_ROLE_TEXT
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Hardware: Other All
: medium normal
Assignee: Not Assigned
QA Contact:
Depends on:
Blocks: a11y-Linux
  Show dependency treegraph
Reported: 2014-11-24 12:51 UTC by Joanmarie Diggs
Modified: 2017-05-30 17:01 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs 2014-11-24 12:51:39 UTC
Steps to reproduce:
1. Launch Writer and type some text.
2. Use find and replace to do a "replace all"
3. Use Accerciser to examine the resulting results dialog (where it says Search key replaced x times.")

Expected results: There would not be any object with ROLE_TEXT.

Actual results: The accessible object containing the string "Search key replaced 8 times" has ROLE_TEXT.

Impact: Orca does not present the results string because ROLE_TEXT is typically used for GtkTextView (e.g. the entire text widget in Gedit, which is GNOME's Notepad equivalent). For static text in dialogs, ROLE_LABEL is traditionally used.

There has admittedly been some confusion about what ROLE_TEXT is applicable to. We have done a couple of things in this regard: 1) Clarified this in the ATK documentation and 2) Created a new role (ATK_ROLE_STATIC). [1]

It would be very helpful if you could either use the new ATK_ROLE_STATIC (introduced in ATK v2.15.2) or the very old ATK_ROLE_LABEL to be consistent with our platform's usage of ROLE_TEXT.

On a related note, apparently IA2 has a text frame role which is appropriate for things like static text in a dialog. The IA2 text frame role in most -- if not all -- cases is NOT the same as ATK_ROLE_TEXT. Thus if the reason ROLE_TEXT was used was because of this presumed equivalency, then it would probably be worth doing a thorough search and correction for ATK.

[1] https://developer.gnome.org/atk/2.15/AtkObject.html#AtkRole
Comment 1 V Stuart Foote 2014-11-24 13:54:39 UTC
Thanks for posting, setting to new.
Comment 2 Julien Nabet 2014-11-24 19:23:51 UTC
JoanMarie: just to complete information, on which LO version are you? FYI, last stable one is 4.3.4
Comment 3 Niklas Johansson 2014-11-25 09:42:28 UTC
Right, I noticed this when trying to fix the issue with the text in message boxes being exposed as password text. As I remember it LibreOffice uses VclMultiLineEdit for the text. At first the intention was to change the role to ROLE_LABEL for labels and text like the ones described below, but I didn't find a good way to change it without the side effect that objects that should be exposed as ROLE_TEXT also would be changed to ROLE_LABEL. Since it at least was possible to get the text read I left it alone.

Maybe what we really want is to create a new class VclMultiLineLabel that inherits VclMultiLineEdit?

Note, I'm out on deep water here so my observations may very well be wrong.

Since I haven't been in contact with ATK_ROLE_STATIC before I won't comment on the differentiation between ATK_ROLE_STATIC and ROLE_LABEL at the moment.
Comment 4 Caolán McNamara 2015-01-19 16:34:35 UTC
Assuming this is a MessageDialog, there would be no problem at all to just call "SetAccessibileRole on the m_pPrimaryMessage and m_pSecondaryMessage widgets in MessageDialog::Execute if that solves the problem. They are merely r/o MultiLineEdits in order to allow the user to select and copy the text out of them.

or if its an InfoBox/etc, convert it to a MessageDialog if they work better, and/or do both if necessary.
Comment 5 Joanmarie Diggs 2015-08-14 23:24:54 UTC
I'm still seeing this issue in
Comment 6 QA Administrators 2017-05-22 13:21:52 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice 
(5.2.7 or 5.3.3  https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and 
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave 
a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)


2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword

Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

Comment 7 Alex ARNAUD 2017-05-30 17:01:41 UTC
Dear all,

I'm using LibreOfficeDev 5.5 from 2017-05-30.

I don't know how exactly to find the role of an element but in Accerciser I see label, not text. So it looks like the bug is no longer present.

Best regards.