GNOME Bugzilla – Bug 648598
Require to review the accessible role on the UI elements
Last modified: 2012-02-19 22:40:19 UTC
After the implementation of the keyboard navigation, and applying patches on 644253, you can navigate on most of the gnome-shell lists, and orca report the element selected, but in general, with a wrong role (in most of the occasions, a panel). In order to solve that: * Create accessible objects for specific StWidget with a clear role. Ie: StClickable (PUSH_BUTTON) * As suggested on bug 626660 comment 9, provide a way to specify the role of the accessible widget, mainly to be used on the js code. That would allow to initialize the object with the role, instead of start to add atk calls to set the role.
I'm not sure what the notification thingy that periodically pops up at the bottom of the screen should be. Apparently we lack ATK_ROLE_NOTIFICATION, and I'm not sure it falls under the 'etc.' of 'warning dialogs, etc.' stated in the ATK docs. <shrugs> Also, I've seen a few instances of ROLE_UNKNOWN (instead of ROLE_PANEL). It would be good to resolve those as well.
(In reply to comment #1) > I'm not sure what the notification thingy that periodically pops up at the > bottom of the screen should be. Apparently we lack ATK_ROLE_NOTIFICATION Just for the sake of completeness, we no longer lack this role. See: http://developer.gnome.org/atk/stable/AtkObject.html#AtkRole
And GNOME 3.2 add a number to the icon indicating how many notifications left unread
(In reply to comment #3) > And GNOME 3.2 add a number to the icon indicating how many notifications left > unread Well, but probably exposing that information should be managed by a different bug. Anyway, not sure how this is done on other cases. Including the number on the text of the summary notification? But as I said, that requires to be managed in other bug.
All the specific issues related to the roles are being managed using specific bugs. Closing this bug.