Accessibility and Copyright, was: Re: Sections of the HTML5 specification being removed from the W3C without discussion

On 9/9/2011 6:16 AM, Shelley Powers wrote:
>
>
> On 9/8/2011 11:38 AM, Charles Pritchard wrote:
>> On 9/8/2011 7:56 AM, Shelley Powers wrote:
>>> There's an ongoing discussion[1] about removing the Editing API from 
>>> the HTML5 specification.
>>>
...
>>> Now, the same thing has happened again, but this time with the 
>>> section of the HTML5 document formerly labeled Dynamic Markup 
>>> insertion[2]. I don't believe there was even a bug report filed on 
>>> this one, it was just removed[3][4].
>>>
>>> In looking at the change control entry, I also find a third 
>>> document, DOM Range[5]. One author identifies himself, the other 
>>> uses a nickname, rather than his real name.
>>>
>>> Seriously?
>>
>> These all look like the same shared effort of DOMCORE:
>> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
>>
>
> But it is still taking material from a LC document, in an existing 
> chartered group, and placing it into another document that has no 
> seeming standing in any group within the W3C, and doing so, if I read 
> the comment in the bug correctly, indifferently.

Likely, this is fall out from the straw poll on the copyright dedication 
for HTML5:
http://www.w3.org/2002/09/wbs/40318/html5-license-poll-v3/results

I am not a lawyer, but I fake it when the opportunity presents itself.

This document is claimed by the three editors, solely, as their 
copyright, and they have released it to public domain:
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.src.html

Via build scripts, they produce this publication, which they have 
granted to the W3C, and the W3C claims copyright:
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

Via build scripts, they also produce this publication, which they 
continue to assert their original copyright, as well as public domain 
status:
http://dvcs.w3.org/hg/domcore/raw-file/tip/dom-core.html

Until and unless there is a legal challenge, I expect that WHATWG 
authors will continue this practice. They maintain their changes very 
closely, and though they work with W3C members, unless they actually cut 
and paste code, they are likely within their rights to continue this 
procedure. If/when I submit content to these editors, I will be 
willingly submitting them with the understanding that it will be 
released into public domain, without attribution. That said, I doubt 
many others are as willing as I am. I caution the WHATWG editors, be 
very careful with what you copy into your specification, lest you taint 
your copyright assertion.


>
>> Many editors have spoken out, requesting a change in W3C policy. 
>> They're looking for less policing.
>>
>
> I would expect to see maturity in a W3C working group. Some might call 
> this "policing", but what we should expect from the W3C is a steady 
> movement to stability of delivered product.
>
> The HTML WG has had to develop an obsessive dependence on procedure, 
> because the group is failing. It started to fail the very first day 
> the group decided to adopt the WHATWG effort, without question, and 
> appoint Ian Hickson as editor. It continued to fail when it didn't 
> adopt another editor when the second, token editor quit.
>
> There is no discussion anymore. The Accessibility group is off doing 
> its thing, which is kind of sad, because most if not all that they'll 
> recommend will get ignored.

They are, at least, supported by changes in US federal law. Many vendors 
have done a poor job of even attempting to put resources into 
accessibility. Many spec editors and vendor-developers consider 
accessibility to be something that authors can not successfully engage 
in. As a developer, I feel a similar lack of respect toward big vendors. 
I take Google's recent revamp of Google Docs as an excellent sign that 
at least one of their divisions has learned its lesson. I take 
Microsoft's revamp of their own accessibility policies as an excellent 
sign that they have learned their lesson. It sure is slow in coming, 
though. Most of Google's divisions have not caught up. They have over a 
hundred committing members to NaCl, and still lack a basic accessibility 
structure. Chrome is in version "15", and still has flaws in basic 
support of Windows high contrast mode. Their efforts are spent more on 
self-voicing, than they are on first supporting the structures already 
available. It's frustrating.

The beliefs of several WHATWG editors, that accessibility is a compact 
between the user agent and the user, is something I find naive. The 
author is involved, the author and the user are involved in human 
communication. It's great to have a user agent that has assistive 
properties, it's more important to have a user agent which the user can 
plug other user agents into, such as ATs like JAWS. But vendor 
priorities don't seem to swing that way. And since their priorities 
don't go that way, the people they employ, to work on specs, are free to 
remain idealists. In an ideal world, markup would be easy, and 
everything would be exposed "automatically", for "free". In the 
practical world, accessibility requires added effort for everyone. This 
conflict doesn't sit well with the ideal world of a "correct" 
specification. Without pressure, editors and vendors can drag their feet 
as long as they desire.

