Response to Last Call Comments:

If you made a comment on the 22 November 2004 Last Call Draft of ATAG 2.0:

Locate your comment text in the "ISSUES" column.

Look-up the response in the adjacent "RESPONSE" column. The numbering of the items in each row determines which RESPONSE goes with which ISSUE.

AREAS

ISSUES

RESPONSE

General:

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

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

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

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

Several parts of the introduction have been reworded in an attempt to improve readability.

The changes to the introduction will hopefully address this concern.

Components document is now referenced; group still in favour of keeping guiding principle: "Everyone should have the ability to create and access Web content."; the ISO dependency has been removed.

the terminology "must always conform" has been removed

Regarding ISO reference:

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

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

Bug976: There is the "problem" of ISO.
If we refer only to general guidelines, we have only "core"
and "secondary" level. This because we have set as:

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

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

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

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

The ISO dependency has been removed.

See (1)

See (1)

See (1)

See (1)

See (1)

See (1)

Introduction: Scope

Bug1186: Sec 1.1 . I presume the 4th bullet will eventually lead to the appendix mentioned. Last paragraph ...as readable and usable _as possible_ [for that diverse audience] while...

Bug1009: I don't understand why the "rationales"
are designated as "normative"..

Rationales are now informative.

Guideline 1

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

The authoring tool must satisfy at least one of the following conditions:
(a) At least one full-featured Web-based authoring interface must always
conform to WCAG.
(b) At least one full-featured non-Web-based authoring interface must
always conform to ISO-TS-16071.

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

The authoring tool must satisfy at least one of the following conditions:
(a) In Web-based authoring interfaces, at least one editing method for
each editable property must always conform to WCAG.
(b) In non-Web-based authoring interfaces, at least one editing method
for each editable property must always conform to ISO-TS-16071.

Bug1132: It is not completely clear that a tool is
required to make editable properties accessible, not all properties
editable. (Also linked term is different than glossary term)

Bug1187: 1.2 ... Web content for publication. ?deliberately
excluding pdf, MSWord, etc. which are sometimes made available on the
web?

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

Bug1196: 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?

New Part A requirements have removed this wording.

See (1)

See (1)

See (1)

1.3 Allow the display preferences of the authoring interface
to be changed without affecting the document markup. [Priority 1]

All editing views must always include an option to display any available
equivalent alternatives.

All editing views must always include an option to keep the display
settings of the authoring interface from affecting the Web content being
edited.

Bug1188: 1.3 Success criteria -- "any available
equivalent alternatives" Many tools will not have text-to-speech;
will not let any response when the display is off, will not be responsive
without a pointing device, will not tab-step through links, etc.

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

Bug1196: 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

This requirement has moved to A.1.4 and this wording has been removed.

This should no longer be an issue with the rewording of A.1.4.

Techniques are non-normative. Also there is no statement that this checkpoint could meet the requirement by itself.

1.4 Ensure that the authoring interface enables the author
to navigate the structure and perform structure-based edits. [Priority
2]

In any element hierarchy, the author must always be able, with a device-independent
action, to move the editing focus from any element to any of the following
elements, if they exist: the element immediately above (i.e. parent),
the first element immediately below (i.e. child), the element immediately
preceding at the same level (i.e. previous sibling), and the element
immediately following at the same level (i.e. next sibling).

In any element hierarchy, the author must always be able, with a device-independent
action, to select content and perform editing functions on any element
along with any content, including subelements.

Bug1114/1196: 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.

Bug1189: 1.4 bullet 4 ...different format specifications
_such as CSS_, use ...
Success Criteria 1: Nice idea for navigation by levels ?Are there any
tools that allow stepping through by hierarchy?
Success Criteria 2: Are there any tools that allow selection of entire
structure with its substructure?

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

Bug1196: Checkpoint 1.4 Why is this important and
unique in reference to navigation and editing?

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

This requirement has been moved to A.2.5. The requirement is intended primarily to address author navigation rather than end-user navigation. Other requirements, such as A.2.1 (Ensure that all functionality is operable via a keyboard or a keyboard interface) should ensure that the navigation options are available.

Yes a variety of tools include structure views and many, including Dreamweaver will select sub-elements when an element is selected.

The new rationale should address this: " It is often efficient to make use of the structure that may be inherent within Web content in order to navigate editing views and perform edits."

When editing structured documents, greater efficency is possible when the structure is leveraged to help the author navigate and edit semantic chunks.

The techniques are informative suggestions rather than normative requirements. While the actual navigation might be handled by the user agent in the case of a Web-based tool, the tool has to be developed to take advantage of whatever navigation the user agents offer.

