JA: look at nav stuff and propose checkpoints and techniques, by Monday
(maybe) techniques what attributes are important to search for group to review
and assign more tasks at next meeting.

Resolutions

Cancel May 12th meeting due to WWW 8 conference

Accept the topics in the checkpoints outlined by Jon Gundersons revised
proposal (http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0041.html)for
inclusion in the next working draft and as representing the AT compatibility
issues. The checkpoints may be modified based on editing and contributions to
the techniques document. If two or more checkpoints share predominately the
same information it may be better to combine them.

JG: new working draft by end of may move to proposed recommendation. Lots of
issues People attending www8 all but jg and mn, may Resolved: cancel May 12
meeting Action items:

JG: revised 7.2 guidelines completed Discussion of AT compatibility

JG: most people can live with checkpoints with some clarifications

DA: concerns-DOM is one way to get access, checkpoint should be to get
access to content on page, technique is use the dom

JG: strong feeling in group to use dom access in the checkpoint, similar to
saying use accessibility features in html, xml, etc. if you use dom then you
will be giving access to all content on a page.

DA: since it is a w3 spec I can live with it

CMN: good because it is a standard interface cross platform to the
information

JG: number of ua have implemented dom

MN: dom implementation is confused at the moment, complete implementation is
difficult, 4 or 5 ua that are saying they will implement dom

ACTION: MN will post message about ua implementation of ua

JG: cmn made strong point for two way communication between ua and AT cmn:
AT being able to set the selection point or focus

JG: we hae a checkpoint for that cmn: need to have one check point to cover
all instances in list jg: 7.2, 7.3, 7.5

CMN: if you have access setting then 7.2-7.5 are redundant jg: can collapse
723 and 724 but makes the techniques more complex, 723 can derive info from os
but allowing external program to change paramaters is not obvious, may be
difficult programmatically. Leave separate, write techniques and see if
thechniques are similar then combine them. If techniques are different then
leave as separate checkpoints ? clarify 725

JG: mouse over how does AT identify and implement the mouse over event
without the mouse. Some os may not have same level of AT support/api, if
browser doesn't use standard controls then AT cant get at the information
(netscape example) then 725 prevents this to allow AT access to nonstandard
controls. Want this section to encompass all the concepts. Kb: any ua that get
check for 723 -725

JG: IE would get check, AT can manipulate dom through activeX , ms is
closest to all, integrate accessibility api,

MN: level of dom support in IE is further along than what w3 recommends,
lots of stuff is available to AT without need for activeaccessibility or other
apis,

JG: AT vendors have different needs, some want AA, others with dom, etc.
same is occuring with sun swing. We want to say do both. Dom is document
centered for use by scripting languages for manipulation of contents, style,
etc. AA and swing java accibility api geared to querying ua for controls, what
is rendered, what info is on the screen, java has extensions to object
classes-more an operating system orientation rather than document orientation.

MN: venders have different needs. Webspeak has own controls etc, needs
access to document. Jaws needs access to both.

MN: sounds similar work I have done with rich already jg: techniques - what
can be done, what should be done, in implementation of checkpoint, may be
different ways to implement. Very technical section, need programmer input (mn,
rich cmn: feels comfortable looking at this material, but not volunteering
resoloved accept 72x checkpoints with additional comments and techniques jg:
ian will integrate after May 15 mg: dependent definition?

JG: dependent ua=Assistive Technology

HB: html 4 accessibility has transitional stuff, should we tighten up the
checkpoints

JG: need to add from pagl, defer until nav and AT issues done, have a strong
statement about html 4, talk about 7.1 support accessibility features of html
but doesn't specify version, techniques point to web content guidelines, need
to go through pagl to make sure uagl reference appropriately, make priorty
match,

JG: w3 note not normative, techniques are a note not a recommendation, one
advantage of putting dom recommendation to 7.1 so as new features are added to
dom easy to change document dom is language neutral, platform independent
jg" implement dom1 in 72x, dom spec does not address exporting, separte
checkpoint to export dom, move implementation to 7.1, discuss dom in techiques
extensively. Issue: should reccomendaiton of dom interface be moved to
guideline 7.1

DA: then we must rewrite 7.1 to not say language

JG: maybe leave dom where it is. Leave as open issue, techniques should help
resolve. review navigation:

JG: clean up and define da: problem with doc tree, is not obvious to user
how structure work jg: problem-how does programmer know what we mean, need to
describe or build algorythm to show what we want, navigate to next block level
element, no defintion of block, make algorithm base on dom hb: table cell

JG: cell is block level element mg: tree structure problem for user jg:
inline tag becomes a node in doc tree, if you move to next sibling might split
word because of formatting with in word, issues with dom oriented checkpoints
in guidelines, need algorithms in techniques to illustrate

KB: need to be careful how guidelines are implemented da: users navigate
sematically, headers, paragraphs, etc., give categories and define, for
programmer assistance on what to do with the tree and how to provide
information.

HB: does break tree, cell up is different part of tree not same branch

DA: jumping around is different than moving semantically, techniques should
give examples of sematic units to naviage by,.

JG: need to build a list and make guidelines accordingly, need a succinct
list - Basic ways to nav nav active elements-links, form control - technique
bring up a list of all links nav all elements-chunks of info, define
chunks/blocks everything else is search (see above ***), find next item that is
similar to X (16pt arial, bold-rather than heading) whats checkpoints to
represent these, then write techniques/algorithms to represent them da: talking
about searching vs browsing, search is specific, browse you don't know what you
are looking for.

HB: there is something Ja: browsing is different using keyboard vs mouse

JG: other high frequency things, likes list of links, then start typing it
moves you to link beginning with letters, techniques could reflect these ideas
Cmn: what is best way to say it, strong feeling about having access to all of
it.

JG: cmn using dom to aid navigation, using algorithms to specify what we
want. Make action items to distill some of this down Take list of nav issues,
distill list of checkpoints for nav functionality

ACTION: JA look at nav stuff and propose checkpoints and
techniques, by Monday (maybe) techniques what attributes are important to
search for group to review and assign more tasks at next meeting.

HB: xsl has axis for navigation, attributes important in xml

JG: attributes that are important, label, name, Focus on todays technology,
then address future technology, be as specific as possible to direct
programmers, Discuss nav items on the list.

MG: good to have data on what users want. Or what is needed

JG: england has studies on web access in the works, microsoft has a list of
grantees, the UK group looking at vi access to the web is on the list. We are
weak on data about usability.