Comments on ATAG 2.0 Draft

ATAG 2.0 Final Draft-
1. Introduction:
- Move description of audience to the opening with justification. Namely 
move paragraphs 1 and 2 of 1.1 to the first paragraph.

1.1 Scope
- Authoring tool software developers appear to be the primary audience, 
but this is never said explicitly.

- The audiences identified in paragraph 2 seem to be of secondary, 
important, but secondary.   The way the paragraph is stated this group 
seems primary.

1.4 Relationship with other Guidelines and Standards:
This section addresses the interaction between five documents: XAG, 
ISO-TS-16071 (for non-web interfaces), WCAG, ATAG and UTAG.   The 
introduction is missing overview of scope and objective of this section. 
It is a large section and it is very critical to understanding the goals 
and content of the guidelines.   It is more ambitious than "The 
Interdependency of Accessible Web Components" in scope and technical 
precision, so some technical language and formal specificity is 
appropriate; however, the section's lack of a careful and clear overview 
leaves the reader with the task of deriving the theme from a collection 
of highly detailed and technically specific pieces.   It is difficult to 
read.

Suggested Reorganization of 1.4:
- Introduce each standard briefly XAG, UAG, WCAG, ISO-TS-16071 and ATAG.

- Describe carefully how ATAG fits in to this picture.

- Move the detailed XAG discussion to a section of its own.   Make the 
primary audience for this subsection clear.

- Keep 1.4.1 but clarify.   Give a link to " "The Interdependency of 
Accessible Web Components".   Paraphrase some of the explanations and 
use essential diagrams from the Web Components document to permit 
readability with out using the link.   Make the primary audience for 
this subsection clear.

- Keep 1.4.2 but be sure that the reason for referencing ISO-TS-16071 is 
explained well.   Make the primary audience for this subsection clear.



2. The Authoring Tool Accessibility Guidelines
Guideline 1:   Make the authoring interface accessible
- First descriptive paragraph, last sentence is long and unnecessarily 
difficult.   Break it up.   Maybe describe 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.   Namely, " 
Rationale - If an authoring feature is present for one user population 
then a functionally equivalent feature should be present for all users."

1.2 Ensure that the authoring interface enables accessible editing of 
element and object properties.
- The term element is ambiguous in its definition.   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.

1.4 Ensure that the authoring interface enables the author to navigate 
the structure and perform structure-based edits.
- Add to the Rationale " If some authors can navigate the structure in 
Web content then all authors should be able to navigate the structure in 
Web content."   This is consistent with 1.2 and the parallel seems to 
apply.

Guideline 2: Enable the production of accessible content that conforms 
to WCAG.
Overall the treatment of Guideline 2 is clear and readable.   The 
motivations 2.1-2.4 are intuitively clear.


Guideline 3 - Support the author in the production of accessible content
3.7 Document all features of the tool that support the production of 
accessible content.
- Add "and give this documentation prominence, " where the term 
prominence links to the formal term "prominence" in the glossary.



Guideline 4: Promote and integrate accessibility solutions.
- The actual specifics 4.1-4.4 are relatively easy to read and 
understand, but I cannot reconcile their description and meaning to the 
general introductory paragraphs for Guideline 4.   I have read this 
introduction several times and still have difficulty with it.   The 
first sentence demonstrates this lack of clarity .   "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 ."   The 
emphasized part of this sentence doesn't make sense to me.

3. Conformance
- I only recommend one change.   The adjectives regular and relative for 
checkpoint are very confusing.   I suggest the following replacement 
terms: Replace regular with ATAG 2.0 and relative with external.

- Overall the section is a difficult read, but that is because the 
content is difficult.   The style and organization is fine.

Glossary
- I found this useful.

General Comments:
Across the document, the phrase …web content that conforms to WCAG...," 
should be reconsidered
- Perhaps the document should add, “and XAG.”

--- Rationale: The use XML schemas will only increase over time.   Lots 
of automatically generated web content will use specialized schemas. 
Also, XAG is mentioned explicitly as one of the standards being 
considered by authors in the Introduction 1.4.

- Another alternative would be to remove all reference to XAG from the 
document.

Introductory comments of the main guidelines 1, 2, 3 and 4 should 
include hyperlinks to any terms that are defined in the glossary.
- Example in Guideline 2 the overall introduction should provide links 
to the terms like unrecognized markup, accessible information, 
transformations, conversions etc.   The term unrecognized markup was 
especially jarring the first time I read it.

Received on Wednesday, 12 January 2005 17:55:06 UTC