RE: HTML.next and Rechartering

Aryeh Gregor wrote:
>
> The Process requires that the only features that can make it into a
> REC are ones with two interoperable implementations.  If at the time
> we want to progress to PR, video and audio themselves are
> interoperably implemented, but accessibility APIs for them are not,
> then we can't put the accessibility APIs in the standard.

Once again, ensuring accessibility - the ability for all users to interact 
with authored content - is not a FEATURE, it's a core requirement for 
success.

Specific to the media elements (of which you know I am very closely aligned 
to) the user-requirements were ironed out over a year ago. Much of the basic 
accessibility APIs have been spec'd and we're pretty close to finalizing the 
remaining few issues. Yet AFAIK, only one browser is currently supporting 
<track> natively (and we have a number of scripted polyfills as well), so 
from a "technology" perspective while we know how to do this today, we don't 
have it. Why aren't the other browsers rolling out support?

But beyond the issues surrounding the media elements, it begs the bigger 
question: if we've spec'd this stuff out already, why is it taking so long 
for the browser vendors to actually implement the accessibility stuff? The 
table at http://www.html5accessibility.com/ is hardly encouraging to see. If 
we need to delay REC because the browsers are failing to support what is 
already in the spec, then the blame for that delay lays squarely at the feet 
of the browser vendors.


> In that
> case, either 1) we put media stuff in HTML5 but push off accessibility
> to HTML6, or 2) we push off all media stuff to HTML6 (!), or 3) we
> delay REC for some indefinite period while we get interoperable
> implementations.  (2) seems crazy, so it's a choice between 1) leave a
> feature only partially defined in HTML5 or 3) delay REC until it can
> be fully defined.

What concerns me most is that you don't see your option 1 as being as crazy 
as option 2.

Treating accessibility requirements, and the users who are dependent on 
those requirements, as inconveniences  who can be pushed off until the "next 
version" is a significant failure of massive proportions. The only real 
answer from my perspective is option 3, and the only way to change option 3 
is to have the browser vendors deliver on a spec they helped author and 
create in the first place.


>
> As I've made it clear before, I think the entire idea of
> versioned standards is undesirable and don't care about the contents
> of anything other than the latest Editor's Draft.

But Aryeh, the "accessibility stuff" you are quite happy to defer to HTML6 
is also already in the Editor's Draft, but not yet implemented by the 
browsers, so the contents of that Draft is no more usable or dependable then 
a versioned spec; at least with a version you know what you can rely on, 
whereas with the "living spec" things can change from right underneath your 
feet. You as an individual might be comfortable with that kind of working 
environment, but the larger global community is understandably uneasy with 
that kind of volatility, and for good reason.

Part of any versioned spec is the requirement that it meets standards and 
community requirements beyond the technical realm, and failing to address 
that, to accept and acknowledge that this too is a reality, is both 
short-sighted and misguided. As I've made it clear before, ensuring 
accessibility support is a requirement that cannot be pushed aside in the 
interest of "progress" - it is hardly progressive to deliberately leave 
behind close to 20% of the population.

Beyond the fact that it is unconscionable to act this way, ensuring support 
to people with disabilities is about good business and money as well:

 “While it’s not always acknowledged, it turns out that individuals with 
disabilities represent an enormous and active customer segment,” said Alan 
Brightman, VP of Global Accessibility (at Yahoo!). “In the US alone, the 
estimated 60 million people with disabilities account for an aggregated 
annual income of a trillion dollars. Our goal is to make sure that every one 
of them can benefit from the same products and services as everyone else.”
http://ycorpblog.com/2011/08/03/accessibility-team/

Failing to accept that web accessibility also has huge business benefits 
(and failure, huge business risks) is also an important consideration that 
often doesn't seem to get the discussion it warrants. To many members of the 
W3C, this is significantly more important than the ability to do table 
layouts in CSS...


> Thus I'm entirely
> neutral on the question of which version number gets which features.
> I'm just pointing out that we *do* have the option of leaving key
> things undefined in HTML5 if we want to get to REC quicker.  We also
> have the option of delaying REC.

The third option is to pressure the browser vendors to complete the work 
that needs to be completed, so that they can deliver to their customers all 
that they really need (rather than chasing after new, niche features that 
benefit a small percentage of the larger community - 
http://techcrunch.com/2011/08/11/chrome-native-client/).


> None of this has to do with the importance of the features.  CSS2.1
> left absolutely essential things undefined, like table layout, so that
> it could progress to REC.

Potatoes and oranges. Failing to define table layout in CSS2.1 did not 
discriminate against some users based upon their disabilities.


> The point is if they're not interoperably
> implemented, however important or unimportant they are, you can't have
> them in a REC.

We agree here. The question is, how do we get the implementation to happen?

>
> As always, I do not speak for Google.  I haven't discussed this with
> anyone, and my opinions have nothing more to do with what Google's
> security officers think than anyone else's.  (Supposing there were
> such a thing as Google's security officers, or that they had any
> opinion on what goes into which standard.)

http://tinyurl.com/3re4b99 - and I'm pretty sure that if something emerged 
in the spec that exposed Google from a security perspective they would be 
have something to say in very short order.


> What winds
> up in HTML5 vs. HTML6 is essentially academic from a technical
> perspective (as opposed to IPR etc. perspectives) except to the extent
> that it determines what people will be confused about when they
> erroneously look at HTML5.

It may feel academic to you, but you are too close to a browser vendor to 
understand how it is less academic and more practical to organizations who 
cannot dedicate massive amounts of resources keeping up with the latest 
tweak to a browser done by one small team, and then dissected by other small 
teams, re-worked and re-written and posted on a wiki somewhere so that other 
browsers might someday get around to doing the same thing.

Part of the point of insisting on 2 implementations is to ensure that when 
content creators *do* use something in the standard, they can do so with the 
assurance that it will work 'agnostically' and will meet all of their needs 
(which includes supporting disabled clients, to get some of those Trillion 
dollars). Even Microsoft has moved away from "Best viewed in" thinking, 
although I am not entirely convinced that all the browser vendors today 
really believe that sentiment.

And if REC must be delayed because we don't have 2 independent 
implementations of support for accessibility requirements, we all know where 
to lay the blame, don't we?

JF

Received on Friday, 12 August 2011 23:59:04 UTC