[Editorial] Update with review tweaks #737
Conversation
✅ Deploy Preview for wcag2ict ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
daniel-montalvo
changed the title
| @@ -5,27 +5,27 @@ This document is an update to a W3C [Working Group Note](https://www.w3.org/2005 | |||
|
|
|||
| [Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)](https://www.w3.org/TR/2013/NOTE-wcag2ict-20130905/), approved in September 2013, described how WCAG 2.0 could be applied to non-web documents and software. WCAG2ICT was organized to mirror WCAG's sections: Perceivable, Operable, Understandable, and Robust. WCAG2ICT clarified when and how WCAG success criteria could be applied to non-web documents and software. Some were applicable without modification and some were applicable with edits and/or notes. Glossary terms were also reviewed. Level AAA success criteria were not addressed in the 2013 WCAG2ICT Working Group Note. | |||
|
|
|||
| The 2013 WCAG2ICT has been relied upon in regulations and legislation. One example is \[\[etsi-en-301-549\]\] (Europe) and other standards that reference or incorporate EN 301 549 (e.g., India, Kenya, Australia). Another example is Section 508 (U.S.) [Application of WCAG 2.0 to Non-Web ICT](https://www.federalregister.gov/documents/2017/01/18/2017-00395/information-and-communication-technology-ict-standards-and-guidelines#h-36), which looked to WCAG2ICT for detailed direction with providing specific guidance and exceptions to particular criteria from being applied to non-web technology. Section 508 incorporated by reference WCAG as the [Accessibility Standard applicable to non-web documents](https://www.access-board.gov/ict/#E205.4) and requires [WCAG Conformance for non-web software](https://www.access-board.gov/ict/#E207.2). | |||
| The 2013 version of WCAG2ICT has been relied upon in regulations and legislation. One example is standards that reference or incorporate WCAG2ICT, such as \[\[etsi-en-301-549\]\] in Europe, and others in India, Kenya, and Australia. Another example is Section 508 [Application of WCAG 2.0 to Non-Web ICT](https://www.federalregister.gov/documents/2017/01/18/2017-00395/information-and-communication-technology-ict-standards-and-guidelines#h-36) in the United States, which looked to WCAG2ICT for detailed direction on providing specific guidance for how to apply WCAG to non-web technology, as well as listing exceptions where WCAG success criteria do not apply. Section 508 incorporated by reference WCAG as the [Accessibility Standard applicable to non-web documents](https://www.access-board.gov/ict/#E205.4) and requires [WCAG Conformance for non-web software](https://www.access-board.gov/ict/#E207.2). | |||
There was a problem hiding this comment.
The edits to this paragraph changes the meaning. the India, Kenya and Australia are country-specific adoptions of the EN 301 549. Therefore, reverting that sentence back to the original. Also, Section 508 was using the WCAG2ICT guidance, not providing its own, which led to exceptions where certain success criteria were not applied.
| The 2013 version of WCAG2ICT has been relied upon in regulations and legislation. One example is standards that reference or incorporate WCAG2ICT, such as \[\[etsi-en-301-549\]\] in Europe, and others in India, Kenya, and Australia. Another example is Section 508 [Application of WCAG 2.0 to Non-Web ICT](https://www.federalregister.gov/documents/2017/01/18/2017-00395/information-and-communication-technology-ict-standards-and-guidelines#h-36) in the United States, which looked to WCAG2ICT for detailed direction on providing specific guidance for how to apply WCAG to non-web technology, as well as listing exceptions where WCAG success criteria do not apply. Section 508 incorporated by reference WCAG as the [Accessibility Standard applicable to non-web documents](https://www.access-board.gov/ict/#E205.4) and requires [WCAG Conformance for non-web software](https://www.access-board.gov/ict/#E207.2). | |
| The 2013 WCAG2ICT has been relied upon in regulations and legislation. One example is \[\[etsi-en-301-549\]\] (Europe) and other standards that reference or incorporate EN 301 549 (e.g., India, Kenya, Australia). Another example is Section 508 [Application of WCAG 2.0 to Non-Web ICT](https://www.federalregister.gov/documents/2017/01/18/2017-00395/information-and-communication-technology-ict-standards-and-guidelines#h-36) in the United States, which looked to WCAG2ICT's guidance for how to apply WCAG to non-web technology which led to a few exceptions where WCAG success criteria are not applied by Section 508 to non-web technology. Section 508 incorporated by reference WCAG as the [Accessibility Standard applicable to non-web documents](https://www.access-board.gov/ict/#E205.4) and requires [WCAG Conformance for non-web software](https://www.access-board.gov/ict/#E207.2). |
There was a problem hiding this comment.
The edits to this paragraph changes the meaning. the India, Kenya and Australia are country-specific adoptions of the EN 301 549. Therefore, reverting that sentence back to the original. Also, Section 508 was using the WCAG2ICT guidance, not providing its own, which led to exceptions where certain success criteria were not applied.
Sorry for that @maryjom and thanks for catching this. In order to make this paragraph easier to parse (a few things are still not clear IMO), would the following work for line 8 without changing the intended meaning?:
WCAG2ICT 2013 has been relied upon in regulations and legislation. One example is the European standard, [[etsi-en-301-549]], which relies upon WCAG2ICT, along with the standards that reference or incorporate EN 301 549 (e.g., India, Kenya, Australia). Another example is Section 508 Application of WCAG 2.0 to Non-Web ICT in the United States, which uses WCAG2ICT to provide guidance on how to apply WCAG to non-web technology, resulting in a few exceptions where WCAG success criteria are not applied by Section 508 to non-web technology. This is important because Section 508 incorporates by reference WCAG as the Accessibility Standard applicable to non-web documents and requires WCAG Conformance for non-web software.
| * This document is not sufficient by itself to ensure accessibility in non-web documents and software. As a web standard, WCAG does not fully cover all accessibility requirements for non-user interface aspects of platforms, user-interface components as individual items, or ICT with closed functionality (where there is no assistive technology to communicate programmatic information). | ||
| * This document does not comment on hardware aspects of products, because the basic constructs on which WCAG 2 is built do not apply to these. | ||
| * This document does not seek to determine which WCAG 2 provisions (principles, guidelines, or success criteria) should or should not apply to non-web documents and software, but rather — if applied — *how* they would apply. | ||
| * This document does not propose changes to WCAG 2 or its supporting documents; and it does not include interpretations for implementing WCAG 2 in web technologies — note that during the development of this document, the WCAG2ICT Task Force did seek clarification on the intent of a number of the success criteria, which led to clarifications in the Understanding WCAG 2 document. |
There was a problem hiding this comment.
IMO, it's ok for a bullet to have multiple sentences.
| * This document does not propose changes to WCAG 2 or its supporting documents; and it does not include interpretations for implementing WCAG 2 in web technologies — note that during the development of this document, the WCAG2ICT Task Force did seek clarification on the intent of a number of the success criteria, which led to clarifications in the Understanding WCAG 2 document. | |
| * This document does not propose changes to WCAG 2 or its supporting documents. It also does not include interpretations for implementing WCAG 2 in web technologies. Note that during the development of this document, the WCAG2ICT Task Force did seek clarification on the intent of a number of the success criteria, which led to clarifications in the Understanding WCAG 2 document. |
There was a problem hiding this comment.
IMO, it's ok for a bullet to have multiple sentences.
@maryjom - I'm happy to accept these reversions to remove the em dashes because we don't currently have a single WAI style guide to point to. Note that we are working on this, including guidance for multi-sentence list items :)
The proposal we're discussing in this instance is to keep individual list items to no more than one complete sentence as a best practice for enhancing readability on the web. If a subsequent clause clarifies something in the previous clause in the list item, this could be signalled using an em dash, which sets off extra information relating to the previous clause and keeps a close connection with it, semantically.
Here is the rationale, along with some considerations for the list we're discussing in this issue:
While multiple sentences are acceptable, if the bullet points are excessively long, this can defeat the purpose of using a list for quick comprehension.
The list design needs to maintain consistency and clarity, and to build rhythm for readability. Multiple sentences in a list are acceptable if they enhance clarity — as long as all the list items conform to a similar pattern.
In other words, if one bullet point contains multiple sentences, all the other bullet points in the same list should also ideally contain multiple sentences, or at least be similar in structure.
In the case of this list, it's hard to create consistency and build rhythm in the way it's currently designed because not all the list items are structured similarly (the second and third list items are especially problematic and IMHO do not help readers to easily and quickly parse the information).
Furthermore. in the case of line 46, this list item has two topics: (a) no changes are proposed; and b) no interpretations for implementing WCAG 2 in web technologies are included). If you separate these topics into two complete sentences within the list item, then I propose it might be better to make the second sentence a separate list item, together with the 'note', which does not appear to be related to the first sentence — or at least, this is not clear to me (but perhaps I misunderstand it?).
| * This document does not comment on hardware aspects of products, because the basic constructs on which WCAG 2 is built do not apply to these. | ||
| * This document does not seek to determine which WCAG 2 provisions (principles, guidelines, or success criteria) should or should not apply to non-web documents and software, but rather — if applied — *how* they would apply. | ||
| * This document does not propose changes to WCAG 2 or its supporting documents; and it does not include interpretations for implementing WCAG 2 in web technologies — note that during the development of this document, the WCAG2ICT Task Force did seek clarification on the intent of a number of the success criteria, which led to clarifications in the Understanding WCAG 2 document. | ||
| * This document is not sufficient by itself to ensure accessibility in non-web documents and software — this is because, as a web standard, WCAG does not fully cover all accessibility requirements for non-user interface aspects of platforms, user-interface components as individual items, or ICT with closed functionality (where there is no assistive technology to communicate programmatic information). |
There was a problem hiding this comment.
| * This document is not sufficient by itself to ensure accessibility in non-web documents and software — this is because, as a web standard, WCAG does not fully cover all accessibility requirements for non-user interface aspects of platforms, user-interface components as individual items, or ICT with closed functionality (where there is no assistive technology to communicate programmatic information). | |
| * This document is not sufficient by itself to ensure accessibility in non-web documents and software. This is because, as a web standard, WCAG does not fully cover all accessibility requirements for non-user interface aspects of platforms, user-interface components as individual items, or ICT with closed functionality (where there is no assistive technology to communicate programmatic information). |
| * This document does not seek to determine which WCAG 2 provisions (principles, guidelines, or success criteria) should or should not apply to non-web documents and software, but rather — if applied — *how* they would apply. | ||
| * This document does not propose changes to WCAG 2 or its supporting documents; and it does not include interpretations for implementing WCAG 2 in web technologies — note that during the development of this document, the WCAG2ICT Task Force did seek clarification on the intent of a number of the success criteria, which led to clarifications in the Understanding WCAG 2 document. | ||
| * This document is not sufficient by itself to ensure accessibility in non-web documents and software — this is because, as a web standard, WCAG does not fully cover all accessibility requirements for non-user interface aspects of platforms, user-interface components as individual items, or ICT with closed functionality (where there is no assistive technology to communicate programmatic information). | ||
| * This document does not comment on hardware aspects of products — this is because the basic constructs on which WCAG 2 is built do not apply to these. |
There was a problem hiding this comment.
| * This document does not comment on hardware aspects of products — this is because the basic constructs on which WCAG 2 is built do not apply to these. | |
| * This document does not comment on hardware aspects of products. This is because the basic constructs on which WCAG 2 is built do not apply to these. |
| * This document does not provide supporting techniques for implementing WCAG 2 in non-web documents and software. | ||
| * This document is purely an informative Note about non-web ICT, not a standard, so it does not describe how non-web ICT should conform to it. | ||
| * This document is purely an informative Note about non-web ICT — it is not a standard — so it does not describe how non-web ICT should conform to it. |
There was a problem hiding this comment.
| * This document is purely an informative Note about non-web ICT — it is not a standard — so it does not describe how non-web ICT should conform to it. | |
| * This document is purely an informative Note about non-web ICT. It is not a standard — so it does not describe how non-web ICT should conform to it. |
Co-authored-by: Mary Jo Mueller <maryjom@us.ibm.com>
Co-authored-by: Mary Jo Mueller <maryjom@us.ibm.com>
Fixes #742