Shelley Powers describes the hoops you need to go through to submit changes to the HTML5 specification:
The draft of the HTML5 spec out at the W3C is under continuous change, the formal Working Draft hasn’t been updated for some time, so we’re having to make changes on the run. To actually make these changes requires a degree of technical proficiency that has nothing to do with HTML markup. We’re told that to propose changes to the document for consideration, we need to, first of all, send our SSH2 public key into the Michael Smith, who will then set us up so that we can check out the existing documents, using CVS. We will then need to use a variety of tools, SVN, CVS, makefiles, XSLT, and so on, just to get reach a point that our concerns and suggestions are actually taken seriously.
And here’s the effect of the barriers:
HTML is a web document markup language. It is not a programming language or operating system. It is not WebKit, the Apache project, or the Linux kernel. Why it is being treated as such is because of group demographics. The recommended processes to work through issues are symptomatic of the fact that there is little or no diversity in the HTML 5 working group, virtually none in the WhatWG group. What we have is a working group run by tech geeks: not designers, not accessibility experts, graphic artists, web authors, not even web developers. Hard core, to the metal, geeks. And to a geek, the way around a problem is to throw technology at it; the way to filter input is to use technology as a barrier.
I couldn’t make up a more perfect example that bears out the point I was making in my post on disparate impact a couple of weeks ago.
Disparate impact in practice
Shelley Powers describes the hoops you need to go through to submit changes to the HTML5 specification:
And here’s the effect of the barriers:
I couldn’t make up a more perfect example that bears out the point I was making in my post on disparate impact a couple of weeks ago.