1.5 Ensure that the authoring interface allows the author
to search within the editing views. [Priority 2]

At least one comprehensive editing view must always include a search
function that meets these conditions:
(a) Provides search within any rendered Web content
(b) Provides the option to search markup when the tool allows direct
editing of markup (e.g. when authored "by hand").
(c) Provides the option to search for text within all text equivalents
of any non-text content.

Bug1115: 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. How do the navigation
techniques here map to UAAG 1.0? Where is the reference to UAAG 1.0?

Bug1226: In checkpoint 1.5, for Web-based tools
can the search be browser's find function? What if only some browsers
support "find".

Metadata enhanced search is not required in A.2.6 but would certainly be a valuable addition developers could pursue. There will be references to UAAG in the techniques.

Yes, the browser find function is explicitly referenced in A.2.6.

Guideline 2

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

Links have been added where necessary.

2.1 Support formats that enable the creation of Web content
that conforms to WCAG. [Priority 1]

Any authoring tool that chooses the format of content for the author
(i.e. a default format) must always choose formats for which there are
published WCAG techniques documents for meeting each WCAG checkpoint.

Any authoring tool that allows authors to choose the format of content
must always support at least one format for which there is a published
WCAG techniques documents for meeting each WCAG checkpoint and always
give prominence to those formats.

Bug1116/1196: 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.

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

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

It is correct that a "Content Type-Specific
WCAG Benchmark" document
is needed for any format (defined by a content recommendation) that an
authoring tool is including in its conformance profile. This document
codifies the evaluator's understanding of how the requirements
that are somewhat generally stated in WCAG are understood with respect to the particular format in question. However, it is not the case that the WCAG Techniques document must be
published by WCAG-GL or any other W3C working group. ATAG 2.0 states that this document can be created
by any person, company, etc., as long as it meets the proper conditions, including being published online (see section 2.2.4). The
intent is to ensure public scrutiny of the WCAG benchmark that any
particular evaluator has set for themselves.
The WCAG-GL or W3C working groups may of course choose to publish
benchmark documents, but this is not necessary.

See (1)

Since anyone can create a "Content Type-Specific WCAG Benchmark" it will not stifle new technologies.

2.2 Ensure that the tool preserves all unrecognized markup
and accessibility information during transformations and conversions.
[Priority 2]

All transformations and conversions supported by the authoring tool
must always meet both of the following conditions:
(a) The author is notified before any unrecognized markup is permanently
removed.
(b) All accessibility information is handled according to at least one
of the following:
(i) Be preserved in the target format such that the information
can be "round-tripped" (i.e. converted or transformed back
into its original form) by the same authoring tool.
(ii) Be preserved in some other way in the target
format.
(iii) Be removed only after the author has been notified
and the content has been preserved in its original format

Bug1117/1196: 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

Bug1196: Checkpoint 2.2 Since this Specification
is so closely coupled with WCAG is it possible to find a way to have
Version 3.0 of each come out at the same time?

There are rich (e.g. HTML) and less rich (e.g. plain
text) formats . The group does not wish to rule out transformations
between them as long as the author knows what is happening.

We are in communication with WCAG-WG.

2.3 Ensure that when the tool automatically generates
content it conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

All markup and content that is automatically generated by the authoring
tool (i.e. not authored "by hand") must always conform to
WCAG.

Bug1196: Checkpoint 2.3 What priority is this checkpoint?

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

Bug1226: In checkpoint 2.3, what if information is required from
the user?
Can the pre-corrected markup be put in anyway?

B.1.3 (in the new draft) is a relative priority checkpoint that
depends on what WCAG has determined to be the priority of the Web content in question.

The note has been removed. In general any exceptions left open by WCAG will carry
over to ATAG's relative priority checkpoints, such as this one, so no
explicit statement is required.

This checkpoint's success criteria basically requires that unless the author has hand picked inaccessible content, the tool can't put it in automatically (i.e. without asking the author or prompting them for whatever is required: alt text, etc.)

2.4 Ensure that all pre-authored content for the tool
conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

Any Web content (e.g., templates, clip art, example pages, etc.) that
is bundled with the authoring tool or preferentially licensed to the
users of the authoring tool (i.e. provided for free or sold at a discount),
must conform to WCAG when inserted.

Bug1190: Success Criteria -- concern: SW free or
sold at a discount is often accompanied by disclaimers -- you get what
you pay for. Such may not clearly identify any conformance. Metadata
on it would help, particularly if the using author could learn of its
content.

