- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 26 May 1999 13:45:35 -0400
- To: w3c-wai-ua@w3.org
WAI UAGL WG Teleconference
26 May 1999
Chair: Jon Gunderson
Scribe: Ian Jacobs
Present:
Harvey Bingham
Denis Anson
Mark Novak
Chris Weaver
Charles McCathieNevile
AGENDA: @@URL
ACTIONS:
- Action Chris: Write up Math techniques proposal and post to mailing
list. Done. @@URL
Action MR to review this.
- Action editors: Incorporate resolutions into next draft of document.
In progress.
- IJ: Write DJW about requirements T&S/WAI.
Wrote three times, still not reply.
- CMN: Write techniques for 7.2.2 and 7.2.6
CMN deferred until publication of Note by Rich and Mark.
Rich and Mark sent Note.
- JG: Techniques for 7.2.1.
Not done.
- JG: Techniques for 7.2.2.
Not done.
- JG: Contact Rob about 7.2.4/5/6
Rob hasn't been participating and we have consensus
on checkpoints in this section.
JG: I need to contact Rob about this. We want
TECHNIQUES that point to vendor-developed (internal)
guidelines. This for platform-specific conventions.
Not done.
- JG: Contact Rich S. and Peter Korn for techniques.
JG: I contacted Rich but not Peter.
Not done.
- JA: Check guidelines for information about tooltip control.
Not done.
- MK: Propose navigation checkpoint to time-sensitive
parts of a document.
Done. @@URL
----
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 synthesis).
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 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 running into 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 synthesis?
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
Received on Wednesday, 26 May 1999 14:34:02 UTC