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

Raw minutes from 26 August Combined GL/UA teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 26 Aug 1999 17:46:17 -0400
Message-ID: <37C5B5A9.CF19A92C@w3.org>
To: w3c-wai-gl@w3.org, w3c-wai-ua@w3.org
UA/GL teleconference to coordinate issues
26 August 1999


Gregg Vanderheiden
Chuck Letourneau
Wendy Chisholm
Ian Jacobs
Al Gilman
Jon Gunderson
Charles McCathieNevile
Gregory Rosmaita
Jason White
Marja Koivunen
Dean Denman (The Lighthouse, joined after 1 hour).

Next scheduled meeting of GL WG: 9 September. 

  Note 1: We will try to schedule a meeting for 2 September.
          If we can schedule this meeting, we will invite
          UA to join the GL call to discuss outstanding
          issues on 9 September.

  Note 2: Meetings will henceforth last 90 minutes.

Agenda [1]
[1] http://www.w3.org/WAI/GL/meetings/19990826.html#agenda

1) Review of action items
2) Navigation bars
3) Long description media types
4) Specificity of checkpoint 1.5
5) Metadata [Not covered]

1) Review of action items.
   (Previous minutes)

   CL: Talked to Coodination Group about a standard set of 
       questions for Web development "instructors". 
       Judy said good idea, and falls within EO, but no
       time to address this today.

   JW: Two other points made as well:
       a) EO has clarification of guidelines on their agenda
       b) Concerns about "scope creep" for GL.

   WC: Rob sent a note to GL with questions.

2) Navigation bars

   JW: Al's suggestion [1] regarding a mode in which DIV/title
       can be regarded as a container that can be skipped
       is a valid suggestion. I do have reservations about
       the use of MAP to contain navigational links. Don't
       want to use this unless in a spec. Could propose to 
       HTML WG, but don't want to endorse without making
       it part of the specification.

       Furthermore, future technologies (schemas) will allow
       us to do this correctly.


     a) For DIV/title: It's a backwards step. It's the navigational
        equivalent of using FONT everywhere to create structural

     b) For MAP: The suggestion comes directly from the HTML 4.0 
        specification [2]. Shows how to use MAP with straight text.
        Similar situation as we were in with longdesc. We recommended
        that people used d-links until longdesc was supported. 
        Similar with MAP: use of MAP as block-level container
        is supported - it is rendered. HTML 4.01 has this.
       [2] http://www.w3.org/TR/REC-html/struct/objects.html#h-13.6

     c) The "skip navbar link" is a hack that is similar to
        the d-link. Useful if understood by humans, but not
        machine recognizable.

   GV: (Scribe missed comments)

   JW: About DIV - it's a container element for style sheets
       and other purposes. When it does this, in an outline
       reading of the document, it should appear as part of

   WC: DIV with a human-readable title is a bridge to XML.
       Are there other elements that need to be grouped (e.g.,

   CMN: But using DIV this way takes you out of the "standard"
       hierarchy. So it's like the XML approach, but it's not
       XML. So use xhtml instead.

      a) For medium term: use schemas. Don't focus on HTML
         but move towards xhtml + schemas.
      b) For immediate: use scripts (for example).

      What problem are we trying to solve?

      a) We can add additional functionalities to existing
         browsers (plug-ins). So don't focus only on short-term

      b) What strategies apply today?

    JW: I see DIV as the only short-term generic solution
        for adding structure that we're looking for. I think
        the long-term solutions should be schemas.

    IJ (to CMN): How does DIV/title strike you in the short term?

    CMN: Marginally inferior to MAP/title solution.
         HTML 4.0 doesn't say explicitly that you don't 
         need an image. CMN notes: MAP content is rendered
         by all browsers I've tested but Amaya.

     IJ: HTML 4.01 language of 13.6.1 section on rendering
         of block-level content of MAP is new. Since HTML 4.01
         in PR now, good time to ask an AC member to add
         a phrase that would be helpful to address this 
         issue (e.g., no image necessary, "should" render

     JW: Two times to render content: 
           a) Image map not represented in display medium.
           b) No image associated with MAP element.

        So I propose adding to HTML 4.01 a comment about
        rendering MAP block content along the lines of
        "The user agent should render MAP content, notably
         when there is no associated image." (Note
         use of "should".)
       [Scribe note: Suppose the user were able to
        configure the browser to render or not to 
        render block content in a MAP element. UAs would
        not be able to render a document progressively
        in "don't render block content"  mode since that
        would imply having to wait for all images (in
        fact, all content) to know whether the MAP was 
        associated with any of them.]

     CMN: What about OBJECT element? If you want to do what
       Jason suggests, do this:

            <OBJECT data="image.gif">  
              <MAP name="foo">
               ...block content...
       Doing this, you get links instead of the image (if
       MAP content is rendered).

     GV: Are we trying to push understanding of MAP to
       far? Is this just a loophole we are exploiting?

     AG: HTML 4's intention was to allow authors to
        specify URLs one time only.

     CMN: Also to allow image maps or text links, both based
        on a single element content. The spec allows this, but
        doesn't say that you can do this even if you never 
        intended to use an image.
     GV: What about case of bulleted list of links? You 
        wouldn't want to put that in a MAP.

     CMN: Users approach these lists differently than

     JW: I'd like to separate
        a) How MAP is defined
        b) Technique of when it should be used for
           grouping links. Author discretion enters here.
     MK: There can be a lot of navbars in a document
        (e.g., CNN site). Users want to be able not
        just to skip, but to return to navbars.

     WC: For DIV/title, if author puts information
         in "title", UA can present this information to
         the user.

    CMN: MAP/title will allow the same thing.

     JW: With appropriate wording in HTML 4.01,
         I'd agree with Charles' proposal. Otherwise,
         I'd opt for DIV with title.

     IJ: What about scripts?

     AG: Problem of Lynx, which doesn't support scripts.

    CMN: Then include a "skip nav bar" in the block of
         links. But this pushes the problem from one
         of listening to physically tabbing through a list
         of links. The "skip nav bar" approach is still
         the solution here. Or use a browser with a structure
         view (e.g., Amaya).

     WG: So first link inside of MAP is to jump over the

    CMN: So this will work today (e.g., with scripts, CSS)
         and tomorrow. Also, use an image map up front and
         text links at the bottom. 

     a) For today, use MAP/title. Put a link in the MAP
        to skip over the others. Use CSS or scripting
        to hide it. Also, put image map at the top and
        text links at the bottom.

        WC: Some bugs using tabindex within frames in 
            at least IE 5. Don't believe supported in NN 4.0
     b) For tomorrow: Use MAP with semantics as written in the

        JW: Ask PF WG to consider this scenario and other 
         structural navigation issues when considering 


      1) CMN: Raise awareness with AC Members about enhancing
              accessibility in HTML 4.01.

         JW: I will dissent use of MAP unless the update
             is made to HTML 4.01.

      2)  WC: Propose techniques based on this discussion.

    JG: Does this discussion represent consensus between UA and GL?

    WC: No. I will write up the GL side of this discussion, send
        to GL for comments, then send to UA.

    CMN: UAs should expect to find MAP if they expect to
         skip blocks of links.

     MK: What about getting to the central content of the page?

     AG: You may find repeated MAP elements, but you won't, from
         this proposal, know how to find the primary content.
         There are undoubtedly refinements to be made.

