List of comments on “Applying WCAG 2.0 to Non-Web Information and Communications Technologies” (dated 27 July 2012)

There are 48 comments (sorted by their types, and the section they are about).

1-20 21-40 41-48

general comment comments

Comment LC-2652: Applying WCAG 2.0 to non-web content: Commenter: Olaf Druemmer <o.druemmer@callassoftware.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

From my point of view WCAG2 is a solution looking for a additional problems to solve. Invented with web content in mind, at least some would claim.agree that it became quite successful - at least for web content. Now, being encouraged by that success it seems WCAG2 proponents felt like they should find other stuff to which WCAG2 concepts could be applied. A little bit like trying to figure out what a hammer - quite good at dealing with nails - could do with screws. While some functionality could be achieved, hammers and screws will never be a good match. Instead, in order to deal with screws, one would have to start thinking starting form what screws are, not even thinking of a hammer. A concept essential to screws - 'turning' - does not even exist in the world of hammers and nails.

Along the same lines I think in order to come up with something useful and meaningful for non-web content.documents, one would have to start from non-web content/documents, not from a tool that has been proven to work well with web content/documents. Otherwise there is a drastic risk to miss essential aspects, and it could easily happen that WCAG2 concepts cover non-web content/documents quite well where actually they don't (or it is at least unknown / undefined to which degree they cover them). And thus the quality and value of "applying WCAG2 to non-web ICT" is undefined / unknown.

Maybe the WAI is not even the ideal context to start doing something about non-web content/documents...?

Olaf; Related issues: (space separated ids); WG Notes: Previous proposed resolution: The W3C did not initiate the concept of applying WCAG outside of Web Content. Rather it was the US Access Board who noted that the guidelines for electronic documents and software in the TEITAC report paralleled WCAG 2.0. The Access Board has proposed that WCAG 2.0 be used as the standard for non-web content and software in the Section 508 refresh process. Current drafts of European Mandate 376 (M376) standards are following the US lead. The W3C is simply providing information about a W3C standard in response to the actions of the US Access Board and EU M376 standards development team. The task force work statement is consistent with the WCAG working group charter that includes the following under its scope: "Coordinating with other entities adopting and using WCAG 2.0." If you feel that WCAG 2.0 should not be used for non-web content and software, then we would suggest that you address your comments to the U.S. Access Board and EU M376 standards development team.; Proposed Resolution: The W3C did not initiate the concept of applying WCAG outside of Web Content. Rather it was the US Access Board who noted that the guidelines for electronic documents and software in the TEITAC report paralleled WCAG 2.0. The Access Board has proposed that WCAG 2.0 be used as the standard for non-web content and software in the Section 508 refresh process. Current drafts of European Mandate 376 (M376) standards are following the US lead. Through this task force, the W3C is developing a common understanding of how WCAG 2.0 might apply to non-web ICT for organizations and entities who are already seeking to so adopt and apply WCAG 2.0. By doing this we increase the likelihood that these applications of WCAG 2.0 will be consistent, and in keeping with the Principles, Guidelines, and Intent of WCAG 2.0. The task force work statement is consistent with the WCAG working group charter that includes the following under its scope: "Coordinating with other entities adopting and using WCAG 2.0." Comments on the use WCAG 2.0 for non-web content and software, can be sent to the U.S. Access Board and/or submitted as part of the EU M376 review process. ================== [WCAG WG] Comments ============== change the last sentence of the first paragraph The W3C created a task force that brought in ICT companies, and the M376 committee, and Access Board to join with WCAG member to create this guidance because it would both identify specific issues in apply WCAG 2.0 to ICT (documents and software) and increase the likelihood that these applications of WCAG 2.0 will be consistent, and in keeping with the Principles, Guidelines, and Intent of WCAG 2.0. and a NEW second paragraph Please note that the introduction points out (in paragraphs 7 and 2) that " This document does not seek to determine which WCAG 2.0 provisions (principles, guidelines, or success criteria) should or should not apply to non-web ICT, but rather how they would apply, if applied." also that " Although this document covers a wide range of issues, it is not able to address all the needs of all people with disabilities. Because WCAG 2.0 was developed for the Web, addressing accessibility for non-Web documents and software may involve provisions beyond those included in this document. Authors and developers are encouraged to seek relevant advice about current best practices to ensure that non-Web documents and software are accessible, as far as possible, to people with disabilities."; (Please make sure the resolution is adapted for public consumption)

Comment LC-2673: Duff Johnson - Conclusion: Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
CONCLUSION

WCAG 2.0 is useful in the web context precisely because it’s web-centric. HTML developers can arrive at a reasonable understanding of how to apply WCAG 2.0 concepts more-or-less directly to the explicit structures of the HTML language and functional parameters of media files and JavaScript.

The WCAG2ICT is replete with unsubstantiated claims together with (seemingly) casual and ill-considered assumptions. Given that the document offers the wholesale application of technical concepts to technologies and contexts never envisioned by WCAG 2.0’s authors, these failures are catastrophic with respect to the current draft. This document cannot be regarded as a serious attempt to address accessibility specifications in non-web content and ICT.

