W3C

List of comments on “Applying WCAG 2.0 to Non-Web Information and Communications Technologies” (dated 27 July 2012)

Quick access to

There are 48 comments (sorted by their types, and the section they are about).

1-20 21-40 41-48

general comment comments

Comment LC-2651: Dummy Example with Instructions
Commenter: Michael Cooper <mnc.1971@hotmail.com> (archived message)
Context: Document as a whole
FOR INSTRUCTIONS ON HOW TO FILL OUT A NEW ENTRY GO TO

https://sites.google.com/site/wcag2ict/review-process/instructions-of-entering-new-issues
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2652: Applying WCAG 2.0 to non-web content
Commenter: Olaf Druemmer <o.druemmer@callassoftware.com> (archived message)
Context: Document as a whole
[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
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2673: Duff Johnson - Conclusion
Commenter: Duff Johnson <djohnson@commonlook.com> (archived message)
Context: Document as a whole
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.

Accordingly, the WCAG2ICT should be entirely re-scoped and revised, moved to an appropriate body for further development, or terminated.
LC-2663
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2663: Duff Johnson - Overview
Commenter: Duff Johnson <djohnson@commonlook.com> (archived message)
Context: Document as a whole
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.
LC-2664 LC-2665 LC-2666 LC-2667 LC-2668 LC-2669 LC-2670 LC-2671 LC-2672 LC-2673 LC-2674
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2667: Duff Johnson - Same Rules
Commenter: Duff Johnson <djohnson@commonlook.com> (archived message)
Context: Document as a whole
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?
LC-2663
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2659: Take into account differences between platform and application software
Commenter: Olaf Drümmer <o.druemmer@callassoftware.com> (archived message)
Context: Document as a whole
[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).


Olaf
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2668: Duff Johnson - Technical Standard
Commenter: Duff Johnson <djohnson@commonlook.com> (archived message)
Context: Document as a whole
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.
LC-2663
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2690: WCAG may not be suitable outside of desktop environment [CLOSED]
Commenter: Alex Li <alli@microsoft.com> on behalf of Microsoft (archived message)
Context: Document as a whole
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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2669: Duff Johnson - Web-Centric
Commenter: Duff Johnson <djohnson@commonlook.com> (archived message)
Context: Navigation aspects e.g. Principle 2 & SC 3.2.3 in
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!
LC-2663
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2661: Show relation to JTC1 SWG-A [OTHER STANDARDS]
Commenter: Olaf Drümmer <o.druemmer@callassoftware.com> (archived message)
Context: Document as a whole
[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):

> ISO/IEC JTC 1 Special Working Group on Accessibility (SWG-A), JTC 1 SWG-A, Inventory of Accessibility and Accessibility-related Standards and Specifications
>
> [This inventory expands and evolves: ISO/IEC 29138-2 Information technology — Accessibility considerations for people with disabilities — Part 2: Standards inventory, 2009-06-15]


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


Olaf
LC-2666, LC-2656
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2662: Document doesn't give guidance for closed systems (kiosks) [CLOSED]
Commenter: Neil Soiffer <NeilS@dessci.com> (archived message)
Context: Document as a whole
---------- Forwarded message ----------
From: Neil Soiffer <NeilS@dessci.com>
Date: Thu, Sep 6, 2012 at 4:19 PM
Subject: WCAG2ICT
To: public-comments-wcag20@w3.org


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?

Sincerely,

Neil Soiffer
Senior Scientist
Design Science, Inc.
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~
LC- 2670 LC-2668
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2670: Duff Johnson - Closed Systems [CLOSED]
Commenter: Duff Johnson <djohnson@commonlook.com> (archived message)
Context: Document as a whole
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.
LC-2663
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2692: Need for WCAG 2.0 to update for new technologies
Commenter: Alex Li <alli@microsoft.com> on behalf of Microsoft (archived message)
Context: Document as a whole
While we recognize that WCAG2ICT is not charged to change the normative text of WCAG 2.0, it should make room for the possibility that other efforts, such as that of Section 508 and M376, should be encouraged to use more contemporary provisions. Furthermore, we encourage WCAG WG to consider updating WCAG 2.0 to keep up with advancement of accessible technologies and to stay in harmonization with more up-to-date standards.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2671: Duff Johnson - Interoperability
Commenter: Duff Johnson <djohnson@commonlook.com> (archived message)
Context: Document as a whole
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.
LC-2663
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2653: Split document into software and documentation parts
Commenter: Olaf Drümmer <o.druemmer@callassoftware.com> (archived message)
Context: Document as a whole
[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 trying to deal with content/documents on one side and software on the other side in one go asks for disaster.

The document "Applying WCAG 2.0 to Non-Web Information and Communications Technologies" per its draft dated July 27, 2012, claims that it can offer useful informative guidance for both [non-web] content/documents and [non-web] software at the same time / in the same document. In the last 30 years that I have been dealing with both electronic content/documents and software it never occurred to me that one could come up with any substantial statements about these two without making independent or specific statements for one or the other. Even after thinking about the concept of dealing with both in one go for quite a while it strikes me as a - please excuse my wording but this is how I see it - pretty dumb idea.

If this document is ever to become meaningful and useful it should be separated into two documents, or two parts, one dealing with content/documents, the other dealing with software. Each of these two are such wide concepts already, that it will be enough of a challenge to get even one of the two right.


In a nutshell:
If the work is continued, split the document into two documents / parts, one for content/documents, the other for software.

Olaf
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2672: Duff Johnson - Overreach
Commenter: Duff Johnson <djohnson@commonlook.com> (archived message)
Context: Document as a whole
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.
LC-2663
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2655: why no acknowledgement of MSAA, IAccessible2, iOS VoiceOver, ... etc.
Commenter: Olaf Drümmer <o.druemmer@callassoftware.com> (archived message)
Context: Document as a whole
[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.


Olaf
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2674: Duff Johnson - Techniques
Commenter: Duff Johnson <djohnson@commonlook.com> (archived message)
Context: Document as a whole
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.)
LC-2663 LC-2673
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2656: Make clear what WCAG2ICT has to offer on top of ISO 9241-171 [OTHER STANDARDS]
Commenter: Olaf Drümmer <o.druemmer@callassoftware.com> (archived message)
Context: Document as a whole
[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:

- ISO/IEC TR 29138-1:2009, Information technology -- Accessibility considerations for people with disabilities -- Part 1: User needs summary
- ISO/IEC TR 29138-2:2009, Information technology -- Accessibility considerations for people with disabilities -- Part 2: Standards inventory
- ISO/IEC TR 29138-3:2009, Information technology -- Accessibility considerations for people with disabilities -- Part 3: Guidance on user needs mapping

- ISO/IEC 24786:2009, Information technology -- User interfaces -- Accessible user interface for accessibility settings

- ISO/IEC 13066-1:2011, Information technology -- Interoperability with assistive technology (AT) -- Part 1: Requirements and recommendations for interoperability

- ISO/IEC 24751-1:2008, Information technology -- Individualized adaptability and accessibility in e-learning, education and training -- Part 1: Framework and reference model
- ISO/IEC 24751-2:2008, Information technology -- Individualized adaptability and accessibility in e-learning, education and training -- Part 2: "Access for all" personal needs and preferences for digital delivery
- ISO/IEC 24751-3:2008, Information technology -- Individualized adaptability and accessibility in e-learning, education and training -- Part 3: "Access for all" digital resource description

- ISO/IEC 24756:2009, Information technology -- Framework for specifying a common access profile (CAP) of needs and capabilities of users, systems, and their environments

- and, even though it's hardware centric: ISO/IEC 29136:2012, Information technology -- User interfaces -- Accessibility of personal computer hardware


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.

Olaf
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2686: Change title of document
Commenter: Alex Li <alli@microsoft.com> on behalf of Microsoft (archived message)
Context: in (Make title more precise to reflect the purpose)
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.
LC-2701
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-40 41-48

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org