Re: Call for Review: Applying WCAG to Non-Web ICT

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/>