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

Raw minutes from 13 July UA Guidelines teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 13 Jul 2000 16:08:42 -0400
Message-ID: <396E21CA.5CBD6731@w3.org>
To: w3c-wai-ua@w3.org
13 July 2000 UA Guidelines Teleconference

Present:
 Jon Gunderson (Chair)
 Ian Jacobs (Scribe)
 Harvey Bingham
 David Poehlman
 Kitch Barnicle
 Mickey Quenzer
 Tim Lacy
 Dick Brown
 Gregory Rosmaita
 Eric Hansen
 Charles McCathieNevile
 Rich Schwerdtfeger

Regrets:
 Mark Novak
 Jim Allan

Next meeting: 20 July.
  Regrets for August: Jim Allan
  
Agenda [1]
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0038.html

Discussion

    0. IJ: I talked with MAC IE developer Tantek Çelik about the UA
       Guidelines. I will send comments about this discussion and 
       issues raised to the list.

    1. Please comment on 7 July 2000 Working Draft. 
      http://www.w3.org/WAI/UA/WD-UAAG10-20000707

     a)  HB: Has there been any effort to harmonize definitions
      across guidelines?
 
      IJ: Yes.
 
      GR: I recommend taking this to EO.
      GR: I reviewed the draft and am still concerned about speech
          characteristics being a P2. We may be missing the needs of
          some people.

      /* Discussion of increments for 4.11 */

      Resolved: Change 4.11 to 5% increments.

     b) Definitions 

     EH: To help break logjam in defining some of these issues,
     I think we should define "primary content" to be content intended
     to be used by people without any disability. Until conventions
     are established for indicating that content is primary or
alternative,
     that certain assumptions should be made. For example, if you have
     content in the "alt" attribute, we assume that that's
     alternative. Same for "longdesc". 

     CMN: I have a long and complex argument against this proposal.

     GR: I have a simple one: primary content is in the mind of the
     beholder.

     /* The Chair moves this discussion to the mailing list. */

     /* EH leaves */

    2.Proposed changes to audio volume control checkpoints
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0004.html

     Resolved: proposal accepted.
     Action IJ: Implement this proposal.

    3.Minimum list of single command functionalities for checkpoint 10.5 
      JRG:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0037.html
      KB:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0433.html

      HB: I don't like all the implications of the list.

      Who hesitates to create an explicit list of functionalities:
      CMN, KB, IJ, DB, HB, GR.

      DP: I like the list, but it shouldn't be the *only* list.

      HB: Some of the proposed functionalities have limited domain
      (e.g., font size).

      KB: When I was first trying to come up with this list, I
      wondered whether "search" was critical, since you need to
      do this by entering text.

      JG: Note clearly that this is single-key (in the case of a
keyboard).
      Not modifiers.

      Resolved: Unless someone sends a new proposal that we accept,
      then this list is ok.
      
    5.Minimum requirement for checkpoint 7.5 on searching: 
      case-sensitive forward.

      IJ: I think that forward is P1. Anything else is convenient.
      
      GR: You search from an arbitrary point, you don't know where you
      are.
   
      HB: When you find content, you need to figure out your context.

      IJ: We assume that you need to be able to search from the
      beginning. You need to be able to continue from where you are.

     Resolved:
       - You need to be able to start a forward search from a location
         in content selected or focused by the user. 
         [The default starting point is the beginning of content.]
       - When a match occurs, you need to be able to 
         continue searching forward from that location in content.
       - Case-insensitive search option (when applicable to 
         the text language).
       - Include in techniques context information (e.g., 3rd match,
         bottom of document reached).
      
     GR: Is search necessarily on a per-viewport basis?
 
     IJ: Both functionalities are useful: search on a set of
         documents, search on this document only.

     GR: What about framesets?

     JG: I think that it would be useful to be able to search
         on all frames in a frameset, but that we shouldn't
         be that specific in the guidelines.

     Action IJ: Add search options to techniques document about
     searching on framesets.

    6.Minimum requirement for Checkpoints 2.7: For author-identified but 
      unsupported natural languages, allow the user to configure the 
      user agent to identify those language changes in content.
[Priority 3]
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html

     IJ: I retract the proposal. I don't want to say "in content". I
