W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2001

Raw minutes from 22 Feb 2001 UA teleconference

From: Ian Jacobs <ij@w3.org>
Date: Thu, 22 Feb 2001 16:01:47 -0500
Message-ID: <3A957E3B.9CA77BF9@w3.org>
To: w3c-wai-ua@w3.org
22 February 2001 UA Guidelines Teleconference

Agenda announcement:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0241
Minutes of previous meeting 15 February 2001:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0227

Next meeting: 1-2 March face-to-face
 http://www.w3.org/WAI/UA/2001/03/ua-meeting

Present: 
 Jon Gunderson, Ian Jacobs (scribe), Harvey Bingham, 
 David Poehlman, Tim Lacy, Eric Hansen, Jim Allan,
 Gregory Rosmaita, Mickey Quenzer, Rich Schwerdtfeger
   
Absent: 
 Charles McCathieNevile, Kitch Barnicle, Denis Anson

-------------
Announcements
-------------

- Glossary meeting Tuesday, 27 March 1-5pm in Cambridge
  [More information to be sent]

- Bridge information for next week's meeting will 
  be available from meeting page:
  http://www.w3.org/WAI/UA/2001/03/ua-meeting

- Meeting agenda:
  http://www.w3.org/WAI/UA/2001/03/ua-agenda

  JG: Note that we will have some demos during the meeting.

- Any UA meetings at CSUN?

JG: No.

Who's going to CSUN (21 March - 25 March)? 
     JG, JA, HB, RS

RS: On Friday morning 23 March at 9:20, I'm doing a presentation on
the "universal access gateway"; accessibility on the
server. Information is distributed to clients. I'll see if I can 
have this taped.

Action RS: Send pointer to information about universal access
	   gateway to the WG.

TL: I think we have some Microsoft folks going to CSUN, but I
won't be attending.

IJ, GR: Not attending.

----------
Discussion
----------

Coordination of joint meetings with DOM and CSS

CSS: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0237

 JG: What about dev-independent support for :hover?
 IJ: This is style, so probably not pertinent.
 GR: Are behaviors still being discussed?
 IJ: I think there are new proposals in the works.
 IJ: I expect to talk to the WG on Tuesday morning. Others
     are welcome to join me.

