DRAFT Responses to Comments on
ATAG 2.0 (7 December 2006) Public Draft:

1. BG: I like the organization of the requirements into parts A and B to address the user interface and the generated content.
2. BG: It is nice to see the same definitions of terms shared with WCAG
3. BG: Nice section on providing prompting! I was nervous when I first read the SC that said prompting was required (I really hate overly restrictive prompting) but the techniques document helps to clarify.
4. BC: The section "How the guidelines are organized" does a nice job of describing which sections and subsections of a guidelines are informative vs. normative. It might be useful to incorporate something similar in the WCAG 2.0 intro.

1. BG: I have some concerns about the use of examples in parentheses within the Success Criterion (SC) text. While it is helpful to understand what the SC is about, I think it sometimes narrows the definition.
2. LGR: Is WCAG still planning to publish Technique documents for specific content types? ATAG has links to what I think are obsolete techniques documents.
3. BC: (bug) All of the icons used in part A and B of the draft implementation techniques documents include relative links to nonexistent anchors.
4. MC: General: hard to tell normative from informative sections. I’ve seen a bit of “this section is normative” and “this section is informative” but not on every section.
5. MC: Priorities: It appears that priority is at the Guideline level, not the Success Criterion level. There were some success criteria that I felt should be at a different priority than the guideline. While I recognize that it would be quite a structural change to accommodate this, I will call out those suggestions in my review in order to explain the rationale on the individual cases.

1. JR: Agreed that this might be a problem, but as you say, it does help to clarify the meaning of the Success Criteria.

1. BC: Suggest moving the section "How the guidelines are organized" to a location earlier in the document. Knowing about Part A and Part B seems important to understanding much of what is in conformance (ex. relative vs. regular priority).
2. MC: First sentence says “Authoring Tool Accessibility Guidelines (WCAG)”: correct acronym

1. MC: Simplify definition. The main thing that gets in the way is the clause that begins “where a collection of software components”; suggest moving everything from there to end of sentence to a definition for “collection of software components” and link to it in the beginning part of the definition, as is already done for “author” and “web content”. If this suggestion is not taken, a serious rewording needs to be done.

1. MC: Third real para “consider that the authors…may be using the tool…in contexts that are very different from…typical”. Add a sentence to the effect of “also consider that authors may not be familiar with the specific needs of people with disabilities and require support from the authoring tool to fill the knowledge gap.

1. BC: Would removing the distinction between relative priority and regular priority checkpoints make conformance easier to understand? Given that there's no difference in a conformance claim (A, AA, and AAA the same thing regardless of checkpoint priority), I'm not sure it's necessary to make a distincition here. I found myself spending a lot of time trying to understand the difference between the two as I worked through the intro, but it seems like this is covered through requirements for conformance claims and sufficient techniques for the relative checkpoints.
2. MC: 2.1 Switch the order of the subsections “Conformance Levels and “Checkpoint Priorities”. I found that reading the first depended on an understanding of the second, so it would read better to put the second first.

1. LGR: ATAG conformance appears to be user agent based, not technology based; conformance claims for web-based functionality must list the name and versions of user agents tested against. Oddly enough, for non-web-based functionality, comparable info is required for the OS, and the accessibility API must be listed, but there seems to be no requirement to test against AT.
2. LGR: An ATAG conformance claim includes documenting how each SC was satisfied! I don't think we are going to see many ATAG conformance claims written up...
3. MC: 2.2 - conditions: 1) Why is it required that a conformance claim be published on the Web? There could be many reasons an organization would want to follow the mechanics of making a conformance claim, but not actually publish it for all the world to see. 2) Remove clause “…W3C does not act as an assuring party <del>but it may do so in the future, or it may establish recommendations for assuring parties</del>”. I don’t think we should be saying anything about this as it’s too speculative.

• Content Type-Specific WCAG Benchmark

