- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 22 Mar 1999 21:59:44 -0500
- To: w3c-wai-gl@w3.org
Attendance:
Ian Jacobs (Chair, scribe)
Eric Hansen
Daniel Dardailler
Jason White
Charles McCathieNevile
Gregg Vanderheiden
Judy Brewer
Regrets:
Chuck Letourneau
Wendy Chisholm
Agenda [0].
[0] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0469.html
Reference document [1]
[1] http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-19990316
A) RESOLVED: To clearly indicate the division between author
responsibility
and user agent responsibility:
a) All checkpoints involving interim responsibility from
authors will contain the wording "Until user agents ..."
These checkpoints are: all of guideline 9, all of guideline 12,
checkpoint 15.4 (group related links), and 1.7
(Provide redundant text links for each active region of an
image map.)
b) For each checkpoint, include the "until" wording since
checkpoints may be read on their own. It is not sufficient
to say it in the guideline rationale.
c) Include an explanation of what "Until user agents..." means
in the glossary section.
Proposed text:
<BLOCKQUOTE>
In some of the checkpoints below, content developers are
clearly the best candidates for ensuring accessibility.
However, there are times when user agents would be the better
choice. Unfortunately, not all user agents or assistive
technologies provide the accessibility control users require
(e.g., some user agents may not allow users to turn off blinking
content, or some screen readers may not handle tables well).
To address cases where the responsibility for providing
accessible control lies with the user agent or assistive
technology but that control is not yet easily available, certain
checkpoints contain the phrase "until user agents ...". When
content developers see this phrase, they should recognize that
they are being asked to provide additional support for
accessibility until most user agents meet users' needs.
For each checkpoint with this phrase, content developers must
consider:
1.What is their anticipated audience? For example,
designing for a company intranet where everyone uses
the same browser is different than designing for the
World Wide Web.
2.Do those users have tools available that satisfy the
demands of the checkpoint?
If the answer to the second question is yes, content developers
are not required to satisfy the checkpoint.
How will content developers know when most user agents or
assistive technologies meet specific needs? The W3C WAI will
make this information available from its Web site (either directly
or by providing links to the information). Content developers
are encouraged to consult this information regularly for updates
on accessibility support.
</BLOCKQUOTE>
ACTION WG: Review this proposal.
B) RESOLVED:
Divide checkpoint 9.2 into two checkpoints:
a) Priority 1: Until user agents allow users to
control it, avoid causing the screen to
flicker. [Add note about epilepsy here.]
b) Priority 2: Until user agents allow users to control it,
avoid causing content to blink (i.e.,
change presentation at a regular rate,
such as turning on and off).
C) RESOLVED:
Proposed change in wording of Note in guideline 12.
The following checkpoints apply until
user agents and assistive technologies address
these issues.
D) RESOLVED:
Do references designated the latest versions
of documents or dated versions?
Proposed:
a) Add a link from checkpoint 13.1 (Use the latest W3C specs)
to the references section.
b) In the references section, add a statement about
where to find the current versions of W3C specs.
c) The list of references will contain dated versions so
that readers will know what existed when the guidelines
were created.
d) To each entry in the list, add a link to the latest
version.
ACTION IAN: Inform Misha, who raised this issue in [2]
[2]
http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0333.html
E) RESOLVED:
It's to say in guideline 1 that when text equivalent
is long, use description.
/* Note: This resolution is subsumed by a later one */
F) RESOLVED:
In 6.3, add to checkpoint the following text:
"including text equivalents (e.g., captions)"
G) RESOLVED:
All checkpoints in guideline 9 priority 2
except for the one about flicker.
H) RESOLVED: Changes for guideline 15.
a) Move note about LINK relationships from 15.3 to 15.2
b) Move 15.10 to after 15.3.
c) Change priority level of 15.6 to 2.
d) Merge 15.4 and 15.5 into a priority 2 checkpoint.
Proposed wording:
Provide information about the general layout
of a site (e.g., a site map, or table of contents).
e) For 15.9:
i) Proposed wording:
Provide information about document collections
(i.e., documents comprising multiple pages.).
ii) Make this an "until user agents" checkpoint.
iii) Techniques: LINK relationships, archives.
iv) Add more rationale (e.g., performance or cost
requires offline browsing)
I) RESOLVED:
In the Abstract, make clear that this is a reference document
and that for more practical information,
readers should consult the WAI Web site.
J) RESOLVED:
Add a definition of "assistive technology" to the glossary.
K) RESOLVED:
Add a section about document conventions, including:
a) Element names are uppercase.
b) Attribute names are quoted lowercase.
c) Linking conventions (to techniques document, to references,
to glossary, etc.)
L) RESOLVED:
All discussion of browser support for elements and attributes
is outside the scope of this document. State this in
the front matter.
M) RESOLVED:
Do not discuss accessibility v. usability in the document.
--
The following resolutions refer to the issues list [3] and
the numbers given here are those in the open issues list.
[3] http://www.w3.org/WAI/GL/wai-gl-issues.html
19) The Specifics of Conformance Claims
See proposal [4] from Judy and comments.
[4] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0483.html
20) Priority of checkpoints related to color
RESOLVED: For checkpoint 4.2,
[Priority 2 for images, Priority 3 for text].
21) Marking up lists
RESOLVED: Priority 2. This is not an editorial
issue (i.e., it's not about choosing to use lists).
22) BLOCKQUOTE for indentation
RESOLVED: Priority 2, notably since style sheets
can address this. Also, the way braille works
(according to Jason), blockquotes and inline are
treated identically.
23) Use of "title"
RESOLVED:
a) Say to use "title" according to HTML 4.0 spec.
b) Don't say anything about using "title" for images
that are not in links.
24) Priority of "Use latest W3C technologies" (Checkpoint 13.1)
RESOLVED
a) Wording: Use W3C technologies and use the latest
versions when they are supported.
b) Link to the discussion of "until user agents"
25) Priority of "Avoid deprecated features" (Checkpoint 13.2)
RESOLVED Wording: Avoid deprecated features of W3C technologies.
26) Priority of "Divide long lists into groups" (Checkpoint 14.5)
RESOLVED: Create a single Priority 2
checkpoint for managing groups of information.
Wording: Divide large blocks of information into more
manageable groups where natural and appropriate.
27) Who's responsible - author or user agent?
See point "A" above.
28) Clarity of natural language guideline (Guideline 6)
RESOLVED: Addressed with new guideline wording:
Clarify natural language usage.
29) URIs for references
See point "D" above.
30) LINK types.
See point "H" above.
31) Off-line reading techniques
See point "H" above.
32) Additional natural language issues?
See point "F" above.
33) Section numbering
RESOLVED in 16 March draft.
34) Consistent use of double priority
Proposal dropped
35) Statement of audience
RESOLVED: Don't add any statements in abstract about
intended readership.
PROPOSED: Add reference to policy makers to conformance
statement.
36) Information about assistive technologies
RESOLVED:
Create a W3C NOTE for this information rather
than including it in the guidelines other than
minimally. The glossary does contain some
short definitions.
37) Clarity of link destination
RESOLVED:
a) Many links cleared up in 16 March draft
b) Will add section on conventions.
38) Support for new elements and attributes
RESOLVED: All proposals are out of scope, covered already,
or will be dealt with at WAI Web site.
Support for "longdesc" doesn't belong here; UA
guidelines probably.
39) Interim support for table header info
RESOLVED: No change. (Lean to the future, use correct markup)
40) Proposal that background/foreground be specified
together to ensure contrast
RESOLVED: No additional checkpoint. This is a technique.
41) Proposal to restructure first three guidelines
/*
NOTE: At this point in the teleconference, the only participants
were Charles McCathieNevile, Jason White, Eric Hansen, and
Ian Jacobs. Judy was present, but working on the conformance
proposal.
*/
RESOLVED:
- Change priority of 3.4 to Priority 1:
(Provide a text version of the auditory
description and collate it with the text
transcript (captions) of the primary audio track.)
The last part of the teleconference call involved an
in-depth study of the first three guidelines, their purpose,
and their checkpoints. The following is a proposal to restructure
these guidelines.
RATIONALE:
i) The first three guidelines not organized clearly.
ii) There are several axes to consider here, including:
1. The format of the "primary" information: audio or visual
2. The format of the alternative information: text, audio, or
video.
3. The purpose of the alternative information:
text equivalent (function) or description (appearance)
iii) The distinction between "equivalent" and "description" is
not always clear. Equivalent information often contains
a descriptive component.
iv) The distinction between "alt" text and "longdesc" text is
an artifact of a choice made by the HTML 4.0 designers.
That the OBJECT element allows rich text equivalents indicates
that the "long versus short" argument is an implementation
detail.
REQUIREMENTS:
i) The most important concept to convey in the
revised guidelines structure is that authors
must provide information that will be equivalent when
rendered.
ii) Text is king (and thus all text equivalent information should
be Priority 1).
iii) Audio or video representations of information are secondary
(and Priority 2).
iv) All the visual information checkpoints may be combined into
one except where qualifications require separation.
PROPOSED:
i) Move checkpoint 1.5 to Guideline 11 (device-independence)
(Checkpoint 1.5 is: Provide client-side image maps
instead of server-side image maps except
where the regions cannot be defined with
an available geometric shape.)
ii) Move checkpoint 1.8 to Guideline 5 (Use markup and style
sheets appropriately).
(Checkpoint 1.8 is: Provide individual button controls
in a form rather than simulating a set of buttons with an
image map.
iii) Proposed: For the part of checkpoint 1.6
involving a link to skip over ascii art, move
to guideline 15 as a priority 2 checkpoint.
iv) Proposed: For the part of checkpoint 1.6
involving using an image instead of ascii art,
create a new checkpoint (priority 2) in guideline 5 about
using images rather than text to provide visual
information. Ensure cross references to other
ascii-art guidelines.
v) Reduce guidelines 1, 2, and 3 to one Guideline,
to read: Provide equivalent information for
visual and auditory information.
The rationale will have to be rewritten based on the
rationales from the three guidelines. The main points
to emphasize are that:
a) The goal is to provide information that may
be used to create an equivalent browsing experience.
b) Function is vital, description may be part of
function. Thus, there will no longer be a separate
topic of "description" - this will be included in
the definition of "equivalent". The implementation
details of which attributes to use and when will
be in the techniques document.
c) Text is king, audio and video equivalents are
useful but text can be rendered as speech,
graphically, or by a braille device.
d) Synchronization is important when equivalents
are interwoven over time.
e) ASCII art has to be carefully defined (e.g., to
not include a smiley, which, in certain circles,
is just a accessible as an abbreviation, and in
other circles, just as obscure. This is
arguably different than using characters
to create an image.
vi) Proposed checkpoints. Each checkpoint will start with
its new number followed by a slash and its old number.
The end of the checkpoint will list the old checkpoint
number(s).
1.1 Provide a text equivalent for every
non-text object. Priority 1. Was checkpoints 1.1,
1.2, 1.3, 1.4, 2.1, 3.1, 3.3, and 3.4. This includes:
images, graphical representations of text,
image map regions, animations (e.g., animated
GIFs), applets, ascii art, scripts, inserted
list bullets, sounds, synthesized speech, audio
tracks of video, and video.
NOTE: Include a cross-ref here to
the (proposed) checkpoint in guideline 15 about
skipping over ascii art. This includes images
as bullets.
QUESTION: From "Provide a text equivalent for every
sound played automatically,"
What does "automatically" mean?
1.2 Provide redundant text links for each active region of an
image map. [Priority 1 - if server-side image maps are used,
Priority 2 - if client-side image maps are used.
Content developers will not need to provide redundant text
links for client-side image maps once most user agents render
text equivalents for the map links.] Was checkpoint 1.7.
1.3 Ensure that audio information played simultaneously
remains comprehensible. Priority 1. Was checkpoint 3.2.
Example: Weave audio tracks and audio descriptions
so they overlap comprehensibly.
1.4 Synchronize equivalents that evolve together
over time. Priority 1. Examples:
a) Subtitles and video must be synchronized.
b) Collate text equivalents of audio tracks
and audio equivalents.
1.5 Provide non-text equivalents where they
facilitate comprehension of the page. Priority 2.
Example: video representation of an applet,
icon representation of text, audio description
of video, recorded spoken text, etc.
Was checkpoint 2.2, 8.5, 16.2
Received on Monday, 22 March 1999 22:00:52 UTC