Now that the iPod has become the frontrunner in portable audio players, iTunes has quickly become the desktop music player of choice. The blind community has quickly adopted the iPod for its simple controls and relatively easy to remember menus, but has not so easily started using iTunes. Noted for its ease of use in doing complicated tasks with a couple of clicks of the mouse, it has become the perfect software complement to the easy to use iPod and even if one does not own an iPod, it is perfect for organizing mass quantities of audio files. That is, if you can see the software. For being such an audio-enabling device, the software that accompanies it is extremely visual in use. Not only that, but iTunes has been shown to be very inaccessible to screen reading software. To enable visually-impaired users of iTunes, an audio interface must be developed that allows commonly-used features to be quickly accessed through auditory prompts, without having to wade through the menu bar or using screen readers that do not navigate well through the software. This is the problem that allTunes attempts to tackle.
The allTunes software is simply an audio menu interface written in Python that uses the iTunes component object model (COM) API and the Microsoft Speech API for the speech instructions. The program broke the complex iTunes interface into a main menu where through the up and down arrows a user can access certain areas of the program like the music player’s controls (i.e. play, pause, fast-forward/rewind), playlist maintenance, burning CDs, and even updating his or her connected iPod.
The main portion of the program, where the user would in theory spend most of their time, would be the player controls submenu. This portion controls the player directly. All of the common player control command can be accessed with the press of just one key. For example, playing and pausing can be accomplished with the press of the ‘p’ key, scrolling through songs can be done with the up and down arrows, fast-forwarding and rewinding is done using the left and right arrows respectively, and stopping done with the ‘s’ key. The player controls were to be designed to be as intuitive as possible to avoid confusion and eliminating the requirement to remember complex instructions for simple tasks. These were all previously available through the iTunes menu bar but now can be quickly accessed by a visually-impaired at literally the press of a key instead of having to scroll through using a screen reader.
Another accessibility feature that allTunes has is the ability to add the current song being played to any playlist. This can only be done with iTunes by physically dragging the song with a mouse to the desired playlist. Obviously, this can pose a dilemma for certain users. In the same player controls section partly described above, if the ‘a’ key is pressed (‘a’ chosen for ‘add’), the playlists in iTunes can be browsed using the up and down arrow and when the desired playlist has been spoken, with the simple press of the enter key, the current track will be added to that playlist. Also at anytime, a press of the ‘m’ key (‘m’ chosen for ‘main menu’) will return the user to the main menu for easy navigation through the program.
To find the artist and song title of the current song, a press of the ‘i’ key (‘i’ chosen for ‘info’), the song title and the performing artist will be read back to the user. Current screen readers read not only the artist and song title, but anything else on the playlist line, such as genre, album, play count, player rating, and any other fields that may be included. This can be very frustrating for a user that just wants quick info on the current song without a lot of unneeded information. On the other hand, with a press of the ‘x’ key (‘x’ chosen for ‘eXtended info’), a menu of all available song metadata fields is read so the user can, if desired, get any information he or she wants, when he or she wants. Simple features like this greatly increase the usability of iTunes for visually-impaired users.
From the main menu, a playlist maintenance menu can be reached. From this submenu, a spoken menu is given that can be scrolled through that gives the user option to do to tasks such as create, load, rename, and delete a playlist. At each option, a spoken prompt (for example, in the create dialog) or a further spoken scrollable menu (such as in the load, deletion, rename dialogs) that will allow the user to select playlists. This playlist submenu was designed to give visually-impaired users the most efficient and quick way to use this very useful feature of the iTunes software.
To actual do the act of updating the user’s iPod, this is as easy as going to the menu and selecting the ‘update iPod’ option. A simple feature simply implemented.
Though there are some remaining features in the iTunes software that the allTunes software does not currently implement, the main features that relied heavily on sight or could not be properly handled with a screen reader have now been opened up to access to non-sighted users. Universal accessibility to software, especially useful programs like iTunes, should not be a design afterthought but in the forefront of implementation so that all users, regardless of limitations, can use and benefit from them.
All in all, Maze Day went pretty well. One user found a way to make the program crash almost as soon as I could get it up and running, but others found more subtle bugs that only come out from extensive use. So Maze Day definitely did its part in revealing things that need to fix. One thing all the users had in common was pushing the up arrow to go to the next song as opposed to the conventional sighted users pushing down. I plan to include an options panel where user settings like that can be set, among other things. Maze Day was a blast though, and I learned a lot. Hopefully as soon as the summer starts I can polish allTunes up and have it ready for general public use.