WAI Face2Face Meetings, Los Angeles Marriott
                       March 22, 1998

Agenda
2. Afternoon Session:
 A) User Agent Guidelines: Jim Allen (for Jon Gunderson)
  I) if Jim A needs to leave before conversation concludes,
  Kitch Barnicle will conduct the remainder of the session
 B) 2 presentations:
  I) Sarah Morley (U of Hertforshire)
  II) Chuck Oppermann (Microsoft)

Legend (Abbreviations Used to Identify
Speakers/Participants)
Al G: Al Gilman
Chuck L [also CL]: Chuck Letourneau (Starling Access)
Chuck O: Chuck Oppermann (Microsoft)
CK: Cynthia King (Gallaudet University)
D Clark: David Clark (CAST)
Daniel D [also DD]: Daniel Dardailler (W3C)
Dennis D: Dennis DeVendra (Recording for the Blind &
Dyslexic)
GJR: Gregory J. Rosmaita (American Foundation for the
Blind/AFB)
GK: George Kerscher (DAISY/Recording for the Blind &
Dyslexic)
GV: Gregg Vanderheiden (Trace)
HB [or Harvey]: Harvey Bingham (Yuri Rubinsky Insight
Foundation/YRIF)
Jaap: Jaap van Lelieveld (European Blind Union/EBU)
Judy: Judy Brewer (WAI Chair; W3C/IPO)
Kevin: Kevin Carey (RNIB)
Kitch: Kitch Barnicle (AFB)
Len: Len Kasday (AT&T)
Madeline: Madeline Rothberg (WGBH/NCAM)
Mark H: Mark Hakkinen (Productivity Works)
Max: Masafumi Nakane (W3C/Keio University)
Phil J [and PJ]: Phil Jenkins (IBM SNS)
Peter B: Peter Boscher (British Computer Association of the
Blind/BCAB)
SM: Sarah Morley (University of Hertfordshire)
Steve:  Steve Tyler (RNIB)
Tom: Tom Wlodkowski (CPB/WGBH/National Center for Accessible
Media)
WC: Wendy Chisholm (Trace)
Will L: Bill Loughborough (Smith-Kettlewell Institute)


Part 2: User Agent Group (Jim Allen for Jon Gunderson)

Introduction
1. will not make decisions; here for review of work in
progress and methods of interaction on the list; at 3:30
will pause for comments from those leaving early

2. note on composition of UA WG: representatives of specific
disability groups; 2 browser reps: one from MS one from PWW;
Netscape will begin participating shortly--have identified
an individual, but could not attend meeting and may not be
able to participate in Face2Face; invited J.Bliss (Judy:
people from Opera on UA and IG lists, Amaya; need liaisons
for Lynx Dev Consortium); talked to Ben Weiss of AI Squared;

1. Charter Review
Jim read mission statement, which is available at:
 http://www.w3.org/WAI/UA/charter.html

2. Timelines
Harvey asked at 3/21 session; Jim: aim is draft by end of
April; Jaap: is a draft available; Judy: is that a public
draft? Jim: don't think so--totally work of Jon summarizing
what has been done so far; date stamped February 13, 1997;
there is a March 12, 1998 on web site--a working draft

3. Issues
mission statement specifically looks at GUI browsers; need
to divide scope of what a browser is include Lynx, text-
based browsers, mobile browsers; phone access, web phone,
non-visual display

4. Form of Guidelines
a. basic functionality for any browser: HTML 4.0 and Css2
support
Chuck O: have a lot of concern about CSS2 is too nebulous
(startled reaction); MS' plans for implementing CSS are very
nebulous; have concerns that timeline for implementing CSS2
in IE isn't practicable; Judy: have had some conversations,
but in terms of accessibility there are a host of reasons
why CSS2 support must be built in; not only browser
manufacturer to be pushed, but would be good if took
leadership role; Chuck O: have concerns about it delaying
our programming; make CSS1 required make CSS2 recommended;
Jim: development of guidelines different than development of
browser as far as timelines are concerned; CSS supported
differently across platforms within browsers; AL: we may
have to look at priorities as to what needs to be consistent
if this is a stymieing issue

