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

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

--- Comment #19 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2011-08-13 18:17:38 UTC ---
(In reply to comment #18)
> > > 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.
>
> I'm having a hard time understanding your logic on this one. We hope that
> content providers provide captions or alternative audio tracks or whatever is
> necessary in order to make the media elements accessible.

Indeed.

> However, this has nothing to do with whether user agents support this
> functionality or not. 

I think whether or not content providers make use of the relevant semantics
will have a *lot* more impact on whether user agents provide UI for it than
spec text. There's a bit of a chicken and egg situation here, but not much of
one, as it's so trivial for users to get access via a bookmarklet or addon.

> Accessibility is not market driven. 

I didn't say it was and I'm not sure what that means.

> What you're almost saying is that user agents like Firefox are lazy, and only
> want to provide support based on market interest--leaving accessibility to
> third party providers because, frankly, it can't be bothered to ensure
> accessible media support.
> 
> Is this what you're implying? That a user agent like Firefox really can't be
> bothered to ensure accessibility of the media? If so, then it becomes even more
> imperative to ensure that the user agent, like Firefox, is given an additional
> incentive to ensure it provides accessibility.

I think characterising an open software project like Firefox as "lazy" is a
sort of category error, so no that's not what I'm saying.

I don't think spec text in itself constitutes a strong incentive for user agent
feature sets.

> > > 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.
> >
> 
> But browsers are, most likely, the primary agents for delivering HTML5 media.
> As such, ensuring they're accessible has a strong, positive impact in the
> industry.

Spec text doesn't ensure anything. You're picking the weakest possible tool to
influence a large and complex ecosystem.

> > > 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.
> >
> 
> When it comes to accessibility, it's the only way.
> 
> To repeat: accessibility is not market driven.

I don't think spec text changes market forces, if that's what you're hoping.

> > > > 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.
> >
> 
> Huge difference between "users do not want" and "cannot provide".
> 
> No one is dictating that user agents that "cannot provide" this capability be
> forced to provide this capability. The text to make this clear could be
> included in the UI section I mentioned earlier.
> 
> However, "users do not want" is, frankly, unacceptable. You're basing your
> whole argument on accessibility being market driven, when, to repeat,
> accessibility is not market driven.

I don't know what you mean when you say my argument is based on "accessibility
being market driven"?

> There are some users that do want this functionality. In point of fact, when
> you including subtitle support in with caption support, I believe you'll find
> the majority of users want this functionality. But regardless, even if this
> functionality is only useful for a smaller subsection of the user population,
> it's _essential_ for that population.

If the content gets created, then users who want access to it will need a way
to access it. It would certainly be preferable if that support was provided
out-of-the-box by popular user agents on consumer devices. I don't think spec
text has much influence on this.

> Providing this support does not impact, in any way, on those who don't need
> this support. Again, it's little different than a TV providing closed
> captioning support: people can turn it on or off. Those who don't need it,
> don't turn it on; those who do, do.

This clearly isn't true. Additional elements of UI increase cognitive load
(making it harder to find the right item in a context menu or the right button
on a remote control) and the amount of additional interaction (keyboarding
through more items in a menu or turning off accidentally triggered captions).
(Personally, I would like my browser to provide me with access to audio
descriptions just as I would like my TV to provide me with captions. But I'm
not going to pretend that's zero-cost.)

> So "users do not want" actually makes no sense at all, and does not reflect the
> web. 

I'm opposed to user agent conformance criteria based on these sorts of
overarching generalizations about the users of the Web want. Who are we to
dictate to users, and the developers who serve them, what they want? Especially
when the users and the developers are one and the same!

> > 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.
> >
> 
> Oh, now, this is the real key, isn't? User agents would rather spend their time
> on gee wiz geegaws than on accessibility.
> 
> My answer? Tough.
> 
> If we use care in the text, there won't be an unreasonable burden on user
> agents. There won't be a case where audio only user agents have to provide
> access to text tracks, or the like. 
> 
> But when the device/user agent is capable of displaying something like text
> tracks for a video, the option must be provided.
> 
> The gee wiz geegaw can just wait a couple of days.

I think people who want to work on "gee wiz" features and do not want to work
on the mandated functionality are going to work on the former regardless of the
proposed spec text.

I think popular browsers will ship - and compete successfully in the market -
regardless of whether they comply with W3C HTML.

> > 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.
> >
> 
> Then they won't be in conformance, and can't brag about their "HTML5" support
> to the world, or folks will call them on it. 

Popular browser vendors will crow about their HTML5 support regardless and the
odd person might call on it, but that crowing will not help accessibility at
all. I don't know why people imagine it well help with HTML5 where it did not
help with HTML4.

Browser vendors don't have a completist approach to standards support anyway.
Heck Microsoft is already talking about their web engine as an "HTML5 engine":

   
http://blogs.msdn.com/b/ie/archive/2011/06/29/site-ready-html5-second-ie10-platform-preview-available-for-developers.aspx

> But that's true of every last aspect of HTML5. It doesn't stop the spec from
> peppering "must" all throughout.

Sure, but MUST is reserved for the basic substrate of interoperability: how do
you parse some bytes into markup, what order do you execute scripts in, etc.
These MUST requirements are realistic to impose on user agent developers,
because they help user agent developers avoid bug reports, not because they
create new bug reports. Adhering to those requirements makes it easier to build
user agents, including user agents with specific accessibility focuses such as
Edbrowse or WebAnywhere. The MUST requirements are not some sort of tool for
browbeating hapless UA developers into adding features to their product; they
are a tool to help them build whatever features they like. That's ultimately
good for end-users, especially end-users who want to participate in
development. An interoperable substrate is actually a massive boon for
accessibility development, since less time will be occupied reverse engineering
basic web engine functionality like parsing HTML. By contrast, UI requirements
do not reduce the need for reverse engineering, so they don't actually free up
any developer resource.

> > 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.
> >
> 
> This is the W3C. The WHATWG has their own priorities, among which seems to be
> lack of interest in accessibility. Whatever. Accessibility is a priority for
> the W3C. 
> 
> We're not arguing about what's including in whatever document at the WHATWG.
> We're talking about what's in the W3C HTML5 specification.
> 
> Your statement seems, on first, read, to be almost a threat. That if the HTML5
> spec does mandate accessibility, the browser companies will basically have a
> snit and take their marbles and go home? I hope I'm reading your statement
> incorrectly. 
> 
> Are you saying that browser companies are that hostile to accessibility? 
> 
> Disturbing.

I do not believe WHATWG has a (particular) "lack of interest in accessibility"
or that "browser companies are … hostile to accessibility".

I can't make a "threat" on behalf of browser vendors (I'm not even a browser
developer!), but I can observe what is actually happening.

As far as I can tell, the frozen W3C version of the spec is already basically
irrelevant to mainstream browser development (as ooposed to marketing), and was
always going to be so, except as a source of patent protection. (Fortunately,
HTML WG influences the WHATWG draft too.) People don't need to implement the
spec to gain such patent protection.

Adding mandatory UI requirements will reinforce that irrelevancy to browser
development, while making it a worse tool for the small number of conservative
authors who read such specs and unrealistically expect them to describe
features that have been widely implemented.

The only rationale for imposing such UI requirements is to try to force popular
browser vendors to adopt them. Since this won't work, that rationale doesn't
hold.

In so far as browser vendors are friendly towards accessibility we don't need
this MUST-level requirement. In so far as they are apathetic about
accessibility, it won't help much.

> I'm stating that HTML5 must meet the needs of a community of users, and among
> this community are those who have need of, and interest in, these accessible
> features.

Adding this MUST-level requirement won't do enough to help that.

> Accessibility is more important than something like WebGL, and a heck of a lot
> easier to implement--not to mention, more secure.

Statements about the importance of accessibility by W3C have close-to-zero
impact on an individual FOSS developer who happens to want to work on WebGL
rather than this context menu item or on a commercial vendor that thinks WebGL
has more market importance. Section 508-style legislation, including
requirements around audio description access, might have a little more impact
on the later.

Writing spec text aiming to change developer or company action that shows a
disregard for how developers or companies work is an inherently bad idea.

Creating UAAG techniques that can be cited by 508-style legislation and that a
company seeking 508-compliance can apply to HTML5 would be a better use of the
advocacy that is going into trying to cram mandatory UI into the HTML spec
itself.

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

Received on Saturday, 13 August 2011 18:17:42 UTC