They are dragging their feet, not maliciously. It's a state of benign 
neglect, and as best as I try to communicate, I can't seem to get 
through it. Sometimes I do consider it willful, a malicious ignorance. 
But then I calm down, and remember that spec editors are idealists, and 
vendors are self-interested corporations. Google uses Webkit, which was 
largely funded by Apple: it's no surprise that their Windows 
accessibility is neglected. Microsoft has its own browser, it's no 
surprise that they have decided not to be regular committers to webkit 
and Mozilla code bases.

Accessibility has had some big wins, in U.S. law, in corporate attention 
and ARIA support. Sure, some of the spec editors see these issues as 
something that can be worked out automatically, if the alchemy is 
just-right. That's ok, the facts will bare themselves out, and 
eventually, the vendors will mature. Microsoft has made ARIA a first 
class citizen. Mozilla has an ARIA implementation with similar maturity. 
It's happening... just, slowly.


>
>>> Secondly, is this the type of stewardship we can count on from the 
>>> W3C going forward? Allowing one specific company to pull chunks of 
>>> W3C specifications out of the W3C, without any consideration of 
>>> other company's intellectual property rights on the concepts in the 
>>> text covered in the text? More importantly, without regard for the 
>>> possible risk this may be placing companies who have started to 
>>> implement these specifications? These member companies have placed 
>>> faith in the W3C. Was this faith misplaced?
>>>
>>> Perhaps rather than ask if the HTML WG is a viable entity, I should 
>>> ask whether the W3C is a viable entity. Actions like these described 
>>> in this email that are allowed to happen without hindrance or even 
>>> comment  casts doubt on the ability of the organization to continue 
>>> being a caretaker for the specifications that form the 
>>> infrastructure for the web.
>>
>> There are many specs within the w3c and working groups that are not 
>> suffering from these power-struggles. 
>
> Oh, there are power struggles (I followed along with the RDF group 
> years ago), but there isn't this constant battle with having to fight 
> another non-group seemingly bent on sabotaging the W3C's effort.

You know the joke, when there are more than two people in a group, 
politics are inevitable.

> And agree, other groups are doing well, with a greater degree of 
> cooperation and a united interest in developing a sane specification.
>
> But, as we've seen, the W3C can't depend on the behavior of the 
> members of the group to ensure the group progresses.
>

>> That said, HTML5, Canvas 2d and DOM4, are suffering.
>> And yes, those are very prominent specifications.
>>
>
> Because the W3C can't deal with a situation where the people aren't 
> cooperating--especially when some of the people who aren't cooperating 
> are from browser companies.
>
> But it is with efforts such as these that we need the W3C to assert 
> some sanity...not adopt a hands off attitude as the effort crumbles.
>
>> Presently, the W3C WGs are the only means we have of defending our 
>> use cases. Though the editors of those specifications can and have 
>> created their own specs, unilaterally, the specs hosted by the w3c 
>> still follow procedure, or at least, are still bound to it.
>>
>
> That's a good point, but with the HTML5 spec, at least, there is no 
> longer a defense for the interests of all communities impacted by HTML.


I've seen the W3C take procedural control of a specification, out of the 
hands of the editor, following WG consensus, a vote, and chair decisions.

Following that, the editor decided to address the issue that was 
discussed in the WG, and added it to a forked, self-hosted, specification.

It's a little dysfunctional, but it is progress. I'm still holding out 
hope for the specs to be merged... it may take a year for that to happen.

In the meantime, following the public comments of many spec editors, 
I've decided that my efforts would be better spent developing patches 
for existing browsers, and appealing to vendors directly, instead of 
quarreling with editors. I do still gain benefit, and more
eyes, ears and conversations, through the W3C than I would otherwise.


>
>> There is still room for objection, and voting, within the W3C. The 
>> W3C still offers protections, and a back channels for communication 
>> across vendors.
>> Those are still present.
>>
>
> I have not seen it in two years. Two years.
>
> No, I no longer believe it.

There are many vendor-developers who only respond through W3C / WHATWG 
public forums, and who have asked me in no uncertain terms, never to 
e-mail them directly.


>> The specification fork for Canvas, explicitly targets and sabotages 
>> some of my use cases. It knowingly operates against the consensus of 
>> the canvas wg, the w3c chairs, and the actual operation of existing 
>> implementations. But, those actions, made unilaterally, by one 
>> person, are hosted off-site, off of the w3c.
>>
>
> Charles, I didn't even know there was a specification fork for Canvas, 
> I'm sorry. I've been so caught up with the HTML5 spec, itself. Where 
> is this fork?