This is simply the wrong mission for W3C and WAI, whose concerns are (rightly) web content.

Further development of the WCAG2ICT along the current lines will bring disrepute to W3C since this project falls so far out of W3C’s scope and expertise, and meshes so poorly with the subject at hand.

Accordingly, the WCAG2ICT should be entirely re-scoped and revised, moved to an appropriate body for further development, or terminated.; Related issues: LC-2663
(space separated ids); WG Notes: Previous proposed resolution: The W3C did not initiate the concept of applying WCAG outside of Web Content. Rather it was the US Access Board who noted that the guidelines for electronic documents and software in the TEITAC report paralleled WCAG 2.0. The Access Board has proposed that WCAG 2.0 be used as the standard for non-web content and software in the Section 508 refresh process. Current drafts of European Mandate 376 (M376) standards are following the US lead. The W3C is simply providing information about a W3C standard in response to the actions of the US Access Board and EU M376 standards development team. The task force work statement is consistent with the WCAG working group charter that includes the following under its scope: "Coordinating with other entities adopting and using WCAG 2.0." If you feel that WCAG 2.0 should not be used for non-web content and software, then we would suggest that you address your comments to the U.S. Access Board and EU M376 standards development team. RE PDF: PDF documents are web-content, and according to WCAG working group members PDF was always envisioned as being covered by WCAG 2.0 during its development -- and techniques have been documented for PDF. Earlier notes: Duff Johnson has been a public critic of WCAG for quite some time. He has posted on LinkedIN groups and tried to initiate momentum against WCAG 2 ... he is CEO of the company Netcentric which specializes in PDF accessibility. He is the chair of the PDF Achieving WCAG 2.0 with PDF/UA v1.01, and the ISO PDF accessibility standard PDF/UA v1.01, which he advances in place of WCAG for PDF, it has several significant deviations from WCAG including prescribed hierarchical headings. This response from him is totally predictable. (DM); Proposed Resolution: The W3C did not initiate the concept of applying WCAG outside of Web Content. Rather it was the US Access Board who noted that the guidelines for electronic documents and software in the TEITAC report paralleled WCAG 2.0. The Access Board has proposed that WCAG 2.0 be used as the standard for non-web content and software in the Section 508 refresh process. Current drafts of European Mandate 376 (M376) standards are following the US lead. Through this task force, the W3C is developing a common understanding of how WCAG 2.0 might apply to non-web ICT for organizations and entities who are already seeking to so adopt and apply WCAG 2.0. By doing this we increase the likelihood that these applications of WCAG 2.0 will be consistent, and in keeping with the Principles, Guidelines, and Intent of WCAG 2.0. If you feel that WCAG 2.0 should not be used for non-web content and software, then we would suggest that you address your comments to the U.S. Access Board and EU M376 standards development team. Comments on the use WCAG 2.0 for non-web content and software, can be sent to the U.S. Access Board and/or submitted as part of the EU M376 review process. RE: PDF; PDF documents are web-content, and according to WCAG working group members PDF were always envisioned as being covered by WCAG 2.0 during its development -- and techniques have been documented for PDF. ================== [WCAG WG] Comments ============== change the last sentence of the first paragraph The W3C created a task force that brought in ICT companies, and the M376 committee, and Access Board to join with WCAG member to create this guidance because it would both identify specific issues in apply WCAG 2.0 to ICT (documents and software) and increase the likelihood that these applications of WCAG 2.0 will be consistent, and in keeping with the Principles, Guidelines, and Intent of WCAG 2.0. and a NEW second paragraph Please note that the introduction points out (in paragraphs 7 and 2) that " This document does not seek to determine which WCAG 2.0 provisions (principles, guidelines, or success criteria) should or should not apply to non-web ICT, but rather how they would apply, if applied." also that " Although this document covers a wide range of issues, it is not able to address all the needs of all people with disabilities. Because WCAG 2.0 was developed for the Web, addressing accessibility for non-Web documents and software may involve provisions beyond those included in this document. Authors and developers are encouraged to seek relevant advice about current best practices to ensure that non-Web documents and software are accessible, as far as possible, to people with disabilities." change the last paragraph to If by "technologies and contexts never envisioned by WCAG 2.0’s authors" you are referring to PDF; PDF documents are web-content, and according to WCAG working group members, PDF were always envisioned as being covered by WCAG 2.0 during its development -- and techniques have been documented for PDF. However the Access Board is now considering applying them beyond the web which is why additional review and guidance was needed - which is what the WCAG2ICT was formed to provide.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2663: Duff Johnson - Overview: Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
NOTE: While my affiliations are provided for purposes of disclosure this Comment is my own and does not represent the views of those organizations.

OVERVIEW

The WCAG2ICT begins with an un-argued assumption: that guidelines written carefully, deliberately and specifically for web content and technologies are reasonable candidates for evaluating accessibility in “non-Web ICT”.

