W3C logo Web Accessibility Initiative (WAI) logo

WAI UA Telecon for June 2nd, 1999


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


Agenda

Review of Open Action Items

Di scussion


Attendance

Chair: Jon Gunderson (JG)

Scribe:Jim Allan (JA)

Harvey Bingham (HB)

Charles McCathieNevile (CMN)

Mark Novak (MN)

Denis Anson (DA, joined at 12:45 point)

Regrets

Ian Jacobs

Rich Schwerdtfeger


Completed Action Items

Continued Action Items

New Action Items


Minutes

Opening statement by JG lack of participation by developers, Jaws folks, Webspeak folks, Ibm folks, MS folks perhaps have a special invitational telecon, if you have access to these people please encourage them to attend, what is happening at UA

CMN: a problem here also, starting to participate regularly, Softquad reviews regularly

JG: send ideas to Jon,

Review of Open 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 accessible 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.

IJ: Posting description of frame work to think about checkpoints and techniques

Discussion

Ian's proposal for reformatting the guidelines and implications for checkpoints

Scripting events (see last weeks minutes)

JG: new draft on the way, sent Techniques for 7.2.1 to the list. who knows about x-window operating system and how it exchanges information between applications want to point to an existing resources for

ACTION: MN resources for x-windows exchanging information between applications and references for apple scripting

MN: COM covers this in windows

JG: I will find pointers for windows maybe ask Peter Korn or Rich about Java resources

MN: apple uses Apple Scripting

JA: tooltips, spawning windows,

editor: remove tooltip item from todo list

JG: Maria - Propose navigation checkpoint to time-sensitive parts of a document. Review this issue in terms of stop/start/rewind/fast-forward checkpoints. (may 24 posting on list "time dependent items") ask lots of questions.

editor: remove MK action item from list

New business

JG: Ian reviewing guidelines, especially about navigation guidelines currently have specific technique type recommendations as checkpoints these are useful if we are comparing user agents for accessibility talked about using GL for conformance Ian proposing to simplify, put technichy checkpoints in techniques, and make GL checkpoints more global JG responded with general suggestions-sequential access, searching, etc. would allow developers to create new techniques restructure doc checkpoint doc and technique doc, with links between

CMN: like it

JA: like it

JG: allows innovation,

HB: approves

ACTION: IJ implement GL proposal, separate techniques from checkpoints, make checkpoints more global, move technichy checkpoints to technique document,

JG: CP related to forms, links, etc, how global do we get, keep specifics for forms, tables, etc. useful guidelines to include nav to links, forms, tables,

CMN: idea in head, may be different from Ian, need basic principals--get to various elements, specific requirements for elements and get a checkpoint because they are critical, important, or beneficial...i.e. anchors, forms

JG: need some separate, forms, anchors is it useful to have these specifics, gave example about a poor page, need specific command like "move to next form control"

CMN: need a new structure to document

ACTION: Ian to include specific navigation checkpoints for the following elements: forms, form controls, tables, in next draft

Scripting Events

JG: scripting events are considered active content, should it be part of navigating to active content, with addition of user configurability--what do I want to nav to? user may have to nav to every element on a page. with separate commands for links and forms

HB: possibility to put script on body, will you need to check every element

JG: with event bubbling, then you would eventually arrive at top level, specific event handler, user doesn't know

HB: these are controlled by event occurrence, rather than moving focus to it

JG: UA could do this and provide keyboard access, mouseover may not be important. alternatives were

1) separate checkpoint for nav scripting events - are they different from any other control?, thinks there are not differences functionally. longdesc needs a separate command.

CMN: scripting are same as any other control

JA: agree ms pull down example

MN: devils advocate- ms site is good example of poor scripting, need script to use on focus, need to know what the event is going to be before you activate it.

JG: explicit event handler, should nav to it. don't want to make people go to events that don't do anything,

CMN: but if they can't go to the event

HB: feed back from event is usually visual

JG: ideally, use GL for device independence. won't need

Dennis Anson joins

JG: events are controls and handled as such, CP nav to active content, events should be part of this, other CP, nav to only elements with scripting events allow user to configure elements to navigate to simulate events, nav to element and expect something to happen but nothing happens

DA: chuck opperman said it was difficult to determine what event was caused by what

CMN: have to get to all events and turn things off

JG: with event handler that bases events on occurrence of other event, bubbles up to main controller, if active web content, follow content guidelines, and application must be accessible not much concern about problem.

ACTION:Include checkpoint: includes scripting events, responds to event, should be part of active content

ACTION:Include checkpoint: Allow user to simulate event activator

ACTION:Include checkpoint: Allow user to configure which elements are considered active content by the user

ACTION:Include checkpoint: Orient user to operation of event, to what events the element responds

JG: do we need separate CP - allow user to navigate to elements with scripting events

HB: looking at ms page, (visac?),

JG: skinner box, click anywhere and something will happen...

DA: goal to make it possible to make all pages accessible

JG: do we need separate CP - allow user to nav to elements with scripting events

DA: to be consistent with other CP we should and make it p2

HB: what is scope of scripts in head

JG: code is in the head, elements do actual activation

DA: are some onload scripts, that run when page loads

JG: can scripts run in the head

CMN: can execute in theory, proprietary, can run anywhere,

JG: no user action to run script, user can't do anything except turn off scripts

ACTION: Include a checkpoint to provide navigation to only the elements that can potentially respond to scripts

CP allow user to nav to elements with scripting events

CP allow user to simulate event activator

CP orient user to operation of event, to what events the element responds

JG: Ian's goal is to have new draft by Friday, not sure if possible.

Accesskey feature

JG: separate checkpoint, should be part of active content, consensus on line no need for specific cp.

JA: explain how IE works with accesskey

MN: problems with sticky key, changes os functioning for keyboard shortcuts, need a CP to turn off accesskey

ACTION: Add checkpoint: turn on/off access key at p2

MN: big usability problem with windows alt key

DA: cognitive problem for users using alternate keyboard access, sticky keys,

HB: issue raised - operability of more than one AT active at a time, accesskey could be a problem,

JG: platform specific implementation issue, point to resources on how to make products more accessible.

HB: send draft to developers after review and invite to attend meeting

JG: silence does not mean agreement, want developer buy in.


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.