ITI comments on the first public draft of “Applying WCAG to Non-Web ICT”

To: public-comments-wcag20@w3.org<mailto:public-comments-wcag20@w3.org>
Subject: ITI comments on the first public draft of “Applying WCAG to Non-Web ICT”

To Whom It May Concern:

On behalf of the Information Technology Industry Council (ITI), I appreciate the opportunity to submit these comments in response to the first public draft of “Applying WCAG to Non-Web ICT”.
ITI is the premier voice, advocate and thought leader for the ICT industry.  ITI is widely recognized as the tech industry's most effective advocacy organization in Washington D.C., and in various foreign capitals around the world.  We are a strong proponent of public-private partnerships, and highly value the opportunity to work closely with the Access Board, other government agencies, consumers and our industry colleagues to promote innovations in ICT accessibility that benefit all stakeholders in every aspect of their lives.
We want to commend the WCAG2ICT Task Force and the WCAG Working Group for the work that has gone into this document.
We have no specific comments at this time on any of the proposed language for how to apply the various Success Criteria to non-web ICT, but want to share with you our general/overall thoughts on this document and the Task Force's work.
Importance of Harmonization

As the W3C recognized in the WCAG2ICT Work Statement<http://www.w3.org/2012/04/WCAG2ICT-WorkStatement.html>, this Working Group Note is being developed “in response to suggestions that WCAG 2.0 could be applied to non-web ICT (Information and Communications Technology) that are not web content”.  It is vital that this task force be as open, transparent, and inclusive of stakeholders and expertise as possible.  From what we have seen, you have done an excellent job to date.  We hope that WCAG2ICT TF continues to collaborate with the Access Board, CEN/CENELEC/ETSI Mandate 376 to develop a harmonized set of guidance.

Challenges with Conformance & Claims of Conformance
The text of a number of the WCAG 2.0 Conformance Requirements<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#conformance-reqs> and Conformance Claims<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#conformance-claims> doesn't fit well in the non-web world. For example, as the W3C made clear in Understanding Levels of Conformance<http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head>, part of the decision as to whether a given Success Criterion was marked as level A vs. AA vs. AAA had to do with “whether it is possible to satisfy the Success Criterion for all Web sites and types of content that the Success Criteria would apply to (e.g., different topics, types of content, types of Web technology)”.  A given Success Criterion (e.g. 3.1.2 Language of Parts<http://www.w3.org/TR/wcag2ict/#meaning-other-lang-id>) may be easily satisfied using HTML and other web technologies, but not “satisfiable” for software running on a platform that doesn't support language/locale tagging for individual passages of text or user interface components.

