Conflict of Constituents (was RE: "image analysis heuristics" (ISSUE-66))

Ian Hickson wrote:
> 
> 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?

Ian Hickson wrote:
> 
> So why should we
> quote the UAAG rather than including any relevant advice inline?

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.

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.
Standards are adopted by entities that cannot, by their very nature, be
nimble and adaptive - governments for one, but other large business
entities that operate not directly inside of our industry, but
increasingly rely on our industry to do business (banks, energy sector,
medical industry, etc.). Standards (and those that use them) have unique
requirements that insist that these standards remain stable and
'non-change-able' - usually for reasons that have nothing to do with
technology: legal obligations, internationalization (translation),
multi-year projects, etc. When one of these entities adopt a Standard,
they cannot have it shifting beneath their feet as our industry races
toward the newest and greatest: the speed with which our industry changes
is both the blessing and the curse that we have as viewed from the
outside.

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 HTML'5', 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.
(Ian Hickson)

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 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.

JF

Received on Monday, 8 February 2010 16:15:26 UTC