Banshee Accessibility: Where Am I?

When I started working on Banshee accessibility, I pointed out various keyboard navigation issues in the ListView. For one, the column headers were not keyboard Navigable, so you couldn’t sort by column. Also, there was no indication the ListView had keyboard focus, this made keyboard navigation confusing.

With my limited theming skills, I solved the latter, if anyone has a better idea for keyboard focus indication – please submit patches! My solution was slightly changing the ListView selection’s color, and making the frame’s border bolder.

As for header navigation, the behavior I implemented mimics GtkTreeView: When tabbing into a ListView, focus first lands on the column headers, a second tab puts focus in the actual list. When focus is on the column headers, left and right change the active header, and return toggles sorting. There is a hidden advantage of horizontal control in the ListView that we will see in a later post regarding screen reader support.

Enjoy this short screencast of keyboard navigation in Banshee’s ListViews.

Banshee ListView Focus Video

Banshee Accessibility: Where Am I?

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