Banshee Accessibility: The Low Fruit

In my quest to make Banshee more accessible, I listed several issues that came up in a few minutes of testing. In this post I will review the solutions to some of the more straight-forward issues.

Fix top toolbar keyboard navigation

The top toolbar, where the play controls live had inconsistent keyboard behavior. Typically, you arrow left and right to reach different items on the bar, but the toolbar had two widgets which grabbed the arrow keys, and did not allow further navigation.

The volume button is a highly customized Gtk.Button, the OnKeyPressEvent method is overridden, and all sorts of key pairs are assigned to do essentially the same thing, you guess what: +/-, Add/Subtract, Up/Down, Left/Right. Since there are plenty of alternatives for adjusting the volume, I simply removed the Left/Right keys so the widget does not consume them, and the parent toolbar will receive them.

The seek slider essentially a Gtk.HScale, I haven’t figured out why but pressing left/right when the slider is in focus does not change it’s value. It’s probably some widget property I missed. In any case, since left/right doesn’t do anything in the widget, I figure nobody will miss it. I overrode OnKeyPressEvent, and made sure to return false when left or right is pressed.

You could see the actual patches in the bug report.

Text alternatives to icon buttons

This took me longer to figure out then I want to admit, the problem seems to be that the playback toolbar button accessible objects do not have a textual representation. It also seems that the current Banshee code does everything right: Gtk.UIManager is used, and text labels are provided. The short answer to my long inquiry is simply that GAIL is not exposing toolbar button names. I wish I filed a GAIL bug once I discovered that, because now – two weeks later – I don’t completely remember what the issue is. In any case a quick workaround in Banshee was to use the Gtk.Stock enumerators and not the stock string ids. I know, silly. I promise to file a GAIL bug on this soon. For now, you could look at the bug report for the workaround.

Banshee Accessibility: The Low Fruit

7 thoughts on “Banshee Accessibility: The Low Fruit

  1. twilightomni says:

    Oddly enough – speaking as a GNOME lay person – why can’t tab simply go between every object, rather than groups of objects?

    If tab (and ctrl-tab in textboxes) rotated between objects, you wouldn’t have to worry about inconsistent use of left/right/up/down arrow keys.

    1. Eitan says:

      I think you just answered your own question. If every object could be reachable with tab, you would have to press tab hundreds of times to navigate through every menu and list item. Tab should be reserved for higher-level objects, and they should manage their children’s focus with different keys, such as arrows. That way you could quickly reach different parts of the application, and only keyboard through items you are looking for.

      Coincidentally there is a bug already filed for’s TileView that showcases the issue, every item is focusable through tab, and it takes a long time to cycle through them and get to the next major Banshee component.

      In the toolbar case, you might be right. It is counterintuitive to use arrows when keyboarding through those widgets, in my opinion. It is probably that way because Windows users have grown to expect it.

  2. twilightomni says:

    “Windows users have grown to expect it…”

    Truly? I never dreamed of tabbing through a toolbar on Windows. I love keyboard access, but I always figured that toolbar key navigation was just broken beyond repair, whether it was Office or Firefox. (Although recently I did notice that Office 2007 has quite pleasurable keyboard accessibility).

    So that does make sense, but unlike me, you seem to consider every child item in a listbox, for example, as a separate object.

    I do not. Lists of items, to me, are inherently different from a “bar of buttons”. It’s a list. The object is the list. I should be able to move through it with natural (up/down/page-up/etc) navigation. I admit subjectivity.

    I also feel that natural arrow-key navigation on a toolbar is untuitive; I just never expected it to work, and still found it awkward under GNOME (warranted in the cases of inconsistency where it still doesn’t work – current Banshee an example).

    And what REALLY bugs me:

    Not that GNOME’s “arrow” navigation of an object doesn’t work; but GNOME inconsistently allows arrow navigation to jump across objects!

    There is nothing more bothersome than navigation a good toolbar (ex, Rhythmbox), pressing “down” one too many times, and then ending up in the source list, where up/down changes my view and does all sorts of stuff accidentally I then need to adjust. Why would the same key to navigate groups items irreversibly change my focused object? Now I can’t navigate back the same way and must use shift-tab.

    I’m fine with the idea of tab through groups, arrows through sub-items, sure. I have different ideas of what an object group is (lists, not toolbars), but I don’t mind that. I just wish it worked consistently.

  3. twilightomni says:

    My point is, it’s hard to tell when an object will capture your arrow key input.

    Drop-down lists capture up and down (and since changes in GNOME are applied on the fly, getting caught in one by accident annoys me to no end). Textboxes don’t capture up and down but do capture left and right; moving up and down moves you to ANOTHER focus object!

    There is no way of knowing if an object (child or top-level, whatever) will capture arrow key input or not. You’ve seen this with Banshee’s toolbar.

    So yes, I would prefer tab-only object navigation, with arrow-key navigation reserved only for special fields and objects (listviews mainly).

    Arrow-key navigation should not be an ambiguous “sometimes moves you between fields, sometimes it doesn’t”. And you shouldn’t have to patch your application to make up for GTK’s lame navigation.

    1. Eitan says:

      I agree with all your points. I was suggesting earlier that flattening the entire focus order would be a bad idea. But I see we both agree on that. Like many things, the inconsistencies in keyboard navigation are mostly for legacy reasons, and today people expect them. Furthermore, they introduce plenty of bugs, for example anything besides buttons in a toolbar is bound to get you in trouble.

      If I were to redesign how keyboard navigation works, I would choose 2 or 3 levels of navigation (between sections, widgets, and items), and I would add a key to the keyboard that would only be used for navigation purposes.

      But alas, we need to fix one issue at a time 🙂

  4. twilightomni says:

    Hmm. No reason that key couldn’t be tab. 🙂

    How do you even file issues about this sort of thing? The component-based GNOME bugzilla doesn’t lend well to general stuff like this.

Comments are closed.