1. BG: I have concerns with reliance on the "content-type-specific WCAG benchmark document" in the checkpoint and success criteria text. Since the definition indicates that the WCAG techniques document for a particular content -type meet this requirement. But, the WCAG techniques are informative and there are not necessarily techniques for every WCAG success criteria for every content-type. Where would the general WCAG techniques fit in? There are many HTML techniques but many fewer for CSS and scripting. What if someone creates a tool that uses ARIA (Accessible Rich Internet Applications from the WAI Protocols and formats group) techniques when creating content? There are currently very few WCAG scripting techniques to support ARIA. Since there are some techniques is there a sufficient content-type-specific WCAG benchmark document"? I think this needs further description / clarification. Also, currently WCAG does not publish the techniques for different content-types in separate documents.
2. LGR: "ATAG 2.0 requires published content type-specific WCAG benchmark documents" - this seems worrisome. Who publishes these?
3. LGR: ATAG makes WCAG techniques normative for a particular conformance claim. Given that we view those documents as non-normative, and that they will change over time, this seems problematic.
4. BC: I have a number of concerns about the content type-specific WCAG benchmark:
   a.) Who publishes benchmark documents? This is a major coordination point between the working groups that needs discussion.
   b.) Since WCAG 2.0 techniques say nothing about conformance to WCAG itself, the benchmark document should refer to some combination of the How to Meet and techniques documents. Not sure his model works unless the benchmark specifies sufficient techniques or combinations of techniques that meet WCAG 2.0. Has the ATAG WG created any sample benchmark documentations to illustrate how this might work?
   c.) All of the references to WCAG 2.0 techniques documents ([WCAG20-TECHS-GENERAL], [WCAG20-TECHS-CSS], [WCAG20-TECHS-HTML], [WCAG20-TECHS-SCRIPTING]) should refer to http://www.w3.org/TR/WCAG20-TECHS/ (the WG is no longer publishing tech-specific techniques documents)
   d.) "All of the requirements in the Benchmark become normative..." This implies that a benchmark document can define conformance to WCAG 2.0, but it's not clear how a benchmark document would address (1) situations in WCAG 2.0 How to meet docuements and (2) situations where multiple sufficient techniques or combinations of techniques meet a criterion. The concern here is that it sounds like a benchmark can include only a subset of the WCAG 2.0 sufficient techniques and then be used to define (by example) WCAG 2.0 conformance.
5. MC: 2.2 – Content Type-Specific WCAG Benchmark: 1) I think this should be prior to the “Components of an ATAG … Claim”, again because of forward references that would be easier to understand if we encountered this first. 2) “The Benchmark document is just the WCAG Techniques document when one exists for a content type” should not be a requirement (which is how I read it now), merely a recommendation. WCAG techniques are non normative, and other organizations are free to create better techniques, or to add to the WCAG techniques. Since the techniques essentially become normative by being absorbed into ATAG conformance requirements, it’s especially important to preserve the integrity of the intention to allow other organizations to create techniques. The second bullet “Benchmark can be created by any person or organization” appears to acknowledge this, but I wasn’t clear what that mean with respect to the statement earlier. 3) I think the WCAG 2.0 reference should be moved out to an external support document. The techniques are already not organized in the way indicated here, and their organization will probably change again.

