1. Bug1197: Build more plain-language clarification into the first few paragraphs of the Introduction, so that readers have more of an idea what ATAG is within the first few sentences of the Introduction. Right now the first sentence seems fairly abstract and does not give a clear idea of what the document is. ("This document specifies requirements that, if satisfied by authoring tool developers, will lower barriers to accessibility"... also, in the abstract, "This specification provides guidelines for designing authoring tools that lower barriers to Web accessibility for people with disabilities.")
2. Bug1197: Check for understandability of the writing throughout the whole Introduction section, particularly focusing on the sequence of what is stated, and where it's explained. Right now these do not seem to flow clearly.
3. Bug1197: This ATAG document doesn't seem to sufficiently differentiate itself from WCAG, even though there is a section addressing this.
4. Bug1197: The status section is very long. There is some redundant information, and some information that seems more appropriate for an Introduction than for a Status section. Here are some specific suggestions for how to address this:

   ...Delete all material between 1.4 and 1.4.1 and refer instead to http://www.w3.org/WAI/intro/components.
   ...Leave section 1.4.1 (with any relevant, non-redundant material from the paragraph 2 before that section)
   ...Leave section 1.4.2 (with any relevant, non-redundant material from the paragraph right before section 1.4.1)
   ...Refer to Components Documents for XAG background, instead of explaining it here since XAG is not yet stable.
   ..For 1.3, consider adding a much more direct and relevant statement: Authoring tools should be designed so that everyone can create Web content. [or] Authoring tools should be accessible to people with disabilities.
   ....There appears to be a recursive link at "authoring interface checkpoints relative to ISO...".

5. Bug1197: In the success criterium, the terminology "must always conform" seems awkward. Why not just say "conforms"? e.g.: Current: "At least one full-featured Web-based authoring interface must always conform to WCAG." Suggested replacement: "At least one full-featured Web-based authoring interface conforms to WCAG." If concerned about "always", could put that in the preface text.
6. Bug1196: I will be interested in seeing the "proof of concept" web authoring tool that meets all of the Priority 1 checkpoints - it isn't going to be easy! BAF indeed it will be. I doubt one exists, we either need to 1) commission the creation of one or 2) find partial solutions across many tools. I think, while a lot of effort, 1 is the most likely to succeed. It will also be the "best" example to learn from..The ATAG techniques doc could be a "spec" for this tool (the tool does not need to be all that functional (ie really generate web content) or self consistent, mostly just show good UI options)

1. Status: KM
2. Status: KM
3. Status:
4. Status:
5. Status:
6. BAF Proposal:
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0008.html
   ATAG Partial Credit.
   TB's Response:
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0010.html

1. Draft:
2. Draft:
3. Draft:
4. Draft:
5. Draft:
6. Draft:

1. Bug1120: The group is using ISO-TS-16071 to define the accessibility of the non-web application . How does this map to 508? Are you introducing additional requirements on companies. This may create a barrier to adoption in the United States and other geos. Somebody from ATAG needs to provide a matrix which describes the differences and equivalents for review and if adopted, the matrix should be published.
2. Bug1196: Overall I think we really need to revisit depending on the ISO standard for non- web tools and define our own criteria. I was queasy about this before (since I never actually saw the standard) but now that other IBMers have assessed it as is as being problematic, I can no longer agree to depending on it solely.
3. Bug976: There is the "problem" of ISO. If we refer only to general guidelines, we have only "core" and "secondary" level. This because we have set as:
4. Bug1196: Does Europe require Priority 1, 1 and 2, 1 and 2 and 3? I might change priorities based on how they are viewed. BAF this is on ISO standard use. The concern is some countries may require all criteria to be met. Big (possibly impossible) burden on tool developers.
5. Bug1196: Checkpoint 1.1 I was disappointed that the URL in the ISO - TS - 16071 does not take you to the document. Since it is assumed that you will use 16071, for checkpoint 1.1 I think a direct link is needed. What priority is this checkpoint? BAF can we link to this document. I don't think so (cost issues). As I said before, I think we need a good condensation of this standard in our document to prevent the hard dependency on getting the ISO document. maybe we need to rethink depending on another body for these criteria.
6. Bug1196: The group is using ISO-TS-16071 to define the accessibility of the non-web application . How does this map to 508? Are you introducing additional requirements on companies. This may create a barrier to adoption in the United States and other geos. Somebody from ATAG needs to provide a matrix which describes the differences and equivalents for review and if adopted, the matrix should be published.
7. Bug1196: BAF: if we continue to use this standard as a base, we need to clarify the application of priorities. We also need to contrast it to other common standards that may apply (especially US section 508) as many tool vendors desire to conform to these standards as well. Certainly we don't want to have conflicting rules (one standard requires something another explicitly disallows). Again this is a reason to revisit the delegation to ISO. Note that this is an early assessment and may be revised or extended (i.e., more issues found).
   ISO 9241 Part 171 has two priority levels - Required and Recommended. It also specifies, for each requirement, whether it is an application only requirement, an OS only requirement, or both an application and OS requirement. IBM is concerned mostly with the application requirements but we also looked at the OS only requirements for their impact to IBM operating systems.

1. Status: If we adopt new reqs then just reply.
2. Status: If we adopt new reqs then just reply.
3. Status: If we adopt new reqs then just reply.
4. Status: If we adopt new reqs then just reply.
5. Status: If we adopt new reqs then just reply.
6. Status: If we adopt new reqs then just reply.
7. Status: If we adopt new reqs then just reply.