Bug1196: Checkpoint 2.4 – I would include that
all samples/examples are accessible and conform to WCAG 2.0, What priority
is this checkpoint?

Exactly - content freely available to all authors is not covered. Only content specially available to customers (and therefore a selling point).

It would not reasonable to expect companies to make large amounts of content that they do not control accessible. The checking and validation requirements of ATAG 2.0 would be triggered in the event that authors made use of this material. This is a relative priority checkpoint that
depends on WCAG to set the priority depending on the content in question.

Yes a "Content Type-Specific WCAG Benchmark" document would be required for each format that is part of the conformance claim.

Guideline 3

3.1 Prompt and assist the author to create content that
conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

Every time that content is added or updated that requires accessibility
information from the author in order to conform to WCAG, then the authoring
tool must inform the author that this additional information is required
(e.g. via input dialogs, interactive feedback, etc.).

Whenever the tool provides instructions to the author, either the
instructions (if followed) must lead to the creation of Web content
that conforms to WCAG, or the author must be informed that following
the instructions would lead to Web content accessibility problems.

Bug1226: In checkpoint 3.1, success criteria 2 is
confusing.

This is now B.2.1 (the success criteria is : "Whenever the tool provides instructions to the author, either the
instructions (if followed) must lead to the creation of Web content that conforms to WCAG, or the author must be informed that following the instructions would lead to Web content accessibility problems." )
It basically says that when the authoring tool provides instructions (e.g. as might appear on image insertion dialog) then either the instructions have to be correct from an accessiblity perspective (e.g. advise author on use of alt and longdesc) or warn the user that following the instructions could cause accessibility problems (hopefully, most developers will take the first option).

3.2 Check for and inform the author of accessibility problems.
[Web Content Checkpoints Relative to WCAG]

The authoring tool must always provide a check (automated check, semi-automated
check or manual check) for each applicable requirement to conform to
WCAG.

The authoring tool must always inform the author of any failed check
results prior to completion of authoring.

Bug1165: Success criteria for 3.2 and 3.3 to emphasize that only manual checking and repair is strictly required. (see also http://lists.w3.org/Archives/Public/w3c- wai-au/2005JanMar/0061.html)

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

Bug1226: In checkpoint 3.2, does success criteria 2 require that
a checker be launched automatically?

B.2.2 (checking) and B.2.3 (repair) have been rewritten for clarity

This wording is removed. The tool just has to provide the option (i.e. by having an accessibility evaluation tool item in the menu) prior to completion of authoring.

The authoring tool must always provide a repair (automated repair,
semi-automated repair or manual repair) for each applicable requirement
to conform to WCAG.

For accessibility problems for which an authoring tool provides only
manual repairs, the repair instructions must always be directly linked
from the corresponding check.

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

We are positioning to release ATAG 2.0 after WCAG 2.0.

3.4 Do not automatically generate equivalent alternatives
or reuse previously authored alternatives without author confirmation,
except when the function is known with certainty. [Priority 1]

When the author inserts an unrecognized non-text object, the tool
must never insert an automatically generated text equivalent (e.g. label
generated from the file name).

When the author inserts a non-text object for which the tool has a
previously authored equivalent alternatives (i.e. created by the author,
tool designer, pre-authored content developer, etc.), but the function
of the object is not known with certainty, the tool must always prompt
the author to confirm insertion of the equivalent. However, where the
function of the non-text object is known with certainty (e.g. "home
button" on a navigation bar, etc.), the tool may automatically
insert the equivalent.

The authoring tool must always keep a record of alternative equivalents
that the author inserts for particular non-text objects in a way that
allows the text equivalent to be offered back to the author for modification
and re-use if the same non-text object is reused.

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

Bug1191: 3.5 ...reusing alternative equivalents -
If the object is from a database, may need to add a field for possible
alternative equivalents.

Developers are free to do this and in some cases metadata can hold alternative equivalents.

Yes, but the exact implementation is up to the developer.

3.6 Provide the author with a summary of accessibility
status. [Priority 3]

The authoring tool must provide an option to view a list of all known
accessibility problems (i.e. detected by automated check or identified
by the author as part of a semi-automated or manual check) prior to
completion of authoring.

3.7 Document all features of the tool that support the
production of accessible content. [Priority 2]

All features that play a role in creating accessible content must
be documented in the help system.

Bug1192: 3.7 ...alternates... should be alternatives.
you don't mean every other!

Bug1226: In checkpoint 3.7, the success criteria
could be interpretted as
covering all functionality (in principle, almost anything can affect accessibility).

This change has been made (now in B.2.7).

The informative rationale lists the type of features that are most relevant. The success criteria does not apply to many common software operations (e.g. opening and saving documents, etc.). Remember, this is documentation for all authors. Documentation specifically to help authors with disabilities is addressed in Part A.

3.8 Ensure that accessibility is modeled in all documentation
and help, including examples. [Priority 3]

All examples of markup and screenshots of the authoring interface
that appear in the documentation and help must model accessible Web
content.

3.9 Provide a tutorial on the process of accessible authoring.
[Priority 3]

A tutorial on accessible authoring for the specific authoring tool
must be provided.

Guideline 4

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

Bug1193: Guideline 4 last paragraph ... seems to weaken the rest of the discussion ..." Moreover, the effectiveness of the solutions are perhaps better judged by the marketplace than by a set of stringent requirements."

In the group's opinion giving accessible options priority and ensuring visibility for accessibility features is a form of promotion and all of the checkpoints involve integration in one form or another.

This text has been removed.

4.1 Ensure that the most accessible option for an authoring
task is given priority. [Priority 2]

When the author has more than one markup implementation to choose
from (e.g. the color of text can be changed with presentation markup
or style sheets), those markup implementations that conform to WCAG
must have equal or higher prominence than those markup implementations
that do not meet the WCAG requirements.

Any choices of formats or authoring practices presented to the author
(e.g., in menus, toolbars or dialogs) that will lead to the creation
of content that does not conform to WCAG must be marked or labeled so
that the author is aware of the consequences prior to making the choice.

4.2 Ensure that accessibility prompting, checking, repair
functions, and documentation are always clearly available to the author.
[Priority 2]

All accessibility prompting, checking, repair functions and documentation
must meet the following conditions:
(a) If they are continuously active, then they must always be enabled
by default and if the author disables them (e.g. from a preferences
screen), then the tool must always inform the author that this may introduce
accessibility problems.
(b) They must have at least the same prominence as the same type of
function (i.e. prompting, checking, repair and documentation) related
to other kinds of information (e.g. markup validity, program code syntax).

Any feature that helps to sequence author actions (such as object
insertion dialogs, design guides, templates, wizards, tutorials, or
instruction text) must integrate relevant accessibility prompts. These
prompts should occur before or at the time that the author is required
to make the authoring decision related to the prompt.

Bug1195: 4.3 Success Criteria ?These prompts should
occur before [what would be so prescient as to anticipate the author's
intent?] I expect you mean the author's trying to initiate use of a
feature that has accessibility consequence, such as insert image add
alt="...", or create table -- add summary.
Such examples might clarify your meaning. For some "at the time
" seems more likely to be following what the author has done, at
which time the accessibility consequences can be determined.

The success criteria for this checkpoint (now B.3.3) have been reword to clarify this:

For interactive features that sequence author actions (e.g. object insertion dialogs, templates, wizards) must integrate any relevant accessibility prompts at or before the first opportunity to complete the operation (i.e. not cancel).

For read-only instruction text (e.g. tutorials, reference manuals, design guides, etc.) that includes a sequence of steps for the author to follow, the relevant accessibility authoring practices must appear in the step sequence before the first opportunity to complete the sequence.

The configurability of all functions related to accessibility prompting,
checking, repair, and documentation must match the configurability of
other prompting, checking, repair, and documentation functions of the
tool (respectively), in terms of both of the following:
(a) the number of options controllable by the author, and
(b) the degree to which each option can be controlled

Conformance: Conformance Scheme

Bug1009: Perhaps Section 3 material should be moved
to before the Guidelines, since it mentions priorities and a reader
might want to know this material before accessing the Guidelines, and
conformance is an important subject that should be "up front"

Bug1009: If an offering claims conformance to Level
AA ATAG2.0 by immediately passing all the Level AA tests first, does
it also conform by default to Level A (assumed to pass the Level A tests
by default, as a way of saving testing effort and resources)? I assume
not from Figure 1 in Section 3?, but this is not explicitly stated..
What constraints are there on the various levels (subdivisions)?

Bug1112: Strike reference to WCAG 1.0 checkpoint
6.3

Bug1121/1196: 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).

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

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

This change has been made.

Yes, the requirements for Single-A are a subset of the requirements of Double-A and so on.

Instead, we are positionning to release after WCAG 2.0.

ATAG 2.0 does not require conformance to both
WCAG 1.0 and WCAG 2.0. Instead, the evaluator may choose EITHER WCAG
1.0 or 2.0, as explained in Section 1.5.1 and in 2.1.2.

Bug1194: 3.2.3 Conformance Where do you intend to
make such claims? -- I suggest in metadata, and possibly as well in
the document content.

What was "bundling" is now handled in the definition of authoring tool ("ATAG 2.0 defines an "authoring tool" as: any software, or collection of software components, that authors use to create or modify Web content for publication. A collection of software components are any software products used together (e.g. base tool and plug-in) or separately (e.g. markup editor, image editor, and validation tool), regardless of whether there has been any formal collaboration between the developers of the products.")

Conformance claims may be published anywhere as long as there is a WCAG conformant version on the Web. A metadata version is certainly a possibility.

Glossary

Bug1198: The EOWG has set up a "Lexicon Task
Force" that is developing a "Beginners' Lexicon for WAI Documents".
This will be short lexicon with definitions in clear and simple language
and contextualized to Web accessibility. The primary purpose of this
beginners' lexicon is to assist translators of WAI documents, though
it also may be helpful to people new to Web accessibility.

The following definitions are ones where we would be likely to change
them slightly or significantly from what is in the glossary section
of your current draft, as shown below, when incorporating them in
the Beginner's Lexicon for WAI Documents. We invite you to examine
these definitions for two reasons: to see if you disagree with any
of our re-statements of your definitions, and to consider whether
any of the following definitions would be more suitable for use within
the ATAG 2.0 glossary than the definitions currently present.

More background on the Lexicon Task Force is available below [1].

- Accessible Web content
Accessible Web content is sufficiently free of accessibility problems
to be usable by everyone regardless of disability or environment.

- Attribute
Information that explains, identifies or modifies an element in a
markup language. Element types may have more than one attribute, like
'class', 'title', 'width' and 'height'. Some attributes are integral
to the accessibility of content (for example, the 'alt', 'title',
and 'longdesc' attributes in HTML)

- Audio Descriptions
Audio description (also called "Described Video") is an
equivalent alternative that provides aural information about actions,
body language, graphics, and scene changes in a video. Audio descriptions
are commonly used by people who are blind or have low vision, although
they may also be used as a low-bandwidth equivalent on the Web. An
audio description is either a pre-recorded human voice or a synthesized
voice (recorded or automatically generated in real time). The audio
description must be synchronized with the auditory track of a video
presentation, usually during natural pauses in the auditory track.

- Authoring Tool
Any software or service that is used to produce content for publishing
on the Web. Authoring tools include Web content editors, document
conversion tools, and software that generates Web content from databases.

- Captions
Captions are equivalent alternatives that consist of a text transcript
of the auditory track of a movie (or other video presentation) and
that is synchronized with the video and auditory tracks. Captions
are generally rendered graphically. They benefit people who are deaf
or hard-of-hearing, and anyone who cannot hear the audio (for example,
someone in a noisy environment).

- Conversion
A conversion is a process that takes, as input, content in one format
and produces, as output, content in another format (for example, "Save
as HTML" functions).

- Device independence
The use of a webpage or event handler with any kind of input device.
Scripting should be device-independent or provide multiple input and
output options for different devices. For example, onDblClick requires
a mouse; there is no keyboard equivalent for double clicking. Input
devices may include pointing devices (such as the mouse), keyboards,
Braille devices, head wands, microphones, and others.

- Equivalent Alternative
An equivalent alternative is content that is an acceptable substitute
for other content that an end-user may not be able to access. An equivalent
alternative fulfils essentially the same function or purpose as the
original content upon presentation to the end-user. Equivalent alternatives
include text alternatives, which present a text version of the information
conveyed in non-text content such as graphics and audio clips. Equivalent
alternatives also include "media alternatives", which present
essential audio information visually (captions) and essential video
information auditorily (audio descriptions).

- Markup language
A markup language is a syntax and/or set of rules to manage content
and structure of a document or object (for example, HTML , SVG , or
MathML).

- Repairing, Accessibility
Accessibility repairing is the process by which Web content accessibility
problems that have been identified within Web content are resolved.
ATAG 2.0 identifies three categories of repair: Automated (that is,
the authoring tool is able to make repairs automatically, with no
author input required), Semi-Automated (that is, the authoring tool
can provide some automated assistance to the author in performing
corrections, but the author's input is still required before the repair
can be complete) and Manual (that is, the authoring tool provides
the author with instructions for making the necessary correction,
but does not automate the task in any substantial way).

- Techniques
Techniques are informative suggestions and examples for ways in which
the success criteria of a checkpoint might be satisfied and implemented.

- Transcript
A transcript is an equivalent text alternative for the sounds, narration,
and dialogue in an audio clip or an auditory track of a multimedia
presentation. For a video, the transcript can also include the description
of actions, body language, graphics, and scene changes of the visual
track.