From this dubious basis the document’s Abstract claims that it will provide information on “how” WCAG 2.0 can be applied to non-Web content. The document’s Introduction goes on to advise that the document will “…help clarify how to use WCAG 2.0”.

Unfortunately, the document does not perform these self-appointed functions whatsoever. Instead, it prefers to simply claim (in most cases) that WCAG 2.0’s Success Criteria may be applied “directly as written” without any suggestion as to “how”.

I’m extremely disappointed. Not only does the WCAG2ICT fail to address its own stated objectives, but reveals in stark terms that W3C has no business going “off-web” in standards development.

I’ve provided details on some of my concerns below.; Related issues: LC-2664 LC-2665 LC-2666 LC-2667 LC-2668 LC-2669 LC-2670 LC-2671 LC-2672 LC-2673 LC-2674
(space separated ids); WG Notes:; Proposed Resolution: We are unsure of what you are referring to as "an un-argued assumption: that guidelines written carefully, deliberately and specifically for web content and technologies are reasonable candidates for evaluating accessibility in “non-Web ICT”." We are unable to find any such language or similar language in the introduction. In any case, this was not our assumption. The W3C is responding with informative guidance to the suggestion by the US Access Board and EU M376 standards development team that WCAG 2.0 be used as a standard for non-web ICT. The WCAG2ICT task force was formed to look at WCAG 2.0 to see how terms should be interpreted, how the success criteria should be applied, etc. to carry the WCAG 2.0 intent over to non-web ICT. The task force’s scope is limited by the work statement and as such, we cannot make changes to the normative parts of WCAG 2.0 (e.g. the success criteria, terminology definitions, or techniques). You can view our work statement at http://www.w3.org/2012/04/WCAG2ICT-WorkStatement.html. ================== [WCAG WG] Comments ============== ADDITION TO END Please note the introduction to WCAG2ICT points out (in Paragraphs 7 and 2) that " This document does not seek to determine which WCAG 2.0 provisions (principles, guidelines, or success criteria) should or should not apply to non-web ICT, but rather how they would apply, if applied." also that " Although this document covers a wide range of issues, it is not able to address all the needs of all people with disabilities. Because WCAG 2.0 was developed for the Web, addressing accessibility for non-Web documents and software may involve provisions beyond those included in this document. Authors and developers are encouraged to seek relevant advice about current best practices to ensure that non-Web documents and software are accessible, as far as possible, to people with disabilities."; (Please make sure the resolution is adapted for public consumption)

Comment LC-2651: Dummy Example with Instructions: Commenter: Michael Cooper <mnc.1971@hotmail.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
FOR INSTRUCTIONS ON HOW TO FILL OUT A NEW ENTRY GO TO

https://sites.google.com/site/wcag2ict/review-process/instructions-of-entering-new-issues; Related issues: (space separated ids); WG Notes:; Resolution: FOR INSTRUCTIONS ON HOW TO PROPOSE A RESPONSE GO TO https://sites.google.com/site/wcag2ict/review-process/instructions-for-proposing-and-answer-to-an-issue; (Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2692: Need for WCAG 2.0 to update for new technologies: Commenter: Alex Li <alli@microsoft.com> on behalf of Microsoft (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
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.; Related issues: (space separated ids); WG Notes:; Proposed Resolution: RE encouraging Section 508 and M376: We understand the issues but this committee is not in a position in this document to make recommendations as to what the Access Board or M376 committee should do in their documents with regard to other standards. These comments can more effectively be made directly to them. RE Recommending that the WCAG WG do something: We also recommend that you submit that comment directly to the WCAG WG.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2671: Duff Johnson - Interoperability: Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
INTEROPERABILITY IGNORED

I have this same complaint about WCAG 2.0 but the same problem is enormously magnified when the scope blooms (as per WCAG2ICT’s remit). Interoperability is key not only to developing agreement on outcomes but in the economics of software development and real-world adoption.

As an economic matter, accessibility is an area that lends itself to the question of conformance and thus potentially, to litigation. If vendors cannot (or believe they cannot) achieve agreement on the technical means of conformance they will tend to shy away from developing in these areas. Application of WCAG 2.0 “directly as written” to non-Web ICT does little or nothing to assist developers who find they have to climb into web-based concepts that may be entirely alien to them simply to begin a conversation about developing towards accessibility.; Related issues: LC-2663
(space separated ids); WG Notes:; Proposed Resolution: It is not clear exactly what change you are suggesting to address this question of interoperability. Part of the effort of this committee is to create language that allows rules to be harmonized internationally, but also harmonized across content types. For example if a document is distributed off of the web but also posted to the web it would be much better for authors if they didn’t have to follow different sets of rules. Also if interactivity or a game-like activity is added to an educational document, it would be helpful if it didn't suddenly become subject to a completely different set of rules. Due to the scope of the committee’s work, we must simply provide clarity about applying the more general principles in the guidelines and success criteria to non-web ICT. Specific techniques will have to be developed outside of this group, as were developed in support of the original Section 508. As for conformance, testing for conformance is definitely not an easy task as many accessibility principles require manual checking by humans rather than automated verification. No matter which accessibility standards are applied (ISO, WCAG, etc.) there will always be an issue with the amount of manual verification that must be done and the cost/burden to complete it. Tools could be developed to make conformance checking easier, but there will always be a manual aspect to the verification.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2653: Split document into software and documentation parts: Commenter: Olaf Drümmer <o.druemmer@callassoftware.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

