Description: In the Format/Lists menu, screen readers read Number List and Bullet list as check items. They should be read as radio items because only one can be selected at a time. Steps to Reproduce: 1. Select Format and List 2. Orca reads the menu entries as check items 3. If you visit the styles menu, these are correctly read as radio items. Actual Results: Items were announced as check items. Expected Results: Items should be announced as radio items Reproducible: Always User Profile Reset: Yes Additional Info: Version: 6.1.0.0.alpha0+ Build ID: 8d4d2bf5405ef9d4b0b126f96f882f01031defd6 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Hello am_dxer, In the format menu, I see the list menu, and inside the list menu there are two items named "Number List" and "Bulleted List". What is your Orca version? Where do you obtain the GTK3 version of the daily build ? The daily build version I've found seems only GTK2. Best regards.
OK am_dxer, I've tested on LibreOfficeDev 6.0 GTK3, I can confirm the issue but it's related to accessibility because on the screen, I see checkbox, it's related to design choice. It seems it's specific to GTK3 because I don't reproduce on GTK2 version of LibreOffice. I think if you expect to see this bug fixed to close this bug and open another one specific to the checkbox issue related to GTK3. Best regards.
I was able to reproduce this same one on Windows with NVDA so I guess it applies to GTK3 and Windows. On GTK2 the check role isn't read by screen readers but neither is the radio item.
I should be more specific. In GTK2, no role is read (radio or checkbox) for Format/Lists. In the Styles menu, the radio role is read for GTK 2.
(In reply to am_dxer from comment #3) > I was able to reproduce this same one on Windows with NVDA so I guess it > applies to GTK3 and Windows. On GTK2 the check role isn't read by screen > readers but neither is the radio item. OK, you're completely right but it's not due to accessibility role but to a design issue. There are two checkbox on the screen instead of two radio button so Orca presents what's it's on the screen. We should discuss that with the design team. I've added the tag "needsUXEval" to have the input for the UX team. I agree with you, we should move from checkbox to radio button even for sighted users IMO it's an issue. Best regards.
(In reply to Alex ARNAUD from comment #5) > There are two checkbox on the screen instead of two radio > button so Orca presents what's it's on the screen. True, that's wrong. If we go with radio buttons it requires a third option 'No list'. But I could also imagine a plain entry (neither check box nor radio button).
(In reply to Heiko Tietze from comment #6) > (In reply to Alex ARNAUD from comment #5) > > There are two checkbox on the screen instead of two radio > > button so Orca presents what's it's on the screen. > > True, that's wrong. > > If we go with radio buttons it requires a third option 'No list'. But I > could also imagine a plain entry (neither check box nor radio button). A third entry "no list" is what I agree with. IMO, only radios buttons make sense on this case. Plain entry would mean dialog whereas radio button or checkbox mean a choice that produces something on the document. I prefer to keep checkbox rather than implementing plain entry. Best regards.
(In reply to Alex ARNAUD from comment #7) I fully agree with Alex. A new "no list" item and radio buttons are the best way to resolve this issue. This is also the case for * the Styles menu and * the styles sub-menu of the context menu where list styles are listed and a "no list" item is also necessary (for no list style see bug 101965). Paragraph and character styles in the Styles menu are also realized as radio buttons.
Created attachment 159275 [details] Preview
I have a working solution where I reused an existing command .uno:RemoveBullets. The Naming of list would go like attachment 159275 [details]. It would be: Bulleted List Numbered List Numbering Off
I would also like it to be shown as 'No list'. Is there a method where I can have two labels for a single uno command and use it accordingly? I mean just by passing an extra argument or something while using it in xml files?
(In reply to Shameem from comment #11) > I would also like it to be shown as 'No list'. Is there a method where I can > have two labels for a single uno command and use it accordingly? I mean just > by passing an extra argument or something while using it in xml files? UNO commands have context/popup/tooltip labels, see https://design.blog.documentfoundation.org/2018/02/28/easyhacking-all-about-terminology/ meaning No ;-). Please check also the Styles menu for your new command.
Created attachment 159303 [details] Menu with fix
What is the actual use case of the menu item marked in red? attachment 159303 [details] It doesn't get activated until we select one of the first two (Bulleted List or Numbered List), So if we are adding a third option in the first section of the menu, does it have an actual use?
(In reply to Shameem from comment #14) > ...does it have an actual use? Wouldn't place the "No List" item at this submenu but under Styles ijn order to have a default item enabled for the list radio button group. "No List" should be checked for ordinary paragraphs.
(In reply to Shameem from comment #11) > I would also like it to be shown as 'No list'. Is there a method where I can > have two labels for a single uno command and use it accordingly? Yes. You can create a new command entry in the xcu file, and link it to an existing command using the TargetURL property, for example: <node oor:name=".uno:MyNewCommand" oor:op="replace"> <prop oor:name="Label" oor:type="xs:string"> <value xml:lang="en-US">Some Label</value> </prop> <prop oor:name="TargetURL" oor:type="xs:string"> <value>.uno:ExistingCommand</value> </prop> </node> This works for menus and toolbars (but not for notebookbar and sidebar).
(In reply to Maxim Monastirsky from comment #16) > Yes. You can... Updated the blog post at https://design.blog.documentfoundation.org/2018/02/28/easyhacking-all-about-terminology with this nice piece of code.
Patch submitted: https://gerrit.libreoffice.org/c/core/+/92041
Can I work on this issue?
Hi I confirm it's not reproducible on Windows with gtk-3 and Libreoffice 7.2 Since it's not reproducible in the latest versions of LibreOffice, I think it should be closed.. Let me know your thoughts on it..
(In reply to An-Kh from comment #20) > Hi > > I confirm it's not reproducible on Windows with gtk-3 and Libreoffice 7.2 > > Since it's not reproducible in the latest versions of LibreOffice, I think > it should be closed.. > > Let me know your thoughts on it.. In the format menu, inside the list menu, there are two items named "Number List" and "Bulleted List" as @Alex mentioned.. I cannot see any checkboxes in the latest version.. However, adding a "No List" option seems relevant to me.. Please let me know your thoughts regarding it :-)
(In reply to An-Kh from comment #19) > Can I work on this issue? Assignee is Shameem although no Assigned status has been set. And s/he submitted a patch but this needs some more work. Actually I don't know if s/he wants to continue. (In reply to An-Kh from comment #20) > I confirm it's not reproducible on Windows with gtk-3 and Libreoffice 7.2 Point is that we don't have a "No List" entry and a) an unclear initial state (a list of radio buttons should always have one entry selected), and b) no way of undoing with the same interaction (no everyone is using the sidebar).
Anshu committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c456f839a597f537f1c59becd7d0bb6c86248ef8 tdf#115965 tdf#92622 NoList default in menu,tool,sidebar It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
am_dxer@fastmail.fm and others: Please have a look at the discussion in bug 148790 regarding the removal of the "No List" button.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9a16cef6f40e59d92d1bb297f40d78dfb2bb6345 tdf#115965 sw RemoveBullet: do not light-up button when NumRule It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c0eb37dfd00311518926bd602ccc8776f89b397c tdf#115965 tdf#148790 sw toolbar: no need for RemoveBullet It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2bb923d236cbd53ea2b10634537cb23fa545b0a2 tdf#115965 tdf#148790 sw sidebar: no need for RemoveBullet It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.