WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Does an accessible video player that works correctly in all major browsers exist?

for

From: Jonathan H
Date: Jun 11, 2014 5:10AM

On 3 June 2014 15:48, Brian Richwine < <EMAIL REMOVED> > wrote:

>
> You might look into the Able Player,


Darn it, wish I'd know about that a few months back! As it happens, I've
been spending quite literally months on and off building an accessible
player with a small group of "trusted testers".

Before you read any further, I'd like you to go and have a play with this
early beta without any preconception of how it SHOULD work.
Then come back here and read on if you wouldn't mind. Here's the link to
the TEST player.
https://googledrive.com/host/0B2NJeY_BTHQfUjk1RlNXbXFuZlU/

Welcome back! The basis for the player is the jPlayer project, but with a
completely new skin using the html5 elements like "progress", along with
some polyfills.

The target audience are listeners of talking newspapers, the output of
which is either generally one long file of over an hour sometimes, or up to
30 short files forming a playlist.

So it was important to have easy and rapid time navigation within long
tracks, but also fast and easy access to multiple items in a playlist.

Feedback also showed a large gulf between the reading speed of the
volunteers, and the speed that SOME listeners wanted to listen at. So
controls affecting speed, but not pitch, were essential.

And it must be able to be totally keyboard drivable.

Happyworm, who created jPlayer, have been extremely helpful, making heavy
modification to the core player and playlist code to make it accessible.
If this passes the "group" test, then those changes will make it into the
main build, benefitting everyone.

However, I've encountered many problems along the way with differing
browsers and screen readers and managed to overcome most.

Let me take you through the page, top to bottom, and explain where I think
it wins, where it fails, and where I need further advice.

My biggest problem is that I am having MAJOR issues with the Aria alert
role. This was to be a key feature of the player, and in early tests it was
well loved - the idea is that you press "pause", and an aria alert would
fire off saying something like "track 2 of 7 paused 2 minutes and 7 seconds
into the 7 minute track titled Broccoli from the playlist Waitrose Kitchen
April 2014".

I have spend DAYS trying to get this working with IE and Firefox and NVDA
and Jaws all at the same time. I've tried hack after fudge after
workaround, and still it only works on 2/3 combinations at a time.
(And right now I seem to have killed it altogether - back to the drawing
board on that one!) If anyone wants, I'll post my notes and hacks I've
tried from various sites.

The next problem is that if I use the aria-valuetext to make the progress
bar say "percent" after the number, it crashes Chromevox (bug filed and
confirmed). So I've had to put that to one side for now (yes, I know very
few people use Chromevox - tricky one!).

If I use the default html5 progress element, or set an aria role of
"progress" on the progress bar/slider, then NVDA constantly "beeps" the
progress status - correct, but not desired.

If I set role="status" on the progress bar, it behaves very nicely across
all screenreaders and browsers I tested - if the progress bar is on focus
or being moved, it gives you a quick update every ten percent, if not, it's
quiet.
Perfect! Except.. the W3 validator says: "Bad value status for attribute
role on element progress".

I know the general feeling is "accessibility over validity every time", but
it's a shame as that's the only fail in a page I worked hard to get valid.
What say you?

Also, in IE and Firefox, the progress bar time slider works properly when
keyboard driven, but in Chrome it doesn't, responding only to being
mouse-dragged.

I have a fairly hefty table of conflicts and problems with various browsers
and screenreader combinations.

For example, NVDA does not speak announced accesskeys involving the minus
(dash - ie accesskey="-" ) but JAWS behaves itself, and the accesskey
itself works.

I know accesskeys are a bone of contention - I'm trying to lay out the
player so that the controls can be totally "tab and enter" driven, not
relying on accesskeys at all, or at least making them purely optional.

Can anyone suggest a better layout to allow easy skipping from, say,
selecting a playlist item, to jumping back to the controls?

Nice accidental Firefox feature: When focussed on timeskip keys, it's skips
30 seconds using space, 1 minute using enter key.

Some older browsers don't have the option to change the HTML5 playback
rate, nor does the flash fallback for obsolete browsers.
Should the "playback rate" option be hidden from users whose browsers don't
have this method?

Talking of older browser, although I note from
http://webaim.org/projects/screenreadersurvey5/#primary that a startling
amount of users are stuck on dangerously obsolete versions of IE, that is a
worldwide survey. I've seen less than 1% of my site users on IE versions
lower than IE9. It seems from surveys that the most popular browser
combinations are IE with JAWS and Firefox with NVDA, so those will be my
primary focus first.

Right, I'll stop there for now - a few other good things that have come out
of this are that I've filed two NVDA bugs which have been fixed, one
Chromevox bug which is filtering its way through dev channels, and a fairly
serious Chrome bug affecting all keyboard users which has gone totally
unactioned for months, despite the 25+ stars you lovely people gave, and
big thanks to Steve Faulkner for at least switching it back from "feature"
to "bug" after some Chrome dev thought that accessibility is a "feature
request". I now understand what the accessibility community is up against
sometimes!

Thanks for any input and thoughts.