Location: Los Angeles, CA
Time: 1:30-5:30p.m.
Date: March, 21, 1998
Jaap: which browsers will be used
SM: range of browsers and range of screen readers
GJR: screen readers only?
SM: screen readers and/or braille displays
Len: how are participants chosen?
SM: recruited from RNIB members, BCAB, etc.
George K: content that will be developed will be a variable as well--some
kinds of content are easier to be made accessible than others; need a
large range of content to test
SM: excellent idea; will also use chuck l's styling pages
Bill L: are any of the web authors and designers blind?
SM: no--or, rather, not yet
Jim read mission statement, which is available at: http://www.w3.org/WAI/UA/charter.html
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
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
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
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
Jim A: original semantics: very important, important, recommended; interim solution 1, 2, 3 (1 top; 3 bottom)
purpose: descriptions that describe how user interact with user agents
Will L: Agent imposed limitations: keep your eye on the donut and not on
the hole; 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
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
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?
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 ***
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
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
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 ***
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
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