EOWG comments on ATAG 2.0 Last Call WD

Dear AUWG Participants,

Please find, below, comments compiled from several EOWG discussions of your 
22 November 2005 ATAG 2.0 Last Call Working Draft:
         http://www.w3.org/TR/2004/WD-ATAG20-20041122/
for which the Call for Review is available at:
         http://lists.w3.org/Archives/Public/w3c-wai-ig/2004OctDec/0221.html

Our comments are divided into three sections: comments on (A) the 
introduction, (B) the guidelines, and (C) the glossary. Please see the 
explanatory note at the beginning of the glossary comments section.

I apologize for the delay in transmitting these comments to your WG. I'd 
previously given Jutta and Matt a link to EOWG's draft comments under 
discussion, so they should already be familiar with the general content.

If you need clarification of any of our comments, please let us know. In 
particular, Shawn hopes to follow up with your group on several of the 
comments.

Thank you for the opportunity to comment.

Regards,

- Judy Brewer, on behalf of EOWG

-------

EOWG Comments on ATAG 1.0 Last Call Working Draft, 22 November 2005

A. Comments on ATAG 2.0 LCWD Introduction:

In general:

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

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

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

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

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


B. Comments on ATAG 2.0 Guidelines
----------------------------------------------

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

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.

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.

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

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.

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.

Success Criteria: In the success criterium, the terminology "must always 
conform" seems awkward. Why not just say "conforms"? e.g.: Current: "At 
least one full-featured Web-based authoring interface must always conform 
to WCAG." Suggested replacement: "At least one full-featured Web-based 
authoring interface conforms to WCAG."
If concerned about "always", could put that in the preface text.


C. Comments on ATAG 2.0 Glossary
--------------------------------------------

Explanation of the following comments:

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.

- User Agent
Software to access Web content, including desktop graphical browsers, text 
browsers, voice
  browsers, mobile phones, multimedia players, plug-ins, and some software 
assistive
  technologies used in conjunction with browsers such as screen readers, screen
  magnifiers, and voice recognition software.


[1] Info on EO Lexicon Task Force:
- First draft of a Lexicon overview:
http://www.w3.org/WAI/lexicon/Overview.html
- Lexicon requirements document:
http://www.w3.org/WAI/EO/changelogs/cl-lexicon
- Lexicon Task Force Work Statement:
http://www.w3.org/WAI/EO/2004/lexicon.html
- Lexicon list archives:
http://lists.w3.org/Archives/Public/public-wai-eo-lexicon




-- 
Judy Brewer    +1.617.258.9741    http://www.w3.org/WAI
Director, Web Accessibility Initiative (WAI), World Wide Web Consortium (W3C)
MIT/CSAIL Building 32-G530
32 Vassar Street
Cambridge, MA,  02139,  USA

Received on Wednesday, 23 February 2005 14:56:42 UTC