MINUTES: W3C WAI User Agent 26 May 1999

Agenda and Minutes can be found at:
http://www.w3.org/WAI/UA/1999/05/wai-ua-telecon-19990526.html

Attendance
Chair: Jon Gunderson (JG)
Scribe: Ian Jacobs (IJ)
Harvey Bingham (HB)
Denis Anson (DA)
Mark Novak (MN)
Chris Weaver (CW)
Regrets
Jim Allen

Completed Action Items
CW: Write up Math techniques proposal and post to mailing list. MR to
review this.
Continued Action Items
Editors: Incorporate resolutions into next draft of document.
IJ: Write DJW about requirements T&S/WAI. Wrote thrice, no reply. Will
follow up.
IJ: Editorial action items
CMN: Write techniques for 7.2.2 and 7.2.6 CMN deferred until publication of
Note by Rich and Mark.
JG: Techniques for 7.2.1.
JG: Techniques for 7.2.2.
JG: Contact Rob Relyea about techniques for microsoft acessible design.
JG: Contact Peter Korn for techniques related to Java accessible design.
JA: Check guidelines for information about tooltip control.
MK: Propose navigation checkpoint to time-sensitive parts of a document.
Review this issue in terms of stop/start/rewind/fast-forward checkpoints.
New Action Items
IJ: Posting description of frame work to think about checkpoints and
techniques
Resolutions
None
Proposals
JG: Include a checkpoint of event simulation
CMN: Allow users to configure which elements are included in sequential
navigation. Maybe a concept that is useful for other situations

Minutes
Agenda 1) Navigation to elements with associated scripts.
JG: In 31 March draft, there are three checkpoints + turn on/off.
JG Summary of issues: a) Device independent triggering of events? (Event
simultation). b) Navigation to elements with explicit event handlers?
DA: Navigation to elements with event handlers shouldn't be priority 1.
JG: I don't think we should include elements with event handlers in set of
active elements. Many events are "superfluous" or decorative. Complicated
issues of deveice independence are being dealt with by WAI PF Working
Groups (e.g., event synthesis) for future specs. One important issue is to
describe the purpose of the event: is it eye candy only or essential for
access to page information?
DA: For Web pages as interfaces, page inaccessible if you can't activate in
a device-independent manner.
DA: Would a "mouse-over" be generated when the user tabs to the element?
MN: We're trying to solve problems we don't understand well. Should we just
push this to techniques?
DA: Until we can tell whether an event handler is important, we shouldn't
limit access to it.
CMN: Anything with an event handler is an active element. The UA could also
provide configurability about what should be included in active elements
(e.g., P3 checkpoint). User could choose to include/exclude event handlers.
DA: Does "active" also mean "takes focus"?
CMN: That's an implementation issue. In IE, in order to specify event
handlers, you need to use certain types of elements. This is an IE
peculiarity. I think "active elements" must be able to take focus, but
things that take focus don't limit the set of active elements.
IJ: I like Charles' suggestion to allow configurability.
PROPOSED: Allow users to configure user agents to say what elements will be
considered active elements. (P3)
/* Editors note: In this case, revise active element definition */
Mark: I like the idea, but I don't want to differ too much from current
practice.
IJ: Might define active element with some user agent-dependent piece (e.g.,
links, controls, maybe other elements).
CMN: My proposal does not really move away from current practice. I think
it's a more accurate description of the principle.
IJ: Why not generalize to allowing the UA to allow the user to configure
any elements that are available in sequential navigation....
Mark: My concern is defining active elements w.r.t. current practice.
Otherwise, including them in the list of active elements seems ok.
CMN: I don't think we should limit to explicitly associated event handlers.
If you allow configurabilty, you address bubbling, etc. You can give users
access to all elements and synthesize the events. You *have* to give
access, in short. I agree that in a lot of cases, you want to skip them.
You'd probably have to adjust settings after viewing a portion of the
document (to see how it works). The UI can be simple (it doesn't have to be
technical). Configurability is an improvement on the first requirement: get
to everything. Configuration can be as sophisticated as you want (reg exps!).
JG: I don't trust that people will be able to make configuration decisions.
/* CMN leaves */
HB: In HTML 4.0, almost all elements can have associated event handlers.
CW: I think it's reasonable to have two checkpoints.
JG: Several browsers already have sequential access. We'd be asking them to
do something different.
Mark: The document is out of date, it's hard to remember what's in there.
I'm torn: (a) yes to access to everything (b) pain to navigate through long
lists (c) programmatic nightmare For (c), the list of event handlers may be
generated dynamically.
DA: I think "active elements" must include event handlers (P1). But have
another checkpoint to navigate elements with explicitly associated scripts
(P2).
HB: Users don't know a priori which elements have associated scripts. Also,
scripts may be associated, but not have an impact.
JG: Right, you don't know what the "purpose" of the script is.
JG: What about event simulation?
IJ: Should this be part of another checkpoint? (the one in the guideline
about device-independence).
JG: I think we need to say it straight to readers.
Mark: Jaws, for example, simulates mouse events. I don't think it needs to
be stated explicitly, but I have no problem with a separate checkpoint.
IJ: I would rather include in single checkpoint.
Chris: How much will access to event handlers help the average user. We
should mention something in the Techniques about appropriateness of
information.
IJ: I don't think there's consensus about whether we need a separate
checkpoint for navigation to elements with associated scripts.
AD: Too much information (e.g., by including event handler information) can
be difficult for those with cognitive disabilities.
NEXT MEETING 2 June.
Regrets: Ian

Copyright  ©  1999 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.
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
	http://www.als.uiuc.edu/InfoTechAccess

Received on Wednesday, 26 May 1999 15:22:27 UTC