From my point of view trying to deal with content/documents on one side and software on the other side in one go asks for disaster.

The document "Applying WCAG 2.0 to Non-Web Information and Communications Technologies" per its draft dated July 27, 2012, claims that it can offer useful informative guidance for both [non-web] content/documents and [non-web] software at the same time / in the same document. In the last 30 years that I have been dealing with both electronic content/documents and software it never occurred to me that one could come up with any substantial statements about these two without making independent or specific statements for one or the other. Even after thinking about the concept of dealing with both in one go for quite a while it strikes me as a - please excuse my wording but this is how I see it - pretty dumb idea.

If this document is ever to become meaningful and useful it should be separated into two documents, or two parts, one dealing with content/documents, the other dealing with software. Each of these two are such wide concepts already, that it will be enough of a challenge to get even one of the two right.

In a nutshell:
If the work is continued, split the document into two documents / parts, one for content/documents, the other for software.

Olaf; Related issues: (space separated ids); WG Notes:; Proposed Resolution: It is true that the document provides guidance on electronic documents as well as software aspects of products. For a number of success criteria such as 1.1.1, the guidance for electronic documents and software is the same. The note about Captchas for instance applies equally to both electronic documents and software. Separating the document will merely result in providing duplicate information. It is also helpful to read guidance for both electronic documents and software together as depending on the content you are generating, guidance provided for both the categories may be relevant. In those places where the comments are different for software, they are listed separately. 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).; (Please make sure the resolution is adapted for public consumption)

Comment LC-2672: Duff Johnson - Overreach: Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
OVERREACH

The web is a colossal sphere of technology and human activity; W3C is well and properly engaged therein. It’s difficult to imagine how a web-centric organization, not to mention a web-centric document (WCAG 2.0) can or should be retro-fitted to an entirely distinctive and notably non-web purpose.

The WCAG2ICT draft is especially disappointing because it represents such a gross overreach for W3C and the WAI. The draft adds insult to injury by entirely failing to acknowledge existing relevant standards as noted above.

It’s as if the rules of the road for cars were applied en-masse to those for trucks, construction equipment, trams and bicycles without even bothering to check in with those developers about their functions, needs, restrictions and aspirations. Certainly, there are many lessons for bicycles to be found in the rules for cars – but it would be foolish and irresponsible to imagine transplanting one to the other.; Related issues: LC-2663
(space separated ids); WG Notes:; Proposed Resolution: <combine this one with 2663. It introduces no new issues and the responses to this one are included in the answer to 2663> @@See response to https://www.w3.org/2006/02/lc-comments-tracker/35422/WD-wcag2ict-20120727/2663?cid=2663; (Please make sure the resolution is adapted for public consumption)

Comment LC-2655: why no acknowledgement of MSAA, IAccessible2, iOS VoiceOver, ... etc.: Commenter: Olaf Drümmer <o.druemmer@callassoftware.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

In the world of software development quite a bit of work has been carried out in order to make software more accessible than it used to be.

The document "Applying WCAG 2.0 to Non-Web Information and Communications Technologies" per its draft dated July 27, 2012 does not take any of that into account though the concepts and principles behind those are extremely useful, both in terms of architecture as well as in terms of various specifics.

I think it is essential to first learn from others about what has already been achieved, before coming up with something else out of the blue.

In a nutshell:
First learn from existing achievements, then - if really something new and useful can be added to it - come up with it. Don't (try to) reinvent the wheel - the world does not need yet another paradigm.

Olaf; Related issues: (space separated ids); WG Notes: First sentense needs to be updated with the correct text from the charter.; Proposed Resolution: The aim of WCAG2ICT is to develop informative guidance on how to apply WCAG 2.0 principles, guidelines, success criteria, and conformance to non-web ICT. The WCAG 2.0 success criteria are technology independent and do not define how to achieve compliance with specific technologies or tools. Many WCAG2ICT task force members have been involved for years in a number of non-web ICT accessibility standards development efforts, developed AT for a number of non-web ICT platforms, and developed and implemented accessibility frameworks for a number of non-web ICT platforms. In fact, there was a proactive effort to include task force members with the critical expertise needed to do this work. Information about platform accessibility services and assistive technologies has been used for discussions within the task force, however, the task force work statement/scope excludes commenting on things beyond applying WCAG 2.0 itself to ICT."; (Please make sure the resolution is adapted for public consumption)

Comment LC-2674: Duff Johnson - Techniques: Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
As presently constituted the document will simply be ignored as developers either wait for “non-Web ICT” Techniques (that W3C is not set up to provide) or simply give up when they realize that even if they achieve conformance as THEY understand it the chances that others will agree about operational details is slim.

