Review of WAI User Agent draft 19981019
Notes by Harvey Bingham
Attendees:
JA: Jim Allan
KB: Kitch Barnicle (AFB)
HB: Harvey Bingham (YRIF)
JB: Judy Brewer (W3C)
KC: Kevin Casey (RNIB)
WC: Wendy Chisholm (TRACE)
DC: David Clark (CAST)
CC: Carson Craig (Henter-Joyce)
JG: Jon Gunderson (UIUC)
EH: Earle Harrison
CH: Cathy Hewett (Microsoft)
IJ: Ian Jacobs (W3C)
CL: Catherine Laws (IBM)
CO: Chuck Oppermann (Microsoft)
MP: Mike Pedersen (Henter-Joyce)
HR: Hans Riesebos
JR: Joe Roeder (National Society for the Blind)
ST: Steve Tyler (only Sunday)
WC: 4.1.1. Grouping too diverse
DC:
KH: Bothered by ratings.
DC: The techniques are not parallel.
CO: Worry about use of these as a club.
HB: Several countries will be using these as clubs.
IJ: Let user control font size, is important.
CO: Down play marketing issues, focus this as input to managers and programs
Consider this is as a checklist, rather than universal guidelines.
HB: Checklist items may not be yes-no. Many are judgemental.
CO: Want yes-no to build checklists.
IJ: Break 4.1.1 into a set of seven.
DC: Consider that the guidelines are vision-centric.
JB: Read for other disabilities, to make sure they are not ignored.
JG: Images have 3 sources: alt-text, title attribute, or longdesc. Title for tool tips is normal use.
Tooltip can use title if present, else alt. Currently no use of longdesc. IBM Homepage reader does
Use longdesc. ?Opera?
DC: Should we assert going from text to speech.
JA: Turn off tool-tip to unclutter.
CO: CSS needs attribute for rendering of tool-tips.
KC: Subtitling and captioning.
KC: Simplified screen
JA: as JAWS linearizes/serializes, we have no guideline to assert this to be desirable.
CO: High Contrast flag in MS. IE3 and IE4 removes background image and double font size.
Removes eye-candy.
JG: User could set up profiles and invoke them. That could include a "simplification" setting.
JA: Add extinguisher, acts like a little proxy, simplifies what it gets before sending to browser.
IJ: 4.2.1 on access to alt content.
JB: We should break these out more consistently. Redundancy in "representation of" alternative content.
The SMIL material here has lost its context when incorporated here.
JG: Break out object treatment from where it was merged.
IJ: Too much was merged.
JG: 4.2 Under access to alternative content, need subguidelines for audio, video, table, objects, applets.
IJ: CSS allows generic mapping into table structures.
KC: Five senses available, guidelines need to address more than two.
JA: A RealAudio player is also a user agent. It needs to be considered,
JB: Much like plugins of many kinds.
KC: Multimedia is to way-out. TV is brought to the common understanding.
KC: Add the authoring clue on what longdesc points to. Mona Lisa should have pointer to the Louvre, not to some textual description of it.
IJ: User may choose to bring up separate window for images, keeping text only concurrently.
KH: Alt text shouldn't be smooth flow. An attempt to make it so, would lose the distinction about why it was included/selected.
JG: Users should have control over which can be displayed.
KC: Seriously low-vision want both image and alt-text. Both are useful.
JG: We don't want unimodal choice, but rather provide simultaneous choice.
WC: User scenarios for variety of users.
JB: A task for EO is to define the user profiles.
WC: Define a variety of disability profiles, and give task and expected use of these.
JG: Two concepts: choose one among, or supply alternatives for concurrent use.
WC: Announce when done loading.
XX: A full image with images off, a blank page.
KL: If there is a URL attached, that id different from a pure img.
KH: Do provide to screen readers info on img.
EH: A link attached to image is read in IBM reader. Often the length of the URL is too confusing.
MP: Render the last part of the link, not the whole thing.
KL: That's what is referenced.
TH: URL on status line, and screen reader would read that to user.
IJ: CSS has a before and after "pseudo-element" before rendered element. Rendering of external objects is not under author control, nor under stylesheet control even. For that reason, there is not adequate to use for alt text.
IJ: Split out 4.1 guideline topics.
JB: Propose overarching controls under user preferences.
IJ: Implementation (by particular ua) vs. technique (CSS).
JA: How pass through user preferences (and to where).
IJ: The techniques doc should be able to indicate what might be achievable.
KB: This format as a checklist is more amenable.
KH: Hard to get this from a longer checklist as too long to an executive summary.
JG: Thanks to participants for taking time and cost to attend.
JB: Indexes in page authoring guidelines, by priority of technique.
WC: Recommend generating checklist from the guidelines. Users of this guideline are the implementors, Microsoft.
CO: Checklist pushback from developer. Why is this important?
KC: How important the turning off of blinking text is dependent on the text, as determined by the author.
JB: May not know that importance.
JB: Report II. Didn't get further to rewriting. Hard to break apart the current organization.
KC: Include the variations in simultaneous access.
JA: complementary or supplementary information revelation. How tell screen reader that a longdesc
is present.
IJ: How let user know that a script is present.
CO: Technique to do longdesc, if image is not shown, put up special icon, add text [indicating that longdesc is present] as well as the alt text, and make the image tab-stoppable if it isn't already, and have menu
choice including longdesc…
WC: Need a querying mechanism to determine what are the alternatives for display.
JG: Characteristics of a context menu may be more generally useful.
EH: If image has longdesc, use "D" special image, present plain text,
CO: Now if right-click on an image get properties of it. Some power tools give more flexibility.
JA: Don't want to hit the context menu for each image.
IJ: Discription elsewhere: orientation about page, number of links, tables, objects, forms, etc.
DC: If in normal mode, need way to know that longdesc exists. [marking about longdesc notice]
is not a good solution in tool tip
JG: When image is rendered, add a visual indication of longdesc presence.
IJ: Any with longdesc set can trigger an action in CSS.
JG: D-link is claimed to be "proprietary", an old company called "D-Link"
WC: D-link is transitional.
DC: Page author guideline immediately. UA guidelines are for futures, assume implement longdesc.
JB: PA for here and now, vs UA for future.
WC: We hedge, do both today, (D-link and longdesc).
KH: Next version of browser 6-months to year.
JB: Could convert from PA D-link to longdesc
IJ: CSS can hide based on attribute value.
KB: Designers dislike D-link distortion. Future authors want converter to longdesc.
WC: ER may be the responsible group for identifying conversion.
WC: GL issue to use predefined values for REL?
IJ: To tell UA what to do with D-link?
JG: Argue against use of REL, there are alternatives, deprecated menu tag.
HB: Class is local convention
IJ: Let user exploit with authoring, and overrideable stylesheet from user choice.
JG: D-Link 4.1.4 is gone.
Techniques for audio and video objects.
DC: Concern for automatic conversion, with what limits?
MP: conflict sound cards driven from several sources.
KC: Put the context of "identify" needs to be said somewhere.
JB: In longdesc, we broke out identification from content, same thing here.
JB: Visibility, group access controls.
JA: If "show-sound" is on, also haul up captions if they are there. Multimedia two streams concurrently that captures visual text in balloons. That is different kind of captions. (Chuck … described to JA).
DC: Complementary vs supplementary, across modalities we have to be clear whether we have a direct interpretation, or an additive interpretation.
JA: Need text caption as well as second video for deaf-blind.
KC: Danger in image file of text, makes inaccessible.
JB: New models of presentation may need to map to
KC: Text in non-text is coming, particularly as digital photography will have overlays of text.
HB: Avoid "caption" as confusion with "closed-caption".
WC: has made distinct "text equivalent".
WC: Visual notification of sound being played. (Show Sounds)
CO: Windowing OS NT knows about wav files, Windows 9x doesn't know other that speaker sounds.
Background sounds in MS extension are available in CSS2. If the browser knows that a sound is being
played, give alerter: pause the sound, replay the sound. Could add ALT to this background sound.
CO: If browser is not involved, how detect it.
DC: We are addressing more than HTML for sounds.
JG: Need a notification and captioning means if text is available.
CO: In HTML, only way to do sounds <BGSOUND>
WC: Java can do sounds. Desire that
CO: Title bar, flash window, invert screen-- window9x only knows speaker, not other soundcard.
Window NT knows all sounds, any sort of *.wav file would work.
DC: User agent, the assistive technology, and the underlying operating system all may effect the user.
Post break.
DC: User agent is not necessarily the one to render the alternative.
IJ: Players that have limited modality may need synchronization with other modality user agents.
KC: Any object should be adequately able to treat its media, but not other media.
WC: RealAudio can handle the text-to-speech?
JA: Quicktime has caption embedded. It should be able to support the captions.
CO: SAMI can have captions from different source. Windows media player, shows video, plays audio, uses IE browser for text.
HB: Synchronization issues, SAMI one way, SMIL another. Use needs to stop, backup, resynchronize.
JB: Different UA have different needs. Summary needs to identify and to render, in some cases browser
May notify the other UA that work is available for it. There may a primary UA.
MP: Info given to assistive technology deserves its own standard for interchange/specification.
JG: Audio track identification and turn on/off.
HB: Multiple audio tracks need selection means.
JB: Text media object is the verbiage parallel to video or audio. Screen reader needs to know that there is a screen object to be read.
IJ: PA guidelines: accessibility issues; and the PA techniques: HTML implementations.
IJ: That model is less appropriate for UA. UA Guidelines include
The UA techniques don't have the same HTML/CSS/CSS2 restriction.
JG: Reorganize
KC: Could we separate structure and content from style.
CO: Want list of attributes that they need to implement. Accesskey on links should be implemented.
IJ: Index of elements in PA techniques, with link to where it is covered in the guidelines.
IJ: None done for attributes yet.
IJ: Consider side-by-side support of attributes "browser-caps, but not for HTML 4.0".
JB: Compatibility section should have implementation for W3C. Different for implementations.
DC: Bobby does some cross UA comparisions. Attribute analyses are not adequate. Different
browsers may ignore attributes, others may treat differently.
HB: No clear statement of what the #IMPLIED values means.
Identify these and note them to IG>
JB: Treat accessibility features to techniques document.
JG: We have items to add to compatibility: different w3c docs have impact.
We've missed title and alt. Do we need a list of compatibility issues.
IJ: Add SMIL and MathML.
IJ: Re: repositioning captions/content
KC: Useful for draggable matter to avoid conflict with what might otherwise be visible.
JC: Jaws gives alternative rendering, strip graphics, make linear reading order,
WC: Navigation bars put at bottom of page.
IJ: Class info could be used to move matter around window.
IJ: CSS2 has a positioning means to place stuff in known positions.
JG: How important is it for UA to do this?
DC: Implementation using class with CSS2 expects support of it. Many objects need repositioning.
IJ: Need to generalize.
KC: Not possible to separate style and content here for navigation. If move object relative to others,
That is a major intellectual property leap to do this for arbitrary objects.
JB: Limit to text equivalents. Authors shouldn't presume visible in authored display area.
JG: Positioning text rendering is issue of video/audio players.
WC: Change rate of either audio or video. Includes pause.
CO: For sound, start, stop, repeat, fast-forward, fast-reverse.
JA: Need to maintain synchronization.
Techniques for other types of objects.
DC: In NOSCRIP don't work in HTML 4.0. (as it isn't rendered).
HB: The bottom of an Object could be a noscript.
WC: Provide for noscrip or alternative to get around scripts.
IJ: If scripts are unsupported the noscript tries to give the alternative.
JA: Author who depends on scripts, if noscript were there with link to alternative that user could activate.
JC: Implies that user can turn off scripts.
IJ: No work on behaviors of HTML documents. Work is going on to bind events and actions, possibly in a cascading way with syntax like CSS.
WC: We'd like to be able to attach a script to recognize and navigate tables that could be reused.
WC: Use my external script on any page, creating a javascript to override/filter in chain of normal use, to manipulate DOM. An extreme manipulation of browser.
IJ: Guidelines don't now let users turn off scripts.
CO: Now in security can turn off scripts. Not same as defaulting to noframes.
CO: Two kinds of pages from MS: DHTML or download version.
WC: User control: for pages that autoupdate, user should have update on/off, and rate of update, and notification of update. User processing rate differs. Pause, say-slow, user say "ready" before continue.
Now this is on the author. Now need non-refresh version to work as well.
HR: Some pages depend on refresh rate. Author should be able to deny user the choice to change rate.
KC: Lots of information update rate (stock price tickers) cannot be specified by user.
IJ: A meta element in the head did a non-normative html to use +3 to say wait 3 sections then go onto
Somewhere else.
CO: Metatags are opportunities to override user control. If turned off, there is likely some static link to
achieve the same effect.
JG: Scripts. Disable, update rate, automatically updated pages. More than DHTML. Some server may be doing this to the user.
KC: will do this clarification on refresh and apply in author ing as well.
JG: Alternatives to frames, NOFRAMES
WC: A list of titles would be useful, if user turn off frames.
KC: Author not stating the sequence in a frame.
MP: Can tell when move to new frame. IE allows moving from one to another frame.
CO: No difference between frames and lots of other products, with different window handles.
CO: Framed sites are often bad.
CO: Hotmail is good example of a second window for frames. Closing that second frame returns to the original.
DC: If frames off, and no noframes, what to do? Give frameset list.
JB: Also issues for cognitive folks. Once open frame, no way back using keyboard shortcuts.
Need clues to work this.
EH: Jaws for Windows lets lists be generated. This is a third-party issue. Not clear why it is a UA issue.
JB: Lot of issues are shared between PA and UA. Make sure that PA isn't looking at only visual issues.
WC: PA wants title and longdesc on frames. Need description of how frames interconnect.
User query to get descriptions, turn on/off frames.
DC: Want quick way to scroll through a page. Frames off, and main window off as default, need to click on it before scrolling through it.
HE: Hard to identify frames by looking at page by itself. The concept of frames is often obscure.
KC: Agent technology cannot clarify author's intention.
DC: Not all groups have alternatives.
JB: Navigation is big issue, for alternative users, quad, eye-gaze.
IJ: Choose noscripts, choose see or ignore noscrips. Probably also for frames.
JA: In some browsers Ctrl-Tab moves frame-to-frame. Title on frame should help identify frame.
JG: We expect keyboard support for stepping among frames.
JB: In identification section, deal with both identification to user agent, others to user. Many will not have mediators
WC: Title attribute is used in frame to step through the links therein(?)
CO: A description of a frame should fit into title or alt. Why need longdesc?
WC: To describe the layout?
CO: Would need to indicate that longdesc was available and a way to get to it.
JB: Deal with frame identification and navigation.
WC: Hard to get orientation with screen readers that just went across the content .
JB: Some screen reader UA could block frames.
EH: UA issue on page with frame, select in frame then go back to beginning, rather than go back to where you entered the frame.
IJ: With two frames and content changing, cannot get back to an ephemeral place. \
WC: Open current frame in windows is in context menu.
CH: IE5 addresses some of these.
IJ: This can be done with scripting.
JG: Keyboard support for frames, history across frames, specify what to do with noframes,
Use title as URI if there is no noframes.
IJ: How define current in the document? Bookmarking? Event cursor? Point of Regard to be returned to,
Needs better definition.
IJ: Events, which elements have them.
IJ: Popups, alertings and escapes from them, and where do we go from that completion.
IJ: onmousedown, onkeydown redundancy as alternative invocations.
WC: Lots of more PA issues today.
DC: The P element isn't used consistently.
IJ: Sentence recognition is an I18N issue.
WC: There are text models, smaller minutia of sentence. Work in Active Accessibility V 2, and Swing
Access model. If those are models for DOM, that would be useful. Swing uses its own object model.
Sun does this low-level work, compare it to DOM. Protocols and Formats group is the one to take this to the DOM working group.
CO: Java accessibility text model is a small subset of what is already in DOM.
IJ: Translations are at a sentence level, so would be useful as sentence recognition/tagging is worth while.
IJ: No draft guidelines on I18N out yet. There is a character model and I18N layout in working drafts.
IJ: Martin Duerst is principal contributor to I18N. Sentence recognition is language recognition.
Japanese have no spaces, or sentences. Word concept is different.
DOM use, what are problems.
CO: Twisties, all collapsed, a click on one of them expands tree under it. Most elements are hidden. Only the selected one initiates expansion.
IJ: A source tree and a rendering structure that may differ. Rendering with "before" and "after" may cause
more stuff to be rendered than in the source. DOM has only the source and structure. It is not always evident what the reverse mapping is from rendering to DOM.
CO: All elements and all attributes and values are exposed in DOM.
7. Ensure that user agent accessibility features are apparent
DC: Configuration part of UA must inherently be accessible.
CH: Turning off scripts is a security issue, so place it there.
DC: Universal design is ultimate objective. Should be integrated in all product.
HR: Some features on platform.
KB: Some redundancy is confusing, if an action can be taken several places.
EH: Wizzard, guidelines, make install, update accessible.
CH: Don't have printed documentation unless in a commercial product.
WC: A user agent assumes you can use info on a computer.
HR: What is "electronic accessible form"? Text, word processor format?
MP: Braille is beautiful, do own braille-out for quick reference. Some use JAWS with speech only.
CC: Provide large print, put braille cards to get started: "put in the CD".
IJ: Need bootstrap fully accessible.
CO: There are white papers on accessibility for all MS products.
Where do we go from here?
IJ: Editors have a new draft by the end of the week.
JB: Next telecon Nov 4. May not need another face-to-face. By end of the year, we are trying to get two guidelines to PR status: PA and UA.
IJ: Need to augment techniques document.
JB: Both need to be ready before going to PR.
DAY 2
TABLES
JG: Tables for spatial formatting: These are used for layout
JG: Data tables
JG: Render summary information
JG: Row order or column order
JG: Data table row and column information.
KB: How do we specify rendering.
CO: Screen readers have been exploiting the logical order of a table. Since IE3.
DC: Make hooks available. Make document structure
Mke: Can read entire row or column
CO: Should pass all attributes that are part of the markup for programmatic means by other stylesheets.
IJ: Table guideline: data table or layout table. A user agent to resolve.
CL: Only uses header info if it is there. Also a where am I? Tried for several months to auto-recognize
The
JB: We need to get help from vendors. No authoring tools. MS will be willing to support the tools
5 or 6 months after UA guidelines.
CL: Too much scrolling, headers
WC: Other reasons for using data.
IJ: CSS2 has speak-header
IJ: There is an HTML4 algorith for guessing the headers in absence of TH.
JA: HoTMetaL 5. Doesn't support table attributes cleanly.
CL: Do use the headers attribute.
KB: Algorithm can read whatever is changing.
JG: New issue: some HTML available is ignored. Some HTML
CO: Lynx just ignores table markup to get original linearization.
CO: Smarter linearization uses logical structure.
JG: Maintain heads for large tables.
JG: Navigation doesn't require serialization. Serialize logically.
IJ: Techniques has all tables material in one place.
Today the UA techniques doc mirrors the UA guideline TOCs.
KEYBOARD NAVIGATION
DC: Pass-through of system-level flags, such as sticky-keys.
IJ: Many of these are needed.
CO: The keyboard model should be logical and consistent with other apps running on the system.
HB: I18N issues on mapping keyboard equivalents.
KC: Different disabilities may want conflicting separations: close together, vs deliberately separate.
JB: provide a remapping. Could pick up on cognitive learning. Voice macros, keyboard combinations,
DC: Single switch input, not output.
IJ: Trace has raised the issues on keyboard needs. Add some rationale as intro to keyboard guidelines.
CL: User has access to most any structural information about page. Often use keywords, like begin/end form, or to images that are not links.
JA: Question need for user to get exposed to HTML markup.
IJ: Search scope:
element content, attribute values, external content (longdesc)
all elements vs active elements,
identification: numeric order, id values, text, some part of text (first letter).
WC: PA asserts importances. UA asserts separately, chicken and egg.
KB: Will typical user know all the search options.
JA: Regenerating what we had in the prior version.
WC: Navigating through headers is useful.
KC: Does use how author
CO: MSIE Powertools, one makes outline.
Find every structural element, put bookmarks into the original, make outline view, and navigate I, without change to the browser. Have two active windows. Alt-tab to get back.
KB: Navigating structural elements we need. Distinguish navigation from searching.
SCRIPTING LANGUAGES
JG: Browser as application where many others may be invoked
How does user act on application with alternative input means (to mouse events)
How does user know what is changed on a page?
CO: Most difficult and/or important problem.
JG: Need cooperation of PA.
JG: 6.5
CC: Jaws cursor: either mouse pointer or PC cursor can be moved. Can route either to JAWS.
MP: Haven't done much with javascript.
JG: Some context menu useful.
JG: Event bubbling. Now no necessary correspondence to place and script (can have a default responder script for interpreting an event.) An alternative is to put all the event responders on any elements.
CO: In MS OLE style guide, a context menu with submenu allow editing of event/action matching.
JA: User needs to know that there is a context menu.
JG: only four have used DHTML:JG, WC, CO, CH.
IJ: Tried to get a bound on what we should address. Too much intractable as cannot predict semantics of a script. An element may be involved in the initiation of an event, though bubble up may make it remote.
The author must assert what a script is doing.
IJ: DOM 2 may have some coupling to help with semantics.
IJ: Identification only for elements with on… events.
IJ: Navigation
JG: WAI Protocols and Formats feeding DOM group. There are mechanisms to get into DOM any special
requirements that WAI may want.
JG: Any element may have associated script(s).
CO: Keyboard actions on equal footing with mouse actions, in DOM.
KH: Some of the MS developers are on DOM team.
CO: Chris Wilson is one.
CL: Often suppress scripts. Do have a DOM representative.
IJ: Scripts with resprect to HTML: bound to events, executed at load/unload, and in head of document,
Submit buttons to trigger scripts. Issue is which would be disabled.
CO: Demo of Outlook 98 Organize feature, uses HTML through scripting.
CO: Content + style + behavior + user input all impact this.
JA: That HTML is used in other application doesn't matter to us.
KH: If you solve the problem in the browser, then other applications built on it get solution free.
WC: We could list what we want for UA. Element may need events list.
IJ: Propose for PA that title be used to describe the on-event
CO: Title as tool tip.
HB: Title isn't explicit enough for all the ten on-events. There is no hook for these differentiations.
JG: Noscript is alternative.
WC: A page authored with script can be ok.
CO: Need path for older sites "noscript" to avoid rewriting site.
CO: Need improvements to DOM and UA to make scripts more nearly accessible?
IJ: What is an accessible script is?
KC: What makes a script inaccessible?
IJ: What makes a page inaccessible? Provide information to replace what script would have provided.
IJ: User can't tell whether or not a script is accessible.
DC: Focus on content rather than its representation. Find alternative
IJ: If script is making page inaccessible, then let user turn it off.
DC: Need alternative content from author.
JA: Why tell user that a script is doing something? If user is expecting something to happen that the
script provides.
CL: Celestial Seasons is all-script. Others use just java submit -- rather than just HTML submit.
JA: hotcoffee authoring tool has included ACSS styling.
KC: What is the problem we are trying to classify regarding scripts. What are the identifiable problems
in DHTML. We need to avoid the "all scripts are bad" syndrome.
CO: An application of a CD-sampler, lots of demo programs on a CD. Install Shield, Nuts and Bolts,
Hover over, watermarks, click and go, etc. May have been written in anything. The problems are
keyboard access, consistent systems colors, user interface timing, visual candy, consistent helps, etc.
CO: Given DOM and its event handling, these are harder to make keyboard mappings.
JG: Should UA try to repair pages authored in DHTML? Is this even doable?
CO: Can there be a keyboard synthesis algorithm that works?
WC: Added a tab index to do keyboard alternative. Can put tab index on a header.
CO: Impression that MS implementation of DOM closer than NS's.
WC: Has used tabindex on table as non-standard but working augmentation. Also put on headers.
JG: Author needs to take responsibility for accessibility of DHTML material. If use browser as application interface, how do we expect to guide them. What are the evaluation and repair issues.
KC: Legal requirements may make authors generate accessible pages. Then a commercial issue may encourage some sites to do so. Most sites won't bother. We can't impose on authors.
JG: An evaluation and repair strategy to synthesize mouse events might be possible.
HB: Question how to evaluate what a script is going to do?
WC: Use DOM, ECMAScript, profiles, etc. Authors needn't then author for multiple platforms. Recommend that UA only use W3C technologies/recommendations.
JB: Avoid non-W3-specific terms, such as DHTML.
CO: Want tabindex to apply to all elements in HTML 4.0
IJ: HTML group not adding function to HTML 4.0. Instead migrating it to XML.
WC: Each element, if it had onfocus
CO: If guideline on kind of trigger, synthesize a virtual tab index. We could do a repair strategy.
JG: supply explicit events to element for input mouse events.
IJ: Should turning off scripts help some users?
CC: IE4.01 and JAWS for windows 3.1.
USA Today page has typical layout table inaccessibility. Choice to reformat into list,
Demo download from on www.HJ.com 11 Mbytes, runs 40 minutes.
HR: Where does DOM come in to UA? Should we propose to design accessibility around DOM?
JG: Some think that DOM will improve accessibility. We may want to specify what parts of DOM
are important.
CL: IBM not using DOM now.
CC: Would like to provide more structure than have. Netscape doesn't have flexibility that MSIE has
in DOM.
JG: What features in DOM need improvement, what are evidently useful, what have no accessibility implications.
JG: Al Gilman is collecting info for DOM2.
IJ: DOM 1 has just gone to specification. Should WAI give requirements input to DOM2?
CO: Important to have companies that have solved or are working on accessibility issues also provide input on needs.
CC: Is the UA guideline useful?
KB: