UA Working Group Face to Face Meeting

Location: Los Angeles, CA

Time: 1:30-5:30p.m.

Date: March, 21, 1998

Presentation: Sarah Morley (University of Hertfordshire)

Study has 2 aims:

  1. to ascertain whether web pages authors are able to use WAI guidelines effectively to produce accessible pages
  2. to ascertain whether pages they create are accessible to the blind

2 groups of students will create pages:

  1. those who have experience creating web pages and those who have never used/studied HTML or CSS
  2. blind users who will test pages will range from novices to "power users"

how the study will work

  1. students will design pages under observation
  2. student output will be made available on the web to be remotely evaluated by blind users; some will be invited into the lab for observation of navigation
  3. tasks: visit web site, then fill out form/questionnaire

Questions for SM

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

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


  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:

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

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:
  4. 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

  1. Brief characterization of user (i.e. functional limitations,
  2. Context for activity they are performing (school or job);
  3. 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 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

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


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?

  1. cannot display; implementing accessibility into mainstream products bound by considerations; not an easy task; have to consider implementation costs;
  2. have not gotten back to level supported in 3.02 release

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 or 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

Four 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

Next Steps

  1. next Face2Face meeting not yet scheduled