Microsoft Comments

The following comments on the July 2012 WCAG2ICT Public Draft were sent to
the WCAG 2.0 Public Comments List. [1]

[1]
http://lists.w3.org/Archives/Public/public-comments-wcag20/2012Sep/0003.html


From: Alex Li <alli@microsoft.com>
Date: Fri, 7 Sep 2012 22:00:58 +0000
To: "public-comments-wcag20@w3.org" <public-comments-wcag20@w3.org>
Message-ID:
<F822343930D48B4C88B4D0DAACC194E03D3D6007@CH1PRD0310MB392.namprd03.prod.outlook.>

To whom this may concern,

Microsoft acknowledges the hard work done in order to produce the first
public working draft of "Applying WCAG 2.0 to Non-Web Information and
Communications Technologies".  Below are our comments to help improve upon
the draft.  We welcome further opportunity to provide input.
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.
WCAG 2.0 is inherently incomplete in the context of non-web ICT
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
further assumed that an operating system is present to support the relevant
user agents and assistive technologies.  We recognize that it is
appropriate for WCAG 2.0 to contain itself to matters relevant only 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 context 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 M376 standard.  In short, WCAG 2.0, even after translation, would
be an incomplete set of guidelines in the context of non-web ICT.  W3C
should make it clear to the audience that applying WCAG 2.0 to non-web ICT
cannot be considered a complete set of accessibility guidelines and that
efforts such as M376 EN and Section 508 refresh are necessary to yield
appropriate and complete results.
WCAG 2.0 conformance requirements may be in conflict with other standards'
conformance requirements
Due to the inherently incomplete nature of WCAG in the context of non-web
ICT, it cannot be used in isolation as a standard of its own for non-web
ICT.  Since other standards contain conformance requirements in conflict
with that of WCAG 2.0.  Section 508, for example, contains the best meet
provision which conflicts with WCAG 2.0 conformance requirements number 1,
2, and 3.  We advise WCAG2ICT TF to recognize that such conflicts can be
highly counterproductive and that the audience must take caution in
applying WCAG 2.0 conformance requirements to other standard development
effort and that it may be more suitable to use the relevant success
criteria and not the conformance requirements.
WCAG2ICT should be prepared to recognize that portions of WCAG 2.0 may not
be appropriate for non-web ICT
We recognize that those success criteria that are more easily translated
for the non-web ICT context managed to achieve consensus in the first
draft.  But there are a number success criteria that are far more
challenging.  It is important to recognize that WCAG was written for web
content only and that non-web ICT is fundamentally different from web
content.  We encourage WCAG2ICT TF to declare certain portions of WCAG 2.0
unfit for non-web ICT if the TF fail to create proper language to translate
WCAG 2.0 for use in non-web ICT context.
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.
Keyboard should not be required for all scenarios.  Alternate approach
should be considered.
WCAG 2.0 success criteria 2.1.1 is no longer an appropriate requirement for
software.  Keyboard was the input method of choice for visually impaired
and users without fine motor control. But keyboard is no long the only
viable option for input and navigation in such scenarios.  It would be
important to recognize that there are alternatives to keyboard input such
as allowing multiple user selectable input options that use different
bodily functions (speech recognition, gesture, touch, etc.)  Keyboard
should no longer be considered a required input method when other viable
options are available.  In fact, we believe our recommendation is more
accessible to more people, with and without disabilities.  We recommend to
replace WCAG 2.0 2.1.1 with a more flexible success criteria to allow
accessible ICT innovation.  "Where the platform supports keyboard
navigational and manipulation interfaces, all functionality of the content
is operable through a keyboard interface without requiring specific timings
for individual keystrokes, except where the underlying function requires
input that depends on the path of the user's movement and not just the
endpoints.  Where the platform does not support keyboard navigational and
manipulation interfaces, all functionality of the content is operable
through at least two user selectable input and feedback modalities, except
where the underlying function requires input that depends on the path of
the user's movement and not just the endpoints."
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.
A note is needed in success criteria 3.3.4 to exclude financial
transactions as an unintended byproduct
An SMS message may cause a cost to a recipient without an unlimited SMS
message plan.  This is likewise the case of any pay per megabyte type
network data agreement.  An email may in certain scenarios trigger a legal
commitment or financial transaction.  It is obviously not possible for an
email agent to detect the present of legal commitment or financial
transaction that may take place within an email.  An exception or note is
necessary to exclude scenarios where the user may trigger a financial
transaction as a result of prior legal or financial commitment.  Optimally,
we would like to see a normative exception that suggests that a refresh of
WCAG 2.0 is necessary.
Error notification may be an appropriate exception for 3.2.2
In order to fulfill success criteria 3.3.1 and 3.3.3, it may well be best
practice to notify the user immediately upon the occurrence of input error.
Such error notification may trigger a change of context.  But it may not be
optimal to provide prior instruction to users for such error notification.
We advise that an exception or note to be added to support this best
practice scenario.  We understand that normative change may be necessary to
accommodate the proposed best practice.

We appreciate your attention to our comments.

All best,
Alex Li
Senior Strategist
Microsoft Trustworthy Computing Group
email: alli@microsoft.com<mailto:alli@microsoft.com>
phone: +1 (425)538-7984
mobile: +1 (206) 778-4202
Microsoft Corporation<http://microsoft.com/>