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

Raw minutes from 21 September UA Guidelines WG teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 21 Sep 2000 16:28:44 -0400
Message-ID: <39CA6F7C.91F7D56A@w3.org>
To: w3c-wai-ua@w3.org
21 September 2000 UA Guidelines Teleconference

 Jon Gunderson (Chair)
 Ian Jacobs (Chair)
 Jim Allan
 Gregory Rosmaita
 Eric Hansen
 Rich Schwerdtfeger
 Harvey Bingham
 Tim Lacy
 Charles McCathieNevile
 Mickey Quenzer


 David Poehlman

 Kitch Barnicle 

Next meetings: 

  Tuesday, 26 September (extra, 13:30 - 14:30 ET)
    Regrets for 26th: KB, HB, JA, TL (for half). 
  Thursday, 28 September (regular)

Minutes of previous meeting 14 September:

Review Action Items (see details below)


    1.Extra teleconference scheduled for Tuesday 26 September 2000 at 
      1:30-2:30 EST USA

    2.Face-to-face meeting update

      IJ: No update now since Judy Brewer in White House event today.
      I will follow up next week.


    2.Issue 311: UAAG 1.0 and DOM Level 2 as UAAG 1.0 moves towards last

    IJ summarizes DOM status, relation to UA status.

    Q: Is there any need to change the document?

    CMN: I propose that we remain in the status of tracking it.

    RS: I wouldn't want to limit 5.1 to read-only. We do some tagging
    to increase performance.

    Action RS: Talk to people at IBM about sending techniques for
    performance-enhancing techniques (and whether proprietary).
    JG: You can always to more.

    RS: Adding an event listener is like modifying the DOM. It's like
    modifying the DOM (extended API). E.g., if you have a dynamic
    document, you can listen to mutation events. Not necessarily a UI
    change. Is adding an event listener considered a change to the
    DOM? We are not changing DOM nodes.

    JG: You could use the DOM 2 event model in 5.5. If we added, then
    that might be part of a requirement for 5.5.

    JG: Do we have implementation experience for the event model?

    RS: I don't think so.

    JG: I'm concerned about making DOM 2 event module a
    minimum requirement if we don't have implementation experience,
    notably to AT vendors who have not used it.

    CMN: Our expectation today is that DOM will not change much
    as it goes to Rec. We are specifying our requirements based on
    that assumption. If there are dramatic changes, we will revisit
    our requirements.

    IJ: I believe we've already discussed changing priority of 5.7
    (and decided not to) and also decided not to add additional 

    RS: Making 5.5 with DOM event model a P1 probably not reasonable
    at this point. I'm ok with 5.5 as is. Could add a P2 requirement
    for DOM 2 event model.

    CMN: I think that the guidelines should set a target for
    developers. I would be unhappy about changing the priority level
    based on implementation levels today. 

    IJ: Problem that people don't love all of the events module. And
    you can't claim conformance to part of the module.

      - Leave current checkpoints: Consensus.
      - Don't add any other DOM Level 2 requirements.

    1.Issue 316: Using the DOM to make available information on user
      generated content

    Q: Is there a requirement that generated content be part of the
    DOM (and thus available to the AT)?
     - Bad markup
     - Configuration
     - Missing resources

    GR: What JFW does today (with COM/DOM) is give the user the
    choice of ignoring graphics without alt text, reading the end of
    the URI, or the alt information if present.

    JG: I'm not sure that having the mainstream user agent put repair
    content in the DOM is a good idea. We decided to make available
    info the DOM because different renderings have different
    requirements. A problem is that the AT user would not know what
    comes from the author and what doesn't.
    MQ: I think we should suggest, but not require inclusion of
    generated content in the DOM.

    GR: What HPR and PwWebSpeak do points the way for what mainstream
    UAs should do: allow the user to configure how much information
    should be provided by the UA.

    RS: One problem - suppose that the AT is depending on what's
    presented graphically, in addition to the DOM. If they are not
    in sync, could be problem.

    IJ: I think the document needs to say clearly that we are building
    the UAAG 1.0 based on assumptions about the DOM. And we are not
    requiring that UA's do things based on screen scraping.

    GR: Issues:
       - Effort
       - Consistency
       - Origin
    RS: I think that if the UA repairs invalid markup, then the
    this should be represented by the UA. For example, form control
    that are outside the FORM element.

    IJ: It's legal to put form controls outside a FORM element.

    TL: We repair incomplete tables.

    IJ: Repair is non-standard. I have a problem requiring
    passing non-standard content through APIs to ATs. It could be
    useful, but no guarantee that that will benefit accessibility.
    Right now, we are not making requirements about the construction
    of the DOM (in fact, we have intentionally said "we don't know
    where it comes from: style sheets, markup, configuration, repair,

    CMN: I would argue that if the user agent changes the DOM, it
    should alert the user.
    IJ: I think most users would prefer not to be told and instead
    just want the UAs to fix stuff silently.

    CMN: I think that some changes made during parsing don't need to
    lead to notification. But where you add content, you should
    tell the user and also put it in the DOM. The fact that the
    document has been changed on load is available.

    RS: I don't think that's useful.

    CMN: Why it's useful: I want to know whether the UA has made
    a change as opposed to a change from the author.

    RS: I think that the only reason you need a mutation event is
    if you give it to the AT, then change it. But changes before
    making available to the AT don't need to be told to AT.

    IJ: I, as a user without a disability, have no idea that my
    user agent has fixed content. 

    RS: And I have no control over how IE does its repairs.

    IJ: Lots and lots of information can change from UA to UA based
    on author changes, configuration changes, repair differences
    (which are not standard), content negotiation, etc.

    JG Summarizing:
      - UAs do repair all the time.
      - The only explicit repairs we require are 2.5 and 2.7
      - Issue of whether user needs to know or wants to know which
        repairs have been made.
    EH: Is this part of the discussion about 1.5 (non-text messages)?

    IJ: 1.5 is not about content but about UA's native UI.

    EH: I have a suggestion: A checkpoint that requires the developer
    to document any information that is likely to go to the user
    interface but that may not be reflected in the DOM. I'm thinking
    about six classes of information:

       Information reflected in the DOM? (yes/no)
       What kind of notification is required (none, in the moment, on
    EH: The UA developer would have to document which information
    they're going to repair without notification (i.e., silently).
    Or, some information will be rendered, but no notification, and
    not in DOM.

    RS: You don't always know what will end up being
    displayed. Notably when you put style sheets in the mix. Also, 
    some repair techniques. 

    IJ: Proposed: Add a statement to the document that says:
    Developers may put repair content in the DOM, but are not required
    to by this document.

    RS: There are better techniques for repairing alt text.

    IJ: 2.5 expresses the minimal requirement.

    RS: I'm saying that if a UA does the job, it should be in the DOM.
    Why is that unreasonable?
    CMN: I agree with RS - the overhead of putting it in the DOM.
    I would go back to the suggestion that if you put it in the DOM,
    you notify the AT. Reason: if you build an AT, then you might
    do even more than what the mainstream UA.

    RS: If a UA does repair, it should be reflected in the DOM.

    JG: How does AT know that there's been generated alt? It can't get
    that information through the DOM.

    CMN: Hence firing the mutation events.

    JG: You don't know who changed the node. It could be a script.

    CMN: Now I'm thinking that this is not a requirement. The minimum
    requirement for change is trivial. I expect that better UAs will
    provide better techniques, and ATs will provide even better ones.
    It's more a point of distinction than a requirement.
    GR: The user doesn't care where the information came from, but
    must have confidence that the AT is doing the right thing.

    CMN: It's more useful for the AT to be able to tell the user:
    a) There's no alt text b) there's generated alt text c) there's
    author-supplied alt text.

    CMN: So my preference is to not put it in the DOM or put it in
    with a mutation event. 

    IJ Proposal for 2.5:
      - If you put repair text in the DOM, notify the user.
        IJ: But I don't know how this is this done.

    CMN: I would like to see a recommendation that repair content
    be put in the DOM and that if this is done, that there is

    RS: If the UA does more than minreqs for 2.5, then include
    in the DOM. But I don't know how you would use the event
    model to indicate which element caused the change.

    RS: The DOM implies structure to the document. Repairs that
    change the structure need to be part of the DOM.

    GR: I think this should be talked about in prose.

      - Don't add any requirements to the document.
      - Add prose to the document summarizing all of this discussion
        (to 3.9 in Techniques).

    Action IJ: Draw up text to this effect.
Open Action Items

    1.GR: Proposed repair checkpoints

    2.KB: Submit technique on providing information on current item and 
          number of items in search

Completed Action Items

    3.CMN: Propose rewording of checkpoint 7.6
    Refer also to JG proposal:

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

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