5. Addition of Section on Browser-server coordination based
on morning's sniffing discussion
AL: some activity in IETF targeted at creating a vocabulary
for use in negotiation; interested in these issues; degrees
of freedom in negotiation are same as key styles; media
types coarse grained

6. Priorities
Jim A: original semantics: very important, important,
recommended; interim solution 1, 2, 3 (1 top; 3 bottom)

7. Summary of Guidelines
4 major sections:
1) presentation adjustability: user control over display
2) navigation: keyboard navigation; alternative input
3) orientation:
5) accessibility visibility: help files and keyword
equivalents so that user can find out how to operate
particular tools

scenarios (Kitch)
purpose: descriptions that describe how user interact with
user agents
1. help developers understand access issues
2. tool for WG prioritize access features and their impact
when implemented of not implemented
3. serve as communications framework: can get users and
individuals to submit problems
4. proposed agent functionality (how feature will be
implemented and how will benefit other users)

suggested scenario components
brief characterization of user (i.e. functional limitations,
context for activity they are performing (school or job);
generic technology profile (platform, which browser, type of
assertive technology); actual task that user trying to
perform (real activity based on a real activity reported
anonymously by UA-WG and highlight current agent imposed
limitations and hardships);
Will L: agent imposed limitations: keep your eye on the
donut and not on the whole; focusing on details of browsers
less fruitful then focusing on how to access what is on the
web; attending too much to the question of whether NS or
MSIE or Opera or whatever can deal with issues is a non-
starter: info is in the code--make the browsers support all
PRs
Jaap: who is the audience?
Jim: browser developers and manufacturers; scenarios as
communication tool; illustrative--give user agent developers
a means of thinking about functionality; force them to think
about access
Will L: problem isn't using browser x, the problem is
accessing the web
David: don't understand the benefit of doing the scenarios
separate from the scenarios being done by the EO WG; one
segment of what EO is doing; why you feel the need to do?
Kitch: agreed; scenarios developed before UA began dialogue
with EO; help EO bang out ideas
Judy: give them to EO so you can get back to core task

implementation suggestions (may move to EO; test pages
simulation pages)
Jim: will take offline and discuss with other WG chairs

what structure should guidelines take?
Jim: ours are different than GL's; developed check-list;
need feedback on form/presentation
Phil: browser should be intelligent enough to keep
conflicting IMPORTANT style elements from rendering
something unintelligible
Dave C: one of the guidelines should be that when you define
one color, i.e. the text color, you must also define the
BGCOLOR; it would be a violation to define one without the
other
GV: if specify white text and beige background and then use
a bg image, will i have bleed-through
Kitch: WG needs to know from developers what kind of info
they need; what are the specific trickle down effects; in
addition to specify that user can define font, must ensure
that browser intelligent enough to look at all other
settings a la Phil's suggestion
Jim A: goes to the whole issue of the priorities set by CSS
GV: is there a contrast setting that makes the foreground
respond to changes in background; example: letter that is
black that is divided by a black line; is it possible to
have the part obscured by black line turned white
Phil: technology exists, but not in browser; mouse pointer
perfect example
Chuck O: could be another font attribute
Al G: in terms of CSS2 cannot get contrasting things via
style sheets; browsers and UA WG should be able to specify
functionality above and beyond CSS2/current standards;
Wendy: when tabbing through client side image maps,
highlighting will change color in response to BGCOLOR
Guido: persons affected by different eye disorders will have
different requirements; won't have a very efficient way to
do auto-corrections; will tax CPU as every pixel will have
to be analyzed; will have to let user specify color contrast
independent of what author does;
GJR: user override of author in all instances

Chuck O's Ten Minute Demo on Accessibility Features of IE4.1
goal: show what is currently in IE4.01; discuss plans/ideas
about future enhancements and possible pitfalls


ACCESSIBILITY OPTIONS
1. title can be placed on any element; displayed as tool-tip
2. formatting: allows to ignore colors, font styles, and/or
font sizes
 (PJ) couldn't that lead to color x on color x?
3. user style sheet: can choose a style sheet and apply it
 GJR: how are you viewing/editing style sheet; first step
 to give them the tools; second step is to give them auto-
 tools; GJR: is there a wizard? Chuck O: no; no plans; GJR:
 why not?
4. options: always expand alt-text for images (only
available when image loading turned off); do not load image;
programmatically turned on by default when screen-reader or
screen-magnification installed on system
5. Active Accessibility
 A. cannot display; implementing accessibility into
 mainstream products bound by considerations; not an easy
 task; have to consider implementation costs;
 B. have not gotten back to level supported in 3.02 release
6. Questions
 Bill: where does LONGDESC fit into tooltip hierarchy? will
 a means of accessing LONGDESCs even be implemented? Chuck:
 thrown into HTML 4 after IE4 began production; no
 guideline on how to implement; want to support it, but
 don't know when or how
 Sarah: are tool tips keyboard accessible? Chuck: no--are
 programmatically accessible via MSAA
 Judy: what about someone with physical disability who
 can't use a mouse?
 GJR: what about those that don't use MSAA? Doesn't current
 "Use My Style Sheet" place an undue onus on user?  we've
 been discussing how difficult it is to get professional
 authors to implement guidelines and adhere to the PRs-why
 no wizard, CSS editor plugin, or property sheet?  current
 set up: rely on default style sheets provided in IE, find
 a style sheet library and download one that appeals; learn
 CSS so that one can edit the style sheet manually; Chuck
 O: wizard would be nice, is on wish list, but
 implementation potentially problematic
 Dennis D: 1) is IE going to be incorporated as part of
 Win98? Chuck: yes (2) is MSAA going to be put into IE for
 Win98; (3) is it being tested with screen-readers to
 ensure accessibility? Chuck O: making certain that what is
 shipped out with Win98 works with tools sent out with
 Win98 but SAVs must utilize MS' standards to obtain info
 Chuck O: PowerTools for IE4.1 allow you to build list of
 links
 GJR: need same thing for list of images, list ALT tags,
 filename if none, link to LONGDESC

 *** end of presentation; resume UA discussion ***

