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).