Sept. 23 Reorganization Proposal

The following proposal is designed to bring together:

1. elements from the last three proposals that recieved the best reception in discussions
2. the ongoing edits that the group has reached consensus on over the last 2 months
3. our decisions and recommendations from the last teleconference

In compiling this, it is not clear whether the best practice measures (note new name) should be included in the guidelines document or removed per recent discussions. When we removed them, what was left looked incomplete. Many of the checkpoints had a single success criteria that was different from the checkpoint, thus leading the reader to wonder why the only criteria for success was worded so differently from the rule that it was a success criterion for. To see this most easily, you can look at View 1 - Required Only, which shows only the required success criteria for each checkpoint.

To view the checkpoints with the required success criteria and the best practice measures only, use View 2 - Required Plus Best Practice Only. I think you will see that everything makes more sense if the best practice are included with the required.

Available Views:

1. View 1 - Required Only
2. View 2 - Required Plus Best Practice Only
3. View 3 - Required, Best Practice and Informative
4. View 4 - Combined (everything in one document)
5. View 5 - Best Practice and Additional Notes Only

Conformance notes

People have asked for the concept of A, Double-A and Triple-A. These will have different meaning than they did last time, but we determined that the meanings we used last time weren't really accurate or appropriate.

For WCAG 2.0, the three levels of conformance might be thought of as:

• A = all of the required criteria for the core checkpoint
• Double-A = all of the required criteria for the core and extended checkpoint
• Triple-A = all of the best practice (for both core and extended checkpoints)

As with WCAG 1.0, almost no one is going to achieve Triple-A in a form that others won't dispute. But, it really isn't important if someone works so hard that they think they have achieved Triple-A, then more power to them. Nobody is going to require it. It will only be A and Double-A that will get much scrutiny.

If we use this approach, then a very careful examination of the comparisons between A and Double-A for WCAG 1.0 and 2.0 will need to be done. We will undoubtedly need the technology specific checklists in order to do this, however.

Keeping Best Practice in the Guidelines Document

By moving all of the best practice success criteria into AAA conformance levels, we may address the primary motivation for removing them from the guidelines (i.e. that they would get incorporated into minimum requirements) by renaming them. "Best Practice Measures" instead of "Best Practice Success Criteria" will further break this linkage.

Finally, we could also add structural markup and visual formatting to emphasize the differences beteen the two categories.

If some country or municipality is bound and determined to add one of these (best practice items) into the required list for their use, however, it is critical that they all use the same wording and that they not make up their own new criteria since that is the worst of all possible worlds because it leads to not just different (compatible) standards but to different incompatible standards that sites might have to conform to.

Change log

General

• incorporated changes (and removed revision markup) for resolved issues 321, 360, 379, 343, 342, 338, 324, 332, 329, 436, 328, 334, 351, 349, 348, 347, 345, 340, 339, 337, 336, 335, 333.
• changed "Best Practice Success Criteria.." headings to "Best Practice Measures..."
• dropped square bracketed indications of old checkpoint numbering. given the number of reorganization proposals that have emerged recently, this seems to be no longer helpful and addresses Issue 391.
• with the exception of checkpoints 1.5, 3.3 and 3.4, all additional notes were moved to best practice or combined with existing best practice items.

Guideline 1

• Checkpoint 1.2 - moved bullet about collated text transcripts to checkpoint 1.1, additional notes.
• Checkpoint 1.2 - moved information about audio description to glossary per CKW proposal.
• Checkpoint 1.4 - changd checkpoint text to read, "All text can be decoded into words represented in Unicode," was "All characters and words in the content can be unambiguously decoded."
• Checkpoint 1.5 - removed "positioning and labels" and "to more people" from checkpoint text per CKW proposal.
• Checkpoint 1.6 - separated audio and visual contrast into two checkpoint per CKW proposal.
• Checkpoint 1.6 Benefits - reworded to "Individuals with low vision can easily make out characters in the content even if they don't have the wide field of view or full range of color perception used by fully sighted persons to separate text from background images," was, "Individuals with low vision can easily make out characters in the content even if they don't have the wide field of view used by fully sighted persons to separate text from background images."
• Checkpoint 1.8 - added a placeholder checkpoint in extended addressing color.

Guideline 2

