ATAG 2.0 Last Call Comments from the WCAG Working Group

*** General Comments

Consolidate WCAG 2.0 related SC: A number of the guidelines include SC
that reference conformance to WCAG 2.0 at various conformance levels.
Consider combining these to reduce the overall number of success
criteria and to minimize repetition and cross-references in the
implementation guide.

For example, combining the three SC listed in A.1.1 might look like:

    A.1.1.1 Web-Based Accessible (WCAG Conformance): Web-based
authoring tool user interfaces conform to WCAG 2.0 at one of the
following conformance levels.

        * Level A: For Level A conformance, web-based authoring tool
user interfaces conform to WCAG 2.0 Level A. (Level A)
        * Level AA: For Level A conformance, web-based authoring tool
user interfaces conform to WCAG 2.0 Level AA. (Level AA)
        * Level AAA: For Level A conformance, web-based authoring tool
user interfaces conform to WCAG 2.0 Level AAA. (Level AAA)

A similar approach should be considered for the B.1.1.x, B.1.3.x,
B.2.2.x, B.2.3.x, B.2.5.x, etc.

*** Comments on specific SC

A.1.2.1 While we agree with the approach and the rationale cited in
the implementation guide, this SC, specifically "...and/or platform
conventions..." may not be testable. How does an authoring tool
developer determine whether they have followed enough platform
conventions to pass? Suggest revising this SC to make it more testable
and adding additional detail to the implementation guide to clarify
what would be required.

A.2.2.2: Consider adding background color to the list of minimum
presentation properties for text.

A.3.2.2 Timing Adjustable: What would be an example of an authoring
tool time limit where extending the time limit would invalidate the
activity (e)?

A.3.2.4 Content Edits Saved (Extended): Suggest revising this SC to
include "automatically" (The authoring tool can be set to
[automatically] save all content edits made by authors.)

A.3.5.1 (b): To avoid confusion with bi-directional text, consider
changing the short name of this item to "Two-way."

A.3.7.2 Preview: As worded, it appears that a UA that utilizes any
third-party user agent for preview would automatically meet this SC.
Suggest that part (a) be revised to require the use of the author's
default user agent, which would avoid a situation where the author is
unable to preview content in the UA that best meets their
accessibility needs.

A.4.2.1 Document Accessibility Features: Suggest incorporating the
accessibility of the documentation in the SC text itself or include
the note from the implementation guide, "The accessibility of the
documentation is covered by Guideline A.1.1 and Guideline A.1.2." with
the SC.

B.1.2.2(a): "Option to Save: authors have the option to save the
accessibility information in another way (e.g., as a "comment", as a
backup copy of the input);" It would be great to add "accessible" to
"authors have the option to save the accessibility information in
another [accessible] way."

B.1.2.4(a) "Preserve Accessibility Information: The authoring tool
only automatically deletes web content that it can detect is not
accessibility information;" This is confusing. The non-accessible part
of web content that is associated with the accessibility information
should not be deleted.

B.1.2.4(b) "Notification Option: Authors have the option to receive
notification before deletion;" Add "and are warned that this may
result in web content accessibility problems in the output"

Guideline B.1.3 "Ensure that automatically generated content is
accessible" and note "See Also: If accessibility information is
required from authors during the automatic generation process, see
Guideline B.2.1." It's not clear how the SC under Guideline B.2.1 help
retrieve accessibility information from authors. Guideline B.2.3 seems
to be the most relevant for providing assistance, though "repair" may
not be fully accurate as it would apply to Guideline B.1.3. However,
given that "actions of authors" is exempt and seems to include the
provision of accessibility information (faulty or otherwise) then this
may be a moot point.

B 2.1.1 (a) and elsewhere term "accessible content" is used where
perhaps "conforming with WCAG 2.0" would be better.

B.2.3.1: Typo refers to Guideline B.2.2 should be, "as required by SC B.2.2.1."

B.2.4.1 Editable: "Authors are able to modify...," may be difficult to
test and it can be argued that it has been met in situations where
it's possible, but more difficult for an author with a disability to
make the change. Consider incorporating into the requirement or the
implementation guide something about the ease with which an author can
make the modification. The "at least as prominent" concept from
B.2.5.6 may be a way to address this concern.

B.2.4.2 Automated Suggestions: The use of the word "can" makes this SC
sound like it's optional. "During the authoring session, the authoring
tool can automatically suggest alternative content..." Suggest "can
[be configured to] automatically suggest...."

B.2.5.2 Provide Accessible Templates: Suggest incorporating a
requirement to clearly identify accessible template options. (ex. "If
the authoring tool provides templates, then there are accessible
template options for a range of template uses [and accessible
templates are clearly identified as such]." Another approach would be
to require that they be "at least as prominent as other templates.

B.3.2.1 Active by Default: Consider softening this requirement to
include a subset of support features (ex. those that relate to WCAG
Level A). Alternatively, consider changing the level of this SC. The
concern here is that automatic tests, especially at Levels AA and AAA,
often lead to repetitive and erroneous error and warning messages,
which could result in authors being motivated to turn off accessible
content support features altogether.

B.3.2.3 Deactivation Warning: Consider promoting this SC to Level A.

B.3.4.1, B.3.4.2, B.3.4.3: Consider adding a requirement to these SC
that the accessible examples be clearly identified and at least as
prominent as other examples in the documentation.

Conformance

Required Components of an ATAG 2.0 Conformance Claim #5 (Authoring
tool information): Consider adding information about the role and
requirements for information about extensions, plugins or modules that
may have modified or extended the authoring tool to meet a
requirement.