(This text was originally a part of Duff Johnson's "Conclusion" section.); Related issues: LC-2663 LC-2673
(space separated ids); WG Notes: Previously proposed resolution: Combine this back with conclusion (LC-2673) as it makes no suggestion -- and the response to the conclusion covers this topic; Proposed Resolution: The W3C did not initiate the concept of applying WCAG outside of Web Content. Rather it was the US Access Board who noted that the guidelines for electronic documents and software in the TEITAC report paralleled WCAG 2.0. The Access Board has proposed that WCAG 2.0 be used as the standard for non-web content and software in the Section 508 refresh process. Current drafts of European Mandate 376 (M376) standards are following the US lead. Through this task force, the W3C is developing a common understanding of how WCAG 2.0 might apply to non-web ICT for organizations and entities who are already seeking to so adopt and apply WCAG 2.0. By doing this we increase the likelihood that these applications of WCAG 2.0 will be consistent, and in keeping with the Principles, Guidelines, and Intent of WCAG 2.0. If you feel that WCAG 2.0 should not be used for non-web content and software, then we would suggest that you address your comments to the U.S. Access Board and EU M376 standards development team. Comments on the use WCAG 2.0 for non-web content and software, can be sent to the U.S. Access Board and/or submitted as part of the EU M376 review process.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2656: Make clear what WCAG2ICT has to offer on top of ISO 9241-171 [OTHER STANDARDS]: Commenter: Olaf Drümmer <o.druemmer@callassoftware.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

The ISO standard "ISO 9241-171:2008 - Ergonomics of human-system interaction -- Part 171: Guidance on software accessibility" covers 'accessible software' quite nicely - what does WCAG2ICT have to offer on top of it?

Along the same lines, the following ISO standards have to be taken into account of WCAG2ICT is serious about its job, and it should be proven, what WCAG2ICT adds that these don't offer yet:

- ISO/IEC TR 29138-1:2009, Information technology -- Accessibility considerations for people with disabilities -- Part 1: User needs summary
- ISO/IEC TR 29138-2:2009, Information technology -- Accessibility considerations for people with disabilities -- Part 2: Standards inventory
- ISO/IEC TR 29138-3:2009, Information technology -- Accessibility considerations for people with disabilities -- Part 3: Guidance on user needs mapping

- ISO/IEC 24786:2009, Information technology -- User interfaces -- Accessible user interface for accessibility settings

- ISO/IEC 13066-1:2011, Information technology -- Interoperability with assistive technology (AT) -- Part 1: Requirements and recommendations for interoperability

- ISO/IEC 24751-1:2008, Information technology -- Individualized adaptability and accessibility in e-learning, education and training -- Part 1: Framework and reference model
- ISO/IEC 24751-2:2008, Information technology -- Individualized adaptability and accessibility in e-learning, education and training -- Part 2: "Access for all" personal needs and preferences for digital delivery
- ISO/IEC 24751-3:2008, Information technology -- Individualized adaptability and accessibility in e-learning, education and training -- Part 3: "Access for all" digital resource description

- ISO/IEC 24756:2009, Information technology -- Framework for specifying a common access profile (CAP) of needs and capabilities of users, systems, and their environments

- and, even though it's hardware centric: ISO/IEC 29136:2012, Information technology -- User interfaces -- Accessibility of personal computer hardware

In a nutshell:
Either make clear what WCAG2ICT has to offer on top of ISO 9241-171 and other ICT related accessibility standards (and if it does offer anything, elaborate on where it overlaps and where it doesn't), or abandon the idea of finalizing and publishing WCAG2ICT as far as software is concerned.

Olaf; Related issues: (space separated ids); WG Notes: PREVIOUS PROPOSED RESOLUTION: The WCAG2ICT task force was not charged with creating a normative standard nor with reviewing and evaluating standards from other organizations. In fact, the task force has no standing to make comments about the applicability or inapplicability of standards from other standards organizations. The Task Force's job is to provide informative guidance on how to apply the WCAG 2.0 principles, guidelines, and success criteria to non-web ICT in response to actions by the US Access Board and EU M376 standards development team proposing to use WCAG 2.0 as the standard for non-web ICT. If this task force were creating a normative standard and normatively citing parts of other standards as part of its standard, then it would indeed list those other standards. However this is not a group that is creating a normative standard. See also the introduction section and the excluded from scope section of the new draft document.; Proposed Resolution: (NOTE: In responding - include the issue in 2661 with this one - we combined them in responding) The WCAG2ICT task force was not charged with creating a normative standard nor with reviewing and evaluating standards from other organizations. In fact, the task force has no standing to make comments about the applicability or inapplicability of standards from other standards organizations. Our job is to provide informative guidance on how to apply the WCAG 2.0 principles, guidelines, and success criteria to non-web ICT in response to actions by the US Access Board and EU M376 standards development team proposing to use WCAG 2.0 as the standard for non-web ICT. If this task force were creating a normative standard and normatively citing parts of other standards as part of its standard, then it would indeed list those other standards. However this is not a group that is creating a normative standard. See also the introduction section and the excluded from scope section of the new draft document. As previously stated, this document is not and does not claim to be a standard. WCAG 2.0 is actually one of the standards listed in the JTC 1 SWG-A inventory of standards. This document provides informative only guidance in response to actions taken by the US Access Board and EU M376 standards development team proposing to apply WCAG 2.0 to non-web ICT.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2686: Change title of document: Commenter: Alex Li <alli@microsoft.com> on behalf of Microsoft (archived message); Context: in (Make title more precise to reflect the purpose); Status:
assigned to; Type:; Comment:
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.; Related issues: LC-2701
(space separated ids); WG Notes:; Proposed Resolution: 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.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2665: Duff Johnson - Use Cases: Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
NEGLECTED USE CASES

A number of concepts occur in the “non-Web” world but don’t feature in the web content considerations developed in WCAG 2.0. Many of these are known to or may have implications for accessibility. Examples include:

Content: interoperability, relationships between text, data, data groupings, metadata, annotations, redactions (selective absence of information), fonts, navigation without links.

Context: pagination, usage, formality, intent (print, email, web, archive), authentication (digital signatures), portability, pagination, closed systems.

Workflow: relationships between source, interim, marked-up, print-stream, flattened, annotated and final-form content.; Related issues: LC-2663
(space separated ids); WG Notes: [Loïc's previous proposal from - 2013-01-14] This document provides informative guidance with regard to the interpretation and application of WCAG 2.0 to non-Web documents and software. WCAG is a standard for Web content accessibility, and it does not deal with such things as hardware aspects of products, closed products and requirements for non-user interface aspects of platforms, nor individual components. For this reason, this document is not sufficient by itself to ensure accessibility in non-Web documents and software. Addressing accessibility for non-Web documents and software may involve provisions beyond those included in this document. Authors and developers are encouraged to seek relevant advice about current best practices to ensure that non-Web documents and software are accessible, as far as possible, to people with disabilities. [Loïc - 2013-01-14] According to the resolutions of the meeting of 2013-01-11, I've modified the proposed resolution. The new text is based on words that we have in the introduction and in the "excluded from scope" section. For the record, here is the text that was the previous resolution proposal: We agree with you that these are important. Most of these involve information that is provided to viewers. The WCAG guidelines individually and collectively require that all information that is presented be accessible in different forms directly, or through AT. So most of these would appear to be covered. You are correct that closed systems or closed functionality would not be covered. As a result, we are going to have 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.; Proposed Resolution: The task force agrees that these are important. Most of these involve information that is provided to viewers. The WCAG guidelines individually and collectively require that all information that is presented be available in different forms directly, or through AT. Many of the items in this list would appear to be covered. Closed systems or closed functionality would not be covered. As a result, the task force is going to have 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. In addition, please see the <<URL: http://www.w3.org/TR/wcag2ict>> 2nd public draft. In the <<URL:http://www.w3.org/TR/wcag2ict/#intro>> introduction it is acknowledged that more provisions may be needed in addition to WCAG 2.0 to fully address accessibility of non-Web ICT: "Because WCAG 2.0 was developed for the Web, addressing accessibility for non-Web documents and software may involve provisions beyond those included in this document. Authors and developers are encouraged to seek relevant advice about current best practices to ensure that non-Web documents and software are accessible, as far as possible, to people with disabilities." And in the <<URL: http://www.w3.org/TR/wcag2ict/#intro_excluded>> "excluded from scope" section, the third item in the list says: "Because this document deals with applying WCAG, which is a standard for content accessibility, to ICT it does not deal with such things as closed products and requirements for non-user interface aspects of platforms, nor individual components. As such, this document is not sufficient by itself to ensure accessibility in non-Web documents and software."; (Please make sure the resolution is adapted for public consumption)

Comment LC-2657: Make the connection between accessibility and usability: Commenter: Olaf Drümmer <o.druemmer@callassoftware.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

In a number of scenarios it can be envisioned that accessibility and usability do not coincide, for example where a software sends out "information" to the user in a concurrent manner, possibly leading to information overflow which can only be kept at bay by reducing the amount of information and boiling it down to the most essential aspects. Thus for example, color, shape or blinking/movement could be used to steer attention to the currently most relevant information. It may be next to impossible to make that incarnation of that software accessible at the same time, and it may rather have to be rewritten (or another mode of operation may have to be implemented), to make it 'accessible' (but maybe not nice / efficient to use anymore for other users). Typically it will have to be asked what kind of user is using the software for what purpose / tasks (does software that controls a nuclear power plant really have to be accessible?).

In a nutshell:
make the connection between accessibility and usability, and take usage context and purpose/tasks into account.

Olaf; Related issues: (space separated ids); WG Notes: Are there any other SC where our additional text can be considered usability related? First sentense to be modified according to text from the charter.; Proposed Resolution: The aim of WCAG2ICT is to develop informative guidance on how to apply WCAG 2.0 success criteria to non-web ICT. WCAG 2.0 success criteria already include a number usability considerations. Further, the WCAG2ICT provides additional notes and guidance where necessary. For example, success criteria 1.4.4 and 2.1.2 have additional notes clarifying the intent. With regard to blinking to draw attention, we note that there is nothing in the WCAG success criteria that prevents the use of color or blinking to draw attention. It simply requires that after three seconds the content stop blinking. This allows the technique to be used to attract attention but then stops the attention grabbing activity so that it does not distract from continuing use of the page.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2666: Duff Johnson - Standards Ignored [OTHER STANDARDS]: Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
EXISTING STANDARDS IGNORED

The document fails to take account of, or even acknowledge, the existence of accessibility standards developed specifically for non-web content such as ISO/IEC 29138, ISO/IEC 24786 or ISO 14289.; Related issues: LC-2663
(space separated ids); WG Notes:; Proposed Resolution: The WCAG2ICT task force was not charged with creating a normative standard nor with reviewing and evaluating standards from other organizations. In fact, the task force has no standing to make comments about the applicability or inapplicability of standards from other standards organizations. The Task Force's job is to provide informative guidance on how to apply the WCAG 2.0 principles, guidelines, and success criteria to non-web ICT in response to actions by the US Access Board and EU M376 standards development team proposing to use WCAG 2.0 as the standard for non-web ICT. If this task force were creating a normative standard and normatively citing parts of other standards as part of its standard, then it would indeed list those other standards. However this is not a group that is creating a normative standard. See also the introduction section and the excluded from scope section of the new draft document.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2667: Duff Johnson - Same Rules: Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
DOCUMENTS AND SOFTWARE – THE SAME RULES?

The WCAG2ICT attempts to apply WCAG 2.0 not only to non-web documents but also to “software aspects of products”. The notion that the same Success Criteria are usefully applicable across these domains is risible at best. Without substantial justification and development of the theoretical and practical underpinnings of this move, such a massive expansion of scope beyond web content can only reflect poorly on the organization making the attempt.

Does Tim know what you guys are doing?; Related issues: LC-2663
(space separated ids); WG Notes: Previous proposed resolution: With regard to the application beyond web content, see previous comments above. With regard to the application of the same rules across non-web documents and software we will be providing additional discussion to make this clearer. One thing is clear is that documents and software are rapidly converging. We expect that many books will contain complete interactive environments, experiments, and other things normally associated with software and games.; Proposed Resolution: The W3C did not initiate the concept of applying WCAG outside of Web Content. Rather it was the US Access Board who noted that the guidelines for electronic documents and software in the TEITAC report paralleled WCAG 2.0. The Access Board has proposed that WCAG 2.0 be used as the standard for non-web content and software in the Section 508 refresh process. Current drafts of European Mandate 376 (M376) standards are following the US lead. Through this task force, the W3C is developing a common understanding of how WCAG 2.0 might apply to non-web ICT for organizations and entities who are already seeking to so adopt and apply WCAG 2.0. By doing this we increase the likelihood that these applications of WCAG 2.0 will be consistent, and in keeping with the Principles, Guidelines, and Intent of WCAG 2.0. If you feel that WCAG 2.0 should not be used for non-web content and software, then we would suggest that you address your comments to the U.S. Access Board and EU M376 standards development team. Comments on the use WCAG 2.0 for non-web content and software, can be sent to the U.S. Access Board and/or submitted as part of the EU M376 review process.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2659: Take into account differences between platform and application software: Commenter: Olaf Drümmer <o.druemmer@callassoftware.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
[This email has been submitted as a comment on the July 27, 2012 draft of "Applying WCAG 2.0 to Non-Web Information and Communications Technologies"]

In ISO/IEC 13066-1 (and elsewhere) there is a very relevant distinction between platform or system software and application software, e.g. as phrased in ISO/IEC 13066-1, clause 4.2.5 (which also adds a third - support software):

"
a) System software, which includes the operating system and other instance of platform software;
b) Application software;
c) Support software.
"

