Response to ATAG 2.0 Public Draft (and Editor's Draft) Comments:

1. [17] B.2.1 - B.2.3 General issue if you make use of tool by PwD P1 and you make authoring content for PwD something less (say RP).   Some audiences may choose to make authoring more critical than use by PwD.

1. [PROPOSED RESPONSE]
   I'm not sure that I understand the reasoning here. RP can be read as "P1 for Level 1 Success Criteria in WCAG 2.0". So the "lowest" level of overall ATAG conformance does in fact mean doing all of the P1 things for authors with disabilities AND all of the Relative Priority things (checking, repair, etc.) for the most important WCAG items.

1. [3] Some people still don't understand how the Relative Priority items are calculated.  "Some are clear, while others could be issues for meeting ATAG compliance.  For example, can you give a better explanation of how a specific checkpoint like B.2.2. will apply to tools if we say all tools must meet all ATAG P1 guidelines while conforming to WCAG 2.0 and not WCAG 1.0."
   [16] B.1.4 Need to better explain relative priority.

1. http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0025.html
   [PROPOSED CHANGE]
   2.1.2 Checkpoint Priorities
   
   Each checkpoint has been assigned a priority level that indicates its importance and determines whether that checkpoint must be met in order for an authoring tool to achieve a particular conformance level. There are three levels of "regular priority" checkpoints as well as a special class of "relative priority" checkpoints.
   
   "Regular Priority" Checkpoints:
   
   The priority of the "regular priority" checkpoints is pre-set and does not depend on the *Content Type-Specific WCAG Benchmark* document. *Note: Because Part A and B of the guidelines refer to different areas (i.e. the accessibility of the authoring interface versus supporting the production of accessible content), the wording of priority levels is slightly different for each part*:
   ...
   "Relative Priority" Checkpoints
   
   "Relative Priority" Checkpoints exist in ATAG 2.0 to provide authoring tool developers with the flexibility to address Web content accessibility issues with higher priorities, as defined by WCAG, before lower priority issues. It is left up to the evaluator to decide which version of WCAG to use in their own *conformance claim* (version 1.0 [WCAG10] or version [WCAG20] @@assuming this becomes a rec@@). These checkpoints can be met to one of three levels, according to level of WCAG that has been met in each instance. *Note: Because Part A and B of the guidelines refer to different areas (i.e. the accessibility of the authoring interface versus supporting the production of accessible content), the wording of priority levels is slightly different for each part*:
   
   SUGGESTED REWORDING IN 1.5.1:
   " ATAG 2.0 depends on WCAG to act as a benchmark for judging the accessibility of Web content and Web-based authoring interfaces and also to define the terms "Accessible Web Content" and "Accessible Authoring Interface". It is left up to the evaluator to decide which version of WCAG to use in their own *conformance claim* (version 1.0 [WCAG10] or version [WCAG20] @@assuming this becomes a rec@@). In order to enable the evaluator to choose which WCAG version to use in the conformance claim, references are made throughout the document to WCAG without an associated version number. The Working Group does recommend considering the following factors when deciding on which WCAG version to use:
   
   [ed. I still think this could be made more clear]

1. [1] Everything in Part A which talks to the UI of the authoring tool should be consistent with WCAG 2.0. In general, where the ATAG guideline intent
   is the same as WCAG, use the WCAG language. For example:
   1. ATAG A.2.1: "Ensure that all functionality is operable via a keyboard or keyboard interface." WCAG 2.0: "Make all functionality operable via a keyboard interface."
   2. ATAG A.2.3 : "Allow authors to control time limits on their reading or interaction."  WCAG 2.0: "Allow users to control time limits on their reading or interaction."

http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0023.html

[PROPOSED CHANGE]
See proposed changes through section A.

1. I don't understand how web content that meets Checkpoint A.0.1 satisfies Checkpoint A.2.1 success criteria 3 and 4.

1. [CHANGE]
   In "For Web-Based Interface Components:" change note to: Meeting Checkpoint A.0.1 will serve to meet success criteria 1 and 2 of this checkpoint. Browser functionality may be relied on to achieve some parts of success criteria 3 and 4 (e.g. Single-key access to move content focus to the next enabled control in user interface, Key-plus-modifier-key (or single-key) access to "undo") as long as the applicable user agent(s) are specified in the conformance profile.

A.1.1 Provide text alternatives for all non-text content in the user interface. [Priority 1]

[PROPOSED CHANGE]
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0023.html
Provide text alternatives for all non-text content[REM]. [Priority 1]

[PROPOSED CHANGE]
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0023.html
A.1.2 Provide synchronized alternatives for multimedia[REM]. [Priority 1]

1. [4] A.1.3 "Ensure that displays are configurable" is not clear until you read the success criteria.  It sounds like you are talking about hardware displays rather than display settings.  I recommend "Make visual and audio display settings configurable." or "Make visual and audio display preferences configurable." I also think that "Make" is a better verb than "Ensure" for this guideline.  You are talking about settings for the UI of the tool, so you must *make* them configurable.

1. [PROPOSED CHANGE]
   http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0023.html
   We could go with: "Make visual and audio display preferences configurable."

1. [5] A.1.4 "Allow the display preferences for the editing view to be changed without affecting the document markup."  By saying "Allow" this implies that the display preferences will change the document markup view and you must provide an option to prevent that from happening.  The language should be  "*Ensure* the document markup view is not changed when the display preferences for the editing view are changed."

1. [PROPOSED CHANGE]
   http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0023.html
   Not exactly - it means don't change the markup of the content to accomplish particular display preferences. I could see rewording it as: "Ensure changes to the display preferences of editing views do not affect the content being edited."

[PROPOSED CHANGE]
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0023.html
A.1.5: Ensure that information, functionality, and structure can be separated from presentation. [Priority 1]

[PROPOSED CHANGE]
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0023.html
A.2.1 MAKE all functionality operable via a [REM] keyboard interface. [Priority 1]

[PROPOSED CHANGE]
http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0023.html
A.2.3 Allow authors to control time limits ON THEIR READING OR INTERACTION. [Priority 1]

1. [7] A.2.4 Allow authors to avoid content that could cause seizures due to photosensitivity. [Priority 1]   - Are sure you don't want to just allow the user to be able to control the rate as opposed to just turning off flashing. What determines flashing? Some flashing is not harmful. This seems like an all or nothing.

http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0023.html
A.2.4 Allow authors to avoid content that could cause seizures due to photosensitivity. [Priority 1]

1. [PROPOSED CHANGE]
   TWO ALTERNATIVE IDEAS (one weaker, one stronger):
   1-If flashing in the user interface violates international health and safety standards for general flash or red flash, the author must be able to turn off the flashing or control the flashing rate so that it no longer violates these standards.
   2-The user interface must not include any flashing that violates the general flash threshold or the red flash threshold. (this is the WCAG formulation)

1. [8] A.2.5 For usable access suggest this be a P1. Users have problems with model-based authoring tools because of this today.

1. [PROPOSED RESPONSE]
   This is a judgment call....is it essential? Lots of authoring already happens on text based tools without this?.

1. [9] A.3.2 For usable access suggest the be a P1. *Maintain consistency within the authoring tool user interface. [Priority 2]*
   [11] The techniques outlined for "Maintain consistency" sound like P1 items, not P2.  Especially in a tool, you don't want icons to have more than one function or UI controls performing multiple functions. Making the Authoring UI understandable takes more than just documenting accessibility features.  I think many items in A.3.2. techniques should be P1 for this guideline.

1. [PROPOSED RESPONSE]
   Once again, this is a judgment call as to whether this is essential? Certainly a tool that didn't do these things would be difficult to use.

1. [6] "Authoring system must be access system friendly" is not strong enough.  Being "friendly" doesn't mean that it works with AT.  I recommend something more like  "Authoring system must work with current assistive technology" which is more consistent with the WCAG principle that "...content must be robust enough to work with current and future technology".  Working and being "friendly" are two different things.
2. [10] Suggest documenting accessibility implementation for AT vendors be a P3? For example, this would encompass what MSAA APIs were supported per widget.
3. [12] Concern over how tough this is to enforce (i.e., what version number of JAWS, which AT products?)

1. BAF working on this.
2. This sounds like it makes sense as a new checkpoint (i.e. A.4.2).
   BAF working on this.
3. [PROPOSED RESPONSE]
   The success criteria don't actually point at AT's. They are more focussed on API support, so this probably isn't a problem.

1. [13] For example, PowerPoint can be delivered from the Web - per WCAG 2. Why not limit this to any technology delivered through the Web? WCAG 1.0 does not fit this mold due to its HTML- like dependencies but WCAG 2 does.
2. [14] Support of new content types is not clear.  For example, does the success criteria for *Support content types that enable the creation of Web content that conforms to **_WCAG_* <http://www.w3.org/TR/2005/WD-ATAG20-20051123/#Relationship-To-WCAG> mean that if a company develops or uses a content type and there is no content-type specific WCAG benchmark then the tool is not compliant?  Does this get us into the type of situation we had with JavaScript in WCAG 1.0 where it was supported, but you still couldn't implement a JavaScript site and be WCAG compliant?

1. [PROPOSED RESPONSE]
   Why limit it? If toolmakers aren't feeling accessibility pressure about their formats then they probably won't be concerned with WCAG and, by extension, ATAG. On the other hand, if they do feel the pressure, then ATAG will be helpful to them. In a case like Powerpoint, they may produce multiple formats, only some of which they might have WCAG concerns about - fortunately ATAG can handle this via the conformance claim mechanism in which only the formats being evaluated are listed.
2. [PROPOSED RESPONSE]
   No - in fact our mechanism was developed expressly to handle this situation. All a developer has to do to claim conformance to a novel format is put in place a "content type-specific WCAG benchmark document" - which they are even allowed to compile themselves.

1. [15] For recognized markup - this should be a P1. Why would this be a P2?  If a new technology comes along with unrecognized markup, shouldn't the tool preserve that?  [When] accessibility information is not preserved ... the authors have to add it back in.  What is the rationale for being P2? Perhaps we need to make a statement on recognized markup, i.e., it must be preserved!

1. [PROPOSED RESPONSE]
   [PROPOSED CHANGE]
   Maybe we need to split this back out into two checkpoints:
   "B.1.2 Ensure that the tool preserves unrecognized markup. [Priority 2]"
   "B.1.2 Ensure that the tool preserves accessibility information during transformations and conversions. [Priority 1]"

1. [18] B.2.1 *Prompt and assist the author to create content that conforms to **_WCAG_* <http://www.w3.org/TR/2005/WD-ATAG20-20051123/#Relationship-To-WCAG>. B.2.2 *Check for and inform the author of accessibility problems* and B.2.3 *Assist authors in repairing accessibility problems*
   [19] Many vendors do not do prompting and/or repair in current tools. This could be a major issue for them.  [Some vendors have] tools that make it possible (with a lot of work) to create accessible content, but there is no prompting.  This is a relative priority, so its unclear the exact impact to these companies. Commenter's opinion: Its not that they shouldn't provide this support, but we don't understand the impact since these are Relative Priority.

1. I think this comes back to making the relative priority checkpoints crystal clear. Prompting sounds a bit scary, but it is really just "letting the author know that some piece of information or decision is needed from them".
   [PROPOSED RESPONSE]
   [PROPOSED CHANGE]
   We may want to change the defintion of "prompt" (again) to make this more clear:
   Prompt: "In this document "prompt" refers to any authoring tool initiated request for a decision or piece of information. Well designed prompting will urge, suggest, and encourage the author."

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

1. [20] B.2.6 *Provide the author with a summary of accessibility status*.  This is a P3 but seems more doable than the Relative priority items in B2.1, B2.2, and B2.3.  Why would this be P3, seems more like P2 according to the ATAG definition of priority.

1. [PROPOSED RESPONSE]
   P2 seems ok - it's probably almost guaranteed for most sensible checker designs.

1. [21] B.2.7 Suggest this be P1. This seems in conflict with what is trying to be accomplished. How can anyone use the authoring tool to accomplish the task of producing accessible content if in fact that author does not know the capabilities of the tool? Example require keyboard access features to be documented.

1. [PROPOSED RESPONSE]
   This is documentation of the features for all users for authoring accessible content, not documentation of accessibility features, which is covered by A.3.3. It's probably not essential because if the design is intuitive, many users will never read the documentation.

1. [22] *B.3.2 Ensure that accessibility prompting, checking, repair functions, and documentation are always clearly available to the author. [Priority 2] *as P2 is inconsistent with all checkpoints in B.2.x.  If you say it isn't Priority 1 to make the features described in B.2.x available, then does that mean you don't have to do them?

1. This other proposal makes a wording and numbering change: http://lists.w3.org/Archives/Public/w3c-wai-au/2006AprJun/0014.html
   [PROPOSED RESPONSE]
   [PROPOSED CHANGE]
   There seems to be a problem with the term "clearly available". Maybe we could use "prominence" - it already has a definition in the glossary. So:
   "Ensure that features of the tool that support the production of accessible content are prominent in the user interface."

1. [2] ATAG glossary should be consistent with WCAG 2.0 glossary. For example, the definition of a keyboard interface. You may have a voice reco system. Using a voice reco system to insert text should not be precluded by having a physical keyboard to also do the insertion.

1. [PROPOSED RESPONSE]
   [PROPOSED CHANGE]
   http://lists.w3.org/Archives/Public/w3c-wai-au/2006JanMar/0024.html
   Comparing the two glossaries, it looks like we can adopt the WCAG definitions of the following words:
   - audio description
   - captions
   - general flash threshold
   - red flash threshold
   - normative
   - user agent Words that we might want to add the ATAG glossary from the WCAG glossary:
   - keyboard interface
   - blink
   - information that is conveyed by color
   - multimedia
   - non-text content (would require also adding "Unicode" and "ASCII Art")
   NOTE: We can also mark the words that match exactly as WCAG does when they get a term from DI etc.

• Yes, the new authoring tool user interface requirements in "PART A" are adequate and the priorities of the checkpoints are appropriate.

• Yes, the updated conformance section seem like a workable mechanism but it is not obvious at once. I had to be alert and read it twice.

• Yes, the requirements for checking and repair are a reasonable compromise.