W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for Feburary 23rd, 2000


Chair: Jon Gunderson
Date: Wednesday, Feburary 23rd
Time: 2:00 pm to 3:30 pm Eastern Standard Time, USA
Call-in: Longfellow Bridge (+1) (617) 252-1038


Agenda

Review Open Action Items

Announcements

  1. Extra Telecon on 1 March 2000 to process Candidate Recommendation issues
  2. FTF meetings at CSUN: Web Content (2/20), Interest Group (2/25), Authoring Tools (2/26) and Education and Outreach (2/26)
  3. Update on User Agent FTF for early April

Discussion

  1. Summary of results from Candidate Recommendation
  2. Preparation for Proposed Recommendation
  3. Implementation report status
  4. Issue CR#190: Reduce the scope of 5.1 to say "write access only for that which you can do through the UI."
  5. Issue CR#201: 5.5 "Ensure that programmatic exchanges proceed in a timely manner" should be a priority 1
  6. Issue CR#203: Checkpoint for access to content for non-HTML or non-XML WWW documents (i.e. Shockwave)

Attendance

Chair: Jon Gunderson

Scribe: Ian Jacobs

RSVP Present:
Dick Brown
Harvey Bingham
Denis Anson
Rich Schwerdtfeger
Charles McCathieNevile
Mark Novak
Philippe Le Hegaret
David Poehlman
Mickey Quenzer
Gregory J. Rosmaita
David Gordon
Hans Riesebos

Regrets:
Daniel Dardailler
Kitch Barnicle


Action Items

Open Action Items

  1. JG: for 5.3: Find out windows/mac accessibility guidelines.
  2. JG: Check with Ian about adding reference in 4.5 to 4.6 in regard to stepping through animation/video/audio.
  3. DB: Ask IE Team about publication of review of IE 5 and Pri 1 checkpoints.
    Status: notes have been lost and are being reconstructed
  4. JA: Rewrite techniques for 3.3 (see minutes)
  5. MK: For 4.8 check if any media players do this?
  6. MK: Find out techniques for sending text search requests to servers of streamed text.
  7. MR: Review techniques for topic 3.1 (Multi-media)
  8. MR: Review techniques for Guideline 4 (Multi-media)
  9. MR: Run a multimedia player through the guidelines for January.
  10. RS: Take these issues to WAI PF. Get input from MSAA developers as well. Craft email to PF WG with Ian

New Action Items

  1. IJ: Propose checkpoint to address event notification timing issue and possibly timely exhange issue

Completed Action Items

  1. IJ: For 4.10 add the CSS2 property. And cross reference 4.7 techniques
  2. IJ: For 4.11 add the CSS2 property.
  3. IJ: XWindows techniques for 5.3
  4. IJ: DOM2 techniques for 5.3 (if any)
  5. IJ: For 6.2 add a link to the TR page. Add links to conformance sections in specs. Also to validation services.
  6. IJ: Fix section numbering in techs doc in checkpoint 7.3
  7. IJ: Ensure that checkpoints are in proper priority order.
  8. IJ: For 6.2, propose some wording to address the "when available" issue.
  9. DA: Rewrite technique for 2.2 (see minutes)
    http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0298.html
  10. GR: Send to the list techniques for how to use and control focus to not have new windows cause problems for usability. In particular, how this will work with ATs.
    Status: Dropped, since information already in techniques document
  11. MQ: Ask Mark Hakkinen about telephone browsers and the guidelines
    Dropped: Telephone browsers will not be directly address in these guidelines
  12. PLH: Send URI to this work to the UA WG mailing list
    http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0353.html

Minutes

Next meeting: TOMORROW at 2:00 ET.

Agenda [1]

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0355.html

1) Review of Action items:

IJ Action items: All done.

JG:
-For 5.3, find Mac access guidelines (not done)
-Contact IJ about stepping through AV (not done)

DA: Write techniques for 2.2 (done, not in document yet).

DB: Ask IE team about publishing IE reviews.

GR: Send techniques about control of focus. (cancelled)

JA: Techniques for 3.3 (no news)

MK: No news.

MR: No news.

MQ: Cancelled.

RS/IJ: Timing issues to PF (pending).

2) Announcements:

- Telecoms: 24 Feb, 1, 2 March. - CSUN WAI meetings. - UA ftf 10-11 April (no new information from Judy) - JG and IJ are putting together a summary of the CR review. Will submit to WG for review. - Hope to go to PR on 8 March (in time for ftf). - IJ will talk to an MS rep working on IE/Mac about UA Guidelines.

3) Candidate Rec issues related to the DOM (190, 201 and 203)

Refer to JG's proposal of 22 February
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0359.html

5.a Make available content information available to other technologies through an API [Priority 1]

IJ: Please refer to my proposal that reuses wording of existing 5.3

DA: Programmatic access to rendered content.

CMN: A UA might ignore content, but pass it off.

JG: A graphical style sheet might ignore an auditory style sheet, but an AT might want it.

Resolved: Add this checkpoint for content.

5.b Provide programmatic access to XML amd HTML content by conforming to W3C Document Object Model (DOM) level 2 Core and HTML module specifications and exporting interfaces defined by those specifications. [Priority 1]

Note: Important special case of Checkpoint 5.a and that the timing efficiency of exchanging information through the exported interface is very important.