1. JR: The "content-type-specific WCAG benchmark document" idea is specifically intended to deal with the problems you point out: (1) WCAG techniques documents being informative rather than normative, (2) WAI creating techniques documents for only a few formats (and not always as separated docs as yous say), (3) New formats being created all the time. To that end: (1) ANYONE can create a benchmark document (so an authoring tool developer doesn't have to wait for WAI), and (2) an informative techniques document BECOMES normative for a GIVEN conformance claim by the act of including a reference to the techniques document in the conformance profile of that conformance claim. We can work on clarifying this in the document.

1. BG: I'm not sure how A.0.1 fits into the organizational scheme? From reading above about how the guidelines are organized it implies that checkpoints are associated with Guidelines? But A.0.1 is not associated with a Guideline - is that the point of using a A.0 designation? I originally just assumed that you were using a zero based numbering scheme but then I scrolled down and noticed that Part B begins with a Guideline and the numbering starts at B.1. I think that the positioning of A.0.1 needs to be clarified.
2. LGR: I'm a bit confused by A.0.1. Even with the rationale and note, it took me a while to sort out that this only applies to aspects of the tool that are displayed on the web. For non-web-based authoring tools, this is probably nothing. For web-based authoring tools, they are web content; I guess this just says that web content needs to conform to WCAG.
3. BC: A.0.1 SC1 seems like it should mention content rather than just functionality. (ex. Content that includes Web-based authoring tool user interface functionality must conform to WCAG.) WCAG 2.0's use of "functionality" (def. processes and outcomes achievable through user action) may be part of what's confusing about this.
4. A.0.1: not sure why this is a separate guideline. It seems awkward to have everything fit into a described numbering scheme, and then have this one outside. Makes it easily overlooked, yet it’s one of the most core guidelines for Web-based authoring tools.

1. JR: The problem is that this requirement actually cuts across all of the sub-sections of Part A.

A.1.1 For the authoring tool user interface, provide text alternatives for all non-text objects. [Priority 1]

1. LGR: A.1.1, SC 3 has an ambiguity: I first read it to say that text alternatives must be displayed in the content being edited, but I think it means to says that that there must be a way to display all text alternatives (and that text alternatives are required for non-text objects in the content). Similarly for A.1.2 SC 2. I'm not sure whether it would be clearer to paraphrase: "All editing views must include an option to display the text alternatives provided for non-text objects in the content being edited."
2. LGR: Why does A.1.1 SC 2 address multimedia? Shouldn't that be an A.1.2 SC?

1. BG: For A.1.3 shouldn't there be a requirement that the authoring tool provides a mechanism to use the operating system display /audio selections (let the platform control the settings)? The requirement is there that the user must be able to select the same settings in the tool but it would be nice to have an option for automatically using the platform settings This would avoid users having to modify the tool to match the operating system display settings. I see that this is covered in the technique section. Perhaps it is standard practice in most operating systems to rely on the platform settings as the default settings that the ATAG group doesn't feel this needs to be made a requirement?
2. AL: A.1.3 SC1--"...authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform." I don't think that can be confirmed one way or the other unless the method of configuration between the authoring tool and the platform are exactly the same. They are usually not the same. That’s goes the same with audio for part 2. You should also consider that authoring tools can provide additional configuration option "on-top-of" the platform. Thus, the authoring tools may extend the configuation options, even though its range may appear lesser than that of the platform.
3. LGR: I'm worried that satisfying WCAG does not satisfy UAAG, and that WCAG relies on UAAG requirements to make effective use of programmatically determined properties of the content. In this case, the authoring tool is the user agent for this web content, I think. This seems related to A.1.3, but I haven't worked out how. In particular, I don't think that satisfying A.0.1 for web-based authoring tools will necessarily meet this checkpoint, depending on the characteristics of the user agent.

1. JR: We actually meant for this to be the case. I suggest making this more clear by adding two nes SCs as follows:
   • NEW SC1: Use the visual display settings of the platform.
   • NEW SC2: Use the audiuo display seetings of the platform.
   • SC3: If the visual display (e.g., fonts, sizes, colors, spacing, positioning) is controlled by the authoring tool rather than by the platform, then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform.
   • SC4: If the audio display (e.g., volume, speech voices) is controlled by the authoring tool rather than by the platform, then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform.
   • SC5: Editing views that have their display characteristics set by rendering the content being edited (e.g., WYSWYG editing views) must override these characteristics if the author explicitly sets visual or audio display preferences as described in the previous two success criteria.
   • SC6: Any visual or audio display settings must be saved between authoring sessions.
2. JR: Maybe we could go back to being more specific. Maybe rewording as:
   • SC: The authoring tool must allow the author to specify font family, text scale, foreground color, background color, magnification (e.g. for garphics and spacing between text) by one of the following methods: (1) inherit these settings from the platform, or (2) include these settings within the authoring tool's own preferences with the same configurability range as the platform.

1. BG: A.1.5 - I'm not sure what a "semantic description" is. There is an example in SC 3 but an example for SC 2 would also be helpful - what is a semantic description of coloring misspelled words?
2. LGR: A.1.5 SC 3 "the semantic description of the presentation" probably wants to be "the semantic description of the information encoded in the presentation". And given our WCAG discussions, I'm not sure this is always possible, at least for web-based authoring tools.
3. LGR: It also seems as if A.1.5 SC 3 and SC 4 should be combined; color is just authoring tool-controlled presentation. Is SC 4 additional requirements on the use of color? Is color the only form of presentation that can be satisfied by an alternate version (per (b))?

1. JR: Agreed. I suggest:
   • changing "semantic description" to "description of the function". So for coloring mispelled words it might be: "this word is mispelled".

1. BG: A.2.1 - should there be something about supporting platform accessibility options for keyboard access (sticky keys and such?).
2. BG: SC 4 is setting a very high bar for web-based authoring tools. For example, I'm not sure how I would implement going to the beginning / end of content within a rich text editor component on the web Undo/redo is also particularly difficult on the Web. I'm not disagreeing that this should be a requirement but it does make it highly unlikely that a web based authoring tool would ever achieve compliance with ATAG (at least in the near future on more than one user agent).
3. BG: SC 5 may be particularly difficult for Web based authoring tools. I guess if they don't provide any additional, selectable keyboard functionality then there is no need to save the preferences.
4. AL: A.2.1 Should add an exception for analog, time-dependent input as in WCAG 2.0 2.1.1
5. AL: A.2.1 Success Criteria 5 is a convenient feature, but should not be priority 1. As long as user/author can use keyboard to activate the settings, it is accessible.
6. LGR: A.2.1 SC 1 is task based! I'm not sure I see a definition of task or authoring task.
7. MC: A.2.1: SC 6 says “the current keyboard settings…” does this mean “<ins>Documentation about</ins> the current keyboard settings”? If so, insert that; if not I didn’t understand the SC.

1. JR: Agreed. Maybe we need a new SC like:
   • NEW SC: Do not interfere with keyboard accessibility features of the platform (e.g. StickyKeys, SlowKeys, )
2. JR: SC4 does say "(if present)" but perhaps this would be more clear if it were broken into two SC's, one for the must have features and one for maybe haves:
   • SC4: The author must have the option to enable key-plus-modifier-key (or single-key) access to both of the following functionalities:
     • (a) move content focus to the previous enabled control (e.g., using "shift-tab" key),
     • (b) navigate between all panels or windows,
   • NEW SC5: If any of the following functionalities is implemented by the authoring tool, the author must have the option to enable key-plus-modifier-key (or single-key) access to them:
     • (a) open help system,
     • (b) open new content,
     • (c) open existing content,
     • (d) save content,
     • (e) cut/copy/paste,
     • (f) undo/redo, and
     • (g) open find/replace function.
3. JR: This is meant for systems in which the user can change keyboard mappings. I suggest clarifying:
   • SC5: "If the author has the option to modify the keyboard operability settings, any modifications must be saved between authoring sessions."
4. JR: Good idea to look at "analog, time-dependent input".
5. JR: I don't think I agree - if you set up different control keys etc. I would expect them to be saved.

1. LGR: A.2.2 - (a) do any applications let authors control the order of menu items in menus? (b) what does "available" mean in this context? Would keyboard shortcuts stop working if items weren't available? Does disabling an item count? Or removing it from the visible UI?

1. AL: A.2.3 Success Criteria 1.  The SC statement draw out a condition of what is needed when time limit is not controlled by time-sensitive external constraints.  But it says nothing about conditions where the time limit is controlled by external constraints.  How are the authoring tools, or more appropriately the authoring environments, where time contraints are controlled by external contraints to fulfill this priority 1 requirement?  You need to make an explicit exception statement here or have instruction of what needs to be done.  As you should know, almost all commercial products are made in collaborative environments where such external time contraints are essential.
2. A.2.3: This sounds very much like WCAG SC 2.2.1; note this has gone through some morphing and may need to be reharmonized.

1. JR: Maybe we need a new SC dealing with this since clearly connect time-outsare different from the actions of collabrative authors.

1. BG: A.2.4 SC 1a - the author must be able to disable the flashing before it occurs. This technique does not seem sufficient: Technique A.2.4-1.1 [Sufficient for (a)]: If flashing begins, providing a single input action that stops the flashing immediately and for at least the rest of the session.
2. BG: What if the flashing generates a seizure before the user can perform the single input action? How would the user know what the single input action is? I think a more appropriate technique would to warn the user of flashing content and provide a mechanism to disable it before it begins.

1. JR: Maybe the trouble is the checkpoint, see below.
2. JR: Agreed. I suggest separate rules for the tool and the content the tool may render:
   • NEW SC1: The editing interface must not include visual elements that violates international health and safety standards for general flash or red flash.
   • NEW SC2: If an editing view renders content that violates international health and safety standards for general flash or red flash, then at least one of the following must be true:
     • (a) the rendering of any such content can be frozen to prevent any flashing, or
     • (b) the rate of flashing must be adjustable so that it no longer violates those safety standards.

1. BG: I don't understand this technique: Technique A.2.5-1.3 [Advisory]: If loops are possible within the structured element set, providing a mechanism for alerting the author when they have completed a loop. An example would be helpful.
2. AL: A.2.5 That is a usability feature.  It impacts people without disabilities just as much.  It should be removed.

1. JR: Agreed:
   • This refers to the (rare) case in which structured information may have loops (e.g. a node is both parent and child to another node. We will try to clarify with an example.
2. JR: So is search but it is in ATAG because it is additionally important to users with certain disabilities. If we take it out, and a tool doesn't do it, we have no way of saying there is an accessibility problem.

1. AL: A.2.6 search funtionality is too specific. There may be other mode to locate things.

1. JR: There may be others, but we require these.

1. AL: A.2.7 Not all functions can be "undoed", especially operations such as file save, delete, and most collaborative funcationalities. Explicit exception is needed.
2. A.2.7: Success Criterion 1 (undo function) should be Priority 1. Undo is high priority though I can agree the rest of this is P2.

1. JR: We do talk about "reversible actions" - maybe we should define this term.

1. A.2.9: Success Criterion 1 (get out of preview) also needs to be Priority 1. Tool breaks if you can’t.

1. AL: A.3.1 where the term "observe" is not specific enough.
2. A.3.1: Success Criterion 1 seems like it would make more sense as a SC of A.2.1. SC 2 should be a SC of A.2.2. They lose context here as a separate guideline.

1. JR: Follow? Implement?

1. AL: A.3.2 does not appear testable.

1. JR: Why not?

1. BG: A.3.3 SC1 - Why must a non-web based authoring tool provide web based documentation? Just because the tool creates Web content, I don't see why it must provide documentation in a Web based form. The SC does say that it doesn't have to be located on-line but if it must conform to WCAG then it would have to be Web content. This seems too restrictive. A non-web based authoring tool should be able to provide accessible non-web based documentation. I am guessing that this is mandated in order to have a guideline to judge the accessibility of the documentation against but I think conforming to Part A of ATAG would be sufficient.
2. LGR: A.3.3 SC 1: while I can see why it is stated this way, it feels like the appeal to WCAG might disqualify something like the use of a Word document or OS-specific documentation format that is accessible on that platform, but not on the web.

1. JR: Yes, we did want to use WCAG as the test standard (UAAG 1.0 does the same). How about adding plain text as a compromise option?

1. BG: A.4.1 SC 2 is very confusing. Even after looking at the techniques I have no idea what I am supposed to "publish"? It sounds like, as an authoring tool author, I am supposed to document how I implemented the accessibility API. Part A seems to require that I document what level of accessibility api I have implemented. Part B seems to just be asking me to implement the accessibility API for each element which can receive focus. And Part C is again asking the author to document the level of support for the accessibility API. The techniques for this didn't help clarify as it is just, " Implementing the relevant accessibility platform architecture(s), such as:", and is incomplete. A.4.1 SC2 really seems to fall under A.4.2 ?
2. AL: A.4.1 There are more way to make applications accessible to AT than the like of MSAA. MSAA and UIA are not capable of meeting all needs from author tool makers. Implementing only MSAA almost gurantee some functionalities will fail in some cases. If the rest of the requirements are met and it works with AT, why do you care how we do it from an architecture standpoint? This is far too prescriptive to be priority 1. Also, this requirement manipulates market dynamics between platform providers, ISPs, AT vendors. That is a bad idea.
3. LGR: A.4.1 SC 2 seems confusing to me. Is it just requiring that the accessibility API support be documented for AT developers? Actually, I don't understand the distinction between A.4.1 and A.4.2.
4. A.4.1: Success Criterion 2, bullet 2 seems elaborate, difficult, and not of significant value to the user. As I read it, every little control of the UI has to be listed in the documentation with fairly complete information about accessibility properties. I think if those properties are properly set, they won’t need to be documented. If the control needs to be documented, there’s something else wrong. Strongly recommend removing this. This is useful for evaluators, but I don’t see that there’s really evaluator-targeted guidelines other than this, so it sticks out.

1. JR: You're right that A.4.1 SC2 might fit well under A.4.2.
2. JR: Would like to discuss this more.

1. AL: Part B in general--Due to potential legal risk associated with WCAG comformance, I don't think you will find too many commercial authoring tool makers who would that say within the tool itself that doing XYZ with a particular authoring tool would qurantee WCAG compliance content. This may be the case, even if the tool technically meets part B requirements. There is too much legal risk to make claims of fulfillment for part B.

1. JR: Well, technically, they aren't guaranteeing they always produce something that meets WCAG 2.0 for example. Instead they are saying they meet a Benchmark document (that they can write) that is based on WCAG techniques.

1. BG: Checkpoints B.1.4 and B.1.5 seem almost impossible to achieve. The note / exception about requiring accessibility information from the author helps. I can live with these but they will be very difficult to meet in non-web based tools and virtually impossible in web-based tools (although Web based tools will meet this by not implementing automatic generation).
2. B.1.4: I’m thinking of Flash when I try to understand “authored by hand”. Flash content isn’t exactly automatically generated, as you get pretty close control over what appears (in contrast to WYSIWYG HTML authoring tools, where you could get elaborate table or nested div structures automatically generated with just a couple authoring steps). However, Flash is most certainly not authorable by hand in the way HTML is, the author has no option to edit the code. So where does it fit with respect to this guideline? I can’t answer that, and therefore can’t determine applicability and conformance of this. I think it needs a fairly substantial rework to take into account the capabilities and possible authoring styles of different content types.

1. JR: It won't be easy, but here's how I see it:
   • A developer needs to start with a finite set of techniques (some machine verifiable, some author verifiable) for making content in a particular format accessible has been decided upon (that's what the benchmark document lists). Without such a finite list checking and repair is impossible.
   • Then it's a matter of deciding when the techniques will be applied (i.e. at the start or at the end) and by which actor (i.e. the automated processes, the author or a little of both).
   • B.1.4 says that automated processes shouldn't be allowed to ignore accessibility techniques entirely (they must do what they can, and enlist the author's input for things they can't - it's up to the developer to decide on the balance.)
   • If B.1.4 weren't there, the automated processes could spit out piles of problems that the author would have to clean up after the fact (e.g. by hand or using a checker). And I think it's fair to say that people don't like cleaning up after software, so it's unlikely to get done.
   • NOTE: I do see how some things aren't a problem until sometime after they are produced. For example, a navigation bar isn't inconsistent until another one has been created that's different. Maybe this is more likely for less HTML-like formats (JSP, JSK, PHP, etc.)

1. BG: Example B.1.5.1.4 doesn't seem realistic. There may be cases where the alt text can not be determined until the image is used.
2. BG: Not exactly sure what this is trying to say - there are extra words or tense issues: Technique B.1.5-1.4 [Advisory]: Ensuring that equivalent alternatives provided for pre-authored content are usable compatible with features to manage, editing, and reusing equivalent alternatives.
3. MC: B.1.5: Suggest adding that content designed exclusively for the Authoring Tool be included in the set of content that must conform. E.g., templates, clip art, etc., that is not bundled with the tool, and is not preferentially licensed to users of the tool, but only works with the tool, would slip through the cracks. It may be there needs to be an exception that this only applies to content produced by the authoring tool manufacturer, but I also suggest that instead it should be a requirement that it not be possible to create content samples that work only with one authoring tool (and are probably only creatable using that authoring tool) and don’t meet WCAG.

1. JR: Although context is very important - generic labels would seem to be possible. In the context of use, if they don't make sense the user can change them. If they don't, it will impact accessibility, but perhaps not quite as much as no label at all.
2. JR: Agreed. Rewording:
   • "Ensuring that equivalent alternatives provided for pre-authored content are usable by features to manage, editing, and reusing equivalent alternatives (see Checkpoint B.2.5).

1. BG: B.2.1 SC 2 item B - I think you mean, "inform the author that NOT following the instructions would lead to Web content accessibility problems." I added the word "NOT" in front of the word "following".

1. JR: No - it's actually worded correctly - since if (a) is not done, it is the instructions that are the problem. I do suggest rewording:
   • SC2: Instructions provided to the author by the authoring tool must meet one of the following:
     • (a) be accessible, such that if followowed by the author, result in content that conforms to WCAG, or
     • (b) be inaccessible, but include a prominent explanation that Web content accessibility problems will result from following the instructions.

B.2.2 Check for and inform the author of accessibility problems. [Relative Priority]

1. BG: Regarding: B.2.2 SC 1: An individual check must be associated with each requirement in the content type-specific WCAG benchmark document (i.e., not blanket statements such as "does the content meet all the requirements"). The content type specific WCAG benchmark has been defined as a WCAG techniques document - the techniques documents are not requirements so this SC doesn't make sense. I think this revolves around my confusion of what exactly is a content-type-specific WCAG benchmark document?
2. BG: Must an authoring tool provide its own accessibility checking? I think it should be allowed to work with a separate tool. Also, when content is auto-generated from server side languages, it is often very difficult for the tool to test for accessibility problems. If I can create a page using JSP, is the tool that allows me to enter the JSP tag required to interpret the tag code and know that it will be inserting an image and that there is no alt text? This entire checkpoint seems overly restrictive as currently worded. This is fine for simple HTML generation tools but becomes much more complicated for more advanced tools that use JSP, JSF, PHP, etc.
3. BG: This example of automated checking doesn't appear to meet the ATAG guidelines since information is conveyed using color. You may want to include a statement that the accessibility problems can also be determined in some other manner in addition to just the blue font. Example of Automated Checking (3): This illustration shows an authoring interface of an automated check in a code-level authoring view. The text is: "<body><p>Image:</p><img href="pic123.gif"/><hr/><blink>Blinking text</blink></body></html>".In this view, the text of elements with accessibility problems (img and blink) is shown in a blue font, instead of the default black font. (Source: mockup by AUWG)
4. AL: B.2.2 So, everytime we have non-text-content, the author tool as to explain to the user/author how to meet 1.1.1 in WCAG 2.0? That seems like a lot to ask for an authoring tool to handle something objective like this.

1. JR: The "content-type-specific WCAG benchmark document" IS made normative by the act of including a reference to it in the ATAG conformance profile. (see above for more discussion of the benchmark documents)
2. JR: ATAG 2.0 does allow the authoring tool to rely on a third-party tool to do the checking and repair and simply include it in a conformance claim. I would like to talk more about the JSP example.
3. JR: Agreed. I suggest adding the following note:
   • Note: Since color should not be used as the sole means of conveying information, an additional means of accessing the information should be provided (e.g. a checking wizard, a keyboard shortcut that moves focus to the next problem, etc.)
4. JR: It depends on how smart the tool wants to be about it. The tool can handle purely decorative non-text content without asking the user at all, some alternatives can be pulled from other sources (B.2.4), and special-purpose UI's can be built to make adding ALT easier.

1. AL: B.2.4 Why do we need this if we already have B.2.2 (both seem overly demanding)?
2. B.2.4: This doesn’t seem to add anything that would not be required under B.2.1 (make sure content conforms to WCAG) and therefore I suggest it should be removed. SC 1 about suggesting text alternatives out of image databases etc. should be techniques of B.2.1. SC 2 should be made more generic – authors must be able to accept, modify, or reject *any* tool-suggested accessibility properties.

1. JR: Because it is important that tools don't try to make up their own alt text - e.g. from file names etc..

B.2.5 Provide functionality for managing, editing, and reusing equivalent alternatives. [Priority 3]

1. BG: B.3.1 SC 1 is confusing: "When the author has more than one authoring option for a given task (e.g., emphasizing text using semantic markup rather than inappropriately using header markup), then any options that conform to WCAG must have equal or higher prominence than any options that do not. " Header markup is semantic markup so I think this needs clarification.
2. B.3.1: I’m concerned that SC 2 is difficult to verify. There are many choices authors can make that lead to content not conforming to WCAG. Sometimes the tool can know for sure that will be the case (e.g., going out of the way to omit an alt attribute), other times it might suspect a problem (the author puts in a the image file name as alt text), and other times it might not really be able to tell (the author puts “Search Engine Optimization” spam into the alt text). I would either remove this SC as untestable, or add a clause that “Any choices of content types or authoring option presented to the author…that <ins>the authoring tool determines will or may</ins> lead to the creation of content that does not conform to WCAG…”.

1. JR: Agreed. I suggest this clarification:
   • SC1: When authoring tool provides more than one option for accomplishing the same authoring task (e.g., making text "bold"), then any options that conform to WCAG must have equal or higher prominence than any that do not.

1. B.3.4: SC 1 and 3 need to be higher priority than P3, I think P1 for both. Without SC 3, you could break the accessible functions of the tool on your first day (kinda like opening a Christmas present and immediately snapping off that crucial piece). Without SC 1, for most users the tool might as well not have bothered to conform to ATAG at all as they’ll never discover and turn on the “author accessible content” option.

1. LGR: Glossary: "accessibility problem, Web content A Web content accessibility problem is an aspect of Web content that fails to meet some requirement of WCAG. The severity of a given problem is relative and is determined by reference to WCAG"
   
   This reflects the misunderstanding of WCAG 2 conformance levels as correlated to levels of accessibility. It may be appropriate for WCAG 1 conformance levels.
   
2. LGR: "content type A content type is a data format, programming or markup language that is intended to be retrieved and rendered by a user agent (e.g., HTML, CSS, SVG, PNG, PDF, Flash, JavaScript or combinations). The usage of the term is a subset of WCAG 2.0's [WCAG20] current usage of the term "Technology"."
   
   How is it only a subset? What is excluded?
   
3. BC: While some terms common to ATAG 2.0 and WCAG 2.0 are defined the same way, it seems that others are not. (ex ATAG "equivalent alternative" seems to be the same as WCAG "alternative version") It would be a good idea for the documents to agree on definitions where possible. Note that some WCAG definitions have changed since our last TR draft based on public comments and ATAG definitions may need to be updated accordingly. Also, some definitions (ex. red and general flash threshold may still change based on WCAG 2.0 comments.)