February 8, 2010
Standard or Specification?
You skipped over a question I asked in the previous e-mail: If there
is advice in the UAAG spec that you think implementors should follow
here, then the best way we can ensure that it is followed is, IMHO, to
also include it in HTML. Is there something I’ve omitted that UAAG
recommends of relevance here? If so, what?
So why should we quote the UAAG rather than including any relevant advice inline?
Standard or Specification?
I believe what we have is a conflict of constituents.
What many people seem to be overlooking here is that we are writing more than just a Technical Specification for browser engineers, we are also writing a Standard, and I believe that the differences between the two is the major rub.
In software development, a functional specification (also, functional spec or specs or functional specifications document (FSD)) is the set of documentation that describes the behavior of a computer program or larger software system. The documentation typically describes various inputs that can be provided to the software system and how the system responds to those inputs.
UAAG is a Guideline – a permeable evolving document that can be reviewed, revised, updated and otherwise modified to address the evolutionary nature of our industry. (Ditto as well for the WCAG2 Techniques for Success Criteria, outside of this discussion, but relevant in the larger perspective)
Standards, on the other hand, do not have that luxury.
Standards are locked down, carved in stone, and take years to re-open. A Standard is
The problem is further compounded by the WHATWG‘s original design intention, adopted apparently by the W3C, of having a ‘version-less’ HTML (while at the same time referring to this as HTML5, and having oblique comments regarding ‘HTML6′). Yet at the same time, we are now racing towards ‘Last Call’, with dates and deadlines – all indicators that at some point work will stop, we will ‘peg’ the spec as a Standard, and then start work on the next version. Why? Legal requirements, internationalization (translation), multi-year projects, etc.
For this reason, separating Techniques from Requirements makes the adoption of new Standards easier for those entities that require the stability that a Standard provides, yet also allows those who actually work with any such Standard the greatest flexibility in achieving all the business requirements, not just the technical ones. Modularization here is a win, not a barrier.
Because I think the document should, to the extent possible, be self-contained. This is why I object to splitting the spec up, it’s why I object to deferring to other documents for implementation advice, it’s why I objected to having a separate “author” version of the spec.
Having one, monolithic tome for the few thousands of engineers who will actually use the document as an implementer is indeed likely useful and perhaps even desirable, but for the millions of others who will be affected by this document – as a Specification or as a Standard – it is less than optimum.
Consider pedagogy: teaching authors (not engineers) how to use and implement HTML5 properly will be a huge undertaking. Already our industry is plagued with the problem of textbooks and instructional manuals that are often obsolete by the time they are published – as a visit to any large bookstore (and their technology remainders bin) will attest. Lumping everything into one 1200 page printed document would on one hand make publisher’s lives easier, but would also do a disservice to the constituents that need this information in a more traditional format like a book. Here again, separating ‘hard’ requirements from evolving techniques allows for a larger degree of control and accuracy in disseminating this crucial information.
As an active web accessibility practitioner, I can attest that this is a lesson that the WAI group learned quite some time ago. Shortly after the release of WCAG1 it was obvious to our community that the ‘all-in-one’ WCAG1 Guideline – written to be a GUIDELINE – was instead being adopted as a Standard around the world, by the very same constituents I referenced previously: governments, banks, energy sector, medical industry, etc. In one significant instance, the ambiguity of the Guideline actually introduced a parallel Standard – Section 508 – which further introduced a cacophony of information, and doubled the work effort of any and all technology vendor who’s business requirements mandated that they adhere to both ‘standards’ – even when one was never really written to be a Standard.
However, the single largest problem we faced was that WCAG1, written in the late 1990′s, was being adopted as a ‘locked-down’ Standard, which sometimes forced authors and developers to remain adhered to obsolete and out-dated techniques. After grappling with this issue for many, many years the WAI came to the realization that separating the requirements from the techniques allowed for the stability and flexibility that was required. Here’s an example: to meet WCAG1 AA compliance, authors are mandated to create documents that “Validate to published formal grammars”
(http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-identify-grammar). For this reason, many content producers today, mandated to follow WCAG1, cannot use ARIA. This clearly is an unintended problem that was introduced when WCAG1 prescribed a specific ‘technique’ to achieve accessible content (and here I will side-step whether or not it actually did produce more accessible documents). Fortunately WCAG2 does not have this specifically mandated technique/requirement, and authors who have the luxury of adopting WCAG2 over WCAG1 can use ARIA today. Why? Because WCAG2 separated techniques from requirements.
I believe the lesson learned here must be acknowledged, else we are doomed to repeat the same mistakes and make the HTML5 Standard (as opposed to the HTML5 Technical Specification) a restrictive document that frustrates rather than encourages innovation. As we collectively write what will surely be the most important technical document of the early 21st century, we must remember all of the constituents that will be affected by our work, and not just focus on one small (albeit important) subset – browser implementers.