W3C home > Mailing lists > Public > public-atag2-comments@w3.org > June 2009

comments on ATAG 2.0 working draft of 21 May 2009

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Tue, 9 Jun 2009 16:25:41 -0700
Message-ID: <824e742c0906091625v17d31619j2e26a91701b1df33@mail.gmail.com>
To: public-atag2-comments@w3.org
Note: these are comments from a review that was separate from the WCAG
WG review. Issues that were already covered by the WCAG WG have not
been repeated here. There is a mixture of editorial and substantive
comments, listed in the order they occur in the document.

    * Is it clear how Guideline B.2.4 ("Assist authors with managing
alternative content for non-text content.") would apply to website
authoring tools? Is it clear how it would apply to content management
systems or photo repository sites?

See comments below on specific issues with some of these SC. The
phrasing of B.2.4.2 leaves things a little vague wrt testing. "can
automatically suggest ... under the following circumstances" sounds
like it is also ok to suggest under different circumstances, or not to
suggest under these circumstances.

    * Does the Glossary definition of "prominence" provide guidance
for objective testing?

See comment on definition for a problem with the current definition.

    * Do the new examples of authoring tools in the Introduction
sufficiently illustrate and differentiate between web and non-web
functionality?

The examples are helpful for understanding the wide range of authoring
tools, and where authoring is a small piece of a larger application.
However, as commented below, I think the introduction doesn't  clarify
web and non-web functionality, and that an authoring tool may be one
or the other or a mixture.

    * Are there any areas in which the guidelines may be lacking?

No.


* Comment 1 (editorial):
In the "Understanding Levels of Conformance" section,  "essential" is
described as
    "even the authoring tool user interface cannot make content accessible"
I don't understand what this means, since the UI is not making the
content accessible. Perhaps this should be "the author cannot use the
authoring tool user interface to make content accessible"?

* Comment 2 (editorial):
Part A. Applicability Notes, item 2 (Reflected Content Accessibility Problems):

I found this paragraph difficult to understand from the wording. I did
finally understand the point, but it took work. Suggest:
"The authoring tool is responsible for ensuring that the content being
edited is accessible to people with disabilities (e.g., ensuring that
an image label in the content is available via the platform). However,
where an authoring tool user interface accessibility problem is caused
directly by a Web content accessibility problem in the content being
edited (e.g., if an image in the content lacks a label), then this
would not be considered a deficiency in the accessibility of the
authoring tool user interface."

* Comment 3 (editorial):
Guideline A.1.1:

I can't understand the rationale; there is something odd about the way
the different ideas in the sentence are being related to one another.
Is this trying to point out that Web applications can be authoring
tools, and that they need to conform themselves? Does it only cover
web applications because this is a W3C web accessibility spec?

* Comment 4 (editorial):
Guideline A.1.1, Applicability Notes:
Guideline A.1.2, Applicability Notes:

In the applicability notes, perhaps you want to start with something
like "An authoring tool may combine web-based functionality with
non-web-based functionality." Or perhaps this distinction needs to be
introduced earlier. The use of "also" in the applicability note is
confusing, particularly without introducing the concept of
applications that are partly web-based and partly non-web-based/

* Comment 5 (editorial):
Guidelines A.1.2:

Suggest dropping "that are not user agents" from the rationale.
Although by the glossary definition, user agents refer to renderers for web
content, I think the distinction between a browser that is displaying
web content and the same browser displaying a local HTML file will be
lost on most readers.


* Comment 6 (editorial):
Guideline A.2.2:

The rationale is very hard to understand again. "information signified
by presentation added by the authoring tool"? "content rendering
editing views"?


* Comment 7 (editorial):
SC A.2.2.3:

It is confusing that one of the examples used (text size) is
already covered by A.2.2.2. You might just omit the examples
completely as part of the success criterion.


* Comment 8 (editorial):
SC A.2.3.1

"content rendering editing views" again. Maybe introduce this
concept in the introduction? and maybe use a simpler phrase?

* Comment 9 (substantive):
 SC A 3.2.3:

 Why is this limited to components that accept mouse input?

* Comment 10 (editorial):
SC  A.3.5:

 It is confusing that the guideline says "for authoring tool user
interface" when the text search appears to address searching the web
content. The guideline seems to imply that users should be able to use
text search to find menu commands, for instance.

* Comment 11 (editorial):
Guideline A.4.1, Applicability notes:

 Typo: "to to"

* Comment 12 (editorial):
Part B applicability notes #3:

It is very hard to understand the first sentence.

* Comment 13 (substantive):
SC  B.1.1.2:

What does it mean to provide Web content technology options?  does
this mean choices of output format?

* Comment 14 (editorial):
 SC  B.1.2.2 typo: "output of a the transformation"

* Comment 15 (substantive):
SC  B 1.2.2 (a):

Why "if possible"? does this introduce testability problems?

* Comment 16 (substantive):
SC B 2.2.1, 2.2.5, 2.2.9:

Do reasonable authoring tool checks exist for all success criteria?
This could introduce a lot of "noisy" checks that just ask authors to
perform a manual check. This tends to clutter up the checking workflow
and encourages authors to ignore it.

* Comment 17 (substantive):
SC B 2.2.2:

Is this checking the same checking as in SC 2.2.1? If so, is a
separate guideline needed?

* Comment 18 (editorial):
Guideline B.2.2 Applicability notes:

I don't understand the comment about manual checking, and how this
relates to 2.2.1, etc. I hope this doesn't require "checks" of the
nature "perform the following manual check".

* Comment 19 (editorial):
SC B.2.3.3:

What is "repair assistance"? What does it mean to provide it? Does
this just mean that it is possible to repair the error?

* Comment 20 (editorial):
SC B.2.4.1 typo: This includes types of alternative content that may
not typically <ins>be</ins> displayed on screen by user agents.

* Comment 21 (editorial):
SC B 2.4.3:

Suggest using "data" or "values" rather than "text content", since the
latter sounds like it is limited to rendered content, while the repair
text is likely to be derived from some sort of metadata.

* Comment 22 (substantive):
SC B 2.4.4:

Whose recommendations? It is hard to know whether you have met this SC
without knowing that, especially if there are conflicting
recommendations from different sources.

And for the specific example of null alt text, the authoring tool
can't determine whether a null alt is needed or is being used
appropriately.

* Comment 23 (editorial):
Examples in the success criteria statements (e.g. parentheticals in
the success criteria) nearly always refer to text alternatives for
images. Are there any other
examples that could be used? One comes away with the impression that
authoring for accessibility is all about alt text....

* Comment 24 (substantive):
"Partial" conformance:

ATAG's use of the term partial conformance is different from WCAG's
use of the concept, which only applies when a web page contains
content that is
not provided by the author. Partial conformance does not mean that
only some of the SC at a level have been satisfied. Many people
misunderstand WCAG's partial conformance to mean something more like
ATAG's. Would it be possible to use a different term, to minimize that
confusion?

* Comment 25 (substantive):
Conformance:

I suggest not including status as part of a conformance
claim. people should not be claiming conformance to a working draft.

* Comment 26 (editorial):
Note on Required Components of an ATAG 2.0 Conformance Claim, item 4:
What is the significance of this note? The burden of what? The
substance was already covered by pointing out that anyone can make a
conformance claim. The note somehow implies that authoring tool
developers shouldn't be asked about their products.

* Comment 27 (editorial):
Required Components of an ATAG 2.0 Conformance Claim, 5(b):

Must a claim cover all the technologies that can be generated by an
authoring tool? can a claim be made for the use of a tool to generate
technology X? - oops, I see this is addressed by 59(d). Can (b) be
worded so it is clearer? Maybe "(b) A list of the Web content
technologies edited/produced by the authoring tool that are covered by
the conformance claim."

* Comment 28 (editorial):
"Progress Towards Conformance" Statement:

Iit is extremely unlikely that developers will be able to provide
timeline information, even if they have
development plans. "encouraged" is ok, but will still probably be the exception.

Glossary:

* Comment 29 (editorial):
Accessibility information:

"added to" - the implication being that the
information would not be present except to provide accessibility. Does
adding heading markup or other semantic mark-up count as accessibility
information?

* Comment 30 (substantive):
Prominence:

Bullet c) works if you are comparing the prominence of 2
items, but when there are more than 2 items, it becomes impossible for
more than 2 to have the same prominence. This is a problem. the
definition probably needs to be generalized to groups of items having
the same prominence.

* Comment 31 (editorial):
Appendix Editors:

Missing close parens: Roberto Scano (IWA/HWG
Received on Tuesday, 9 June 2009 23:26:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 9 June 2009 23:26:18 GMT