think
     that style and the DOM in tandem would allow people to know.

     IJ: Also, I think that "notification" is the wrong idea. 
     I think identification is necessary. Prompts are not.

     DP: I agree, I don't think that the user should be interrupted.

     /* Rich joins */

    Action IJ: Repropose checkpoint 2.7.

    7.Minimum requirement for Checkpoints 6.1: 6.1 Implement the 
   accessibility features of all supported specifications (markup
languages, 
   style sheet languages,
      metadata languages, graphics formats, etc.). [Priority 1]
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html

    IJ: In short - implement the features related to the requirements
    of the WAI guidelines.

    CMN: Re circularity; I have concerns about how far "applicability"
    goes.

    /* IJ notes that IETF drafts have "security issues" sections,
       which allows people to know what security issues are raised by
       a spec. We don't have the same thing for accessibility. */

    IJ: Basically, I want people to:
       - Look at specs for identified accessibility features.
       - Look at WAI guidelines to find out accessibility
         requirements.
       - Look at system level accessibility requirements.
       - That's all you're required to do.

   CMN: The process I have in mind is this:
      - You're building a VRML browser. You go to the VRML spec
        and implement what it requires.
      - Then you go to WCAG 1.0 and see what features in VRML let
        you do this. 
      - I'm not so sure about system-level requirements.
        GR: Those are required by ATAG and UAAG.
        (You don't need to do anything in addition to meeting ATAG
         and UAAG.)

   Resolved:
    The set of things to implement is :
        - Those things labeled in the spec as such.
        - Those things in the specification which support
          WAI Guidelines requirements.

    8.Minimum requirement for Checkpoints 8.1: 8.1 Make available to the 
    user the author-specified purpose of each table and the
    relationships among the table cells and headers. [Priority 1]
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html

    IJ: Do we need to say more than "support what the spec says"?
     In my discussion with Tantek yesterday, we talked about UA
requirements
     to conform to specification but also to *not conform* by
     performing repair functionalities. I'll raise this issue on the
     list.

     /* DB leaves */

    IJ: I am proposing to leave the checkpoint as is and adding
    as a note that information that relies on spatial relationships
    in a two-d environment must translate those relationships
    if rendering serially. And leave this as a note as well:
    "For graphical user agents, it is sufficient 
     to render a table as a two-dimensional grid with header
     information, and to make available all content per checkpoint
     2.1."

     GR: This assumes that you can view header and cell information
     together on the same screen (size of table, screen magnification, 
     etc.)

     KB: I have concerns similar to GR. The spatial is only
     meaningful if you can get at the information needed.

     IJ: There may be some rendering situations when you simply
     can't render cells and header cells at the same time.

     HB: You could enable scrolling.

     HB: A concern that I have: most markup used today does not
     use the features available in HTML.

     JG: I think we may need a query interface.

     /* We don't have any other query requirements, only "make
        available" */
  
     IJ:
      - I think we might want to point out danger cases instead
        of establishing minimal requirements, and possible techniques:
        a) MQ: For large tables, or large text, need to ensure
           that relationships are available, e.g., through a query
           interface. Refer to structured navigation, which could
           be used in conjunction with a query mechanism.
        b) For many cases, fixed headers and footers will suffice
           (i.e., rendering alone will suffice). Heads up on serial
           rendering.

     Resolved: In 8.1, change "relationships" to
     "author-specified relationships". No change to 
     make a minimal requirement.

     Action IJ: Make rendering v. query clearer in the note after
     the checkpoint.
    
     Action HB: Propose a finite set of information about tables
     calculated by the user agent based on author-specified
     markup that might be incorporated as a minimal requirement for
     checkpoint 8.1.

    9.Minimum requirement for Checkpoints 8.2 and 8.3: Distinguishing 
      link checkpoints. 
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0448.html

   12.Minimum requirement for checkpoint 4.13: Allow the user to
configure 
how the selection is highlighted (e.g., foreground and background
color). 
[Priority 1]
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0036.html

   13.Minimum requirement for checkpoint 4.14: Allow the user to
configure 
how the content focus is highlighted (e.g., foreground and background 
color). [Priority
      1]
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0035.html

   IJ: I propose for 8.2, 8.3, 4.13, and 4.14 one mechanism beyond
       color. Note that this is for the UA's user interface, the 
       information must also be available through an API.
 
   GR: I would also add - don't rely on font characteristics alone as
       well.

   IJ: If you your solution uses fonts, you need to make sure that
       the user can control font family and font size.

   Action IJ: Propose change for these four checkpoints that basically
   says:
      - At least one mechanism other than color.
      - Any mechanism used must meet the accessibility requirements
        of this document (e.g., related to color selection, font
        size or family selection, etc.).

Open Action Items

    1.IJ: Draft a preliminary executive summary/mini-FAQ for developers. 
      (No deadline.)

Completed Action Items

    2.JG: Check on availability of telephone bridge for starting telecon 
      one half hour earlier.
  
      Results: We will have two-hour teleconferences starting today.

   3.GR: Re-examine the orientation checkpoints and see whether they can 
    be clarified to account for control of rendering of audio (and
possibly 
    other content) on load.

      Refer to IJ's proposal:
     
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0022.html


-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 13 July 2000 16:08:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:13 GMT