This distinction has to play a substantial role when talking about the accessibility of software. For example, on iOS, when a piece of application software is programmed strictly adhering to applicable iOS guidelines, and does not introduce any 'custom stuff', the developer often essentially does not have to do anything about accessibility, as it will be taken care of by iOS and its built-in accessibility support.

In a nutshell:
WCAG2ICT to distinguish between platform (or systems software) and application software, only come up with guidelines specific to each of these, and also explain how one of the two relates to the other. Also, make sure to take the whole ISO/IEC 13066-1 into account (at least where software aspects are concerned).

Olaf; Related issues: (space separated ids); WG Notes:; Proposed Resolution: We have looked at this aspect very carefully and are finding that, as software is evolving, it is very difficult to differentiate software which is an application from that which is a platform. Rather than dividing software into these different categories, it is more useful to think of these as roles that software may play. Software may only play one of these roles but in many cases it will play multiple roles. Some application software, for example, is also a "platform" in that it provides services to other applications. With regard to this task force, however, we are not making any guidelines for software acting in its platform role(s) since these are not covered in WCAG. These should be covered elsewhere. For instance they are covered in various ISO standards, as you mention, and in both the Dec 2011 US Access Board and July 2012 EU M376 standard draft releases.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2668: Duff Johnson - Technical Standard: Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
NOT A TECHNICAL STANDARD

