Re: Kynn's Feedback on AERT 26 April 2000 Draft

Kynn,

thanks for your comments.  My responses are interspersed and prefixed with WC::


>These comments are based on the 26 April 2000 draft of AERT
>(http://www.w3.org/TR/2000/WD-AERT-20000426)
>
>To Do list:
>
>  1.  The term "author" is preferable here to "user" -- as with
>      the Authoring Tool Accessibility Guidelines, "author"
>      should refer to the person creating/preparing content for
>      the web, and "user" to the end user, even if the author
>      is a "user" of specific software.

WC:: I had an interesting discussion yesterday with someone who said that 
"author" and "designer" imply very different things and both will be users 
of the tools being developed.  therefore, i'm not sure that we want to 
limit it to "author" but I also don't think it makes too much of a 
difference as long as we are consistent and people know what we mean when 
we use a chosen term.

>Introduction
>
>  1.  The specific purpose of this document is unclear to me; while
>      I understand what it does, I am unable to discern the exact
>      scope and goals of AERT.  The use of priorities (inherited
>      from WCAG) and of "absolute language" in many guidelines
>      make this sound as if it were a normative document, not a
>      list of suggestions.

WC:: I'm not sure what you mean by "absolute language."

What if we modify the second paragraph in the Introduction to read:
<blockquote>
This is an informative document that builds on the WCAG 1.0 foundation by 
outlining techniques that evaluation and repair tools may use to uncover 
accessibility problems and possibly repair them. These techniques may be 
used by those who create web authoring tools or by anyone interested in 
creating accessible Web documents.  Tools are not expected to conform to 
the processes in this document.  This is not a definitive list of what an 
evaluation and repair tool must perform.  It is expected that tools may be 
developed that focus on one technique while others will try to implement 
all of the techniques depending on the goals of the tool.
</blockquote>

Also, I propose that we cut the last paragraph of the introduction and 
rework the 2nd to last paragraph to read:
<blockquote>
Many people creating content for the Web will not be familiar with the 
various markup languages that are used. Many others will not know about Web 
accessibility. Tools should be intuitive and easy to use and available at a 
minimal cost. Tools should not generate excessive warnings or false 
positive accessibility errors.  However, this document does not address how 
to interact with the author. Please refer to the Authoring Tool 
Accessibility Guidelines for information on dialog and interface techniques 
for creating authoring tools.
</blockquote>

note that this assumes that we will take the "suggested language" sections 
out of this document and synch them with the ATAG techniques as we 
discussed at the face2face.  we have not completely reached consensus on 
how or what to do. we need to start a thread on that.

>  2.  Is the goal to be a "collection of good things to do", a "list
>      of minimal functionality", a "comprehensive list of every
>      way to evaluate a web document" or something else?  The
>      answer will have a definite effect on the software tools
>      developed and how they use this document.  If this strives
>      to be a "definitive listing," for example, this could adversely
>      affect the ability of companies to produce commercial ERT
>      tools that have competitive advantages.

WC:: no, this is not a definitive listing.  this is informative.  it's a 
collection of brainstorms for people to pick from.

>  3.  An explanation of this document relates to the Authoring
>      Tools Accessibility Guidelines and techniques would be
>      useful -- otherwise the possibility for confusion exists.

WC:: agreed. perhaps even more should be added to the paragraph i just 
proposed.

>Structure of this Document
>
>  1.  The nature of the inherited checkpoint priorities needs to
>      be addressed -- is the listing of WCAG priorities meant to
>      be merely informative or are ERT tool creators expected to
>      follow those?

WC:: informative.  we have inherited the priorities from WCAG.  many tools 
need to know what the priorities are as we expect that people will 
implement P1 checks first.

again, there is no conforming to this document. it is informative.  i tried 
to clarify that in my first proposal (at the beginning of this message).

>  2.  When a repair strategy is suggested, it should be made clear
>      that the options provided are not the only ones that could
>      be made available to an author -- and in all cases the author
>      should have the ability to override the tool at any point
>      in the process.

WC::those are ATAG issues (guidelines in fact) .  as just stated, i think 
we will be moving the interface information to the ATAG techniques.

>Technique 1.1.1:
>
>  1.  NULL "alt" values (alt="") should be allowed.

WC:: this is an unending argument that i will not address here.


>  2.  The use of the term "suspicious" is, well, suspicious, or at
>      the very least could be avoided.  In English, this word has
>      a connotation of "deceit" and "guilt" that are not appropriate
>      for suggested messages or even for internal use.   A better
>      term should be selected, such as "Potential Accessibility
>      Problem" or "Requires Manual Check", which are value-neutral.

WC:: we are not suggesting that any of the text in the "Evaluation" 
sections of each technique be used in the interface.  this is part of the 
algorithm that a tool should implement.  if a suspicious pattern is 
identified, then it should trigger an action within the tool.  this action 
might be performed automatically by the tool or it may require the author 
to do something.

I can see changing the text in the "suggested message" section, however I 
think this section will be changing greatly or incorporated into ATAG 
techniques.

>  3.  The suggested message for missing text equivalent should
>      explicitly mention the "alt" attribute, simply because many
>      web designers are likely to be familiar with the term.
>      Revised suggested message:  Missing text equivalent ("alt"
>      attribute) for image.
>
>  4.  Suggested text for "longdesc", however, will always need
>      further explanation, as this attribute is not familiar to
>      most web authors, and can lead to confusion easily -- for
>      example, many people will incorrectly guess that "longdesc"
>      is simply a longer text string, a la "alt", rather than
>      a URI reference.

WC:: refer to previous comments.

I will respond to this rest of your suggestions later today.  thanks again 
for the comments.
--wendy
--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Tuesday, 23 May 2000 09:06:10 UTC