W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 1999

Minutes from 13 April Working Group Teleconference

From: Ian Jacobs <ij@w3.org>
Date: Wed, 14 Apr 1999 08:17:46 -0400
Message-ID: <3714876A.B1FE613@w3.org>
To: w3c-wai-gl@w3.org
Chair: Gregg Vanderheiden
       Chuck Letourneau
Scribe: Ian Jacobs

Wendy Chisholm
Jason White
Charles McCathieNevile
Gregg Vanderheiden
Eric Hansen


CHARLES: What about mixed-case problems? Difficult for
some users to process. Should this be a technique?
Don't encode information in all-caps only.

GV: Device-independence issues.

IJ: Case not well-defined for all languages.


Issue 1.) Bug-8.  Note that is recently underwent a revision and
therefore might be expected to require some editing. As noted, the
reference to "synthesized speech" as requiring a "text equivalent"
would not be comprehensible without further explanation.

RESOLVED: Delete reference to synthesized speech.

/* Eric Hansen joined here */

Issue 2.) Bug-9.  Checkpoint 14.2 mistakenly makes reference to
equivalents "to text".  [Provide visual or auditory equivalents to
text where they facilitate comprehension of the page.]

RESOLVED: Edit the checkpoint to read, "Supplement text
with graphic or auditory presentations where they will facilitate
comprehension of a page."

ALSO RESOLVED: Remove note about helping non-readers - it's too
simplistic to try to communicate through symbols only. Remove
the Note and discuss it in Techniques.

Issue 3.)  Bug-10. The possibility of synchronizing text equivalents
for video was not acknowledged in checkpoint 1.3 [For each movie,
provide an auditory description of the video track and synchronize it
with the audio track.]

Proposed resolution: This idea is in checkpoint 1.4 [For any
time-based presentation (e.g., a movie, animation, or multimedia
presentation), synchronize equivalent alternatives (e.g., captions or
video descriptions) with the presentation.]  However, since it seems
completely redundant with a portion of 1.4 have we left out an idea or
has 1.3 been misrepresented?  The editors will compare an older
version with the latest and if nothing has been left out, delete this
checkpoint.  Otherwise, bring a new proposal for the wording of 1.3 to
the group on Thursday.

1.3 is about providing a description.
1.4 is about synchronization.
 a) Edit 1.3 to make synchronization parenthetical
 b) Change wording of 1.4 to "equivalent alternatives must be

PROPOSED: Until most video player technologies can generate an audio
description of the video track from a text equivalent (see
checkpoint 1.1), provide an auditory description of the video track]
(synchronized with the audio track as per [#Tsynchronize-equivalents])

Issue 4.) Bug-11. The word "visual" is used to describe non-text
elements, even though text is usually rendered in a visual manner.

Proposed resolution: The editors will reread the document to ensure
that visual is use appropriately, especially in regards to presenting
text.  If something earth shattering is revealed, the editors will
bring it to the discussion on Thursday.

ACTION Editors: review the document for this.

Issue 5.  Bug-12. The need for text equivalents for ASCII art was
cited in two checkpoints (1.1 and 1.5). [1.1 - Provide a text
equivalent for every non-text element.  1.5 - Replace ASCII art with
an image or explain it.]

Proposed resolution: Delete checkpoint 1.5.

Jason: Sufficiently rare that doesn't warrent a checkpoint.
Put it in techniques document.

  a) Delete checkpoint 1.5.
  b) Discuss equivalents for ascii art in techniques docuemnt
  c) Put link to glossary example in 13.10

Issue 6.  Bug-13. The description of the relationship between the
terms "assistive technology", "screen reader", and "user agent"
is not consistent throughout the document.

Proposed resolution: The editors will reread the document to ensure
that these terms are used consistently.  If something earth
shattering is revealed, the editors will bring it to the
discussion on Thursday.

ACTION Editors: review the document for this.

Issue 7.  Bug-14. The guidelines document does not claim
a conformance level.

Proposed resolution: Add the following statement at the end of the
Conformance section, "The <a href="#claim">conformance claim for this
document</a> is located at the end of the document."

 a) Make this document Triple-A compliant (Yikes!)
 b) Use the icon (if availble).

Proposal: Say "do not" instead of "avoid"
GV: "avoid" conveys meaning that there is an alternative.
    "do not use" does not.

EH: But "avoid" also implies "discretion". I tried to but
    I couldn't.

Examine each case:

 1) Avoid using tables for layout.
 2) Avoid causing the screen to flicker.
 3) Avoid causing content to blink.
 4) Avoid movement in pages.
 5) Do not cause pop-ups or other windows.
 6) Avoid deprecated features of W3C technologies.


ISSUE: PRIORITY 2 for all tables for layout? (checkpoint 5.3)

IJ: W3C Home page works fine. Why priority 2 if my table
    degrades gracefully?
GV: If we have a table linearizer, would this drop to Priority 3?
WC: You could use frames (but this is probably more troublesome
    than tables).

Proposed: Do not use tables for layout unless they
          render logically when table markup is ignored.

Wendy: The GL used to say 'If you can't use style sheets,
it's ok to use tables "until supported"'.

10.3 is problematic as well. It's not about "rendering".
It's about getting at data cell-by-cell (e.g., navigation).

JW: Cell-by-cell navigation is still a significant nuisance -
understanding the logical order of a document.

JW: If you don't use tables but you do use style sheets,
other elements (e.g., P) will be used properly. Otherwise,
if tables are used, TH is abused.

JW: Don't like confusing structure with tables for layout.

CMN: There are abuses that don't compromise accessibility. But
   that doesn't mean we shouldn't care.

PROPOSED: Priority 1:
      Any table used for layout must make sense when
      table markup is ignored.
    Make clear in note that this is an abuse of tables.

JW: If same markup is used for layout as for tabular information,
and can't be automatically distinguished, user must go through
manipulations to figure it out.

ACTION Ian: send proposal to list.
Received on Wednesday, 14 April 1999 08:16:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:29 UTC