Chair: Jon
Gunderson
Date: Wednesday, September 23rd
Time: 12:00 to 1:00 Eastern Standard Time
Call-in: (+1) 617/258-7910
12:00-12:30 Frames
12:30-1:00 Embedded applications and DHTML Scipting
Chair: Jon Gunderson
Scribe: Ian Jacobs
Paul Edelson
Chuck Opperman
Harvey Bingham
Kathy Hewitt
Denis Anson
Al Gilman
Scott Luebking
Kitch Barnicle
Jim Allan
Daniel Dardailler
Continue discussion of DHTML and DOM
Denis: Is there good justification for frames?
Jon: Perhaps we shouldn't try to address this question since people will continue to use frames (or tables) anyway.
Chuck: A good example of frames involves mail (being able to read mail, follow links, keep mail handy.
Jon: We need to deal with them...
Kitch: Switch to turn frames on / off.
Jon: If NOFRAMES appears, should user be able to toggle? Several of rendering: frames, noframes, Lynx-style (one frame at a time), linearization of frames (like tables). Problem of serialization: you may want to jump from one location to another. With a frame, you want to maintain a "current focus"
Kitch: How about being able to minimize/maximize frames. Browser tells you you're in the first of three frames.
Al: Kitch's idea is a generalization of the Lynx strategy. Proposal for an index of frames (that gives sizes, names, number of images, form controls, etc.). You can navigate the index.
Jon: The info that is available is not semantic (describing the purpose of the frame).
Kitch: Extends the notion of status info. Proposal to give overview information based on heuristic info. This would complement longdesc and other descriptions. Frame index would contain URI for each frame and have statistical information (total number of words, top ten words used). Daniel: Discussion of DOM. If UA implements DOM, there is enough information through the object model.
Chuck: Few people would use the statistical information, but this information should be made available. But available through a shortcut key, for example. Interface vs. functionality. Why would you need IE if all display handled externally to it?
Chuck: Display and rendering different. Many MS products embed the HTML rendering engine with another UI.
DD: How can I provide an extension that sits between IE and some third-party assistive technology? (Chuck explains. And discussion of power toys.) Are power toys keyboard accessible?
Kathy: Somewhat, but not perfect.
Kathy: In coming up with these guidelines, we have to consider different types of browsers: mainstream, special, third-party assistive. Should mainstream browsers provide such information directly, to third-party technologies, etc.?
Al: This is an old question. Let's first identify what are the presentation techniques that make the information accessible. Worry about how to share the work later.
Chuck: We at MS don't have a clear idea of the division being requested by the UA WG. What should be supported natively? What should be provided programmatically?
Al: We would like to identify the strategies first. /* Discussion of guidelines architecture: abstract guidelines vs. concrete techniques for implementing them */
Chuck: AOL and Compuserve use IE browser engine with different interfaces. Possible to add controls to engine.
Ian: Important for guidelines to distinguish what "allow" means. (e.g., allow keyboard access) Does this mean natively or programmatically? Guidelines must make clear what is expected of browsers.
Chuck: In some cases (e.g., keyboard access), this is obvious. Other cases less obvious (e.g., serialization). What about a telephone browser (i.e., without a keyboard)? /* Mention of voice browser workshop */ Ian discusses PAGL discussion of keyboard access: explicit reference to keyboard (and not more general) to (1) not scare people off and (2) if you can do it with a keyboard, you can generally do this with other input devices. When are we talking about backend support (e.g., IE engine) and when are we talking about what the user actually manipulates and interacts with. Should WG define "User Agent" as the interface between the user and the Web?
Jon: In techniques section, make explicit mention of dependencies on technologies from other groups (e.g., DOM). Request from Chuck: Can we delineate what should be in a specialized browsers or all browsers.
Chuck: I agree it's important to identify what information must be provided for which components of browsers. Let's limit ourselves to majority browsers today.
Scott: Big responsibility on third-party browsers to work with different browsers if features not required by browsers. Let's push access features to browsers.
Chuck: Not likely to get away from browser dependence in near future. But "feature location" a good distinction to understand. 2) Embedded applications /* Seamless transition to this agenda item */ What about embedded applications? How would access technology get to the virtual machine?
/* Discussion of accessible Java objects */
DOM won't be rich enough to give access to all aspects of the embedded application. This access is script-dependent.
/* Discussion of "how to identify what an application means to do" to be pushed to DOM level 2 requirements discussion elsewhere */
/* Discussion of event bubbling and problems this poses for accessibility: Where does the keyboard access get attached? */
Al: User wants identification not that it was "mouse-down" event, but more abstract information about what was to be accomplished. Distinguish functionality added by script from means to trigger it. DOM WG should help in this distinction. What about rapid sequence of mouse-over events? How to accomplish with keyboard? Chuck: We can discourage in guidelines radical changes to a document achieved, e.g., by mouse-over sequences.
/* Discussion of keyboard navigation, tab stops, and interaction with bubbling */
DD: Is it as simple as saying that when a page has bubbling, it's not accessible?
Chuck: Unlike "alt", I can't provide a workaround to make it accessible.
Al: Can you query mouse coordinates of object clicked?
Chuck: Yes. Ian notes that events were discussed at last DOM meeting. /*
Ian: See DOM discussion of event handling in minutes.
http://www.w3.org/DOM/Group/meetings/m19980826.html */
Chuck: Was keyboard access discussed there?
Ian: No, I don't recall. Perhaps make a requirement to be submitted to DOM WG.
Chuck: What do we do while we wait for DOM 2? How do we make pages accessible in the mean time? What is role of a user agent?
Jon: Keyboard access will remain on the agenda. Perhaps should be discussed in PAGL as well? Or at least bring up DHTML in next WAI CG meeting.
/* Conversation continues without a quorum */
Ian: What does User Agent mean? What happens when burden shifts to a back-end engine from top-level part of a browser. (How does this relate to dependent user agents?)
Al: Convention today goes from user interface all the way to communication protocol (browser, mail tool, etc.)
Al: We should define accessible interface first, worry about assigning tasks later (possibly outside of this document).
Denis: This document should be defining parameters of accessible interface.
Jon: A lot of people don't have access to specialized browsers. Specialized browsers aren't free, people don't know they exist. (Made several arguments for pushing accessibility features to mainstream browsers). Note: Accessibility design starts with the least common denominator and is built up from there. issue