1. Draft:
2. Draft:
3. Draft:
4. Draft:
5. Draft:
6. Draft:
7. Draft:

1. Bug1111/1196: Modify: Examples: timelines, waveforms, vector-based graphic editors, etc. To include: objects which represent web implementations for graphical widgets (menus, etc.).Under indirect authoring functions include model-based authoring tools

1. Agreed 28 March 05.

1. Draft

1. Bug1009: I don't understand why the "rationales" are designated as "normative"..

1. Agreed 4 April 05: Change text to: "A rationale for the checkpoint. (Informative)"

1. Draft

1. Bug1197: Guideline 1: "Make the authoring interface accessible": In the first descriptive paragraph, the last sentence is long and unnecessarily difficult; consider breaking it up. Consider describing 1.2, 1.3, 1.4 and 1.5 individually. Compare this to the first descriptive paragraph for Guideline 2; that paragraph briefly describes every part 2.1-2.4. Perhaps an overall rationale needs to be stated explicitly; for instance, "Rationale - If an authoring feature is present for one user population then a functionally equivalent feature should be present for all users."

1. Status: KM volunteers.

1. Draft

1.1 Ensure that the authoring interface follows applicable software accessibility guidelines. [Authoring Interface Checkpoints Relative to WCAG or Authoring Interface Checkpoints Relative to ISO-TS-16071]

1. The authoring tool must satisfy at least one of the following conditions:
   (a) At least one full-featured Web-based authoring interface must always conform to WCAG.
   (b) At least one full-featured non-Web-based authoring interface must always conform to ISO-TS-16071.
   

1. Bug1186: Sec 1.1 . I presume the 4th bullet will eventually lead to the appendix mentioned. Last paragraph ...as readable and usable _as possible_ [for that diverse audience] while...
2. Bug1197: Success Criteria: In the success criterium, the terminology "must always conform" seems awkward. Why not just say "conforms"? e.g.: Current: "At least one full-featured Web-based authoring interface must always conform to WCAG." Suggested replacement: "At least one full-featured Web-based authoring interface conforms to WCAG." If concerned about "always", could put that in the preface text.
3. Bug1196: I have concerns that "At least one full-featured Web-based authoring interface must always conform to WCAG. " Since WCAG 2.0 is not released yet, a current web tool cannot conform to WCAG 2.0 and thus MUST conform to WCAG 1.0. It would be practically impossible for a full featured web based authoring tool to conform to WCAG 1.0 because of the following WCAG priority 1 checkpoint: "6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1] " I realize that WCAG 2.0 isn't complete and ATAG must rely on WCAG 1.0 but I think some concessions should have been made since JavaScript is so much better supported since WCAG 1.0 was released. I think it is good that ATAG and WCAG and UUAG are being related but the versioning skew between the documents may cause issues.
   BAF I know we dealt with version references issues before, but this is a particularly important one (ie scripted page accommodation/alternatives) that we need to addresses the situation in our own criteria, not delegate to another standard.

1. Proposal to replace all of GL1 (JR):
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0029.html
2. Status: This may still be an issue. Do we still need to say only one full featured authoring inteface need be accessible? Is this the "back of the bus" if a tool has a "word processing " view and a source view but only the source view is accessible.
3. Status: Just need to reply.

1. Draft
2. Draft
3. Draft

1.2 Ensure that the authoring interface enables accessible editing of element and object properties. [Authoring Interface Checkpoints Relative to WCAG or Authoring Interface Checkpoints Relative to ISO-TS-16071]

1. The authoring tool must satisfy at least one of the following conditions:
   (a) In Web-based authoring interfaces, at least one editing method for each editable property must always conform to WCAG.
   (b) In non-Web-based authoring interfaces, at least one editing method for each editable property must always conform to ISO-TS-16071.

1. Bug1132: It is not completely clear that a tool is required to make editable properties accessible, not all properties editable. (Also linked term is different than glossary term)
2. Bug1187: 1.2 ... Web content for publication. ?deliberately excluding pdf, MSWord, etc. which are sometimes made available on the web?
3. Bug1197: Guideline 1.2: "Ensure that the authoring interface enables accessible editing of element and object properties": The term "element" is ambiguous in its definition or usage here. Following the link to definition of element reveals the term is used in two ways: (1) to denote a general token in the programming language sense and (2) to denote the actual grammar symbol, element, from markup languages HTML and XML. Also, please examine whether this is the term really needed.
4. Bug1196: Checkpoint 1.2 I can only assume that ISO - TS - 16071 does not address element and object properties which is the reason they are called out here. What priority is this checkpoint?

1. Status: Assigned to KM to make proposal.
2. Status: just reply
3. Status: Assigned to KM to make proposal.
4. Status: If we adopt new reqs then just reply.

1. Draft
2. Draft
3. Draft
4. Draft

1.3 Allow the display preferences of the authoring interface to be changed without affecting the document markup. [Priority 1]

1. All editing views must always include an option to display any available equivalent alternatives.
2. All editing views must always include an option to keep the display settings of the authoring interface from affecting the Web content being edited.