topic: implementation of Dynamic HTML
issues (Jim A): how does one get keyboard access to it?
tooltips are operating system dependent; need more
universalistic approach
Jaap: how are you aware that there is ALT, LONGDESC, TITLE,
and tooltip
David C: what we are trying to do is tell the browser
manufacturers how to implement something or providing a list
of what needs to be implemented; what to implement, rather
than how to implement
Judy: may be some benefits to some of the what's making some
comments on the how; advantage in consistency for core
issues
Len: can take any HTML and transform to XSL; a lot of
accessibility problems can be addressed if XSL was
sufficiently powerful and someone provided the scripts; when
is XSL going to be part of the browser and how powerful will
it be?
Al G: favor a certain amount of how; precedent: ALT-text;
what you get out of authors is how the browsers handle the
markup; must be consistent so as to provide authors with a
single target at which to aim; virtue of this group is that
it is a consolidate body that brings together info on needs
of persons with various disabilities
Chuck O: participation is aimed at getting concrete
implementation ideas; ideas are great, hard and fast rules
are not
Mark H: agree with chuck; have lot of ideas to implement
LONGDESC; open to ideas but opposed to hard and fast rules
GV: right click to pop up LONGDESC; keystroke on item;
render small visual indication that can be easily identified
Jim: can be implemented with CSS
GV: user can turn off options
Len: XSL tested against existence of attribute
GJR: encourage authors to add accessibility-oriented text to
page using style sheets; in absence of commitment by UA
manufacturers to support LONGDESC, should also encourage use
of style sheets to add links to page for LONGDESC
TV: XSL will allow us to do a lot of the transformation
needed for access; for example, intelligently unrolling and
reordering tables; downside: XSL working group just getting
formed, so let's not rely on it for accessibility
Len: does MS have plans to release a pre-recommendation use
of XSL?
Kathy Hewitt: have to look at what is available when browser
is released and use that

