[Bug 13436] Editorial changes to The Video element (4 of 5)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13436

--- Comment #15 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2011-08-13 14:26:44 UTC ---
(In reply to comment #14)
> > In this case, I don't see how your proposed text change would make any sense
> > for user agents like wget that do not display content, or printers that do not
> > allow interaction with content, or any user agent that does not have access to
> > sound output and therefore cannot "display" audio description tracks.
> 
> But then, these user agents would not provide a control at all. Nor support the
> multimedia API, or provide any other interactivity. 

Not necessarily true in the last case!

> Let's not play semantics, let's look at the real issue: if a means to control a
> media file is present, then user agents must provide controls to enable or
> disable the display of closed captions, audio description tracks, etc. 

Yeah, confusion about what we all mean by "UI" aside, I don't think this is a
matter of semantics but first principles of an open system like the Web.

Why should a user agent that can show captions but cannot play audio tracks and
so does not show user audio description controls be non-conforming?

For example, if a user agent is designed for a device does not have sound
output capable of rendering the audio tracks (like a first-generation Kindle),
why should it be required to display controls to play audio descriptions?

Or again, why should a user agent designed for deafblind users that does not
include audio description controls be non-conforming?

    http://www.nanopac.com/BrailleNote%20DeafBlind%20Communicator.htm

One can of course argue about whether it's good or not for the user to include
information about content they cannot immediately access. But it seems to me
that as usual such negotiations are best left to users and user agent
developers. Trying to mandate feature sets as if we knew all the ways people
might want to consume web content would be hubristic.

Of course we want easy access to audio description tracks under normal
circumstances in classic user agents like Firefox, Internet Explorer, Chrome,
and Safari, but I object to trying to achieve that access by baking in feature
set requirements for HTML user agents into the W3C HTML spec. I don't think
it's an effective way to achieve such desirable results (historically it's been
fairly unsuccessful), and promoting people's freedom to consume web content
however they want (and build conforming user agents that allow them to do so)
is (I think) more important. That freedom does, after all, allow people to
build user agents that provide easy access to audio description tracks.
Ultimately that freedom can even correct accessibility failings of user agents
in jobs and public places. For example, let's say in two years user agents
common in the workplace and public web access points like libraries support
<video> but don't provide controls for audio descriptions, due to failings in
the enforcement of discrimination laws or whatever. The freedom to build user
agents that serve particular needs allows one to go ahead and construct (say) a
proxy that adds on-page controls providing access to audio description tracks
similar to how WebAnywhere provides screenreading access anywhere:

    http://webanywhere.cs.washington.edu/wa.php

In practice, I think the big problem will be getting the audio descriptions in
the first place, rather than finding software capable of playing them back. The
admitted problems of @longdesc access in popular user agents are less
significant to society than a widespread absence of long text alternatives.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Saturday, 13 August 2011 14:26:47 UTC