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

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

--- Comment #16 from Shelley Powers <shelleyp@burningbird.net> 2011-08-13 14:50:58 UTC ---
(In reply to comment #15)
> (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!
> 

There should still be accessibility controls in the latter case, but
appropriate to the circumstance. 

> > 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?
>

Actually, first generation Kindles do have audio. Are you talking about the
ability to translate text into audio? Regardless, that's beside the point since
we're talking about HTML5 media. 

Again, the accessibility controls would reflect the circumstances. If the
device has no audio, no support for audio is provided, including accessibility
support. However, video support _must_ be provided. 

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

Again, it doesn't have to add to the overall length of the HTML5 document to
detail accessibility control requirements based on circumstances. 

>     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.
> 

No, they're not. 

You mention longdesc later in your comment. If user agents had properly
supported longdesc, how much more would its correct use had been advanced? 

In my opinion, too many user agents have demonstrated a mostly lukewarm
interest in supporting accessibility. It seems that user agents are more
interested in competing with each other over the latest gee wiz geegaw than in
providing accessibility. 

After all, "BANG! SPLASH!" drives more news articles than something like
support for longdesc. 

Since user agents have demonstrated such lukewarm support, we need to up the
ante--make accessibility a conformance issue.

And we're not talking incorporating a burdensome amount of text into the HTML5
spec, either. The HTML5 document contains a complete section on recommended
uses of HTML for specific circumstances where there are no specific elements.
Well, media accessibility is as important--more important--than that particular
section. We're talking about ensuring a basic set of accessibility features for
media elements, rather than leave such up to each individual user agent (and
their interpretation of "good reasons").


> 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. 

What does this have to do with ensuring accessibility? Seriously, what you just
wrote sounds noble, but how does providing accessible controls impede user
freedom to consume media however they want? 

Just like with today's blu-ray players, people don't have to turn on subtitles
or captions. Just like with today's Kindle, people don't have to turn on audio
translations of books. This capability in no way impedes people's use of the
media.

However, _not_ having this capability does impede the freedom of use for a
portion of the user community. 

So, on the one hand, all web users have access, and on the other, only a
portion of the consumers have access. Frankly, I'll take option number 1.


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.

Again, what you wrote sounds noble, but is largely irrelevant to ensuring that
accessibility is baked into the HTML5 media controls. 

This isn't about laws, or libraries, or whether the audio tracks are even
available--this is about ensuring HTML5 media elements are accessible.

-- 
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:51:04 UTC