Description: There should be a distinction between the LABEL role and the STATIC role, as distinguished by ATK. Steps to Reproduce: 1. Open the print dialog 2. Open the "Details" part Actual Results: The "Default printer" label has role label in accerciser. Expected Results: The "Default printer" label should have role static in accerciser. Reproducible: Always User Profile Reset: No Additional Info: Making this kind of text "static" helps the screen reader to know that this is just information text, which is not used to label something else, and such text appearing in a dialog box means it should be spoken. This was described briefly by Joanmarie in https://bugs.documentfoundation.org/show_bug.cgi?id=86661 . To get this, we would need to define a STATIC role along the existing LABEL role, which would be mapped to atk's ATK_ROLE_STATIC, and to IA2's IA2_ROLE_TEXT_FRAME. GtkBuilder already defines a way to set the role of a GtkLabel, so we can use that to fix the roles within .ui files. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Joanmarie, James, do you agree on this approach?
It seems logical to me according to the ATK documentation: https://developer.gnome.org/atk/stable/AtkObject.html#AtkRole The ATK_ROLE_STATIC seems on the context you describe (print dialog, details) the most appropriate. I'm waiting the feedback of other person to switch the status of this bug to new. Best regards, Alex.
Moving to NEW...
Hello, Joanmarie, James, could you confirm that this is the approach we want? I can work on the implementation, I just need confirmation that it's the proper way, to avoid useless work if it is not.
I have no opinion on IA2. That's for James to decide. I believe I've already stated in a number of places -- including the ATK documentation (which I myself wrote) -- that static text which does not label anything should have ATK_ROLE_STATIC. So I'm not sure what other information is sought from me.
Ok, thanks for the confirmation :) James, can you confirm on the IA2 side that IA2_ROLE_TEXT_FRAME is the right thing?
ATK_ROLE_STATIC is always paired with IA2_ROLE_TEXT_FRAME in Gecko, and used for accessible inline text. Thus I'd say it should be safe for you to proceed with IA2_ROLE_TEXT_FRAME. Makes sense to double check with Jamie for sure.
I have pushed to https://gerrit.libreoffice.org/#/c/58734/ a patch that adds the STATIC role and maps it to ATK_ROLE_STATIC and IA2_ROLE_TEXT_FRAME. I have also pushed to https://gerrit.libreoffice.org/#/c/58736/ an example of use, as was suggested in https://bugs.documentfoundation.org/show_bug.cgi?id=86661 .
Created attachment 144030 [details] patch for fixedtext This (untested) patch makes the fixedtext window type use static when there is no accessible relation. I'm not sure if we really want to do this yet, since it'd make orphan labels exposed as static, thus making orca speak them even if they should actually be labels for another widget and thus not spoken unless reaching that widget. Note: I have not tested it, in particular I don't know if relations are already set when getDefaultAccessibleRole() is called. This is really only for discussing the principle for now.
Created attachment 144032 [details] patch for statusbaritem This patch makes statusbaritem use the STATIC role too. I'm not sure where these can be found exactly, but I guess STATIC makes more sense here, what do people think?
(In reply to Samuel Thibault from comment #10) > Created attachment 144032 [details] > patch for statusbaritem > > This patch makes statusbaritem use the STATIC role too. > > I'm not sure where these can be found exactly, but I guess STATIC makes more > sense here, what do people think? It makes sense to me. Is it still read by Orca? Best regards, Alex.
> > This patch makes statusbaritem use the STATIC role too. > > > > I'm not sure where these can be found exactly, but I guess STATIC makes more > > sense here, what do people think? > > It makes sense to me. Is it still read by Orca? Apparently they are simply the items in the status bar at the bottom of the libreoffice window. I don't know when they are to be read by Orca, would you have a scenario?
I have pushed to https://gerrit.libreoffice.org/58767 a patch to make widget roles configurable from .ui files, both the explicit way through an AtkObject, and the shortcut implemented in gtkbuilder.
(In reply to Samuel Thibault from comment #12) > > > This patch makes statusbaritem use the STATIC role too. > > > > > > I'm not sure where these can be found exactly, but I guess STATIC makes more > > > sense here, what do people think? > > > > It makes sense to me. Is it still read by Orca? > > Apparently they are simply the items in the status bar at the bottom of the > libreoffice window. > > I don't know when they are to be read by Orca, would you have a scenario? There is a shortcut dedicated to read the status bar. Best regards, Alex.
> > > > This patch makes statusbaritem use the STATIC role too. > > > > > > > > [...] I guess STATIC makes more sense here, what do people think? > > > > > > It makes sense to me. Is it still read by Orca? > > > > I don't know when they are to be read by Orca, would you have a scenario? > > There is a shortcut dedicated to read the status bar. Ok, it does still work with STATIC.
Samuel Thibault committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4917430c1c5e8105987e81d65d31df21955ad60e tdf#116542 a11y: introduce STATIC role It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Thibault committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ac475d8d6fb68798ebd77f291bef6336e580859a tdf#116542 a11y: Make R/O accessibleedit use STATIC role It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Thibault committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5732db01795df90df95944cffc8566ea11e6c389 tdf#116542 a11y: Implement .ui ways of setting widget role It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I tried the 24th Aug snapshot (58f2e4690b57f0fa7a95be3a023d54d8967f5529), it does allow to change the widget roles, but the "static" widget role gets mapped to atk's "label" role. I guess the atk library used on the snapshot build host is too old, would it be possible to upgrade it to at least 2.15.2 to get the ATK_ROLE_STATIC macro?
I have made an archive built with an upgraded atk, and uploaded it to https://people.debian.org/~sthibault/tmp/libreoffice-6.2dev-staticrole.tar.xz Joanmarie, could you try if you can run it? I have included a few testcases where the Orca behavior might have to be adapted for these static text widgets.
(In reply to Samuel Thibault from comment #20) > I have made an archive built with an upgraded atk, and uploaded it to > https://people.debian.org/~sthibault/tmp/libreoffice-6.2dev-staticrole.tar.xz > > Joanmarie, could you try if you can run it? I have included a few testcases > where the Orca behavior might have to be adapted for these static text > widgets. Sorry for being dense, but where are the test cases? That said, I did try your build and verified the static role was present (e.g. in the dialog which appears when you attempt to close a document with unsaved changes). Orca master presented the static contents to me. Since you stated Orca's behavior might have to be adapted, I'm wondering if you got different results.
Joanmarie wrote: > Sorry for being dense, but where are the test cases? No problem, sorry for not being clear: I'll have to make the list for myself too :) I just wanted to make sure we have the test build working before getting into details. > Orca master presented the static contents to me. Since you stated > Orca's behavior might have to be adapted, I'm wondering if you got > different results. I'll be checking the different scenarii. I guess you will prefer them as bug reports on orca's gitlab?
I have sent the various scenarii to the gnome gitlab.