Required Components of an ATAG 2.0 Conformance Claim #6 (Web content
technologies produced): Consider dropping the requirement for a list
of technologies not included as this can be derived from the list of
technologies that the tool is capable of producing when compared to
the list of technologies included in the claim.

Required Components of an ATAG 2.0 Conformance Claim #7 (Declarations)
and Checklist: This requirement implies that each claim would have to
list each SC that is met. It should be possible to declare a range of
SC that have been met. (ex. All Level A). Additionally, inviting
claimants to declare success criteria that are not applicable may be a
slippery slope and often leads to inaccurate claims. Instead, suggest
including a statement that says that where an authoring tool does not
include a feature that is relevant to a given SC, then that SC is
automatically satisfied.

Waiving of WCAG 2.0's conformance requirement #4: Only
Accessibility-Supported Ways of Using Technologies. Many of ATAG's
success criteria rely on conformance with WCAG 2.0 but allow for
information or functionality provided in a way that is not
accessibility supported. This is potentially quite a loophole and can
easily mislead (intentional or not) the intended audience regarding
the production of content that conforms to WCAG 2.0.


Glossary

Many of the defined terms in ATAG 2.0 differ from those in WCAG 2.0
and/or make notes and examples from the WCAG 2.0 definitions a part of
the definition itself in ATAG 2.0 . We found the resulting definitions
confusing. We suggest synchronizing and formatting these definitions
so that they are consistent across the WAI guidelines. Examples
include "keyboard interface," "label," "non-text content" etc.

There were only three terms that were different enough to warrant a
review. We are concerned that it may not be clear to readers that
these definitions are intended to be the same. We would encourage you
to use the WCAG definitions as closely as possible, augmented by
additional information needed to address ATAG-specific considerations.


1. assistive technology: We suggest that you use the WCAG definition
with an additional note about authoring tools providing direct
accessibility features.

ATAG
assistive technology
    Software (or hardware), separate from the authoring tool, that
provides functionality to meet the requirements of users with
disabilities. Some authoring tools may also provide direct
accessibility features.

WCAG
assistive technology
    hardware and/or software that acts as a user agent, or along with
a mainstream user agent, to provide functionality to meet the
requirements of users with disabilities that go beyond those offered
by mainstream user agents

    Note 1: functionality provided by assistive technology includes
alternative presentations (e.g., as synthesized speech or magnified
content), alternative input methods (e.g., voice), additional
navigation or orientation mechanisms, and content transformations
(e.g., to make tables more accessible).

    Note 2: Assistive technologies often communicate data and messages
with mainstream user agents by using and monitoring APIs.

    Note 3: The distinction between mainstream user agents and
assistive technologies is not absolute. Many mainstream user agents
provide some features to assist individuals with disabilities. The
basic difference is that mainstream user agents target broad and
diverse audiences that usually include people with and without
disabilities. Assistive technologies target narrowly defined
populations of users with specific disabilities. The assistance
provided by an assistive technology is more specific and appropriate
to the needs of its target users. The mainstream user agent may
provide important functionality to assistive technologies like
retrieving Web content from program objects or parsing markup into
identifiable bundles.

[[Examples listed for assistive technology were the same for both documents.]]

2. programmatically determined: We suggest that you use the WCAG
definition and include your second sentence as a Note.

ATAG
programmatically determined (programmatically determinable)
    When information is encoded in a way that allows different
software, including assistive technologies, to extract and present the
information in different modalities. For non-web-based user
interfaces, this means making use of a platform accessibility
architecture. For web-based user interfaces , this means following
WCAG 2.0 so that the user agent can pass on the information.

WCAG
programmatically determined (programmatically determinable)
    determined by software from author-supplied data provided in a way
that different user agents, including assistive technologies, can
extract and present this information to users in different modalities

    Example 1: Determined in a markup language from elements and
attributes that are accessed directly by commonly available assistive
technology.

    Example 2: Determined from technology-specific data structures in
a non-markup language and exposed to assistive technology via an
accessibility API that is supported by commonly available assistive
technology.

3. non-text content: We believe that it is critical that your
definition include the phrase "can be programmatically determined".

ATAG
non-text content
    Any content that is not a sequence of characters that can be
recognized or where the sequence is not expressing something in human
language. This includes ASCII Art (which is a pattern of characters),
emoticons, and images representing text.

WCAG
non-text content
    any content that is not a sequence of characters that can be
programmatically determined or where the sequence is not expressing
something in human language
    Note: This includes ASCII Art (which is a pattern of characters),
emoticons, leetspeak (which uses character substitution), and images
representing text

Received on Saturday, 28 August 2010 00:38:09 UTC