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.

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.

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

• 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.

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.

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. 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?

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.

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?

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. 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. 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.

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."

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. 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.

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.

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.

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 ?

1. JR: You're right that A.4.1 SC2 might fit well under A.4.2.

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).

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

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)

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.)

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.

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.