Discussion Summary (Kitch)
Kitch: guidelines should tell developers what to implement
and provide suggestions as to how when we can, but what to
implement will be required
GV: Access Board compiled an appendix of all required items,
accompanied by strategies/suggestions
Dennis D: implementations bog us down; need lists of what,
not how
Chuck O: questions for Raman: how can we get control over
process of rendering frames and tables and intelligently
unrolling them in the browser
TV: to unroll table with CSS would need: (a) unroll table
and show rules (b) eliminate certain items (c) ability to
add certain items; for full blown solution CSS not place to
do this--right place is XSL, but since XSL is not yet here,
should do it in the browser, as capabilities outlined above
are not in CSS 1 or 2 and are not yet supported by any PR or
WD
Chuck O: how does Lynx handle tables?
GJR: simply unrolls them by inserting a <BR> when it
encounters a </TR>
PJ: what about headers?
GJR: <BR> at end of each <TH>
Cindy K: what about embedded tables?
Al: renders the parse tree; will complete first inner table
first, then second
Chuck O: is it doing any processing?
TV: gut feeling no (agreement from GJR & Al G)
Jim A: let's take topic offline and put online--too
technical

topic: Features List/Parsing Eval
Kitch: is there one place that describes features each
browser has and/or how they implement certain things; do we
need to do that?
Greg V: could be useful for WG, but should not be used as an
evaluation; useful to have list of browsers and what they do
Wendy: browser catch and browser watch; don't go into
details
Jim A: how does bobby check browser compliance
David: browser check is done totally independent of the
accessibility check; accessibility check is the
accessibility; and the browser check is a browser check--no
interplay between browser and accessibility check; browser
checks are based on DTD format between browser and HTML
level/DTD; what is being ask is functionality; CAST does
straight DTD checking; the DTD for each particular browser
is different from straight HTML DTDs; each browser version
handles a specific DTD and handles HTML in accordance with
their internal DTD
Jim A: useful for group to compile
Chuck O: want to resolve holes in IE4.1; if you see a bug or
something implemented incorrectly notify
chuckop@microsoft.com or kathyhe@microsoft.com and send to
list
Jim A: how to distinguish what is a bug and what is a
feature
Kathy H: err on side of conservatism and i will tell you if
that is way supposed to work or if it is a bug, and if it is
by design will be brought up with IE group
David C:  role of this group is to compile a wish list of
features we think should be implemented; only use compiled
list as a resource for examples to bolster our arguments
rather than having that list drive what we are doing
Jim A: group should be developing functionality wish list
for all browsers
Kitch: have a draft of wish list; how to get people to add
to wish list?  need then to prioritize and develop scenarios

 *** break ***

Topic: Current Browser Capabilities
Mark H: PW will place list of capabilities on PW site
Kathy Hewitt: MS will do same
GJR: will do same for Unix Lynx and Lynx32 in conjunction
with Lynx-Dev

