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.
Items were announced as check items.
Items should be announced as radio items
User Profile Reset: Yes
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
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.
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.
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.
(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.
(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.