1. Bug1188: 1.3 Success criteria -- "any available equivalent alternatives" Many tools will not have text-to-speech; will not let any response when the display is off, will not be responsive without a pointing device, will not tab-step through links, etc.
2. Bug1196: Guideline 1.3
   Success criteria 2: All editing views must always include an option to keep the display settings of the authoring interface from affecting the Web content being edited.
   Implementation techniques 1.3.2 and 1.3.3 conflict - you can't have both. If the web tool is honoring system display settings, the tool itself and any preview of created content will display in the system settings. Technique 1.3.2: Respect system display settings.
   Technique 1.3.3: For tools with editing views, provide the author with the ability to change the fonts, colors, sizing (zoom), etc. within the editing view, independently of the ability to control the markup that is actually produced. [STRONGLY SUGGESTED]
   BAF we need to clarify this so that we make the strong separation between the use/definition of settings for previewing authored web content and the use/definition of settings used by the tool outside any preview windows. The settings may be totally different in these two contexts. Also we need to make sure that the reader understands that we are saying that the tool's settings should not dictated the settings used in any authored web content (ex settings for any generated CSS info) or preview view of that content, that is they are independent (but the may share defaults).
3. Bug1196: The technique 1.3.1 for implementing this calls for respecting system font and color information. How does this meet this checkpoint in and by itself

1. Status: ???
2. Status: May be misunderstanding
3. Status: Just reply

1. Draft
2. Draft
3. Draft

1.4 Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits. [Priority 2]

1. In any element hierarchy, the author must always be able, with a device-independent action, to move the editing focus from any element to any of the following elements, if they exist: the element immediately above (i.e. parent), the first element immediately below (i.e. child), the element immediately preceding at the same level (i.e. previous sibling), and the element immediately following at the same level (i.e. next sibling).
2. In any element hierarchy, the author must always be able, with a device-independent action, to select content and perform editing functions on any element along with any content, including subelements.

1. Bug1114/1196: This requires the author to perform structure-based edits. The document structure being edited should be without error correction performed. Assistive technology vendors often have to deal with bad content as the DOM structure they are processing does not match that which is rendered. So, if the authoring tool operates off of corrected content the results may not meet the needs of the impaired user while being used by an assistive technology. This should not be limited to only target device independence.
   The second issue is that the author must be able to enumerate the available actions which can be taken at a given object and selectively activate them. For content which provides text equivalents for the corresponding action such as the new access feature in XHTML 2.0 this information should be provided to the author. An action may cause an action to occur which moves focus.
2. Bug1189: 1.4 bullet 4 ...different format specifications _such as CSS_, use ...
   Success Criteria 1: Nice idea for navigation by levels ?Are there any tools that allow stepping through by hierarchy?
   Success Criteria 2: Are there any tools that allow selection of entire structure with its substructure?
3. Bug1197: Guideline 1.4 "Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits": The rationale needs more explanation in order not to be interpreted as a requirement for a general usability feature. For instance, explaining why this is essential for authors with certain types of disabilities would be helpful.
4. Bug1196: Checkpoint 1.4 Why is this important and unique in reference to navigation and editing?
5. Bug1196: Guideline 1.4 Success Criteria 2 I have concerns that this technique may not be achievable in all web interfaces and widgets:
   Technique 1.4.5: Allows the author to move among, select, copy, cut, or paste elements of the document. On the web, the following techniques seem to be more of a function of user agents
   Technique 1.4.7: In a hypertext document, allow the author to navigate among interactive elements of content (e.g. links, form elements).
   Technique 1.4.8: Allow editing view navigation of content by any accesskeys defined in that content.
   BAF we may need to distinguish support in web vs. non-web tools to address these concerns.

1. Status: Assigned to GP to make wording proposal.
2. Status: Assigned to GP to make wording proposal.
3. Status: Assigned to GP to make wording proposal.
4. Status: Assigned to GP to make wording proposal.
5. Status: Assigned to GP to make wording proposal.

1. Draft
2. Draft
3. Draft
4. Draft
5. Draft

1.5 Ensure that the authoring interface allows the author to search within the editing views. [Priority 2]

1. At least one comprehensive editing view must always include a search function that meets these conditions:
   (a) Provides search within any rendered Web content
   (b) Provides the option to search markup when the tool allows direct editing of markup (e.g. when authored "by hand").
   (c) Provides the option to search for text within all text equivalents of any non-text content.

1. Bug1115: In XHTML 2.0 we are introducing the role attribute and other important meta data which is important for authoring tools. This includes search for text equivalents for non-text objects. Does this include things like role meta data which includes additional semantics vs. simply a text alternative? This is not clear. It should be clarified either in the document or its techniques. How do the navigation techniques here map to UAAG 1.0? Where is the reference to UAAG 1.0?
2. Bug1196: In XHTML 2.0 we are introducing the role attribute and other important meta data which is important for authoring tools. This includes search for text equivalents for non-text objects. Does this include things like role meta data which includes additional semantics vs. simply a text alternative? This is not clear. It should be clarified either in the document or its techniques.
   BAF: we need to look more closely at XHTML 2.0 to see if it has features we need to explicitly account for in these guidelines.
   How do the navigation techniques here map to UAAG 1.0? Where is the reference to UAAG 1.0?
3. Bug1226: In checkpoint 1.5, for Web-based tools can the search be browser's find function? What if only some browsers support "find".

1. Status:MM (add "and metadata" to success criteria 1c)
2. (Same as above)
3. JR Proposal:
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0007.html
   JR Revised Proposal:
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0016.html

1. Draft
2. Draft
3. Draft

