GNOME Bugzilla – Bug 155506
gnopernicus does not speak disabled menu items
Last modified: 2004-12-22 21:47:04 UTC
1) Invoke gnopernicus, enable speech in it. 2) Open gnome-terminal. 3) Click on Edit menu. It does not read the disabled submenu items like, copy. It does not read the disabled submenu items like, close tab. In some other applications, like mozilla even disabled menu items will be read as disabled. expected result: Even disabled items shall be sent to reader, so that a blind user can hear it, even though he won;t be able to use it.
The step-by-step instructions are insufficient. If the tester is arrowing through the menu, and such arrowing skips over the disabled menus, then this is NOT a bug and should be closed. Tester, please tell us what is going on?
In mozilla, when user is arrowing through the menu, a 'focus:' event is fired for every menu item (even if it is enabled or disabled). This is the reason why gnopernicus is reading the disabled menu items. In gtk apps (i.e. gnome-terminal, gedit, ...), only the enabled menu items are focused so gnopernicus can not read the disabled menu items. This is certainly not a gnopernicus bug. Should it be closed as NOTABUG or transferred in the right place for further evaluations?
This behavior sounds like a bug in mozilla.
When we found and discussed this issue (easily over a year ago), I believe we decided that this is simply different and legal behavior, and so long as Gnopernicus reports what is going on all is OK. That was when we were less comfortable changing general/UI behavior in apps. I think this is worth discussing on the mozilla mailing list, and I'll do so. But I'm still not prepared to argue that this is a mozilla bug yet.
I agree with Peter. This is not a gnopernicus bug and also not a A11y bug for both terminal and mozilla. This is caused by different behaviour of applications. Arguing which kind of behaviour is correct may have no result in short term. It's beyond the scope of current a11y work.