The WCAG2ICT fails to execute on the announced purpose.

NOTE: While my affiliations are provided for purposes of disclosure this Comment is my own and does not represent the views of those organizations.

OVERVIEW
 
The WCAG2ICT begins with an un-argued assumption: that guidelines written carefully, deliberately and specifically for web content and technologies are reasonable candidates for evaluating accessibility in “non-Web ICT”.
 
From this dubious basis the document’s Abstract claims that it will provide information on “how” WCAG 2.0 can be applied to non-Web content.  The document’s Introduction goes on to advise that the document will “…help clarify how to use WCAG 2.0”.
 
Unfortunately, the document does not perform these self-appointed functions whatsoever. Instead, it prefers to simply claim (in most cases) that WCAG 2.0’s Success Criteria may be applied “directly as written” without any suggestion as to “how”.
 
I’m extremely disappointed. Not only does the WCAG2ICT fail to address its own stated objectives, but reveals in stark terms that W3C has no business going “off-web” in standards development.
 
I’ve provided details on some of my concerns below.
 
 
NO DEFINITION OF TERMS
 
The document does not define any terms at all; an essential prerequisite to understanding the intended scope and application.
 
EXAMPLES: “Software aspects of products” is a key phrase that could mean almost anything. “ICT” presumably includes the vast landscape of kiosks but closed systems receive no attention at all! Perhaps it’s because WCAG 2.0 assumes a content/browser interaction, and thus does not conceive of such systems.
 
To belly-flop at this point in the document strongly implies that the scope simply hasn’t received proper scrutiny.
 
 
NEGLECTED USE CASES
 
A number of concepts occur in the “non-Web” world but don’t feature in the web content considerations developed in WCAG 2.0. Many of these are known to or may have implications for accessibility. Examples include:
 
Content: interoperability, relationships between text, data, data groupings, metadata, annotations, redactions (selective absence of information), fonts, navigation without links.
 
Context: pagination, usage, formality, intent (print, email, web, archive), authentication (digital signatures), portability, pagination, closed systems.
 
Workflow: relationships between source, interim, marked-up, print-stream, flattened, annotated and final-form content.
 
 
EXISTING STANDARDS IGNORED
 
The document fails to take account of, or even acknowledge, the existence of accessibility standards developed specifically for non-web content such as ISO/IEC 29138, ISO/IEC 24786 or ISO 14289.
 
 
DOCUMENTS AND SOFTWARE – THE SAME RULES?
 
The WCAG2ICT attempts to apply WCAG 2.0 not only to non-web documents but also to “software aspects of products”. The notion that the same Success Criteria are usefully applicable across these domains is risible at best. Without substantial justification and development of the theoretical and practical underpinnings of this move, such a massive expansion of scope beyond web content can only reflect poorly on the organization making the attempt.
 
Does Tim know what you guys are doing?
 
 
NOT A TECHNICAL STANDARD
 
While offering broad value at the Principles and Guidelines level, the WCAG 2.0 Success Criteria do not provide much technical guidance that’s applicable directly to non-web ICT.  In an informal (but not-inconsiderable) survey of implementers regarding WCAG 2.0 over the past year, I’ve found that:
 
- Even Web developers (HTML/CSS/JavaScript) often disagree over key provisions of WCAG 2.0.
 
- Non-web developers find WCAG 2.0 both vague and woefully underspecified with respect to technical guidance; SC 1.3.1 is particularly overloaded in this regard.
 
 
WEB-CENTRIC
 
A key example of how WCAG 2.0’s web-centricity makes application to “non-Web ICT” problematic is the question of navigation.
 
In WCAG 2.0 the normative language is developed on the basis that “navigation” in electronic content occurs by way of “links” – controls deliberately embedded in the content by the author for navigational purposes
 
However, the ability to navigate content is a fundamental aspect of accessibility for users of documents – irrespective of links. Non-web documents – from PDF to DOC to PPT files to databases and others, may not include any links at all. Users customarily navigate such files using entirely different (and not always adequate) means such as headings, bookmarks, thumbnails and other features.
 
