[DRAFT] Compiled EOWG comments on ATAG 2.0 Last Call WD

EOWG,

Following is a draft compilation of EOWG and EO Lexicon Task Force comments 
on ATAG 2.0 Last Call WD.

Please review this draft compilation and send clarifications to the EOWG 
list, w3c-wai-eo, by Tuesday 8 February, if you feel that clarifications of 
these comments are essential. I won't be including any new comments in this 
compilation since we won't have had the chance to discuss them together, 
but comments can always be sent separately to the AUWG mailing list.

Since this draft compilation is even later than the extension which Jutta 
Treviranus and Matt May (Chair and Team Contact of AUWG) gave us, I will 
provide them a link to this message so that they can get a rough idea of 
our comments. I will take whatever clarifications comments come in by the 
end of the day Tuesday and send a completed version of these comments to 
the AUWG mailing list.

Thank you,

- Judy

-----

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/
and 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 the introduction, 
the guidelines, and the glossary. Please see the introductory note at the 
beginning of the glossary comments section.

If you need clarification of any of our comments, please let us know.

Regards,

- Judy Brewer, on behalf of the 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.

Specifically:

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

- [@@EOWG please check this point] Check for recursive links ("authoring 
interface checkpoints" and ISO document).

- 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. Break 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 formed a "Lexicon Task Force" that is setting up a "Beginners' 
Lexicon for WAI Documents" of WAI a small set of terminology. This will be 
short lexicon with definitions in clear and simple language. The purpose 
this beginners' lexicon is to assist translators of WAI documents, as well 
as people new to Web accessibility, by describing the meaning of technical 
terms with a meaning specific to the Web accessibility context.

The following definitions are ones where we would be likely to change them 
slightly or significantly, 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 Monday, 7 February 2005 05:12:58 UTC