It's minor: the editor decided that interactive form elements in the 
<canvas> subtree should be restricted to <button>, radio and checkbox. 
There are some other changes, but they are actually productive, and 
intended to solve the use cases presented. It would be nice if they were 
the topic of conversation, instead of non-discussed code-forks. I think 
the editor was a little bitter about seeing the w3c specification 
forcefully altered by w3c staff.

There was a similar attempt to restrict ARIA semantics on HTML tags, 
such that tags with existing semantics could not be overwritten;
that is, one would not be able to do : <a role="button" href>...</a>

That was also met with resistance.


>> That seems to be the direction of things. I'd request that, when 
>> editors are publishing to w3c, they stay within the w3c domain. 
>> Otherwise, as they're well aware, they can link where-ever they like, 
>> and do whatever they want.
>>
>> All of us have benefited from the added mobility that WHATWG-oriented 
>> editors have gained these past few years.
>>
>
> You know, I'm no so sure.
>
> The infrastructure of the web is more in a state of chaos then growth, 
> now. The efforts seem to be more targeted to a small group of 
> like-minded individuals, than the web community at large. The 
> accessibility folks have been especially treated with disdain, which I 
> find disquieting. And the world at large is burned out on the 
> contention between the W3C and the WHATWG.
>
> Most of the WHATWG effort seems to be focused more on creating a new 
> generation of browser wars, then building the web.

I thought there might be a systematic means of proving HTML 
completeness, by demonstrating that the accessibility tree, the DOM (as 
accessed by the scripting environment) and the visual output, were on 
par with the flexibility of current desktop applications. I thought 
that'd be a nice way of looking at current needs. Many vendor-developers 
told me off, on that one, claiming that user interface widgets are too 
complex for authors to handle, and should be left up to user agents.

The current chaos, yes it is a bit chaotic, but it's serving the 
growing, new, Web Apps community. I know that Doug had hoped for more 
rapid progress and uptake of SVG. I wanted the same back in 2003.

Anyway, it didn't work out, so what we have instead are a whole lot of 
components. And they are working out. We're able to build web 
applications, which I contend, are fundamentally different than web 
documents.
Documents are consumed by a user agent. Applications -are- a user agent, 
they consume content. And as nice as HTML forms are, they're very basic 
UI constructs.

I've had this argument a few times with spec editors and vendors. They 
hum and haw, and finally say that "games", those are different than 
documents, but web applications are not. They also claim that games can 
not be served by existing accessibility semantics. A perspective I also 
disagree with.

Here's David Singer of Apple, doing his best to imagine a "bio-reactor" 
application, where he contends that existing accessibility semantics 
would be in-effective:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0227.html
'a bio-reactor, in which various populations of algae, funghi, bacteria 
etc. are competing. The user can interact with it using a 'virtual 
pipette'... "

I've countered several times, that whether in games or in mechanical 
simulations, current accessibility practices should be the first thing 
examined.


>> I ask, again, WHATWG-oriented editors, please maintain the w3c 
>> specifications, when you are making your changes.
>>
>
> I echo your statement, except I address it more towards the W3C.
>
> W3C, fix this mess.
>

Given the propensity of spec editors to fork, and to do things how they 
want to, I think that the precedent set by DOMCore (now DOM4) is sound.
Move the specs onto the distributed version control system. Ask WHATWG 
editors to use a single source file, and appropriate markup to handle 
attribution and specification forks.

That makes it easy for the W3C to step in, when process dictates, while 
still allowing the editor to maintain their own personal preferences on 
their personal publications.


TLDR; WHATWG editors have a strong legal argument for asserting their 
copyright in publications, independent of W3C publications. Many spec 
editors and vendors have neglected practical accessibility 
considerations, per WCAG, but they are increasingly giving those 
principles more attention.  The W3C can force-the-hand of spec editors, 
by having W3C staff alter specification documents hosted on w3c servers, 
this has happened with Canvas.  Many spec editors and vendors continue 
to want to innovate, and serve accessibility, but they are doing so from 
a place of idealism, and are unreasonably neglecting existing 
infrastructure. Many spec editors will continue to fork their 
specifications from the decisions of WHATWG working groups. This 
situation can be made more tolerable by maintaining documents and 
version control which are suited to frequent forking and merging.


-Charles

Received on Friday, 9 September 2011 20:25:38 UTC