Here are some comments I have collected from IBMers with interest in this 
subject .  I have not filtered the comments all that much (just removed 
personal identifiers and any IBM confidential info).  They are grouped by the 
source (so there may be repeating or conflicting comments) .  I have added my 
thoughts after some of them with BAF leads (note I may not always agree with 
the original comment author's position, I need to work more inside IBM to come 
up with a firm consolidated position in these situations - I didn't want to 
hold this input up until I could get that.).

(sorry this comes after last call, it was hard to get this level of input to 
earlier drafts, although I did ask).

Some comments may also already have come in from the source directly.

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.

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

From an IBM accessibility enablement consultant:

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.
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.
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?
Checkpoint 1.4 
Why is this important and unique in reference to navigation and editing?
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?
Checkpoint 2.3 
What priority is this checkpoint?
Checkpoint 2.4  
I would include that all samples/examples are accessible and conform to WCAG 
2.0, What priority is this checkpoint?

From a WCAG member:

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


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

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.


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.

Guideline 2.3

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

Guideline 2.4

same conformance to WCAG concerns.

Guideline 3.1

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

Guideline 3.2

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.

Guideline 3.3 

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

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)

From a Protocols member

ATAG 2.0 is important, especially for the EU and IBM is preparing to support 
these guidelines in some of our products now, however these new issues are a 
problem. Hopefully they can get resolved quickly.

This is my review of ATAG 2.0: http://www.w3.org/TR/2004/WD-ATAG20-20041122/

- Section 1.2

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

- Guideline 1.1, 1.2

This section says conform to WCAG. For P1 this definition, 
http://www.w3.org/TR/2004/WD-ATAG20-20041122/#priority-Relative-To-WCAG-
Interface, includes the following in WCAG 1.0:

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]

This is wrong and should be struck or should be written such that P1 can be 
satisfied for WCAG 1.0 or WCAG 2.0 P1. Any reference to WCAG 1.0 should be 
removed or modified. This WCAG 1.0 checkpoint is obsolete. I am concerned that 
this impacts both JavaScript generated content as well as XForms where, in 
fact, programmatic objects are bound to the data model and follow an active MVC 
architecture. This would appear that a mode should be available to turn active 
content off in the user agent and still work or that someone would need to 
provide an alternative page equivalent for this type of content although it is 
not how this would work in the case of forms which are active.
BAF  Alternative content should be a requirement in the case where the "active" 
content cannot be made accessible (less and less of a problem over time I 
expect) and is core to the use of the web site else the user is denied some 
function of the web site.  We probably need to disconnect the criteria from 
WCAG so we lose the version dependency.  Also we cannot force site to run 
without JavaScript entirely as too many sites depend on it now. We many want to 
lower the priority of this as it is so costly to meet.  Maybe we need to add 
the "core to use" condition (ie vs implying just any JavaScript needs an 
alternative)

- Guideline 1.3

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?

- Guideline 1.4

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.

- Guideline 1.5

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?

- Guideline 2.1

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.
BAF: As we did discuss, there is concern about this in that all popular content 
types don't have techniques documents.  Is there any other way we can qualify 
content types as accessible so they can be used and still meet ATAG?

- Guideline 2.2

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

- Guideline 2.4

expand (e.g. to include objects which represent web implementations for 
graphical widgets (menus, etc.).

- Guideline 3.5

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.

- Conformance section 2.1.2

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

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.


from a WCAG member, issues with ISO 171 standard:

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.