Topic: Navigation
Jim A: summarized current suggestions/recommendations for
navigation discussed/proposed on UA list
Wendy C: user control over elements over which you want to
navigate/have exposed
Al: pre-walking commands; take all classes of elements,
develop priority list of elements, place in tree; navigate
through tree; done by U of Toronto; ability to have schema
view in which user defined which would be
editable/exposed/navigable
George K: where is status line on mobile/phone browser
David C:  how much do we want to tell browser manufacturers
what to do?
Greg V: if do as suggestions, then they will use them and
avoid having programmer-specific designations; mechanism has
to work even if elements have no logical structure and form
no tree
Phil J: HomePage Reader has highlighted
internationalization; example ALT text--need translation for
every language; need to talk to browser manufacturers to get
list of images;
Max: more than just ALT text that is both and
internationalization AND accessibility issue; W3C starting
an internationalization group
Jim A: form small working sub-group on the list: Phil, Mark,
Max, Microsoft person in Japan who is slated to participate
in Internationalization WG
Al: WAI CG should ensure coordination with
Internationalization WG
Chuck O: efficient keyboard access is something that IE
wants to look at; what IE does with keyboard access is going
to be very different than what other browsers do; if we say
move to elements, what does it mean--what is selection, what
is insertion point, what is focus? 2) forms--beginning and
end; in many there is no delineation; (3) navigation models:
author's model, user control, accessibility aided
navigation; make sure that aid built on top can access info
Len: DHTML does what i want out of XSL; can have script on
context menu that can break tables; apply searchable anchors
into the page; could be way of doing some accessibility
work, endowing author with more control;
Jaap: should limit ourselves to what browsers can do and not
what screen access apps can do
Jim A: what is a screen reader function?
Jaap: navigation of tables, et. al.
Phil J: mobility impaired need full keyboard navigation
Jim A: browser working on different level than screen access
George K: we know what elements are; should be able to
navigate to headings
Jim A: George please bring up on UA list
Greg V: id those things that are most important and put them
into browsers; CSS and scripts beyond capacity of most users
David C: not sure if choice between one or the other, there
is a minimal threshold of functionality for navigation that
needs to be built into browser and not role of specific
screen access software; universal design should apply;
advanced set does not need to be in browser, but minimum set
not only needs to be in browser, but in an easily findable
place
Madeline: should be more than minimal in browser; can
produce features that general users would use and
appreciate; our work is valuable to a larger community, more
effective in getting them implemented
Len: pushing scripts and style sheets because encourage
people outside community to get involved;
Greg V: might be useful if there was a script that would
take frequent accessibility options and put them back on the
toolbar
Chuck O: customizable toolbar is something that Kathy and i
are advocating
Greg V: what about an accessibility toolbar to save you from
having to build a wizard; like to see kiosk browser
Peter B: need to have basic mechanism; blind people read
serially, need to have that functionality built into the
browser
Jim A: keyboard navigation and focus indication necessary
for serial reading; focus between frames--keyboard focus
remains stuck on previous frame although highlighting moved
to other frame
Jaap: when go from frame to frame, and then return to a
frame, want focus to be where it was left-currently goes to
top of frame
GJR: need not only interframe focus retention, but
identification of frames (frame X of Y), just as need user-
controlled ability to maximize minimize frames, a don't
display as frames option; ability to navigate and orient
element by element, don't just in status line (audio
browsers in cell phones, et. al. don't have a status line);
want ability to move element by element and have a cursor
that responds appropriately; bottom line is all browsers
need to endow user with the option of turning on a cursor
Judy: particularly want to move to headers
Chuck O: what do you mean by moving to header
Judy: want to navigate by chunks, not links
Al: when you page down focus moves to first visible as you
page down, if no link no focus
Dave C: define focus
Chuck O: something is selected and it can take input in some
fashion
Hans: 2 ways to navigation: by structure by hierarchy and
sequentially; the 2 should not be mixed
Wendy: command line interface; need more direct access to
things; especially with use of ACCESSKEY; need to search
text on page and make us of them in browser
Greg V: 2 ways of going through page: 1) don't know content
and are browsing 2) knowledge of page and want to get
somewhere
Chuck O: spatial model; WebTV optimized for quick browsing--
5 buttons: up, down, left, right, go
Jaap, Jim, and GJR: that is the basic functionality that
Lynx gives the user
Jaap: put this in wish list
Guido: is there going to be any kind of auditory feedback
when focus moves across frame boundaries?  would eliminate
tying to status line
Chuck O: there is a sound pack with IE4: start navigation,
end navigation, and 2 others can't remember off top of head
David C: we need action on any find command when you find
only within elements; context dependent searches
Wendy: should be able to take any element out of DOM and
search it
Judy: need someone from WebTV to participate
Chuck O: will try to get someone to participate from WebTV

Topic: Recruiting Beta Testers from the Disabled Community
Kitch: maybe other disability orgs can build on work at U of
Hertfordshire
SM: definitely yes
Al G: EO volunteered to be keeper of scenarios; need to feed
output from U of Hertfordshire to EO, especially those at
the knee of the curve--those that are critical
GJR: need to id usability labs in disability orgs that can
perform usability studies on current technology, in
particular the W3C products, especially Amaya, but also the
major and minor browsers, authoring tools,
validation/evaluation tools, etc.; keep findings public and
elicit responses/feedback from users via lists (not just W3C
lists) and the web

TOPICS for Discussion on UA LIST
1. implementation of DHTML
2. what functionality is needed that is not on wish list and
is not extant
3. user agent implementation: what kind of tools and
metaphors are we going to need and/or address
4. alternative ways of navigating--command line interface