DOM: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0213

 RS: I put in my requirements for DOM 3 to the PF WG.
   - Add style sheets (not necessarily on the client side).
   - Need an API to the computed value of a property (without
     implementing the cascade).
     IJ: Not sure this would work in some @media cases
     (since the browser may not do speech, for example).

 IJ: Additional idea from Aaron Leventhal: add a DOM module
 to account for what MSAA does and the DOM does not.

 RS: We talked about this PF. We were trying to extend the DOM up to
 the application layer.  You put an overlay over the DOM to get DOM
 + application specific information. It's a lot of work to get this
 happen (e.g., a subgroup of the DOM WG). One thing that the JAVA
 accessibility API does (and we're looking for in MSAA), is to
 create an indexable character interface to documents (something
 like an offscreen model interface).

------
Issues
------

1. Definition Issues:
     1. Issue 359: Definition: text content (incompatible with WCAG?)
     2. Issue 358: Definition: Equivalent
     3. Issue 322: The definition of the word element
     4. Issue 321: Equivalency relationships and the wording of
	checkpoint 2.3
     5. Issue 394: Checkpoint 2.1: Vague about what cannot be
	provided through a source view
 Proposal:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0249


 IJ Reviews proposal:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0249

 HB: Why "optional" and not "alternative"?
 IJ: Optional content is a larger class (including titles,
     alternatives, etc.)

 JG: My concern is that checkpoint c is P2 in this proposal.
     Why P2 here?

 IJ: Strictly speaking, checkpoints a and b are P1 and 
     provide sufficient access. Checkpoint c did not qualify
     for P1 strictly speaking.

 EH: When we were considering the priority of 2.3, in my mind,
     it was P1 because the old 2.1 was broken. The source
     view was not a P1 requirement at that time. In this proposal,
     I think the need for P1 is lessened.

 IJ: Another piece of the reasoning behind why (c) is P2:
     "content meant for users" is not always clear, and therefore
     it was difficult to push this as a P1 checkpoint when this
     intention is not clearly discernable in the format.

 GR: "Required optional content" is a little weird.

 IJ: Good point! 

 Action IJ: Find clearer wording.

 GR: I propose changing "optional content" to "conditional content".
     I think that conditional doesn't presume that one form of
     content is preferred over another.

 IJ: I don't think "optional" suggests that optional content
     is lower class.

 JG: Does the proposal overall seem to capture what the WG
     was trying to capture with the original 2.1 and 2.3?

 GR: I think that this proposal improves the document.
 DP: Me too.
 TL: Me too.
 JA: Me too.
 MQ: Me too. But unsure about the definition of "optional content".
 
 Action IJ: Put back rationale about why user control of optional
 content is required (to allow users to find useful equivalents).

 JG: Who wants checkpoint (c) to be a P1 checkpoint? Since few people
 will be able to use a source view to get at optional content, I think
 it should be P1.

 P1: MQ (I don't like to have to depend on the user's access to 
         source code), GR, JG (I don't think most users will be
         able to do this).
 P2: JA, DP (I don't think we'll gain anything by raising to P1),
     RS, TL, HB (You have access to the source view, the fallback).

 IJ: I don't feel strongly about limiting (c) to P2. I know there
     are arguments on both sides.
 EH: I feel similarly. This may not be strictly P1, but it makes
     it hard on the user. But if you abuse "P1" a lot, it ruins
     credibility. So I think P2, but I don't feel strongly about it;
     I probably wouldn't object to P1.

 JG: I think that making (c) a P2 would be a big change to the
     document. E.g., low-vision users having to access "alt" 
     through a source view.

 GR: How will someone with a severe cognitive disability use a source
     view to access unrendered optional content?

 IJ: Note that (a) gives "alt" text when images are turned off
     (in the case of HTML). Don't bind 3.7 to Guideline 2 since
     3.7 is not specific to HTML.

 EH: I think that (c) is a repair function, in the sense that either
     the original spec wasn't adequate or because the user agent
     can't understand that specification.

 Resolved:
  - Accept the proposal with (c) as a P1.
  - Add an issue to the issues list about the priority of (c)
    (to lower to P2).

2. Issue 430: What classes of animations are covered by our  
              G4 animation requirements?
   http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#430

IJ: Status of question of what classes of animations should
    be covered by our requirements to control animations. 
    Refer to question on the list:
    http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0250

3. Issue 443: Checkpoint 1.4: Device independent access to pointer
   (mouse) specific events.

 IJ Proposal:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0243

 JG Additional Proposal:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0248

 JA: I agree with IJ's comments on this as a repair issue.
     I think that checkpoint (c) should be P3. You can emulate
     all kinds of things and you're not guaranteed of a result.
     And from what I've heard from Rich and others, I think this
     would be hard to implement.

 /* JA leaves the call */

 GR: I think that the ultimate call needs to rest with the user, not
     the user agent; the user should be able to turn off the 
     emulation feature or use it.

 JG: Everyone I've asked about this repair says "P1 since this is
     prevalent on the Web - authors are doing the wrong thing."
     What is it reasonable for the UA to do that would potentially
     benefit the average keyboard user? So I proposed a fourth
     checkpoint.
     http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0248
 
     Checkpoint D: Provide keyboard activation of the following
     pointer based scripting events for elements with explicit event
     handlers: onClick, onDblClick, onMouseOver, onMouseOut, onMouseUp
     and onMouseDown [Priority 1].

 IJ: This is specific to the DOM and HTML.

 JG: I'd rather have the necesssary repair be as narrow as possible.
     People tell me that this is a major problem and the UA needs
     to do something.

 IJ: Is this repair really useful for users?

 GR: That's up to the user to decide.

 IJ: Why does mousekeys not suffice?

 GR: You need snap-to-focus functionality.

 JG: Moving the mouse automatically breaks GUI design rules.
     But unless you can get to the focus with mouse keys,
     I don't think it would meet the requirement.

 IJ: Note the different levels of requirements:
    a) Manual emulation (fishing around)
    b) Automatic emulation (trigger onmouseover when onfocus occurs).

 No resolution.

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 22 February 2001 16:01:55 GMT

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