W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for May 26th, 1999


Chair: Jon Gunderson
Date: Wednesday, May 26th
Time: 12:00 noon to 1:30 pm Eastern Standard Time
Call-in: W3C Tobin Bridge (+1) 617-252-7000


Agenda

Review open action items

Discussion


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

Continued Action Items

New Action Items

Resolutions

Proposals


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.