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

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

--- Comment #17 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2011-08-13 15:59:57 UTC ---
(In reply to comment #16)
> 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.

I disagree that UAs should be required to do anything at all with <video> or
any other element not of interest.

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

Concision is a good thing, but the length of the draft is not my motivating
concern here. I think it's inherently risky to predict and try to cover all
"circumstances". As we can see from the discussion so far, John's proposed
change did not cover all circumstances. I see no reason why you or I can
imagine all circumstances. SHOULD does cover all circumstances.

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

I think the poor implementation status of @longdesc is only a tiny contributor
to the rarity of long text alternatives on the Web. I've not seen a concrete
case where someone has made an explicit decision not to provide a long text
alternative *because* @longdesc is poorly supported, as opposed to simply
adopting another (perhaps inferior) mechanism. Similarly, I think whether user
agents like Firefox include audio description track controls in their default
UI is only going to be a tiny contributor to the frequency of audio description
on the Web over the next decade, and especially given the existence of a
clientside API for detecting and playing such tracks, it's not going to be a
substantial barrier to access. It seems like it would be fairly trivial to make
an addon or bookmarklet to expose such tracks.

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

Perhaps, but I think you'd be hard-pressed to demonstrate that popular user
agents are worse in this respect than other large software projects.

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

I disagree that baking MUST-level conformance requirements into the HTML spec
is the right approach.

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

You're potentially mandating people work on features that their users do not
want or that they cannot provide.

Either they take that requirement seriously, which takes time away from them
working on features that their users do want or (worse) it stops them building
the software in the first place.

Or (vastly more likely) they ignore that requirement, and treat the spec with
less respect for trying to place such restrictions on their free use of the
Web. If you train implementors to ignore conformance requirements, then you
encourage more fundamental lack of interoperability. If you destroy
interoperability, then you make it even harder to build tools that depend on an
interoperable substrate, such as WebAnywhere.

In practice, since WHATWG takes a firm line on not mandating UI, since popular
browser implementors appear to be using the WHATWG spec as the basis of
implementations rather than the W3C spec, and since naturally implementors
pick-and-mix features to implement, the only real-world impact would be to make
the W3C spec more irrelevant. It's not like the W3C creating UAAG made popular
browsers actually implement UAAG. You need people involved in developing
browsers to agree that these features are important and implement them. If they
are, a SHOULD level requirement is more than enough *and* it protects us from
our inability to consider all possible circumstances.

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

If I thought a MUST requirement would such a difference, I'd be more inclined
to agree.

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

I can see how you if you imagine that by adding these MUST-level requirements
we'd actually get implementations whereas with SHOULD-level requirements you
could might be willing to trample over the free consumption of the Web to get
there. I place a lot less faith in the power of spec text.

Spec text can enable the creation of accessible content and code that supports
that content but it cannot actually make people create the content or write the
code. The time spent spilling ink arguing for fairly futile MUST-level
requirements would be better spent in a code editor building the features, not
least because doing so is likely to uncover problems in the spec that we *do*
need to fix to get interoperable accessibility in popular browsers. Or, if you
can't code, it's better spent advocating directly to user agent vendors. Bug
reports trump spec requirements, which is why the development of this HTML
draft has so often been based on user agent developers explaining they will not
conform to a requirement because of bug reports. The squeaky wheel gets the
grease, and the W3C HTML spec is actually a very quiet wheel.

-- 
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 16:00:04 UTC