W3C

Disposition of comments for the Accessibility Guidelines Working Group

Single page view

Not all comments have been marked as replied to. The disposition of comments is not complete.

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-2817 Duff Johnson <duff@duff-johnson.com>
Intro (para 2):

"This document is intended to help clarify how to use WCAG 2.0"

- Remove the world "help". Either the document does or does not "clarify".
DUPLICATE tocheck
LC-2695 Ken Salaets <ksalaets@itic.org> on behalf of Information Technology Industry Council (ITI)
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).
We have not yet developed additional guidance on conformance. We plan to work on this topic soon and will consider these comments at that time.

We are sending responses to all comments received from you in order to close out issues on this older draft and incorporate edits into the next draft. At this time we have not completed discussion of the conformance issues you raise. We intend to consider your comments during this process, and invite you to review this issue and submit additional comments if needed in the next draft.


@@@ send but don't close comment
tocheck
LC-2698 Ken Salaets <ksalaets@itic.org> on behalf of Information Technology Industry Council
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.
Thank you for your comments

We have gone beyond just substitution and included notes as well as suggested changes that WCAG made to the intent section in Understanding WCAG 2.0. We are constrained by our work statement from changing the success criteria themselves.
tocheck
LC-2700 Ken Salaets <ksalaets@itic.org> on behalf of Information Technology Industry Council
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.
Before we complete our work, we intend to find consensus on all of the items. At this point, we have consensus on how all success criteria are to be applied to documents and to software and this will appear in the next pubic working draft. tocheck
LC-2701 Ken Salaets <ksalaets@itic.org> on behalf of Information Technology Industry Council
“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.
We agree that some web specific terms like "Web Page" and "Web Content" have to be interpreted to find their counterpart in the broader scope of non-web content and software. We have also asked the WCAG WG to expand their INTENT section in Understanding WCAG 2.0 to better explain certain aspects of the intent of specific success criterion. However there have been relatively few other edits required and most of the success criteria seem to apply pretty well as they were written.

We have changed the title to "Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies" and hope that this new title addresses your concern.
tocheck
LC-2702 Ken Salaets <ksalaets@itic.org> on behalf of Information Technology Industry Council
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.
RE: Stating that other standards are needed along with WCAG:
We agree that additional requirements are needed especially for software acting in platform role(s). The focus of the work is on "content" as it occurs in both electronic documents and software. Other aspects of software are outside the scope of the Task Force and are covered in separate provisions being drafted for Section 508 (in the US) and Mandate 376 (in Europe).

As you point out, these are the purview of the US Access Board and the EU M376 standards development team. It would be inappropriate for us to step beyond our role of discussing how WCAG would be applied to ICT and into the Access Board and M376 standard team's role and make comments on what the overall requirements for ICT should be or what portion of this WCAG would cover.

We have, however, included a statement in the introduction explaining that WCAG 2.0 may not be sufficient to ensure accessibility for non-web ICT. Specifically, "This document does not address gaps in requirements that could potentially materialize when WCAG 2.0 is used with non-Web ICT; it is therefore important to note that WCAG 2.0 may not be sufficient by itself to ensure accessibility in non-Web ICT."

RE: Many SC may not be suitable especially for closed products .
We have created a specific section in the introduction that discusses closed functionality and how to handle them since "programmatic determinability" won't work if assistive technologies cannot be used . It is included below:

<insert paragraph on closed functionality> @@@@
tocheck

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:40:47 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org