3) Long description media types      

   See Al's proposal. [3]

   GV: longdesc was designed to lead to something really
       accessible. Other than "why limit it if we
       don't have to", what's the benefit for making
       this more than text?

   AG: We're trying not to make it different than a standard
       URI reference, which doesn't limit to a specific
       media type.

   IJ: But no "type" attribute with longdesc.

   GV: But putting audio at the end of longdesc
       raises barriers.

   AG: But to meet WCAG, you'd need an auditory
       description to accompany the audio clip.

   JW: I don't think it's approprite to limit content
       types for longdesc in an HTML spec. I think 
       the WCAG should have jurisdiction.

   MK: "longdesc" also used in SMIL.

   GV: I'd like to register nervousness on this point.
       I fear people will put content out their that
       will impose too many layers before getting to
       accessible content.

   IJ: Drop longdesc from SMIL and use schemas.

  CMN: Drop IMG entirely.

  /* Chuck leaves the call */

   JW: In response to Greg's concern, I'd be willing
       to have non-normative language in an HTML
       spec that longdesc generally points to text.

   GV: Use the Techniques Doc to address the longdesc

  CMN: Having text is nowhere near as good as having
       full markup: Put HTML at the end of a longdesc.

   GV: Why use a movie at the end of a longdesc?

  CMN: E.g., instructional videos. 

   GV: Why not put it on the main page?
  CMN: No particular way to do it. The primary version
       may be images plus text. The decision of
       what is main and what is secondary is up to the

   IJ: This sounds like a cognitive technique: put text
       as primary content, video as complement.

   JW: Longdesc should not designate plain text alone,
       but markup.

  CMN: Yes, at a minimum, refer to markup.

   JW: But this should not be normative in the HTML spec.

   GV: We need to talk about the purpose of longdesc:
       should limit it to a description of the image, not
       supplemental information about the context in which
       the image occurs. Similar to using alt text just
       for the purposes of a tool tip. Warning: if the
       function goes beyond a description of the image,
       this could lead to problems.
   AG: What about content negotation? You get text
       or video depending on preferences. Refer also
       to CC/PP.

   IJ: Distinguish
      a) Function of longdesc
      b) Content types.

    GV: But users may not know how to adjust clients
       to get different types.

   WG: How used in SMIL?

   MK: Every media object has it (audio, video, textstream, ...)
  CMN: Working from the HTML 4.0 spec [4]
       [4] http://www.w3.org/TR/REC-html/struct/objects.html#edef-IMG
  WC: Conclusion - we need to get consensus on the list about what's
     the intended use of "longdesc".

4) Specificity of checkpoint 1.5

   1.5 Until user agents render text equivalents for 
       client-side image map links, provide redundant
       text links for each active region of a client-side 
       image map. 

   Action IJ: Send proposal to GL list about broadening
              language to refer to device-independence, not
              just text.
Received on Thursday, 26 August 1999 17:46:59 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:07:16 UTC