- From: Harvey Bingham <hbingham@acm.org>
- Date: Sat, 27 Nov 1999 14:21:33 -0500
- To: w3c-wai-au@w3.org
Previously sent to wai-au-review@w3.org 1999-11-13. Charles McCathieNevile
requests I resend them to this group.
Meta Notation:
XomitX
_insert_
?hb: question?
!hb: observation!
Abstract Para 2:
It is equally important that _any person_ Xall peopleX can be the
_author_XauthorsX of Web content, rather than merely _a
recipient_XrecipientsX.
!hb: authors of Web content suggests collaborative authoring!
1. Introduction
* Tools for site management or site publication, including tools that
generate Web sites dynamically from a database, on-the-fly conversion
and Web site publishing tools;
Para after bulleted list:
... Because most of the content of the Web is created using authoring
tools, they play a critical role in ensuring the accessibility of the Web.
!hb: I believe today that most content is actually generated dynamically!
!hb: In this means for generation, the role of authoring tools needs to
be extended to allow accessibility support for such dynamically generated
content. Another sentence should assert that the script design for that
dynamic content, and its accessibility implications, is done with script
authoring tools. The guidance for how to generate the needed accessibility
supporting information must be part of the instructions/scrips for that
dynamic generation. !
Checkpoint 2.1 Use the latest versions of W3C Recommendations when they are
available and appropriate for a task. [Priority 2]
!hb: In practice there is a time lag from the "latest version" until
software can be upgraded to conform to that checkpoint. Just because W3C
comes out with a new recommendation doesn't automatically downgrade a
prior product's asserted conformance level to the earlier version. !
Paragraph following those 2.N checkpoints:
...one of the XmostX_more_ challenging aspects of Web design. ...
!hb: most is an absolute; more doesn't suggest all have that same absolute.!
Checkpoint 5.2
Ensure that [WAI-WEBCONTENT] Priority 1 accessible authoring practices are
among the _more_ XmostX obvious and easily initiated by the author.
[Priority 2]
Guideline 6 first para
The issues surrounding the creation of accessible Web content are often
unknown to Web authors. Help and documentation _must_ include explanations
of accessibility problems, and should demonstrate solutions with examples.
?hb: must or should?
Guideline 7
Para 2
Some additional user interface design considerations apply specifically
to Web authoring tools. For instance, authoring tools must ensure that
the author can edit (in the editing view) using one set of stylistic
preferences and publish using different styles. For instance, authors
with low vision may need large text when editing but want to publish
with a smaller default text size. The style preferences of the editing
view must not affect the markup of the published document.
!hb: Seems to need some amplification on authoring tools for styles and
for scripts. A separate style may be appropriate for different assistive
technologies, as well as for the distinction: authoring vs. user. I do
not find any particular discussion of authoring tools for styles and how
those styles may be presumed to inject accessible information about content,
such as link counts, or preceding and following information about element
content. !
Definitions
Attributes This document uses the term "attribute" as used in SGML and XML
([XML]): Element types may be defined as having any number of attributes.
In the following example, the attributes of the beverage element type are
"flavour", which has the value "lots", and "colour", which has the value
"red":
<beverage flavour="lots" colour="red">my favourite</beverage>
!hb: "lots" doesn't seem an appropriate choice to describe a flavour.
Suggest "sweet".
Auditory Description An auditory description provides information about
actions, body language, graphics, and scene changes in a video. They 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 auditory
description is either a pre-recorded human voice or a synthesized voice
(recorded or generated on the fly). The auditory description must be
synchronized with the audio track of a video presentation, usually during
natural pauses in the audio track.
!hb: An auditory description may also be synchronized with the textual
content as it is read, say to support low-vision use of a magnifier.
The auditory description may be in a different natural language than that
of the normal sound track of the video. !
Captions: Captions are essential text equivalents for movie audio. Captions
consist of a text transcript of the audio track of the movie (or other
video presentation) that is synchronized with the video and audio tracks.
Captions are generally rendered graphically and benefit people who can see
but are deaf, hard-of-hearing, or cannot hear the audio.
!hb: Captions generally should include Auditory Description. Different
captions may be supplied in different national languages. !
Markup Language: Authors encode information using a markup language such as
HTML ([HTML40]), _an application of XML,_ SVG ([SVG]), or MathML ([MATHML]).
!hb: need link there, to XML spec. !
Prompt ... (such as alternative text)
?hb: That link in the glossary gets to the name: Alternative information
(Equivalent Alternative). Consistency?
5. References
No mention of CSS or SMIL.
Regards/Harvey Bingham
Received on Saturday, 27 November 1999 14:24:13 UTC