• Checkpoint 2.1 - removed "concisely" from first success criterion. now reads, "all of the functionality of the content, where the functionality or its outcome can be expressed in words, is operable at a minimum through a keyboard or keyboard interface." and links to the definition of "ability to be expressed in words"
• Checkpoint 2.2 - combined required and best practice criteria to read, "content is designed so that time limits are not an essential part of interaction or at least one of the following is true for each time limit."
• Checkpoint 2.2 - moved BP item, "any blinking content can be turned off" to BP under 1.3. CKW draft suggested that this is usually an issue of content/structure separation and that it should be associated with techniques from 1.3.
• Checkpoint 2.4 - now reads, "Mechanisms have been added to facilitate orientation and movement in content." (removed "Structure and/or alternate navigation" fom beginning per CKW reccomendation.)
• Checkpoint 2.4 - dropped an editorial note explaining the rationale for combining old 3.1 and 3.2.
• Checkpoint 2.5 - changed required item 1 to "if a user error is detected, the error is identified and (where possible) suggestions for correction are provided (in an accessible form that meets core checkpoints). ," was "if an error is detected, feedback is provided to the user identifying the error (in an accessible form that meets core checkpoints)."

Guideline 3

• Checkpoint 3.1 - moved "document attributes identify the natural language of the document" up to required.
• Checkpoint 3.2 - moved benefits "Summarizing information that is difficult to understand helps people who do not read well," and "roviding a summary of the visual cues that show relationships between complex information helps people who do not use visual cues or who have difficulty using visual cues. For example, people who are completely blind do not use any visual cues, while people with dyslexia or with low vision might have difficulty interpreting visual cues," to 3.3.
• Checkpoint 3.3 and 3.4 - added a best practice item that refers to lists in additional notes sections.

Guideline 4

• Checkpoint 4.1 - Removed, "for Application Programming Interfaces (API's), programming standards for the language are followed."
• Checkpoint 4.1 - Removed, "accessibility features and API's are used when available."
• Checkpoint 4.2 [was 4.3] - Included proposed changes for 4.2., moving what was checkpoint 4.3 to 4.2
• Checkpoint 4.3 [was 4.2] - reworded best practice to "technologies and features on the required list are available in at least two independently-developed implementations. (it is preferable that the technologies used for the implementations have been supported for at least one prior version of the software)" was, "Technologies and features on the required list are available in at least two independently-developed implementations." and removed additional note that read "of at least two such implementations, it is true that the technologies and features on the required list have been supported by at least one prior version of the software."
• Checkpoint 4.2 [was 4.2] - reworded best practice item to read "the interface has been tested using a variety of assistive technologies and preferably real people with disabilities who use assistive technologies to determine that those assistive technologies are able to access all information on the page or hidden within the page," was "the interface has been tested using a variety of assistive technologies and preferably real people with disabilities who use assistive technologies to determine that assistive technologies can access all information on the page or hidden within the page. " and removed editorial note that read "It would be possible to comply with the checkpoint without carrying out tests (either with users or with assistive technologies). Conversely, it is possible to conduct tests, but still fail to meet the checkpoint (with respect to assistive technologies that were not tested, for example). Should this success criterion be deleted?"

Appendix A

• removed duplicate definitions for non-text content.
• added termref elements to terms used in document for glossary linking
• made entries for captions and audio descriptions separated from definition of media equivalent.
• combined definitions of structure (previously defined in both 1.3 and 2.4).

Variations from CKW draft

• Checkpoint 1.1 - moved bullet about collated text transcripts from required and moved down to best practice. (agreed with proposed change in checkpoint association)
• Checkpoint 2.4 - The CKW reorganization proposed that all of the items in required be removed and proposed a rewording of the item in best practice that addressed logical, linear reading order. Added an editorial note about this proposal and referenced issue 441.
• Checkpoint 2.5 - The CKW proposal suggested that this required success criterion be combined with one of the best practice items and that another best practice item be moved up. (issue 440) We were a concerned that this was difficult to do and that the "where possible" language made it somewhat fuzzy. For now, we left these edits out and logged a new issue that is referenced by a new editorial note.
• 4.1 - though splitting into two checkpoints was interesting, we felt that this propsal had the potential to make it very difficult to meet extended as a group and created a problematic tradeoff for those attempting full compliance with extended since it could sometimes mean excluding users of certain AT or user agents that do not support fully standards compliant code correctly. Also, since the use of some depracated markup does not always adversely impact users of AT, it seemed that it was better to leave the note about exceptions at the best practice level.