1. Bug1197: Introductory comments for the main guidelines 1, 2, 3 and 4: The introductory comments for the main guidelines should include links to any terms that are defined in the glossary. For example, in Guideline 2, the overall introduction should provide links to the terms such as "unrecognized markup," "accessible information," "transformations," "conversions," etc. Any defined term occurring in the document link should to the definition the first time it occurs.

1. Status: KM volunteers

1. Draft

2.1 Support formats that enable the creation of Web content that conforms to WCAG. [Priority 1]

1. Any authoring tool that chooses the format of content for the author (i.e. a default format) must always choose formats for which there are published WCAG techniques documents for meeting each WCAG checkpoint.
2. Any authoring tool that allows authors to choose the format of content must always support at least one format for which there is a published WCAG techniques documents for meeting each WCAG checkpoint and always give prominence to those formats.

1. Bug1116/1196: This would indicate we (HTML working group) need to publish a WCAG 2.0 conformance techniques document for XHTML 2. This means any existing content recommendation which does not have a WCAG conformance techniques document does not comply with ATAG 2.0.
2. Bug1197: Guideline 2.1, "Support formats that enable the creation of Web content that conforms to WCAG": Even after considerable discussion, and following the link to the definition, we were not entirely clear what is meant by "format" here. For instance, we were wondering whether it was related to markup languages, or to doc type schemas, or something else. Please clarify here and then reinforce that in the glossary.
3. Bug1196: Guideline 2.1 Support formats that enable the creation of Web content that conforms to WCAG. [Priority 1]
   I have the same concerns here as for Guideline 1.1 - issues with WCAG 1.0 and JavaScript. We should allow tools to generate JavaScript as long as the generated JavaScript is accessible and not require sites to run with JavaScript turned off.
   Do Success Criteria 1 & 2 mean that you can't use a format for content if there is no WCAG techniques document for it? I certainly hope not - that could stifle new technologies!!! The checkpoint techniques make it a bit clearer, but I find the Success Criteria, as written, confusing. BAF my understanding is - if no WCAG techniques doc then the format can't be used and conform to ATAG (unless alternative conforming content is provided). If correct, we are putting a strong dependency on the creation of WCAG techniques docs by the format creators (or others). We need to make sure this dependency is well and widely know so it will be meet.

1. JR Proposal:
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005JanMar/0085.html
   Superceded by:
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0022.html
   [ADOPTED]
2. See #1
3. Status: See #1.

1. Draft: It is correct that a WCAG Techniques document is needed for any format (defined by a content recommendation) that an authoring tool is including in its conformance profile. This document codifies the evaluators understanding of the generally stated requirements of WCAG with respect to the particular format. However, it is not the case that the WCAG Techniques document must be published by WCAG-GL or any other W3C working group. For the purposes of ATAG 2.0, the WCAG Techniques document that is referenced can be created by any person, company, etc., as long as it is published on-line. The intent is to ensure public scrutiny of the WCAG standard that any particular evaluator has set for themselves. The WCAG-GL and W3C working groups may of course choose to publish techniques documents, but this is not necessary. We do intend to clarify this concept by including a definition of "WCAG techniques document".
2. Draft
3. Draft

2.2 Ensure that the tool preserves all unrecognized markup and accessibility information during transformations and conversions. [Priority 2]

1. All transformations and conversions supported by the authoring tool must always meet both of the following conditions:
   (a) The author is notified before any unrecognized markup is permanently removed.
   (b) All accessibility information is handled according to at least one of the following:
      (i) Be preserved in the target format such that the information can be "round-tripped" (i.e. converted or transformed back into its original form) by the same authoring tool.
      (ii) Be preserved in some other way in the target format.
      (iii) Be removed only after the author has been notified and the content has been preserved in its original format

1. Bug1117/1196: In this success criteria, I don't see why the ATAG group would allow the author to be able to knowingly remove accessibility information (iii) and still be compliant with this checkpoint
2. Bug1196: Checkpoint 2.2 Since this Specification is so closely coupled with WCAG is it possible to find away to have Version 3.0 of each come out at the same time?

1. Status: No change reqd.
2. Status: No change reqd.

1. Draft: There are rich (HTML) and less rich (plain text) formats . The group does not wish to rule out transformations between them as long as the author knows what is happening.
2. Draft: That would be nice, but we can't make any promises.

2.3 Ensure that when the tool automatically generates content it conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

1. All markup and content that is automatically generated by the authoring tool (i.e. not authored "by hand") must always conform to WCAG.

1. Bug1196: Checkpoint 2.3 What priority is this checkpoint?
2. Bug1196: includes a Note that WCAG includes a validation requirement. While this is true, WCAG 2.0 allows for non-valid content if it improves the accessibility. BAF we should allow this exception too (not sure when invalid content turns out to be more accessible, but if that truly is the case...)
3. Bug1226: In checkpoint 2.3, what if information is required from the user? Can the pre-corrected markup be put in anyway?

1. Status: No change req'd
2. Status: No change req'd
3. JR Proposal:
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0007.html
   [1] Change success criteria text from: "All markup and content that is automatically generated by the authoring tool (i.e. not authored "by hand") must always conform to WCAG."
   TO: "All markup and content that is automatically generated by the authoring tool (i.e. not authored "by hand") must always conform to WCAG unless assisting or prompting (see Checkpoint 3.1) occurs immediately."
   BAF to make proposal:

1. Draft: It is a relative priority checkpoint that depends on WCAG to set the priority depending on the content in question.
2. Draft: Any exceptions left open by WCAG will carry over to ATAG's relative priority checkpoints, such as this one, so no explicit statement is required.
3. Draft