While offering broad value at the Principles and Guidelines level, the WCAG 2.0 Success Criteria do not provide much technical guidance that’s applicable directly to non-web ICT. In an informal (but not-inconsiderable) survey of implementers regarding WCAG 2.0 over the past year, I’ve found that:

- Even Web developers (HTML/CSS/JavaScript) often disagree over key provisions of WCAG 2.0.

- Non-web developers find WCAG 2.0 both vague and woefully underspecified with respect to technical guidance; SC 1.3.1 is particularly overloaded in this regard.; Related issues: LC-2663
(space separated ids); WG Notes:; Proposed Resolution: It seems from your comment that you are saying that WCAG 2.0 is not a technical standard, especially as it relates to non-web ICT. We do agree that the technical guidance for non-web ICT is not present, but is out of scope for this committee to define. However, the principles and guidelines in WCAG 2.0 are written to be technology agnostic and most are easily translatable to non-web ICT. With regard to your comment about the value of additional technical guidance with regard to applying WCAG 2.0 to non-web developers, we also agree, however it is outside the scope of this task force to prepare extensive application materials. We hope that there will soon be a number of books, manuals, training materials etc. on this topic. If you or the implementers you know have specific issues with the provisions or technical guidance in WCAG 2.0, we suggest you direct those comments to the WCAG 2.0 working group.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2690: WCAG may not be suitable outside of desktop environment [CLOSED]: Commenter: Alex Li <alli@microsoft.com> on behalf of Microsoft (archived message); Context: Document as a whole; Status:
assigned to; Type:; Comment:
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.; Related issues: (space separated ids); WG Notes:; Proposed Resolution: We agree that many of the WCAG provisions are based upon information being programmatically determinable and that this would not be of any benefit to closed functionality or closed products. We have added 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> @@@@ from http://www.w3.org/WAI/GL/wiki/WCAG2ICT_Introduction#Closed_Functionality; (Please make sure the resolution is adapted for public consumption)