Also, as the W3C similarly made clear in Understanding Levels of Conformance<http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head>, another part of the decision as to whether a given Success Criterion was marked as level A vs. AA vs. AAA had to do with “whether the Success Criterion is essential (in other words, if the Success Criterion isn't met, then even assistive technology can't make the content accessible)”.  A given Success Criterion (e.g. 2.4.5 Multiple Ways<http://www.w3.org/TR/wcag2ict/#navigation-mechanisms-mult-loc>) may be of far less importance for individual documents (e.g. e-mail attachments) that aren't part of a “set”, or for a software user interface, as compared to pages on a typical web site.

Therefore, without the flexibility to re-apply these same factors (as well as others that might arise from a non-web software and/or non-web document centric analysis) in re-assigning the Success Criteria to potentially different levels (A/AA/AAA), it may be impossible to develop an appropriate equivalent set of Conformance Requirements for non-web ICT.

Separate from the question of appropriate levels for Conformance, there is the challenge of applying the five Conformance Requirements<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#conformance-reqs> to non-web ICT.  For example, as noted in Understanding Conformance Requirements<http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conformance-requirements-head>, Requirement 2 is tied to “full pages”.  But it is difficult to determine what the analog to “full page” is for non-web software (and we note that the Task Force hasn't proposed such a global replacement in this first public draft).  Furthermore, it is highly questionable whether any analog other than “the entire software application” would be useful and meaningful to anyone consuming a Conformance statement (whether or not it is a formal Conformance Claim) for that software.  A related conundrum arises with Requirement 3 which speaks to “complete processes” and with Requirement 1 which points to meeting success criteria “in full”, which likewise doesn't seem to map well to the non-web software world.  Lastly, requirements 4 and 5 are already covered more comprehensively by more specific provisions within Section 508 ANPRM and M376 EN.

Finally, while we have long felt that the WCAG 2.0 Conformance Claim was of little practical value as it only applied to individual pages and not the real world of large websites, we see absolutely no value in it for non-web software.  Particularly given the impetus of this work – being in response to the Access Board and Mandate 376 who are considering using WCAG 2.0 for non-web ICT as part of procurement regulations – it stretches the imagination to think any large or complex software application could report itself as 100% perfect.  Nor would reporting on a “screen by screen” (e.g. “web page by web page”) basis make sense to procurement consumers. Furthermore, the nature of software user interfaces is that they are dynamic, and what they contain varies depending upon user input.  With large software applications, the combinatorics of possible code paths and user interfaces are too large – nobody can test them all (if they could, products wouldn't ship with bugs!).

Therefore, we hope that the Task Force will conclude – and formally state – that WCAG Conformance Claims do not make sense for non-web ICT generally (and particularly for non-web software).  Furthermore, we hope that the Task Force will explicitly note the challenges with attempting to apply the WCAG Conformance Requirements to non-web ICT. And while it isn't in the Task Force Work Statement, we think the Task Force should explore and suggest ways to utilize the WCAG 2.0 Success Criteria  to report the nature and severity of accessibility issues the non-web ICT was found to contain (as would be particularly useful for procurement contexts).

Changes in Understanding WCAG arising from the work of this Task Force

We appreciate the changes we have seen in Understanding WCAG 2.0<http://www.w3.org/TR/UNDERSTANDING-WCAG20/Overview.html> that were developed out of the work of the Task Force.  All have been improvements not only to non-web ICT uses of WCAG, but also to the web context.  Looking at WCAG through the lens of non-web software is also helpful for web software uses, as there has been tremendous innovation in the world of web applications since WCAG 2.0 was published in December 2008.

Going beyond direct substitution of “web page” if/where necessary

Thus far in the Success Criteria that WCAG2ICT addressed in this first public draft, you have managed to develop guidance based on a direct substitution of the phrase “web page” (or “set of web pages” or other variant).  You haven't done so with a single, global substitution which we think is wise – particularly in the non-web software world we don't believe there is a single replacement that works for all Success Criteria.

However, we are concerned that you may feel constrained in your work of determining how to apply WCAG to non-web ICT to only modify a few words here and there in various Success Criteria.  Nothing in your Work Statement<http://www.w3.org/2012/04/WCAG2ICT-WorkStatement.html> puts such a limitation on you.  In this draft you haven't proposed language for applying some of the Success Criteria that we feel are particularly difficult to apply to non-web ICT (as detailed in the section “WCAG 2.0 Conformance” in our comments submitted in response to the 2011 ANPRM<http://www.regulations.gov/#%21documentDetail;D=ATBCB-2011-0007-0074>) and we encourage you to explore broader changes of the wording of those difficult Success Criteria.  Such changes may enable you to find a way to apply those Success Criteria to non-web ICT.

Stating that some Success Criteria may not apply in certain contexts

Should you follow our advice (above) and explore broader changes to the wording of difficult Success Criteria as you seek to apply them to non-web ICT, you may nonetheless find yourselves unable to succeed while still keeping true to the purpose of the Criterion.  If that happens, we urge you to state that conclusion explicitly in the Working Group Note: that a given Success Criterion doesn't apply to some or all non-web ICT (who better than the W3C and WCAG to observe that certain WCAG 2.0 success criteria don’t apply outside of the web?).  Simply stating that you failed reach consensus in developing language would invite others to nonetheless try to do so themselves, and perhaps in doing so mis-apply WCAG.

“Interpreting” is a better term than “applying” for this work

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 be changed to “Interpreting and applying WCAG 2.0 to Non-Web Information and Communications Technologies” to prevent the audience from being misled into believing that WCAG 2.0 can be applied in its current form to non-web ICT.

WCAG2ICT deliverables should clearly state that WCAG 2.0 was not designed to be a complete standard for non-web ICT; other requirements may be needed

Inherent in the nature of web content is that it is necessary for a user agent to be present in order for the web content to be consumable.  It is likewise necessary for an operating system to be present to support the relevant user agents and assistive technologies.  Given this, WCAG 2.0 appropriately focused solely on matters relevant to web content.  But non-web ICT accessibility standards inherently need to address architectural matters more specific to the context of software, operating systems, and other aspects of ICT that are beyond the scope of WCAG.  For example, Section 508 in its current form and various drafts contain provisions far beyond the scope of WCAG.  This is also the case for various drafts of the M376 standard.  In short, WCAG 2.0, even after interpretation beyond the Web, would be an incomplete set of guidelines in these non-web contexts.  W3C should therefore make it clear in this document that the use of WCAG 2.0 for non-web ICT cannot be considered a complete set of accessibility guidelines, and that efforts such as M376 EN and Section 508 refresh must necessarily consider additional provisions if they are to develop an appropriate and complete accessibility standard for non-web ICT.

Many WCAG 2.0 SCs, even after interpretation, may not be suitable in a variety of non-web ICT contexts
Many of the WCAG 2.0 success criteria necessarily assume the presence of a browser, an operating system, and some form of assistive technology.  This is not an appropriate assumption in many non-web ICT contexts (for example, the context of ICT functions closed from assistive technologies such as most ATM machine functions).  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 not applicable.  Indeed, it should still be 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 a context. We recognize that the WCAG2ICT TF has not considered ICT with closed functionalities from assistive technologies yet, but the TF should make this limitation clear to its audience.


Thank you again for this opportunity to comment on this first public draft of “Applying WCAG to Non-Web ICT”.  We would welcome the opportunity to respond to any questions that the task force has, as well as to provide additional details regarding the comments above.

Sincerely,

Ken J. Salaets
Director, Global Policy
Information Technology Industry Council
1101 K Street NW, Suite 610
Washington, DC 20005
+202-626-5752
Website: www.itic.org
Twitter: @TechElect<http://twitter.com/techelect>