WCAG 2.0 is silent on navigation besides links. If applied to non-Web ICT, therefore, it’s reasonable to conclude that developers could safely ignore navigational considerations if their documents or other ICT do not include links or other context-changing controls. That’s not exactly the desired outcome!

 
NO APPLICATION IN CLOSED SYSTEMS
 
Programmatic determinability is (rightly) a key concept in WCAG 2.0. The notion rests entirely on the assumption that the operating context is content “out there” and that a user’s browser processes such content as accessed over HTTP. Fair enough – this is all part of the web content definition and other terms of art employed by WCAG 2.0.
 
It’s obvious, however, that this paradigm is entirely inapplicable to closed systems such as kiosks, phones, equipment control interfaces and the like. As such, I have no idea how WCAG 2.0 is to be applied even notionally to such systems – yet the WCAG2ICT advises me to “apply WCAG 2.0 directly as written”!
 
Since closed systems represent a high volume of use cases for non-web ICT, the WCAG2ICT’s assertions in this regard (un-argued as they are) may be dismissed.
 
 
INTEROPERABILITY IGNORED
 
I have this same complaint about WCAG 2.0 but the same problem is enormously magnified when the scope blooms (as per WCAG2ICT’s remit). Interoperability is key not only to developing agreement on outcomes but in the economics of software development and real-world adoption.
 
As an economic matter, accessibility is an area that lends itself to the question of conformance and thus potentially, to litigation. If vendors cannot (or believe they cannot) achieve agreement on the technical means of conformance they will tend to shy away from developing in these areas. Application of WCAG 2.0 “directly as written” to non-Web ICT does little or nothing to assist developers who find they have to climb into web-based concepts that may be entirely alien to them simply to begin a conversation about developing towards accessibility.
 
 
OVERREACH
 
The web is a colossal sphere of technology and human activity; W3C is well and properly engaged therein. It’s difficult to imagine how a web-centric organization, not to mention a web-centric document (WCAG 2.0) can or should be retro-fitted to an entirely distinctive and notably non-web purpose.
 
The WCAG2ICT draft is especially disappointing because it represents such a gross overreach for W3C and the WAI. The draft adds insult to injury by entirely failing to acknowledge existing relevant standards as noted above.
 
It’s as if the rules of the road for cars were applied en-masse to those for trucks, construction equipment, trams and bicycles without even bothering to check in with those developers about their functions, needs, restrictions and aspirations. Certainly, there are many lessons for bicycles to be found in the rules for cars – but it would be foolish and irresponsible to imagine transplanting one to the other.
 
 
CONCLUSION
 
WCAG 2.0 is useful in the web context precisely because it’s web-centric. HTML developers can arrive at a reasonable understanding of how to apply WCAG 2.0 concepts more-or-less directly to the explicit structures of the HTML language and functional parameters of media files and JavaScript.
 
The WCAG2ICT is replete with unsubstantiated claims together with (seemingly) casual and ill-considered assumptions. Given that the document offers the wholesale application of technical concepts to technologies and contexts never envisioned by WCAG 2.0’s authors, these failures are catastrophic with respect to the current draft. This document cannot be regarded as a serious attempt to address accessibility specifications in non-web content and ICT.

This is simply the wrong mission for W3C and WAI, whose concerns are (rightly) web content.
 
Further development of the WCAG2ICT along the current lines will bring disrepute to W3C since this project falls so far out of W3C’s scope and expertise, and meshes so poorly with the subject at hand.
 
As presently constituted the document will simply be ignored as developers either wait for “non-Web ICT” Techniques (that W3C is not set up to provide) or simply give up when they realize that even if they achieve conformance as THEY understand it the chances that others will agree about operational details is slim.
 
Accordingly, the WCAG2ICT should be entirely re-scoped and revised, moved to an appropriate body for further development, or terminated.

Best regards,

Duff Johnson

President, NetCentric US (Creators of CommonLook)
ISO 32000 Intl. Project Co-Leader, US Chair
ISO 14289 US Chair
PDF Association Vice-Chair

Office: +1 617 401 8140
Mobile: +1 617 283 4226
djohnson@commonlook.com
http://www.commonlook.com

Received on Friday, 7 September 2012 15:59:54 UTC