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

---------- Forwarded message ----------
From: Salaets, Ken <ksalaets@itic.org>
Date: Fri, Sep 7, 2012 at 2:07 PM
Subject: ITI comments on the first public draft of “Applying WCAG to
Non-Web ICT”
To: "public-comments-wcag20@w3.org" <public-comments-wcag20@w3.org>
Cc: "Salaets, Ken" <ksalaets@itic.org>


 To: 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),
Iappreciate 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>****