PLH: DOM Level 2 core is same as DOM Level 1, plus namespaces. DOM Level 2 HTML is same as DOM Level 1 HTML.

GG: I think a perfect example of this is MSAA available in IE 4.01. You could get at the data if you had a whole lot of time. I think that timeliness should be Priority 1.

RS: I think we want the same performance as for a scripting language.

CMN: You need to know about events in a timely manner, and perhaps be able to react (and stop) the results of events.

IJ: I have problems with a requirement that something be "fast". That may vary according to processor, network, operating system, interface, user ability, ...

RS: Since we're isolating the DOM as part of the UA, can we say that the AT should be able to access the DOM at the same performance level as the UA itself.

DA: You want "equivalence" of access.

HR: I don't think we need equivalent, just sufficient.

DA: I think that a lot of people with disabilities would argue that anything less than equivalence doesn't suffice.

PLH: When you rely on your own structure, you can access faster than what you can do through the DOM. So I don't think that you can guarantee "equivalent" access. It may be implemented as a proxy.

IJ: What are the functional disadvantages by not having fast access?

GG: You lose responsiveness, but that's not functional.

DA: Consider two people doing research - a person who is able-bodied might be twice as productive as someone who is using an AT.

CMN: If the AT doesn't have enough access, the page will change before the user has read it. For example, caused by timers on scripts.

IJ: We have a requirement to allow users to turn off dynamic changes.

DP: But sometimes you need to have content changes to remain oriented, and if the AT doesn't keep up, you've lost your orientation.

PLH: Maybe you're looking for atomic interactions. In a SMIL document, you want to change the "begin" attribute but not the "end" attribute. The implementation may change the end attribute. There are two operations and you want only one.

PLH: An API offered by the UA will never be as fast as the UA's internal calls.

GG: Yes, but this is must better than cross-process calls.

IJ: Something like "The UA must allow access as though the AT were running in the same process."

CMN: The AT has to be able to control the processing of any changes.

IJ: This is better to me since it doesn't refer to "speed".

JG: Two separate timing issues have come up:
- It's slow to get at content.
- I need to be able to keep up with changes.

GG: I think these are intimately related.

RS: The DOM (2) allows you to have filtering. If we stay with something about equivalence performance level, then filtering of events would do the same thing.

IJ: I really hesitate to go into the world of handshaking and protocols.

DA: The bottom line: can the user of an AT be as productive?

IJ: Speed is not part of our priority definition. Slow access still means that it's not Priority 1.

MN: I think that this is a high priority issue. I'm mulling over RS's expression of the problem. An in-process DLL will get content faster than a script. I think we should use technologies that are already available to us.

JG: A reference implementation may be useful to people (to show what's reasonable performance).

MN: Other applications are addressing this problem as well. It just needs to be implemented. Developers keep in the front of their minds to do things quickly.

CMN: There's an orthogonal break between how it's being implemented and what we specify. If it's implemented, that's great, but how do we specify the requirement in the first place (so that it may be verified).

MN: The idea being as quick as scripting we can relate to and it's do-able.

HR: I think that timing is important. When I'm using the DOM, the most important thing is to be in sync with the user agent. The key word is "synchronized" with events generated by the user agent.

RS: You could put something in sync and slow the whole application down.

HR: Having the events in sync is only part of the solution. This is the part we can identify more clearly. Performance is the real issue.

IJ: What about "The UA has to provide programmatic access to content in a way that allows comparable performance to AT users."

CMN: I don't think that's adequate.

HR: In-process communication is not really developed for the Mac.

RS: What if we say "For multitasking environments, the AT needs to run in the same process space as the UA for access to the DOM."

DP: The AT needs to do some processing once it's hooked in to the UA.

DA: In David and Charles' proposal, the AT slows down the UA. I think that we should be considering how to go as fast, not to slow down.

DP: The hook needs to be early in the processing.

IJ: Scope of the problem is dynamic changes to document.

RS: Not always: and AT may only deal with part of the document.

GG: Sometimes, you need to get a lot of calls to get summary information.

MN: Static pages may be so large, there's an issue of getting information, period.

CMN: I think that there are two issues: (a) dynamically changing pages (b) how to do you deal with a big fat monstrous document. The Pri 1 content is only when you can't get at the information at all.

IJ: Isn't rendering orders of magnitudes slower than exchange? Is there really an issue for static documents?

GG: If you want a list of all the links, you may have to wait 20 seconds for all the content to download.

CMN: But you still have that today for downloads (e.g., the long W3C list of 400 Members).

CMN: I think we need a requirement for at least dynamic content.

CMN: I'm not saying that static is not important. The piece that's critical is when content changes before you get at it. When the content is steady, you need to get at it in a reasonable amount of time. The best techniques may satisfy both requirements. But we should distinguish the cases.

DA: I would agree with CMN that dynamic is P1 and static is P2.

IJ: How about a requirement that the exchange of information take place on the same time scale as event changes.

JG: I still propose that we delete 5.5 and make the requirement in a note after each programmatic exchange checkpoint.

GG: I think that the dynamic case is just as important as the static case (for different reasons).

RS: Treating them separately confuses me.

CMN: We want the AT user to be able to have the lock so that the user can stop the chain of events if necessary.

DB: Is there any place else where "timely manner" is defined?

Action IJ: Propose a checkpoint by Friday.


Copyright  ©  2000 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.