W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2000

Raw minutes from 14 September UAWG teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 14 Sep 2000 16:01:00 -0400
Message-ID: <39C12E7C.85A63084@w3.org>
To: w3c-wai-ua@w3.org
14 September 2000 UA Guidelines Teleconference

 Jon Gunderson (Chair)
 Ian Jacobs (Scribe)
 Eric Hansen
 Tim Lacy
 Kitch Barnicle 
 David Poehlman
 Charles McCathieNevile
 Mickey Quenzer
 Jim Allan
 Harvey Bingham

 Rich Schwerdtfeger
 Gregory Rosmaita

Next meeting: 19 September

Minutes of previous meeting 12 September:

Regrets: Charles


Review Action Items


    1.Extra telecon on 19 September 1:30-2:30 EST USA


    1.Issue 257: 4.17 Allow the user to configure the user agent 
      so that after one viewport is open, no other viewports 
      open except as the result of explicit user
      request. [Priority 2]

   /* Ian reviews proposed 4.17 */
   CMN: You don't want the viewport to obscure the history. You
   want viewports to carry over history. (i.e., don't obscure the

   IJ: Note that this is not an issue of focus: I can configure my
   Linux box (and have it configured thusly) to not switch focus
   when new windows open.

   CMN: Often, in full-screen mode, a viewport replaces another
   and doesn't carry forward the history. You can't go back.
   And this confuses the user even more.

   TL: I agree with the proposal, as long as it's configurable
   by the user. 

   JG: True, if a new window opens and is not on top, and there's no
   room for it, it would appear "minimized". How would you know that
   something happened?

   IJ: Yes, notification is missing. (Just like last week's

   TL: You could call the task switcher. In Windows, you can raise
   a dialog that something has happened. 

   JG: Make both same priority?

   IJ: Note that a dialog box is not a viewport.

   JG: For partially obscured graphical viewports. 

   IJ: I propose adding a requirement for notification to the
   second proposed checkpoint.

   JA: Need to ensure cross references with checkpoint on 
   focus shifts.

   IJ: Another wording: Configuration so that the graphical
   viewport with focus is "on top" (i.e., nothing is in front
   of it). Notify the user when the configuration is in place.

    a) Accept proposal with following changes:
     i) Reword second checkpoint to avoid "obscure"
        (e.g., "Configuration so that the graphical
         viewport with focus is "on top" (i.e., nothing is in front
         of it). Notify the user when the configuration is in place.")
    ii) Add notification to second checkpoint.

   3.Issue 313: On Prompt/Notify/Advise/Alert
   Refer to issue

   IJ: Does prompt mean for user interaction?
       Does notify not mean that?
    a) Alert means no user response required.
    b) Prompt means user response required.
    c) s/advise|notify/alert
    d) Leave 1.5 as is.
    e) Add definitions of alert and prompt.
       CMN: There's a definition of prompt in the ATAG

   2.Issue 312: Checkpoint 7.5: Serial renderings and search

   EH: Refer to my proposed wording:

   IJ: Refer to clarification

   MQ: What about notification when you don't find something?
   a) Adopt proposal:
   b) Add requirement to move point of regard.
   c) Add notification when search not found.
   d) Add a technique to provide orientation by stating the number of
   e) Add a technique to allow the user to easily search
      from the top, backwards search, etc.

   5.Issue 315: Definition of terms text and non-text in 
     checkpoints 7.5, 2.5, 2.6, 1.5, 3.8

   /* IJ summarizes EH proposal */
   IJ: Text means sequence of characters from doc char set. Text is
   the base term. EH wants to build on top of "text" with "text element"
   or "non-text element". 

   EH: There may be better terms than "text element" because "text
   may have another meaning in another context. What I want "text
   to mean (w.r.t. WCAG 1.0) is: "pre-rendering content that is
   when rendered as synthesized speech, visually displayed text,
   Key to this is that the rendering is understandable to a qualified
   individual (e.g., used to using synthesized speech).

   EH: A text equivalent is a text equivalent that has a recognized
   equivalence relationship to another piece of content, when rendered
   those three fashions, fufills its essential function for those
   disability groups.
   EH: Note that a text element is not defined just as being text.
   Consider ascii art, scripts, etc. that require text equivalents.

   EH: In principle, a text element could be built from any
   format. However, ordinarily, a text equivalent should be build
   from text. It can have markup, style, etc. But the style must
   be "disposable"; the element can't depend on the style to
   deliver its essential message.

   JG: What does the WG need to decide?

   EH: When we refer to non-text content, that we say that this
   is one or more non-text elements per WCAG 1.0. I don't think
   we should use the term "text content".

   IJ: We use non-text content, but not text content.

   IJ: Why is it called "text element" if one criterion
   is not that it be composed of characters pre-rendering?

   EH: I don't contest that. But we inherit the term from WCAG 1.0.
   IJ: So our problem is that:
   a) We have a term from WCAG 1.0
   b) We have the term "text" which implies characters to people.

   EH: I'm just trying to stay the course in a direction set
   by WCAG 1.0.

   IJ: What about binary formats? The UA may recognize them
   and be able to handle them, but the information may not be
   composed of characters from the document character set. 

   IJ: Important: The product is human language! I think that
   this is key: the information is converted into a human 
   language description. We are not talking about conveying
   an image of a boat as sound.

   EH: But what about a data chart that has three points.
   Is the list of coordinates a text equivalent? I would argue
   that it may not be complete: you probably need a summary
   of what the coordinates turn into. When talking about text
   equivalents, we have normally emphasized the digest aspect.
   I've been wondering out loud : to what extent can we allow
   more complete descriptions of non-text equivalents as part
   of their text equivalent? We don't want to set a standard that
   text equivalent cannot include a full description. 

   IJ: I don't think that a list of coordinates would be a text
   equivalent for a picture since users of the picture do not
   view the coordinates themselves.

   EH: Right, a set of pixel coordinates does not suffice. But
   I don't want to rule it out. For example, consider the table
   summary. I think that the summary is the digest portion of
   a text equivalent.

   EH: In short, I don't want us, in our definitions, to not
   paint ourselves into a corner.

  Q: Should 1.5 be expanded to other information in the
     user interface?

  EH: Are there distinct classes of messages? 

  EH: I retract (since it may be covered by another issue)
  the proposed changes to 1.5).

  Resolved changes based on EH's proposal:
  1) Adopt a definition of non-text content, text element, non-text 
  2) Add a definition of text. Explain relationship to WCAG 1.0
  3) Examine 2.5, 2.6, and 3.8 (editorial)
  4) Editorial review of usage of the term "text" based on the
  5) [If glyph is used, define it.]

Open Action Items

    1.GR: Proposed repair checkpoints

Completed Action Items

    1.JG: Add issue related to user agent generated 
          content being a part of the DOM

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 14 September 2000 16:01:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:28 UTC