WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: accessibility of Google flash audio player

for

From: steven
Date: Oct 7, 2010 9:33AM

"I'm appalled at how many of them are completely inaccessible to me. Don't
people do even the barest accessibility testing before they start
advertising how accessible something is?"

It would seem they leave the testing to us, Deborah.

Steven




Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of
<EMAIL REMOVED>
Sent: 07 October 2010 15:40
To: WebAIM Discussion List
Subject: [WebAIM] accessibility of Google flash audio player

Hey, folks. I have a question about the Google flash audio
player. It's embedded as an example on the page
<http://www.labnol.org/internet/design/html-embed-mp3-songs-podcasts-music-i
n-blogs-websites/2232/>
(a couple of paragraphs under the second heading).

I've been testing it, and here's what I've found:

1. Mouse action on all of the keyboard controls works.

2. There are keyboard controls, but they don't correspond with
the buttons. It looks like once you've gone into the flash app,
using the space-bar no matter what button is highlighted will
always be play/pause, using the right and left arrows no matter
what button is highlighted will always be fast forward/reverse,
and using the up and down arrows no matter what button is
highlighted will always be volume control.

3. The buttons don't have captions, so they aren't announced to
screenreader users. But since the buttons don't have functional
keyboard controls, I'm not sure what good they would be to
screenreader users anyway.

4. The button highlighting is inconsistent and in some cases bad,
although again, since the buttons don't do anything with the
keyboard, I'm not sure what value there is to highlighting them
at all. Or even making them tabable.

I actually prefer the idea of keyboard controls that are global
inside the flash app to having to tab around buttons and figure
out what they do, but that only works if those keyboard controls
are documented and visible every time the application appears,
right? And that documentation has to be something screenreader
users are likely to find BEFORE they get to the flash app.

What do you guys think about best practices here? Since I think
this code is open for modification, if you were going to grab it,
what would you change?

(In my searching, I've come across a lot of pages that advertise
their awesome accessible multimedia players, and I'm appalled at
how many of them are completely inaccessible to me. Don't people
do even the barest accessibility testing before they start
advertising how accessible something is?

Sorry, stupid question.)

Thanks,

-deborah