Anatomy of a Widget
My Internet radio player is an animal on it’s own evolutionary branch apart from most web-based audio players. In some ways, that’s good. In others, not so much.
Unlike most players, it has no progress bar, no pause button, no mute checkbox. This is in part my preference but also reflects the realities of internet radio.
Internally, it lacks some quality controls that do not seem possible to me.
My pride is that I can operate the player with my screen readers on Windows or my iPhone, something that has eluded me with popular vendor apps.
Life in the stream
Completing the player required getting my head around two realities.
First, online radio is a data stream without end. So, adding a progress bar to the player becomes pointless. The right end of a progress bar usually denotes “100%” played. But what is 100% of an endless stream?
Second, listeners can have some very odd experiences if they are not hearing the latest point in the broadcast. For example, a user pauses a broadcast for 10 minutes then un-pauses it. At 12:10 p.m., she hears “the time is now 12 noon.” This is why my player omits the pause , forward and backward buttons.
Quality controls
HTML’s Audio element has some very cool features for controlling quality. Frankly, I am concerned how they will work in my player.
No one wants to wait forever to hear sound after clicking the Play button. The Audio element addresses this by letting developers specify preloading some sound information. However, Apple does not allow browsers to preload any data. I lacked the energy to devise a workaround for non-Apple users. I just hope I do not get a lot of gripes about long start times.
My other concern may turn out to be a groundless anxiety. Most developers create audio players with the source files on hand. They can analyze the recording quality, the audio format and so on. They can make changes if they encounter something they do not like. I do not have those options. I am just grabbing the audio links from other websites The best I could do is incorporate error handling mechanisms that will pop up some scary messages should something go wrong.
Fun with the other audio: screen reader speech
Most audio players on any platform provide some support for screen readers, but most have places where they leave me guessing what to do.
I never need to guess with my player.
The screen reader announces when I have navigated into the player. It tells me that the Stations button controls a menu and that the menu has opened or closed. Once I have chosen a station, the reader announces a confirmation of the choice. I know the volume level and when buttons are disabled.
Keeping in mind users who are hard-of-hearing
A user who is hard-of-hearing may get some assistance from the speaker image that changes when the Play button is pressed. This may be particularly helpful if a slow Internet connection delays the audio startup. My hope is that the image change prevents this user from wondering whether she have failed to click the Play button.
Technical notes
The player definitely uses many more attributes of ARIA (Accessible Rich Internet Application) than other pages in this site. Also, the attributes are used in more complex ways.
The ARIA is most sophisticated in two areas.
I used the toolbar role on the navy blue rectangle to force Windows screen readers
to exit their default mode in which they control the Up and Down arrow keys.
So now the listener can use the keyboard keys to change the volume any time the focus is in this area.
I use the menu role on the stations menu.
This necessitates other ARIA on parts of the menu plus a lot of JavaScript to enable navigating the menu with arrow keys and managing the user selection.
I say throughout this site that creating accessible pages is often not more work, but that opinion does not apply to application menus like this.
The upside to this extra effort is clear: Most of these special techniques, such as focus management, transfer easily to other projects.
Published: