Re: [free-aria] Re: Seeking feedback on HTML5 video accessibility experiment

On Sun, Aug 2, 2009 at 1:04 PM, Silvia
Pfeiffer<> wrote:
> Hi Victor, all,
> I just watched your video at
> after receiving some
> private emails from several members of this group. I have promptly
> added headers and more comments to the demo at
> . Please note that I am not
> experience in general Web accessibility, but only know my way around
> video and time-aligned text such as captions and subtitles. This is
> the challenge I am addressing.
> Now, I have to apologize to everyone because I probably made some
> assumptions about the HTML5 video tag that I should not have made
> (judging from the emails that I received). So, let me take a step back
> and explain about the status of HTML5 video.
> Firstly, html5 video is a very new tag that has not been implemented
> in all browsers yet - and not all browsers support the Ogg
> Theora/Video codec that my demo uses. Only the latest Firefox 3.5
> release will support my demo out of the box. For Chrome and Opera you
> will have to use the latest nightly build (which I am not even sure
> are publicly available). IE does not support it at all. For
> Safari/Webkit you will need the latest release and install the XiphQT
> quicktime component to provide support for the codec.
> My recommendation is clearly to use Firefox 3.5 to try this demo.
> Secondly, the standardisation of the HTML5 video tag is still in
> process. Some of the attributes have not been validated through
> implementations, some of the use cases have not been turned into
> specifications, and most importantly to the group here, there have
> been very little experiments with accessibility around the HTML5 video
> tag.
> Most of the comments that I received were concerned with the
> accessibility of the video controls, which is not an area I intended
> to look into, assuming that would already be solved by the browsers.
> However, I will have to do some work on it, if simply to enable people
> to actually test the demo.
> So, let me explain about the video controls.
> In HTML5 video, there is a attribute called @controls. If it is
> available, the browser is expected to display default controls on top
> of the video. Here is what the current specification says:
> "This user interface should include features to begin playback, pause
> playback, seek to an arbitrary position in the content (if the content
> supports arbitrary seeking), change the volume, and show the media
> content in manners more suitable to the user (e.g. full-screen video
> or in an independent resizable window)."
> In Firefox 3.5, the controls attribute currently creates the following controls:
> * play/pause button (toggles between the two)
> * slider for current playback position and seeking (also displays how
> much of the video has currently been downloaded)
> * duration display (just display)
> * roll-over button for volume on/off and to display slider for volume
> * FAIK fullscreen is not currently implemented
> Further, the HTML5 specification prescribes that if the @controls
> attribute is not available, "user agents may provide controls to
> affect playback of the media resource (e.g. play, pause, seeking, and
> volume controls), but such features should not interfere with the
> page's normal rendering. For example, such features could be exposed
> in the media element's context menu."
> In Firefox 3.5, this has been implemented with a right-click context
> menu, which contains:
> * play/pause toggle
> * mute/unmute toggle
> * show/hide controls toggle
> When the controls are being displayed, there are keyboard shortcuts to
> control them:
> * space bar toggles between play and pause
> * left/right arrow winds video forward/back by 5 sec
> * CTRL+left/right arrow winds video forward/back by 60sec
> * HOME+left/right jumps to beginning/end of video
> * when focused on the volume button, up/down arrow increases/decreases volume
> As for exposure of these controls to screen readers, Mozilla
> implemented this in June, see Marco Zehe's blog post on it:
> .
> So, this is the current state of HTML5 video technology.
> My work is actually meant to take this further and explore how to deal
> with what I call time-aligned text files for video and audio. For the
> purposes of this mailing list, we are mainly concerned with subtitles,
> captions, and audio descriptions that come in textual form and should
> be read out by a screen reader or made available to braille devices.
> I am concerned both with time-aligned text that comes within a video
> file, but also those that are available as external Web resources and
> are just associated to the video through HTML. It is this latter use
> case that my demo explored.
> To create a nice looking demo, I used a skin for the video player that
> was developed by somebody else. Now, I didn't pay attention to whether
> that skin was actually accessible and this is the source of most of
> the problems that have been mentioned to me thus far.
> I will endeavor to make a new demo soon that doesn't use this skin,
> but creates a menu for available text tracks in a different manner.
> Then, I will post this here again and you should be able to make use
> of the existing accessibility functionality for video, as well as the
> new features I am proposing.

And here we go - I worked on a rough new demo today and uploaded it to
the server (which was down for a few hours today - apologies if you
tried linking to it).

The new demo is at - the
default player controls should be accessible as described above and I
hope that the extra button that I implemented for the menu is now
accessible, too.

Happy for any feedback and suggestions of improvement!


Received on Sunday, 2 August 2009 13:53:00 UTC