This was my second in a series of blog posts on creating an accessible HTML5 audio player. If you're more interested in outcome than process, see the article Putting it all together: Accessible HTML5 Audio Player with Yahoo! Media Fallback.
In my previous blog post, I described how I created an accessible custom HTML5 audio player. For users whose browsers don't support the new HTML5 <audio> element, I need an accessible fallback option.
I started by testing each of the 10 Easy To Implement Flash Based Mp3 Players with JAWS 11, and found that nine of the ten players do not have labels on their controls. With no labels, JAWS identifies the various controls as "Graphic 1", "Graphic 2", etc., or in some cases simply says "Flash movie start. Flash movie end."
See my niftyPlayer Test Page.
One lingering problem is that the <object> code recommended in the niftyPlayer documentation fails HTML5 validation. HTML5 actually supports both <object> and (for the first time ever in an HTML spec) <embed>. However, the classid and codebase attributes are obsolete, and probably a few other attributes as well. At this phase in my testing I wasn't especially inclined to spend much time trying to figure out how to convert old <object> code to valid, functional HTML5, although it looks like Bruce Lawson has gotten a jump start on this in his article HTML 5 Flash embedded and other validation errors.
There are a few other problems with niftyPlayer too. The API is limited. It doesn't provide access to the volume control and there's no way to seek forward or backward within a tune. And as far as I could find, nobody seems to be doing any further niftyDevelopment, and there's little or no support for the existing player, either from the original developer or the user community. As a result of all this, I abandoned my niftyPlayer testing, leaving my implementation in a somewhat incomplete and buggy state. But I had high hopes for the next player in line to be tested...
Yahoo! Media Player
My test pages:
- Yahoo! Test #1 - default user interface, with player minimized
- Yahoo! Test #2 - default user interface, with player maximized
- Yahoo! Test #3 - custom player
I'm not one to gush over big name brands, but one big advantage of the Yahoo! Player over the niftPlayer is that it was developed by Yahoo! Like many Yahoo! creations these days, there were clear signs that accessibility, particularly for screen reader users, had been actively considered.
The Yahoo! Media Player is easy to implement by following the steps documented at mediaplayer.yahoo.com. The one-page API documentation is similarly easy to follow, although as a developer I'd prefer having more details - there's a lot left undocumented. However, there's also an active user community on Yahoo! Groups as well as some historic activity on the Yahoo! Media Player wiki, unearthing the undocumented potential of the player and sharing their hacks (for example, see Michael Ryvkin's article Hacking the Yahoo! Media Player).
The player is highly customizable, and has a much more robust API than niftyPlayer does. One of its configuration parameters is displaystate, which can be set to:
- 0 to load in a minimized state (default setting)
- 1 to load in a maximized state
- -1 to load in a hidden state. This hides all the invisible screen reader -accessible content in addition to the skin. It simply displays play buttons beside each MP3 link, and when one of these links is clicked the player (including its accompanying accessible HTML) becomes visible in its maximized state.
- 3 to load in a "no UI" state. This is initially the same as -1, but the player never loads, even after clicking a song title link from the playlist. This essentially disables the default player interface, but still allows access to the player via the API, so you can create your own.
There are a couple of things I don't like about the default player: The code is inserted at the very bottom of the web page, just prior to the </body> tag, and that's where it's always positioned visibly. I'd rather it be embedded within the flow of the document, at the author's discretion. There's no parameter that allows this to happen, and if there's a way to adjust its position using CSS, I don't know how to do it. Worse yet, the default player fails miserably on color contrast:
The Contrast Analyser agrees:
So, I created my own player, again striving for a similar interface to the one I created for HTML5. Again, the details are in the commented source code. I'm pleased with the results. It works, and it's fully accessible to screen reader users.
I did find one seemingly rare bug, and it's not just my code - I can replicate it on any Yahoo! Media Player, including the one on the YMP home page. In Firefox 3.6.8 in Windows 7 on my computer, if I pause the media, then play again, it behaves like a Stop button, and restarts the media at 0 rather than resuming where it left off. This happens on my computer even if Firefox is running in safe mode, but does not happen in Firefox 3.6.8 running on Windows XP nor on Mac OS X. I've had a couple people running this same browser in Windows 7 on their computers, who don't experience the problem, so who knows. Maybe it's just my bad luck. Regardless, I'm not too concerned about this bug, because for my purposes the Yahoo! player is fallback content, and Firefox 3.6.8 users will be playing their audio in HTML5.
Now that I have both a custom HTML5 audio player and a fallback custom Yahoo! Media Player, I'm ready to put them together into a functional unit. Stay tuned...