EOWG Comments on ATAG 1.0 Last Call Working Draft, 22 November 2005

A. Comments on ATAG 2.0 LCWD Introduction:

In general:

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

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

- This ATAG document doesn't seem to sufficiently differentiate itself from 
WCAG, even though there is a section addressing this.

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

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


B. Comments on ATAG 2.0 Guidelines
----------------------------------------------

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

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.

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.

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

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.

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.

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.