HTML is currently defined in multiple documents, each purporting to be THE definition of HTML/HTML5. The documents are developed, published and maintained by 2 separate organisations. The 2 organisations have differing development models, one (W3C) employs a consensus process for resolving conflicts about the normative and informative content of the HTML specification, in the other (WHATWG) all decisions about what is in the specification are made by one person (the editor, Ian Hickson).
The W3C process has over time resulted in consensus based decision’s that Ian Hickson has not agreed with, the end result being that normative and informative content changes have been made to the W3C HTML5 specification that have not been made to the WHATWG HTML living standard and vice versa. It is interesting to note that the majority of these differences relate to accessibility. Below are the intentional accessibility related differences introduced by Ian Hickson, so far:
Working Group Decision on ISSUE-131 caret-location-api
The WHATWG living standard omits a whole section of implementation requirements for making canvas content more accessible to people with disabilities.
Working Group Decision on ISSUE-66 – Image Analysis Heuristics
The WHATWG Living standard includes a paragraph of implementation advice in regards to image analysis heuristics that is considered not helpful to anyone.
Working Group Decision on ISSUE-109 aria-section-title
The WHATWG living standard omits a paragraph encouraging implementers to make WAI-ARIA features useful to a wider range of people with disabilities and anybody else who they may be useful to.
Working Group Decision on ISSUE-122 shalott-example
The WHATWG living standard defines normative requirements that forbid authors from providing text alternatives for emotionally rich images.
ISSUE-161: defining mappings from html elements to platform accessibility apis
The WHATWG Living standard omits a link to HTML to Platform Accessibility APIs Implementation Guide, a work in progress designed to provide the significant amount of accessibility implementation advice not provided in HTML.
Working Group Decision on ISSUE-130: table-layout
The WHATWG living standard omits advice on how authors can mitigate the negative accessibility effects of layout tables.
Working Group Decision on ISSUE-31 / ISSUE-80 validation survey
The WHATWG living standard allows authors of HTML emails to omit text alternatives for images.
Working group chair decision from May 2011 -Use of ARIA
The WHATWG living standard includes a clause that requires conformance checkers to emit errors for use of ARIA roles in cases where their use improves the accessibility of the content.
Working group chair decision from June 2011
WHATWG living standard includes a clause that requires conformance checkers to emit errors for use of ARIA roles in cases where their use improves the accessibility of canvas content.
Who benefits?
Who exactly benefits from the divergence of normative requirements and advice across documents claiming to authoritatively define HTML? If forking is bad for HTML what are the parties involved doing to to remedy it? I have asked people involved, but as yet no answers have been forthcoming.
Comments
Prima facie, if someone doesn’t agree with something to the point of doing something drastic (e.g., fork the spec) then you don’t have consensus and it’s not a consensus based decision.
(“Consensus” does not mean “good” or even “democratic” or “legitimate”. That a process aims at consensus based decision making doesn’t mean that it achieves it. In the W3C if there’s a formal objection, for example, I think it’s by definition not a consensus decision.)
Nominal consensus can happen with no real consensus (e.g., people drop out of the process in a variety of ways).
I presume it’s obvious that Ian (and some others) disagree strongly with the W3C’s decisions, thus, by forking, they hope to support their position and achieve their goals. I take it as given that everyone shares the fundamental goal of an accessible web and the disagreement is fundamentally (though profoundly!) about strategy and tactics.
Hi Bijan,
I don’t see how any of the decisions made form a legitimate basis for forking of the spec. As you pointed out, if someone disagrees they can and do file formal objections.
What makes a forking illegitimate? What legitimates a fork?
It seems like you were attempting to make the legitimacy distinction based on consensus vs. non-consensus. I hope it’s clear that I’ve shown that that isn’t a simple way to go (i.e., it’s perfectly possible for a W3C decision to be not consensus based and it’s perfectly possible for a WHATWG decision to be consensus based — the consensusness of a decision is somewhat independent of the formal mechanism or the pronouncement of any party).
In any case, that value system (i.e., legitimacy stems from a consensus oriented decision procedure; forks require a hight threshold of justification) is not shared by all parties. So, your questions don’t, for them, expose the emperor you expect them too.
AFAIK, nothing in the participant agreement of the W3C or in the process document requires or even suggests that any participant pursue standardization goals solely or even primarily within the W3C. Nothing in the agreement, AFAIK, between the WHATWG and the HTMLWG requires that they harmonize at all points (merely that they pursue convergence). Finally, there’s nothing in that agreement that ranks the W3C process over the WHATWG process.
So, people who do not share the value system that the W3C is inherently legitimate and the WHATWG is inherently at least less legitimate can respond in any number of ways, including “ultimate convergence does not require convergence at every step”.
You disagree with the substance of these divergences and prefer the W3C ones. You (I take it) also believe you have more control and likelihood of success inside the W3C. These are powerful reasons to prefer the W3C. But they don’t undermine the legitimacy of alternative, per se. Even in a consensus based system, equal likelihood of outcome is not a fundamental property.
In the end, the best arguments here are first order, e.g., that something will or will not promote accessibility. Legitimacy arguments can be useful, but they are rather tricky and often look really bad.
(This is part of what’s so very wrong with the thread about the forking. Several people have basically said, “Obviously, the WHATWG version is the illegitimate one. Obviously, Ian has broken faith.” But, AFAICT, that’s nowhere near true nor is it particularly effective.
Oh, and lest we forget, the ultimate decision structure of the W3C and the WHATWG are the same: Benevolent dictatorship. The director (Tim) has at least as much nominal power as Ian. Tim exercises it less (or rather delegates it a lot more) and is generally less involved and, at this point in time, much less technical capable. There have been plenty of times when I’ve heard people wish Tim would (or would be able to) exercise more control and provide a more unified technical vision.
Well no, I was trying to say, that given the assumption that forking of HTML is bad, then none of the decisions appeared to constitute a good reason to fork. You have inferred I believe that not all parties involved believe it is bad to fork, if so then my statment is moot. But from what I have read publically none of the parties believe that forking is a good thing. If you have evidence to the contrary I am happy to be disabused.
I don’t believe the differences introduced benefit anyone, if you can provide me with reasons why they do, it would be much appreciated.
Hi Bijan,
And that is what the arguments and decisions in the HTML WG have been based on. There have been decisions made that I have disagreed with, in some cases I have strongly disagreed and have in one case made a formal objection and in another am working on a proposal to re-open the decision.
It seems clear that Ian thinks that the W3C decisions were wrong and the WHATWG decisions are sufficiently better. I’m truly puzzled by your puzzlement.
Perhaps you think forking costs more than other people. I.e., you can think that forking isn’t ideal without thinking that forking isn’t to be avoided even for weak reasons.
I don’t think Ian think forking is so bad. Indeed, that was strongly encouraged (esp. in the early days of the working group). The WHATWG folks are really heavily concerned with enabling cheap forking (see the licensing discussion). And a possibly temporary fork seems esp. ok.
Ok, to go back to your original question:
People who want their position to win benefit. Existing, drafted text supported by at least one organization gives you a much better chance of your position ultimately winning.
I mean, if you’re sufficiently adverse to forks, why not propose that the HTMLWG synch with the WHATWG one? Who’s doing the forking here? (It’s symmetric, right?)
I conclude that, for all parties, forking is less bad than the positions they want to see win. Which is totally reasonable.
(Also note that once you have a fork the marginal cost of additional forked details go down. It’s just “one more point of divergence” rather than the point that forces a fork.)
Sure, but the current discussion is not, afaict.
If you think forking is an overriding problem, then you should advocate the W3C synch with the WHATWG version. That would solve the problem. But no one values non-forking to that degree, so it’s no surprise that forking happens.
Ian Hickson took part in the HTML WG process that lead to those decisions, because they didn’t go his way, he then decided to fork the specs. To me that is a good example of acting in bad faith.
This does not answer the question of who the differences benefit, as in users, authors or implementors?
So why are the same people so concerned with the possibility of accidental forking in W3C HTML documents? (see author version discussion)
While completely unrelated to the discussion of accessibility, I think a recent blog post from Jeni Tennison https://www.jenitennison.com/blog/node/157 touches on an interesting and relevant point, and one that *does* circle back to this discussion. Start at the section marked “Standards Bodies”. She wrote:
The fundamental difference between the way either of the competing HTML5 ‘authoring groups’ works comes down to one simple fact: at the WHAT WG if Ian Hickson disagrees with you, he ignores you and plows forward with his idea. Some feel that this is the right thing, that strong leadership makes for a responsive and agile specification, unburdened with having to account for all points of view or criticisms. Just like a dictatorship. Clearly the 4 browser companies (excluding Microsoft) feel that this is in the best interest – after all they have product requirements and release cycles that measure in weeks, and the browser that has the most wiz-bang features this month wins market share, and that means money (even to the “Open Source” Mozilla). Many however disagree that this is the best way to advance the web.
The larger question becomes what happens *if* Ian is mistaken? What if he makes a miscalculation. I mean, does anyone truly believe he is infallible? That every single thing he decides upon is 100% correct? That his sheer genius is such that he alone can single-handedly address and solve all of the problems of the web?
The real problem with the WHAT WG is that it is a mono-culture that consists of nothing but engineers. There is little diversity of voices or opinions, and those voices that do contradict Ian are quickly and bluntly dismissed by Ian, with no recourse, no second sober thought, no appeal process. And even when WHAT WG *do* settle on a ‘solution’ to accessibility issues, they really don’t actually get around to doing anything about it. It often appears that when it comes time for real commitment to ensuring accessibility, for the major browser manufacturers there is much waving of hands, but little substance under the hood.
The truly sad thing is that Bijan (and I mean you no offense) has missed this larger and more fundamental problem here; that the divergences, the “forking” almost always falls on questions of ensuring accessible web content. This is however, sadly an area that both Ian, and his employer Google, seems to consistently miss the mark. Ask yourself, how accessible *IS* Android today? Chrome OS? Why is the US DOJ conducting an investigation on the accessibility of the suite of Google apps (Gmail, Contacts, Calendar, Google docs)? When on-line accessibility is simply a buzz-word that gets paid nothing more than lip-service by the browser vendors (which sadly is what we can point to today – the proof is in the delivery), then Ian can dream up and be wrong on any manner of techniques and points.
What many readers need to remember however, and that includes web developers who need and want all this cool stuff this afternoon – never mind next week, is that the web is more than a bunch of hot-shot code jockeys cranking out the latest and coolest web app. It’s now a multi-billion dollar business and communications tool that is employed not just by The Next Cool Website, Inc., but also by large corporations across multiple sectors (from the Royal Bank of Scotland – apparently the richest bank in the world, to Exxon Mobil, Pfizer drugs, Toyota or General Motors, Nippon Telegraph and Telephone or AT&T). It is now also a critical tool for Academia and Governments around the world.
Bijan wrote:
The problem here of course is that the people that want the WHAT WG version to win are but a small minority of the larger ecosystem. This is due in part to the fact that they are younger, smaller, and more nimble. They lack however the larger and broader perspective that consulting with other less “tech-savvy” (or at least less jack-rabbit responsive) entities bring to the discussion. And it is worth noting that for many of these organizations, they put their trust and faith in the W3C to not make costly mistakes.
Thus the real harm to me is the perpetuation of the myth that only the browser manufacturers truly have a say in how things will unfold. As Jeni noted in her article I started out referencing, once-upon-a-time Microsoft tried that approach, and sadly learned an expensive lesson. Between expensive and embarrassing lawsuits in the European Union (around the restrictively tight bundling of IE to Windows) to the whole IE 6 issue and it’s “our way is the right way” approach, never mind consulting (and it is worth remembering that at one time IE6 was *the most* standards compliant browser in the marketplace).
Maybe when Google and Apple face that same cross-roads they will come to realize that all dictators eventually get deposed, and that truly a system that values all input and delivers on agreed solutions (rather than imposed solutions) will win out. Meanwhile I fervently hope that the newest generation of web developers out there pause for just a minute and reflect on history, because as Sir Winston Churchill said:
Clearly not. As I pointed out, there’s nothing, afaik, in the member agreement or in the WHATWG/W3C agreement, or in anything Ian’s ever said that bound him explicitly or implicitly to not maintain a separate version of HTML. The contrary. The WHATWG process was clear before the work came to the W3C.
It sure seems like you are importing a legitimacy point.
I’m pretty sure for many of these decision you can find the arguments for it, including the relevant beneficiaries. I think my general answer suffices for who benefits from the fact of divergence.
I don’t see any inconsistency with someone resisting some forks but not others. Resisting accidental forks seems to be a perfectly reasonable thing to do, in general. (Are you defending accidental forks? I.e., forks that weren’t intended and don’t have a goal supported by that forking.) Finally, you can always consistently resist the substantive goals of any particular fork.
Hi John,
So, you are making a legitimacy point. But your argument consists primarily of 1) a weak analogy, 2) some mis-statements, and 3) disagreement with substantive outcomes.
Re, 1: There just is no fundamental illegitimacy (at least no unusual ones) in a standards organization being organized as a “benevolent dictatorship”. That’s the (nominal) organization of the W3C. It’s the nominal organizaiton of most companies and other organizations in the US. It’s a common model for software development.
Re, 2: It’s very clear, very very clear, that Ian does “account” for all points of view or criticism. He clearer reads it all and weighs it (including his own). You just don’t agree with his response to that critcism. Which is fine! He may well be wrong. But we can easily imagine someone who systematically fails to even nominally deal with or solicit other points of view. That just isn’t Ian. It’s actually a real strength of him qua editor that he seeks out a huge amount and diversity of input. You do your position no strength to deny that.
So it really comes down to problems with the substantive outcomes. Which are serious!
Oh John. C’mon. I didn’t miss that that is part of Steve’s subtext here. Steve didn’t raise that here directly and I’m addressing the actual arguments raised here that I think are clearly and, more importantly, obviously wrong.
(FWIW, I don’t think you do well in a debate to presume and condescend in this way. You have little idea of my overall beliefs and motivations and thus to project a certain psychological state on me, aside from being potentially offensive (which you recognized and tried to forestall) puts you at strong risk at not understanding and acknowledging divergent points of view. Which, by your own lights, is some sort of problem.
It’s not that I don’t think that there are psychological points to be made. For example, I think that a lot people make these weak procedural arguments because they feel like they have more power in the W3C. Which I think is a fine motive, but it doesn’t change whether Ian is acting in good faith wrt forking or whether a state of consensus exists in either organization.)
Oops, gotta run, I’ll try to address the rest later.
Hi Bijan,
You haven’t provided any evidence as to the benefits of forking HTML apart from
This is a weak argument at best, yet you fail to provide any other evidence of benefits for the people who the spec is supposed to be for.
You continue to push the legimacy/illegitimacy line, as if it is a symptom of the W3C, when it is it is a concept inherent within the rhetoric of the WHATWG advocates that the WHATWG spec is the canonical definition of HTML, while the W3C version is an inferior subset of the former:
https://lists.w3.org/Archives/Public/public-html/2011Jun/0175.html
You have provided no argument as to why it is consistent on the one hand to object to the normativity of one version of a spec (in case accidental forks occur), which is mechanically processed subset of and intended to be in synch with another while supporting the intentional conflicts in another version. To be consistent the same people should be arguing that the HTML5 spec should not have normative status as it is a mechanically processed version of the HTML living standard (+intentional conflicts) or the whatwg web developer edition or web applications 1.0 should not claim to be normative, but there is nothing on the public record to this effect.
Hi Steve,
I hope we can separate out various entangled points, but it’s not been looking good so far 🙁 Perhaps I’ll do shorter comments which focus on one point.
It’s not complicated. 1) People who want their position to win (or be considered, etc.) benefit from having their preferred solution specced in an obvious, prominent place. I take it you don’t deny this. 2) The people who are forking (regardless of which way you think the forks is going, i.e., that the WHATWG is forking from the W3C or the W3C is forking from the WHATWG) have beliefs about how their positions benefit various groups. In so far as they are correct in their beliefs, those groups benefit.
Both sides claim, and I believe with sincerity, that their position on these accessibility issues primarily benefit people in need of such support. Both sides claim that the other sides position is (comparatively, at least) detrimental to people in need of accessibility support.
This is all non-controversial, right? If Ian’s right on the first order points, then we all want him to win. If you are right (for example), we all want you to win.
I trust that you wouldn’t be very satisfied if the W3C produced an anti-accessibility spec, even if it adhered to all the W3C procedures. This has happened (though not in quite such stark terms; see the WCAG Samurai)!
So, it’s really not about forking, or organizational legitimacy, but with substantive points of disagreement within, I believe, broad agreement on goals.
I find nothing to disagree with in your last comment, but it doesn’t explain how for example an implementor benefits if she has 2 conflicting normative requirements, both claiming to be authoritative or an author benefits or the end user.
Threaded comments would be nice 🙂
I push a critique of that line, because I see it in your writing and I believe your particular use of it is incorrect (and strategically counterproductive). It may be similarly correct elsewhere.
The quote you cite is primarily about 1) the technical quality of and 2) the sociological facts surrounding the two specs not about the legitimacy of the generating processes.
Now there is a connection between e.g., technical quality and perceived legitimacy and actual adoption. There can be connections between trust in a procedure or organization and adoption. But I think, overall, they are fairly minor wrt HTML5 and, in general, the W3C started far down the credibility scale.
I don’t think it’s wrong to try to use the W3C to influence HTML 5. It’s probably a good idea, in fact. But esp. if you hold consensus to be a key value you need to take people’s strongly expressed interests and positions seriously.
Plus, I don’t really see what you (or anyone) expect to achieve by trying to cast doubt on the WHATWG’s legitimacy. I guess it’s good for whipping up some ire in some people (that can be useful). But unless you are scrupulously fair to the WHATWG it’s hard to see how you can make a moral suasion case against it.
Obviously, no one benefits from that per se which is why people object to the possibility of accidentally entering that situation.
However, if you disagree with one set, and can’t change the other, then what gain to you get by not forking? (You can, sometimes! It depends on the strength of the feeling, of course.)
Again, you could advocate the W3C simply sych with the WHATWG version. That would end the forking. It’s perfectly possible. Ian, I’m sure, would be happy to only maintain the one version. But I presume you care enough about the divergences to prefer the status quo to that status.
Evidently that’s true of Ian as well. Which simply takes us back to the first order disagreement. That’s where the discussion properly rests. I think there are fairly reasonable cases to be made both ways in many of the situations, so I’m pretty happy for there to be some competition. I don’t yet see any short term negative effects (e.g., it’s not blocking adoption of HTML5; afaik, it’s not degraded accessibility on the web; etc.) and there’s been some good ones (e.g., I think the discussion pro-longdesc has gotten a lot better over the years; I was fairly convinced by the longdesc lottery line but I’m more on the fence now although, for example, I don’t fine all of Laura’s doc very convincing, esp. the idea that an exact replacement is required).
I wrote this piece as a counterpoint to the persistent negative statements made about the legitimacy of the W3C by WHATWG advocates in regards to HTML and the wording of the intro in the WHATG spec about the differences and to highlight the fact that the majority of the differences have to do with accessibility.
and yes I do consider an organisation that includes many people with disabilities and accessibility practicioners, who are actively involved in the development process of HTML, as better than effectively a one person organisation that does not include the same.
@Bijan
You wrote:
It is very good that you share that goal. But having followed the discussions on the HTML5 WG mailing list I think that your assumption unfortunately is not justified.
Andreas Kuckartz:
If you have any evidence to back up such an extraordinary claim, I suggest you post it.
In my opinion HTML5 will significantly increase web accessibility, and WHATWG and HTMLWG have already done more to advance web accessibility than W3C WAI has managed to achieve in over a decade.
And this is what really annoys a tiny minority of W3C WAI people (not Steve) and makes them deliberately misrepresent accessibility in HTML5. It’s not the 0.1% HTML5 got wrong about accessibility that annoys them, it’s the 99.9% it got right.
Andreas Kuckartz, pretty much everyone has stated explicitly that they are for whatever measures they can be convinced are actually effective. I think there has been enough evidence to show that accessibility is at least one goal of everyone.
Take the longdesc debate: Those opposed couch all their debate in terms of the negative effect they perceive of longdesc on overall accessibility. I really see no other motivation for them to oppose it. Really. What would it be? Opposing it causes enough of a stink that it seems reasonable to think that the cost of not opposing it is high relative to just giving in. Do you think that e.g., Ian is actively anti-accessibility?
That, frankly, seems off the chart to me.
That’s fine, but then I don’t know why you denied my claim that you are primarily making legitimacy arguments. I don’t find your particular arguments about WHATWG legitimacy to be convincing at all. It’s not that hard to come up with some arguments as to why the W3C has legitimacy. That the current HTMLWG has made these decisions based on consensus is pretty easy to show false, though (for a reasonable notion of consensus).
I’ll note that these are different grounds and not about pure legitimacy qua organization per say (at least the first part) but, I think, about substantive outcome.
In neither case are the organizations broadly — or even structurally — democratic, for example. The W3C has a fairly mixed history wrt accessibility (e.g., see the WCAG Samurai).
I think the “one person shop” line is more rhetoric than reasonable. Yes, Ian has decision power, but it’s equally clear that there is broad, effective participation.
Try this thought experiment: If Ian were systematically making decisions you liked, would you have a problem with that organization? If the WHATWG version was switched with the W3C version, would you want the fork to continue?
Being passionate about substantive outcomes is great. But I think it’s important to recognize that there is a substantive disagreement about strategy and tactics (and less about goals). Similarly, the procedural issues really don’t matter too much next to the substantive ones.
Given that you have no real procedural leverage over Ian, it also just seems more pragmatic.
Finally, I think the size and immediate effect of microdata is a far bigger than any of the accessibility ones, afaict, if only because the accessibility stuff shifts more slowly. I guess that’s just a bit of evidence that it’s not all about the accessibility for the WHATWG.
I trust it goes without my saying, but it seems worth it to say, that the likely negative effects of botched accessibility are almost certainly far more serious to a much more vulnerable population than microdata vs. RDFa. In the latter it’s mostly big companies vs. other companies; in the former, it’s a traditionally marginalized group.
But that cuts both ways! I think it’s possible to sincerely and passionately care about accessibility and think longdesc is a bad idea (Mark Pilgrim comes to mind, but he might be an outlier for a variety of reasons). Indeed, the more congruent the values of both sides wrt accessibility, the more stubborn about the substantive results each, by their own lights, should be.
I agree with you @mattur, but would also like you to back up your extraordinary claim:
Hi Bijan,
I don’t think that I am “primarily making legitimacy arguments”.
Can you elucidate?
Well no as that is not a point of divergence, there is no fork of the normative requirements of the WHATWG living standard and W3C microdata spec that I am aware of.
The majority of decisions Ian makes I do not have the knowledge or understanding to either like or dislike them or agree/disagree, the majority of decisions he has made in regards to accessibility in HTML/HTML5 I think I have agreed with (its hard to quantify). If the W3C version was switched with the WHATWG version I would be using the HTML WG process to argue for changes. I don’t see your point.
I don’t see how your mention of the WCAG Samurai demonstrates that the W3C has a fairly mixed history in regards to accessibility, can you explain?
I am not a member of the HTML-WG or the WHATWG. I have however followed the process to develop a new version of HTML since well before the effort was called HTML5. Those that have read what I write on Twitter probably know where I stand in all this by now, but I am going to try to put that aside for a second and try to explain why I think the HTML5 specification is forked ( I’m probably wrong ) but here it is:
First of all, both organizations involved here are capable of error. Just to give some examples, from what I have read the process at the W3C to develop the second version of the WCAG left a lot to be desired. Just like the process to standardize WebSockets could have been handled better by the WHATWG. If we don’t accept that people and organizations are capable of error then there is no point in discussing this. But it is important that the people involved try to learn something from that so that these errors/mistakes can be avoided in the future.
I think the main reason why the specification is forked is because of the change proposals. These seems very polarizing, often with one proposal from one “side” and another from the other side. Then the HTML-WG chairs have the somewhat impossible task to select one of them without driving the different sides further apart. Then there is no guarantee that other, related, issues get decisions that go in the same direction which of course could make the specification inconsistent ( I’m not necessarily saying that I think that’s the case though ).
Just as John Foliot pointed out earlier, the WHATWG consists mainly of engineers. Why isn’t this used as an advantage, accessibility experts from the WAI works out requirements to solve a problem in the specification, and people more interested in the engineering side works out a technical solution that satisfies these requirements and is easy to implement for the web browser developers and makes sense for document authors. Then we would have a change proposal with people from both sides supporting it and that should clearly demonstrate both organizations’ commitment to accessibility. I am not saying that things like this never happen, but it doesn’t seem to happen enough.
If this just continues along the same path then I think the two specifications will just continue to diverge even further.
WebAIM describe alt text for images as “the first principle of web accessibility. It is also one of the most difficult to properly implement” [1]
WAI took 2 years to put a badge on Trace’s accessibility guidelines, and then accidentally froze the already out-of-date WCAG1 for 9 years. When WCAG2 was finally published it had 2 alt examples. At the time, the WHATWG HTML5 spec had 16 alt examples. When this was pointed out [2], it prompted you to write the Text Alternatives in HTML5 document – in the HTMLWG.
IMHO your document is the most important and effective accessibility guidance to come out of the W3C to date.
So yes, I think the WHATWG and HTMLWG, which are trying to make accessibility as intrinsic/built-in as possible as well as providing effective guidance on accommodation techniques, have done more to advance accessibility than the WAI has managed in its entire existence. I also think the WHATWG and HTMLWG are making progress on web accessibility by examining whether the 1997-era AT-specific techniques recommended by WAI (eg the summary attribute) actually work in practice, or could be improved, or are so flawed they should be retired altogether.
It would be great if WAI were doing all this instead – after all it is supposed to be their job – but WAI unfortunately has a well established reputation for being systemically dysfunctional [3][4]. As WAI appears to be unfit for purpose and the W3C management is apparently reluctant or incapable of doing anything to remedy the situation, by necessity the WHATWG, and more recently the HTMLWG, have had to pick up the slack.
To be clear: I think WAI has lots of talented, dedicated individuals in it. The problem is the W3C/WAI process, not the people.
[1] https://webaim.org/techniques/alttext/
[2] https://blog.whatwg.org/omit-alt#comment-7755
[3] https://alistapart.com/article/tohellwithwcag2/
[4] https://alistapart.com/article/testability/
In this post? What is there other than the procedural legitimacy issues (consensus vs. benevolent dictatorship; forking).
(Obviously, you are making substantive arguments all of the time! But I’m not addressing those.)
Ok, so you really do have a strong procedural motivation. Fair enough!
Well, if you look at the call to arms by Joe Clark, you’ll see some serious accusations, e.g.,
The rest of the article details both substantive and procedural issues which led Clark to work outside the W3C and, in fact, to fork the spec (via errata).
Hi Mattur,
A similar claim was made by Hixie in 2009
Which I showed to be false .
As a member of the protocols and formats working group I consider myself to be part of WAI and work closely with both the W3C WAI staff and other people involved in the working groups under the WAI domain, including any work involved with HTML.
Just to cherry pick a few points. In general, I think, John, that your overall view is not correct 🙂
How did you determine this? Of people who are paying attention, it seems like a significant fraction do prefer the WHATWG version. Of the people are paying only some attention, I’d guess they don’t know the difference.
My understanding of participation rates is that the WHATWG has a larger and larger active participation.
I don’t think anyone says that per se. The browser vendors quickly point out all the constraints from their user base they are under. Ian consistently solicits inputs from all corners. Everyone would welcome active participation from e.g., screen reader developers (their absences is an ongoing shame).
But, in the end, the browser is probably the most complex and most significant piece of software for the web. (Web servers come close, but they’re rather easier.) It’s really quite fair to say that the constitute the web for most people. They certainly are the primary point of contact for almost everyone almost all the time. And they are developed by private organizations, acting more or less freely, in an open, somewhat regulated market. I’m not sure how anyone can systematically compel them to do anything. I don’t see any of them having monopoly status…indeed, I’m really unsure as to what you think the (structural) problem is. There’s at least two, highly forkable, code bases with which you could attempt to become a rival and thus wield similar market power.
I agree that it’s sensible to seek input far and wide. But I fail to see that there is any objectionable imposition (in the moral or legal sense).
Oops, missed this, sure! A reasonable notion of a state of consensus existing within an organization wrt a decision is that the participants in the organizations have all consented to the decision, typically with a sufficient level of agreement.
Prima facie, having a disagreement of a level such that you fork (i.e., negate the decision in a very strong way) simply means that there is no actual consensus, regardless of the formal markers. It’s clear that a lot of people just withdrew from certain aspects of the W3C group. It’s also clear that if the fork didn’t exist, then many of those people would use the W3C procedural tools more aggressively.
In essence, there’s no solidarity wrt those decisions. Which is not too surprising, given their contentiousness, the stakes, and the size of the group. The WHATWG has a fair bit of consensus among the members of the mailing list, afaict, but that’s achieved by people who are in serious dissent leaving or not joining.
Consensus isn’t the only value, of course. But if you do value consensus then you care strongly about everyone’s interests and input. Including Ian’s, for example, and that of like minded people.
(I’m not saying that you, personally, are bound to seek consensus with them. You aren’t! But neither can you claim consensus.)
So are you saying that the HTML WG decisions are not consensus decisions as per 3.3 Consensus or that your definition differs?
how would you propose to accomplish this?
In regards to the WCAG Samurai , I was there at the time, Joe’s public issue raising caused changes to WCAG 2, for the better I believe, his ‘fork’ went nowhere and I don’t believe it was effective by any measure.
From the overall tone of your comments it is obvious to me that you have a higher opinion of the WHATWG and Ian in particular, than you do of the HTML WG, but as yet, just as you don’t find my arguments convincing, you have presented nothing that I find persuasive.
I have attempted to take your thoughts on board.
Any decision with a FO is not a W3C-consensus decision. But the W3C-consensus definition isn’t a definition of consensus. It’s more like a standard marker of consensus. If you believe consensus is a value, then presumably you mean consensus in its general sense.
The W3C-consensus criteria, for example, apply only to “eligible” individuals, not to all stakeholders and not even to all interested stakeholders.
“Consensus by attrition” may present the formal signs of consensus without reflecting a real state of consensus (e.g., everyone’s interests taken seriously; solidarity in the decision). That people don’t bother to register their dissent in the proscribed ways doesn’t indicate that there is consensus among them.
To put it another way, if there weren’t the fork, you’d almost certainly see FO to all these decisions. That, to me, is a pretty good indicator that there’s no consensus.
I presume his willingness and attempt to fork was part of what made the changes happen. You don’t necessarily need your fork to win (in the sense of displacing the other) for it to have been effective (e.g., by changing the original).
Well, you’re just wrong there, sorry. Next time ask.
I have a higher opinion of the legitimacy of the WHATWG than you do, afaict. I don’t believe that the W3C is inherently better or even procedurally better. I think they have different strengths and weaknesses.
I think very highly of Ian as an editor. He does an extraordinary job. I don’t think he’s hugely effective at bridging communities, at least directly. He did rather well at building up the WHATWG and moving HTML5 forward.
These seem pretty indisputable.
I am having trouble pinning you down 🙂
But, for example, I think it’s evident that the fact of a fork in normative requirements means that there is no true consensus on the normative requirements in dispute, regardless of whether the HTMLWG decision meets the W3C formal requirements for a declaration of consensus. Do you agree?
Hi Bijan,
thanks for clarifying.
Probably because my thoughts and opinions continue to evolve.
I agree.
I don’t question or doubt his technical skills in specifying how browsers work. I do question his abilities to define authoring conformance requirements.
He has been woefully ineffective in regards to the accessibility community, and while a few dissenting individuals can be accepted, the scale of the dissent across a broad range of people involved in accessibility is deeply troubling.
Interesting to note that you haven’t picked up on my forking of HTML5/HTML in the alt techniques document.
Is it relevant here? I don’t, for example, think you are a hypocrite for opposing some forks and endorsing others. I think you’re wrong to have suggested the other forks as illegitimate or that the other people are being hypocritical by opposing some forks but not others. (One can be hypocritical in such cases, but I don’t see strong evidence that anyone is at the moment. I have a fairly high evidentiary bar there, fwiw.)
Yes, Ian hasn’t faired well with a key accessibility community (my colleague Simon Harper, for example, gets livid about it), but the reverse is true as well. (Though, I think most people have made some reasonable efforts; yours are among the “most improved” afaict.)
Personally, I want the best thing to win and I don’t know what that is at the moment. So I’m rather more tolerant of dissent. For example, I think the upsurage of pro-longdesc analysis and argument is great even though I’m not yet convinced.
Steve:
One factor in that could be the wave of FUD circulated by some (not you).
eg WHATWG is removing accessibility! help keep accessibility and semantics in HTML! alt is being removed! longdesc will stop working and no one will notice! millions of disabled people will die! is there hope for inclusion?! HTML5 will break the web by killing off a valid and useful shrubbery! Hixie hates blind people and once smiled at diveintomark! ensuring accessibility support in HTML5! The scale of the dissent is deeply troubling! (just kidding) etc etc etc.
Come to think of it, I’m surprised the HTML5 is Anti-Accessibility!!! movement isn’t significantly bigger.
I suppose after some folks in hats promoted XHTML1 as “more accessible” even though that wasn’t true, it was perhaps inevitable that some folks would say HTML5 is “less accessible”, even though that isn’t true either. Especially when they realised they’d been led off a cliff. Still disappointing imho.
Yeah, that is exactly what I mean. If we can go from a situation where people could say things like “I agree that this feature is needed but I am still going to try to stop the CP because the proposed solution is horribad” to “I agree that this feature is needed but I am going to suggest some changes to the proposed solution” then I think the need for the specs to diverge further could be minimized.
More cooperation would hopefully also lead to that it is easier to find a compromise when people disagree if a feature is needed or not. All this does of course assume, among other things, that people actually want this process to work better.