Comment LC-2669: Duff Johnson - Web-Centric: Commenter: Duff Johnson <djohnson@commonlook.com> (archived message); Context: Navigation aspects e.g. Principle 2 & SC 3.2.3 in; Status:
assigned to; Type:; Comment:
WEB-CENTRIC

A key example of how WCAG 2.0’s web-centricity makes application to “non-Web ICT” problematic is the question of navigation.

In WCAG 2.0 the normative language is developed on the basis that “navigation” in electronic content occurs by way of “links” – controls deliberately embedded in the content by the author for navigational purposes

However, the ability to navigate content is a fundamental aspect of accessibility for users of documents – irrespective of links. Non-web documents – from PDF to DOC to PPT files to databases and others, may not include any links at all. Users customarily navigate such files using entirely different (and not always adequate) means such as headings, bookmarks, thumbnails and other features.

WCAG 2.0 is silent on navigation besides links. If applied to non-Web ICT, therefore, it’s reasonable to conclude that developers could safely ignore navigational considerations if their documents or other ICT do not include links or other context-changing controls. That’s not exactly the desired outcome!; Related issues: LC-2663
(space separated ids); WG Notes: I think we should Hold on this item until we finish our discussion on the navigation items and our definition of navigation etc.We agree that users navigate documents in many ways besides links. However, navigating content by paragraph, section, etc., is done by the user agent (including AT). WCAG doesn't speak to that sort of navigation - it only addresses navigation mechanisms explicitly put into the page(s) by the author of those page(s). Note that other success criteria - SC 1.3.1, SC 2.4.6 - speak to the need for structure, headings, etc. User agents in non-web ICT may utilize this information to provide means for navigating. ================== [WCAG WG] Comments ============== Change to We agree that users navigate documents in many ways besides links. The Understanding WCAG 2.0 INTENT for 2.4.6 specifically refers to headings used for navigation. Other success criteria - SC 1.3.1, SC 2.4.6 - speak to the need for structure, headings, etc. User agents in non-web ICT may utilize this information to provide means for navigating.; Proposed Resolution: We agree that users navigate documents in many ways besides links. The INTENT for 2.4.6 in Understanding WCAG 2.0 specifically refers to headings used for navigation. Other success criteria - SC 1.3.1, SC 1.3.2, SC 2.4.3 - speak to the need for structure, programmatically determined reading sequence, a focus order that preserves meaning and operation, etc. User agents in non-web ICT may utilize this information to provide means for navigating.; (Please make sure the resolution is adapted for public consumption)

1-20 21-40 41-48

Add a comment.