general comment comments

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.

Accordingly, the WCAG2ICT should be entirely re-scoped and revised, moved to an appropriate body for further development, or terminated.

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.

[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

From my point of view WCAG2 is a solution looking for a additional problems to solve. Invented with web content in mind, at least some would claim.agree that it became quite successful - at least for web content. Now, being encouraged by that success it seems WCAG2 proponents felt like they should find other stuff to which WCAG2 concepts could be applied. A little bit like trying to figure out what a hammer - quite good at dealing with nails - could do with screws. While some functionality could be achieved, hammers and screws will never be a good match. Instead, in order to deal with screws, one would have to start thinking starting form what screws are, not even thinking of a hammer. A concept essential to screws - 'turning' - does not even exist in the world of hammers and nails.

Along the same lines I think in order to come up with something useful and meaningful for non-web content.documents, one would have to start from non-web content/documents, not from a tool that has been proven to work well with web content/documents. Otherwise there is a drastic risk to miss essential aspects, and it could easily happen that WCAG2 concepts cover non-web content/documents quite well where actually they don't (or it is at least unknown / undefined to which degree they cover them). And thus the quality and value of "applying WCAG2 to non-web ICT" is undefined / unknown.

Maybe the WAI is not even the ideal context to start doing something about non-web content/documents...?

Olaf

Related issues: (space separated ids)

WG Notes:

Proposed Resolution:

(Please make sure the resolution is adapted for public consumption)

substantive comments

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.

[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

In the world of software development quite a bit of work has been carried out in order to make software more accessible than it used to be.

The document "Applying WCAG 2.0 to Non-Web Information and Communications Technologies" per its draft dated July 27, 2012 does not take any of that into account though the concepts and principles behind those are extremely useful, both in terms of architecture as well as in terms of various specifics.

I think it is essential to first learn from others about what has already been achieved, before coming up with something else out of the blue.

In a nutshell:
First learn from existing achievements, then - if really something new and useful can be added to it - come up with it. Don't (try to) reinvent the wheel - the world does not need yet another paradigm.

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.

(This text was originally a part of Duff Johnson's "Conclusion" section.)

[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

The ISO standard "ISO 9241-171:2008 - Ergonomics of human-system interaction -- Part 171: Guidance on software accessibility" covers 'accessible software' quite nicely - what does WCAG2ICT have to offer on top of it?

Along the same lines, the following ISO standards have to be taken into account of WCAG2ICT is serious about its job, and it should be proven, what WCAG2ICT adds that these don't offer yet:

In a nutshell:
Either make clear what WCAG2ICT has to offer on top of ISO 9241-171 and other ICT related accessibility standards (and if it does offer anything, elaborate on where it overlaps and where it doesn't), or abandon the idea of finalizing and publishing WCAG2ICT as far as software is concerned.

Title change from "Applying WCAG 2.0 to Non-Web Information and Communications Technologies" to "Translating and Applying WCAG 2.0 to Non-Web Information and Communications Technologies"

The introductory text and the proposed draft clearly indicate that much of the normative text in WCAG 2.0 cannot be used for non-web ICT context without significant text replacement. The title "Applying WCAG 2.0 to Non-Web Information and Communications Technologies" is misleading given the substantial changes necessary for any attempt to apply WCAG 2.0 to non-web ICT. In fact, the first sentence of the introductory text used the term interpretation and application instead. We urge that the title of the document to be changed to "Interpreting and applying WCAG 2.0 to Non-Web Information and Communications Technologies" to prevent audience from being misled into believing that WCAG 2.0 can be applied as its current form to non-web ICT.

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:

[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

In a number of scenarios it can be envisioned that accessibility and usability do not coincide, for example where a software sends out "information" to the user in a concurrent manner, possibly leading to information overflow which can only be kept at bay by reducing the amount of information and boiling it down to the most essential aspects. Thus for example, color, shape or blinking/movement could be used to steer attention to the currently most relevant information. It may be next to impossible to make that incarnation of that software accessible at the same time, and it may rather have to be rewritten (or another mode of operation may have to be implemented), to make it 'accessible' (but maybe not nice / efficient to use anymore for other users). Typically it will have to be asked what kind of user is using the software for what purpose / tasks (does software that controls a nuclear power plant really have to be accessible?).

In a nutshell:
make the connection between accessibility and usability, and take usage context and purpose/tasks into account.

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.

[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

In ISO/IEC 13066-1 (and elsewhere) there is a very relevant distinction between platform or system software and application software, e.g. as phrased in ISO/IEC 13066-1, clause 4.2.5 (which also adds a third - support software):

"
a) System software, which includes the operating system and other instance of platform software;
b) Application software;
c) Support software.
"

This distinction has to play a substantial role when talking about the accessibility of software. For example, on iOS, when a piece of application software is programmed strictly adhering to applicable iOS guidelines, and does not introduce any 'custom stuff', the developer often essentially does not have to do anything about accessibility, as it will be taken care of by iOS and its built-in accessibility support.

In a nutshell:
WCAG2ICT to distinguish between platform (or systems software) and application software, only come up with guidelines specific to each of these, and also explain how one of the two relates to the other. Also, make sure to take the whole ISO/IEC 13066-1 into account (at least where software aspects are concerned).

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.

WCAG 2.0, even after translation, may not be suitable to environments outside of the desktop
A fundamental assumption made in many success criteria of WCAG 2.0 is the presence of a browser, an operating system, and some form of assistive technologies. This was a fair assumption during the creation of WCAG 2.0. But it is not appropriate assumption in the context of non-web ICT. This is most obviously the case for ICT functionalities closed from assistive technologies such as most ATM machine functionalities. All success criteria containing the term "programmatically determined" were constructed to allow assistive technologies to better decipher the web content. But when assistive technologies are not present, these success criteria are effectively useless. Indeed, it is still necessary for the content to be presented in a way that users with disabilities can consume. But implementing such solutions in a programmatically determined nature is not necessary in such context. We recognize that WCAG2ICT TF has not considered ICT with closed functionalities from assistive technologies yet. But the TF should be aware of the unstated limitation of its work so far and make this clear to its audience as soon as possible.

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!

[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

ISO/IEC JTC 1 Special Working Group on Accessibility (SWG-A), JTC 1 SWG-A, has compiled a document that provides an inventory of Accessibility and Accessibility-related Standards and Specifications (cf. http://www.jtc1access.org/documents/swga_522_Inventory_Standards_Specifications.pdf):

it would be good to see that WCAG2ICT takes it into account and refers to it as a relevant source, and explains what WCAG2ICT would add on top of the standards and specifications listed in this document, and how it relates at least to those standards and specification listed in the document that are relevant to the topic at hand.

In a nutshell:
Review and take into account the SWG-A document, identify what is added on top of standards listed there, and indicate relation between WCAG2ICT and the (standards listed in the) SGW-A document

I have a lot of trouble trying understand how this document helps anyone.
On the one hand, the document refers to WCAG "programmatically determined"
repeatedly, and this doesn't make sense in many closed systems such as ATMs
or Kiosks.

On the other hand, it lacks details to help me as a developer figure out
what I need to do. E.g., my personal focus is math. A question that often
comes up is "what is required for math accessibility?" A search for the
term math comes up empty as does a similar search of WCAG 2.0 (not good).
Having spent a good deal of time reading the WCAG guidelines, I know that
math is covered under 1.1.1 (text alternatives) or 1.3.1 (information,
structure, and relationships). So how to meet 1.1.1 in a non-web
environment? WCAG2ICT says to provide a text alternative. Similarly, for
1.3.1, it says the structure should be "programmatically determined or are
available in text". But these don't make sense in many situations away
from a PC such as a kiosk in a museum. The focus should be on providing an
alternative presentation such as speech or braille, not on the actual
underlying content.

The bottom line is that it seems that the document is just lazy: it
doesn't do the work needed to understanding non-web context and simply
parrots WCAG. It leaves it up to the reader to try and figure out if WCAG
makes sense for the particular technology or not and how to adopt WCAG to
the appropriate situations... but isn't the purpose of this document to
inform the reader about how WCAG applies to their non-web situation?

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.