2.4 Ensure that all pre-authored content for the tool conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

1. Any Web content (e.g., templates, clip art, example pages, etc.) that is bundled with the authoring tool or preferentially licensed to the users of the authoring tool (i.e. provided for free or sold at a discount), must conform to WCAG when inserted.

1. Bug1118: expand (e.g. to include objects which represent web implementations for graphical widgets (menus, etc.).
2. Bug1190: Success Criteria -- concern: SW free or sold at a discount is often accompanied by disclaimers -- you get what you pay for. Such may not clearly identify any conformance. Metadata on it would help, particularly if the using author could learn of its content.
3. Bug1196: Checkpoint 2.4 – I would include that all samples/examples are accessible and conform to WCAG 2.0, What priority is this checkpoint?
4. Bug1196: same conformance to WCAG concerns. (JR i.e. is a WCAG techs doc req'd?)

1. Status: "graphical widgets"?
2. Status: Open issue: How good is the quality of alt text etc. written out of context - beyond that "Finished Goods" argument.
3. Status: No change reqd (3.8)
4. Status:

1. Draft
2. Draft
3. Draft: It is a relative priority checkpoint that depends on WCAG to set the priority depending on the content in question.
4. Draft

3.1 Prompt and assist the author to create content that conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

1. Every time that content is added or updated that requires accessibility information from the author in order to conform to WCAG, then the authoring tool must inform the author that this additional information is required (e.g. via input dialogs, interactive feedback, etc.).
2. Whenever the tool provides instructions to the author, either the instructions (if followed) must lead to the creation of Web content that conforms to WCAG, or the author must be informed that following the instructions would lead to Web content accessibility problems.

1. Bug1165: Success criteria for 3.2 and 3.3 to emphasize that only manual checking and repair is strictly required. (see also http://lists.w3.org/Archives/Public/w3c- wai-au/2005JanMar/0061.html)
2. Bug1196: I was happy to see this definition of prompt - I hate intrusive interfaces! Clarification of Term "Prompt":The term prompt in this checkpoint should not be interpreted as necessarily implying intrusive prompts, such as pop-up dialog boxes. Instead, ATAG 2.0 uses prompt in a wider sense, to mean any tool initiated process of eliciting author input (see definition of prompting for more information).
3. Bug1226: In checkpoint 3.1, success criteria 2 is confusing.

1. Status: JR
2. Status: JR
3. JR Proposal:
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0007.html
   [1] Change success criteria text from: "Whenever the tool provides instructions to the author, either the instructions (if followed) must lead to the creation of Web content that conforms to WCAG, or the author must be informed that following the instructions would lead to Web content accessibility problems."
   TO: "Any instructions provided by the tool, must either lead to the creation of Web content that conforms to WCAG (if followed), or be labelled with a warning that the instructions will lead to accessibility problems."

1. Draft
2. Draft
3. Draft

3.2 Check for and inform the author of accessibility problems. [Web Content Checkpoints Relative to WCAG]

1. The authoring tool must always provide a check (automated check, semi-automated check or manual check) for each applicable requirement to conform to WCAG.
2. The authoring tool must always inform the author of any failed check results prior to completion of authoring.

1. Bug1196: I disagree with success criteria 2: The authoring tool must always inform the author of any failed check results prior to completion of authoring. If the developer performs a manual check (as allowed by success criteria 1), I don't think the developer needs a reminder of failed results when exiting. I can live with this guideline but, to me, it verges on intrusive. BAF sort of agree, especially if the tool is not aware of the failures detected by the human in the manual check.
2. Bug1226: In checkpoint 3.2, does success criteria 2 require that a checker be launched automatically?

1. Status: (see proposal below)
2. JR Proposal:
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0007.html
   [1] Change success criteria text from: "The authoring tool must always inform the author of any failed check results prior to completion of authoring."
   TO (if we do NOT intend to require checking): "If an automated or semi-automated check has been performed by the authoring tool and the result is negative, the authoring tool must inform the author of the result prior to completion of authoring."
   OR: TO (if we do intend to require checking): "When automated or semi-automated checking is available, the authoring tool must either perform or offer to perform the checking prior to completion of authoring. If only manual checking is available, the authoring tool must have prompted the author to perform the checking prior to completion of authoring."

1. Draft
2. Draft

3.3 Assist authors in repairing accessibility problems. [Web Content Checkpoints Relative to WCAG]

1. The authoring tool must always provide a repair (automated repair, semi-automated repair or manual repair) for each applicable requirement to conform to WCAG.
2. For accessibility problems for which an authoring tool provides only manual repairs, the repair instructions must always be directly linked from the corresponding check.

1. Bug1196: - back to that JavaScript issue again..... It would be very difficult for an authoring tool to suggest alternatives for JavaScript which work with JavaScript turned off. In some cases to work without JavaScript might require additional pages to be created.
   BAF I agree that this means extra effort. IMHO extra pages is the most common way authors would compensate for disabled JavaScript and that the tool should go out of its way to make the user realize these extra pages are needed to compensate or that a redesign is needed..

1. Status: Reply needed

1. Draft

3.4 Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]

1. When the author inserts an unrecognized non-text object, the tool must never insert an automatically generated text equivalent (e.g. label generated from the file name).
2. When the author inserts a non-text object for which the tool has a previously authored equivalent alternatives (i.e. created by the author, tool designer, pre-authored content developer, etc.), but the function of the object is not known with certainty, the tool must always prompt the author to confirm insertion of the equivalent. However, where the function of the non-text object is known with certainty (e.g. "home button" on a navigation bar, etc.), the tool may automatically insert the equivalent.

3.5 Provide functionality for managing, editing, and reusing alternative equivalents. [Priority 3]

1. The authoring tool must always keep a record of alternative equivalents that the author inserts for particular non-text objects in a way that allows the text equivalent to be offered back to the author for modification and re-use if the same non-text object is reused.

1. Bug1119: This only addresses things like alternative text such that you could render the alternative text alone and that would be adequate for the content user. This guideline should be extended or a new guideline should be added to include ANY accessibility related meta data. This will include Role meta data in xhtml 2, XForms labels, XML event descriptions, upcoming state attributes from the WAI PF working group. The role is not considered an "alternative equivalent" as stated. Other information such as state data are required for things like check boxes. This has a WCAG 1.0 flavor and does not include new content being created which provides for improved semantics.
2. Bug1191: 3.5 ...reusing alternative equivalents - If the object is from a database, may need to add a field for possible alternative equivalents.
3. Bug1196: This only addresses things like alternative text such that you could render the alternative text alone and that would be adequate for the content user. This guideline should be extended or a new guideline should be added to include ANY accessibility related meta data. This will include Role meta data in xhtml 2, XForms labels, XML event descriptions, upcoming state attributes from the WAI PF working group. The role is not considered an "alternative equivalent" as stated. Other information such as state data are required for things like check boxes. This has a WCAG 1.0 flavor and does not include new content being created which provides for improved semantics. BAF again, I think we need to look into other newer WAI specs to understand the new types of "content" that may exist.

1. Status: reply: WCAG issue
2. Status:
3. Status:

1. Draft
2. Draft
3. Draft

3.6 Provide the author with a summary of accessibility status. [Priority 3]

1. The authoring tool must provide an option to view a list of all known accessibility problems (i.e. detected by automated check or identified by the author as part of a semi-automated or manual check) prior to completion of authoring.
   

3.7 Document all features of the tool that support the production of accessible content. [Priority 2]

1. All features that play a role in creating accessible content must be documented in the help system.

1. Bug1192: 3.7 ...alternates... should be alternatives. you don't mean every other!
2. Bug1226: In checkpoint 3.7, the success criteria could be interpretted as covering all functionality (in principle, almost anything can affect accessibility).

1. Status: JR
2. JR Proposal:
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0007.html
   [1] Change success criteria text from: "All features that play a role in creating accessible content must be documented in the help system."
   TO: "The help system must document all prompts for equivalent alternatives, as well as any accessibility checking and repair features."

1. Draft
2. Draft

3.8 Ensure that accessibility is modeled in all documentation and help, including examples. [Priority 3]

1. All examples of markup and screenshots of the authoring interface that appear in the documentation and help must model accessible Web content.

3.9 Provide a tutorial on the process of accessible authoring. [Priority 3]

1. A tutorial on accessible authoring for the specific authoring tool must be provided.

1. Bug1197: Guideline 4: "Promote and integrate accessibility solutions": Guidelines 4.1 - 4.4 are relatively easy to read and understand, but it is difficult to reconcile their description and meaning with the general introductory paragraphs for Guideline 4. The first sentence in particular is difficult to parse: "This guideline requires that authoring tools must promote accessible authoring practices within the tool as well as smoothly integrate any functions added to meet the other requirements in this document."

1. Status: KM

1. Draft

4.1 Ensure that the most accessible option for an authoring task is given priority. [Priority 2]

1. When the author has more than one markup implementation to choose from (e.g. the color of text can be changed with presentation markup or style sheets), those markup implementations that conform to WCAG must have equal or higher prominence than those markup implementations that do not meet the WCAG requirements.
2. Any choices of formats or authoring practices presented to the author (e.g., in menus, toolbars or dialogs) that will lead to the creation of content that does not conform to WCAG must be marked or labeled so that the author is aware of the consequences prior to making the choice.

4.2 Ensure that accessibility prompting, checking, repair functions, and documentation are always clearly available to the author. [Priority 2]

1. All accessibility prompting, checking, repair functions and documentation must meet the following conditions:
   (a) If they are continuously active, then they must always be enabled by default and if the author disables them (e.g. from a preferences screen), then the tool must always inform the author that this may introduce accessibility problems.
   (b) They must have at least the same prominence as the same type of function (i.e. prompting, checking, repair and documentation) related to other kinds of information (e.g. markup validity, program code syntax).

4.3. Ensure that sequential authoring processes integrate accessible authoring practices. [Priority 2]

1. Any feature that helps to sequence author actions (such as object insertion dialogs, design guides, templates, wizards, tutorials, or instruction text) must integrate relevant accessibility prompts. These prompts should occur before or at the time that the author is required to make the authoring decision related to the prompt.

1. Bug1195: 4.3 Success Criteria ?These prompts should occur before [what would be so prescient as to anticipate the author's intent?] I expect you mean the author's trying to initiate use of a feature that has accessibility consequence, such as insert image add alt="...", or create table -- add summary.
   Such examples might clarify your meaning. For some "at the time " seems more likely to be following what the author has done, at which time the accessibility consequences can be determined.

1. Status: JR

1. Draft

4.4 Ensure that accessibility prompting, checking, repair functions and documentation are configurable. [Priority 3]

1. The configurability of all functions related to accessibility prompting, checking, repair, and documentation must match the configurability of other prompting, checking, repair, and documentation functions of the tool (respectively), in terms of both of the following:
   (a) the number of options controllable by the author, and
   (b) the degree to which each option can be controlled

1. Bug1009: Perhaps Section 3 material should be moved to before the Guidelines, since it mentions priorities and a reader might want to know this material before accessing the Guidelines, and conformance is an important subject that should be "up front"
2. Bug1009: If an offering claims conformance to Level AA ATAG2.0 by immediately passing all the Level AA tests first, does it also conform by default to Level A (assumed to pass the Level A tests by default, as a way of saving testing effort and resources)? I assume not from Figure 1 in Section 3?, but this is not explicitly stated.. What constraints are there on the various levels (subdivisions)?
3. Bug1112: Strike reference to WCAG 1.0 checkpoint 6.3
4. Bug1121/1196: Again, for WCAG compliance priority levels it should be either WCAG 2.0 priorities or WCAG 1.0 or WCAG 2.0 for a given priority level (not both).
5. Bug1196: We also need to revisit the disabled JavaScript position. I think our position should be you can use JavaScript and depend on it (ie can't be turned off) but the result must be accessible. If not then alternate content is required. Some JS driven GUIs are just to complicated and interactive to expect alternate implementations (with similar appearance). Of course, all the functions of the site should be available in some form for all users, even if using different UI metaphors.
6. Bug1197: Priorities: We are wondering if it's unnecessarily complex. It is hard to understand what the consequences of the different categories of priorities are; it seems that it would help if these are linked back to the practical meaning. Alternatively, maybe this section is necessarily complex, but needs more of an introduction to the terminology before getting into the explanation. (For example, the graphic uses terms before they are introduced in the text, which is confusing.) Several people commented that the regular vs. relative terminology is helpful, and perhaps should even be used more, but should be defined earlier. We don't have specific a specific suggestion on how to rewrite the priorities section, but we'd like to offer to work with you on it.

1. Agreed 4 April 05 (1009): Section 3 material should be moved to before the Guidelines
2. Agreed 4 April 05 (1009): Add: Note: Conforming to a higher level (e.g. Double-"A") automatically entails conformance to a lower level (e.g. Single-"A") as well.
   JR Proposal(1009): Replacing the conformance scheme figure with: http://lists.w3.org/Archives/Public/w3c-wai-au/2005JanMar/att-0084/conformance.png
3. JR Proposal
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0004.html
   [3] re: Checkpoint 6.3 in WCAG 1.0, it would be difficult for the AUWG to second-guess the WCAG-GL on this point. Instead we will recommend using WCAG 2.0 when it is released.
4. JR Proposal(1121,1196):
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0004.html
   [2] ADD TEXT: "or, " to the end of each line beginning "WCAG 1.0: The " in section 3.1.2.
5. Status: See (#3)
6. Status:

1. Draft
2. Draft
3. Draft
4. Draft: ATAG 2.0 does not require conformance to both WCAG 1.0 and WCAG 2.0. Instead, the evaluator may choose EITHER WCAG 1.0 or 2.0, as explained in Section 1.4.1. http://www.w3.org/TR/ATAG20/#OtherDocs However, this is not very clear in the conformance section, so the following edit will be made:
5. Draft
6. Draft

1. Bug1164: Bundling clause should meet the requirements set out here (http://lists.w3.org/Archives/Public/w3c-wai-au/2005JanMar/0061.html) as well as the QA requirements. The terminology may need to be changed from "bundle" to "process".
2. Bug1194: 3.2.3 Conformance Where do you intend to make such claims? -- I suggest in metadata, and possibly as well in the document content.

1. JR Proposal:
   To move bundling into definition of authoring tool http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0005.html
2. Status:

1. Draft
2. Draft

1. Bug1198: The EOWG has set up a "Lexicon Task Force" that is developing a "Beginners' Lexicon for WAI Documents". This will be short lexicon with definitions in clear and simple language and contextualized to Web accessibility. The primary purpose of this beginners' lexicon is to assist translators of WAI documents, though it also may be helpful to people new to Web accessibility.

   The following definitions are ones where we would be likely to change them slightly or significantly from what is in the glossary section of your current draft, as shown below, when incorporating them in the Beginner's Lexicon for WAI Documents. We invite you to examine these definitions for two reasons: to see if you disagree with any of our re-statements of your definitions, and to consider whether any of the following definitions would be more suitable for use within the ATAG 2.0 glossary than the definitions currently present.

   More background on the Lexicon Task Force is available below [1].

   - Accessible Web content
   Accessible Web content is sufficiently free of accessibility problems to be usable by everyone regardless of disability or environment.

   - Attribute
   Information that explains, identifies or modifies an element in a markup language. Element types may have more than one attribute, like 'class', 'title', 'width' and 'height'. Some attributes are integral to the accessibility of content (for example, the 'alt', 'title', and 'longdesc' attributes in HTML)

   - Audio Descriptions
   Audio description (also called "Described Video") is an equivalent alternative that provides aural information about actions, body language, graphics, and scene changes in a video. Audio descriptions are commonly used by people who are blind or have low vision, although they may also be used as a low-bandwidth equivalent on the Web. An audio description is either a pre-recorded human voice or a synthesized voice (recorded or automatically generated in real time). The audio description must be synchronized with the auditory track of a video presentation, usually during natural pauses in the auditory track.

   - Authoring Tool
   Any software or service that is used to produce content for publishing on the Web. Authoring tools include Web content editors, document conversion tools, and software that generates Web content from databases.

   - Captions
   Captions are equivalent alternatives that consist of a text transcript of the auditory track of a movie (or other video presentation) and that is synchronized with the video and auditory tracks. Captions are generally rendered graphically. They benefit people who are deaf or hard-of-hearing, and anyone who cannot hear the audio (for example, someone in a noisy environment).

   - Conversion
   A conversion is a process that takes, as input, content in one format and produces, as output, content in another format (for example, "Save as HTML" functions).

   - Device independence
   The use of a webpage or event handler with any kind of input device. Scripting should be device-independent or provide multiple input and output options for different devices. For example, onDblClick requires a mouse; there is no keyboard equivalent for double clicking. Input devices may include pointing devices (such as the mouse), keyboards, Braille devices, head wands, microphones, and others.

   - Equivalent Alternative
   An equivalent alternative is content that is an acceptable substitute for other content that an end-user may not be able to access. An equivalent alternative fulfils essentially the same function or purpose as the original content upon presentation to the end-user. Equivalent alternatives include text alternatives, which present a text version of the information conveyed in non-text content such as graphics and audio clips. Equivalent alternatives also include "media alternatives", which present essential audio information visually (captions) and essential video information auditorily (audio descriptions).

   - Markup language
   A markup language is a syntax and/or set of rules to manage content and structure of a document or object (for example, HTML , SVG , or MathML).

   - Repairing, Accessibility
   Accessibility repairing is the process by which Web content accessibility problems that have been identified within Web content are resolved. ATAG 2.0 identifies three categories of repair: Automated (that is, the authoring tool is able to make repairs automatically, with no author input required), Semi-Automated (that is, the authoring tool can provide some automated assistance to the author in performing corrections, but the author's input is still required before the repair can be complete) and Manual (that is, the authoring tool provides the author with instructions for making the necessary correction, but does not automate the task in any substantial way).

   - Techniques
   Techniques are informative suggestions and examples for ways in which the success criteria of a checkpoint might be satisfied and implemented.

   - Transcript
   A transcript is an equivalent text alternative for the sounds, narration, and dialogue in an audio clip or an auditory track of a multimedia presentation. For a video, the transcript can also include the description of actions, body language, graphics, and scene changes of the visual track.

   - User Agent
   Software to access Web content, including desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software.

   [1] Info on EO Lexicon Task Force:
   - First draft of a Lexicon overview:
   http://www.w3.org/WAI/lexicon/Overview.html
   - Lexicon requirements document:
   http://www.w3.org/WAI/EO/changelogs/cl-lexicon
   - Lexicon Task Force Work Statement:
   http://www.w3.org/WAI/EO/2004/lexicon.html
   - Lexicon list archives:
   http://lists.w3.org/Archives/Public/public-wai-eo-lexicon

1. Status:

1. Draft

1. Bug1185: The pointer to the ATAG Glossary is broken. The ATAG References indicate some sources are unknown.
   Google finds:[WHAT-IS] "What is Accessible Software," James W. Thatcher, Ph.D., IBM, 1997. http://www.empowermentzone.com/acc_soft.txt
   [SUN-Design] Designing for Accessibility http://www.sun.com/access/developers/software.guides.html
   [SUN-HCI] " Towards Accessible Human-Computer Interaction," Eric Bergman, Earl Johnson, Sun Microsystems 1995. A substantial paper, with a valuable print bibliography. excerpt: http://www.sun.com/access/developers/updt.HCI.advance.html
   [This is available as an acm member-only paper in their archives.]

1. Status:

1. Draft

1. Bug1009: A list of changes from ATAG1.0 to ATAG2.0 needs to be included (probably as an appendix), as well as whether the specification allows extensions
2. Bug1009: Any deprecated features from ATAG1.0 to ATAG2.0 (see previous) need to be identified; if there are any, then ATAG2.0 needs to define how to handle them
3. Bug1193: The most significant is to identify and give samples of meta information that can identify the conformance claims and levels for the document.
   jargon: Pg 2 This document was produced under the 24 January 2002 _CPP_ ?what?
   Guideline 4 last paragraph ... seems to weaken the rest of the discussion ..." Moreover, the effectiveness of the solutions are perhaps better judged by the marketplace than by a set of stringent requirements."
   3.1.1 The longdesc ... with rows labeled _bottom up_

1. Status: A list of changes document is ready for final editing.
   JR Proposal:
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0003.html
   Add new section to the conformance scheme: Extensions: ATAG 2.0 does not limit the creative development of authoring tool functionality. A conforming authoring tool may have any range of features as long as all of the features have been implemented with accessible authoring interfaces and the required accessibility-related functionality is present.
2. Proposal (1009):
   http://lists.w3.org/Archives/Public/w3c-wai-au/2005AprJun/0003.html
   Add new section to the conformance scheme: Deprecated Requirements: Some functionality is required to conform to ATAG 1.0, but not to ATAG 2.0. The only truly deprecated requirements in ATAG 2.0 are those inherited by changes between WCAG 1.0 and WCAG 2.0 (currently still a draft). For these changes see [WCAG deprecated requirements list?].
3. Status:

1. Draft
2. Draft
3. Draft