IRC log of ua on 2007-01-23
Timestamps are in UTC.
- 14:16:36 [RRSAgent]
- RRSAgent has joined #ua
- 14:16:36 [RRSAgent]
- logging to http://www.w3.org/2007/01/23-ua-irc
- 14:16:54 [JR]
- Meeting: WAI UA
- 14:17:20 [JR]
- Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2007JanMar/0009.html
- 14:17:37 [JR]
- Scribe: JR
- 14:17:58 [JR]
- Chair: Jim Allan
- 14:20:56 [parente]
- http://www.w3.org/TR/wcag2-req/
- 14:24:43 [cklaws]
- This document provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities (visual, hearing, physical, cognitive, and neurological).
- 14:24:52 [JR]
- All: Editing Requirements Intro - using WCAG 2.0 Req document as a model
- 14:33:58 [judy]
- judy has joined #ua
- 14:34:59 [jallan]
- http://cita.rehab.uiuc.edu/wai-eval/index.php?option=Test%20Suites
- 14:36:21 [KFord]
- KFord has joined #ua
- 14:36:41 [JR]
- All: Introduction edits: hilighting info from test suites.
- 14:37:46 [KFord]
- Yes, I do have Skype.
- 14:40:52 [KFord]
- Yes, trying to add as a contact now.
- 14:41:50 [KFord]
- I'm told this contact isn't found, can you phone kellford1967 on skype?
- 14:47:18 [jallan]
- Introduction
- 14:47:18 [jallan]
- User Agent Accessibility Guidelines 1.0 (UAAG 1.0) provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities (visual, hearing, physical, cognitive, and neurological).
- 14:47:33 [jallan]
- Since the release of UAAG 1.0 as a W3C Recommendation in December 2002, the UA WG has received feedback about the usability, understandability, and applicability of the suite of documents.[changes in the techniques used in web pages (extensive scripting, changes in the use of technology used for the web, udates in the functionality of assistive technology, changes in accessibilty APIs, changes in platforms (pervasive, mobile devices, etc.) These changes in additio
- 14:48:29 [jallan]
- The primary goal of UAAG 2.0 is the same as 1.0: to lower barriers to accessibility of user agents. Additional goals discussed in this document are:
- 14:48:29 [jallan]
- Ensure that requirements may be applied across technologies
- 14:48:29 [jallan]
- Ensure that the conformance requirements are clear
- 14:48:29 [jallan]
- Design deliverables with ease of use in mind
- 14:48:29 [jallan]
- shift focus back to base browser (make user agent base provide the accessibility model )
- 14:48:31 [jallan]
- explain how to demonstrate compliance through an accessible view using the appropriate UIs (browsesr and extenstions, assistive technology
- 14:48:34 [jallan]
- Clearly identify who benefits from accessible user agents
- 14:48:36 [jallan]
- Ensure that the revision is "backwards and forward compatible"
- 14:52:44 [JR]
- CL: CL's ideas for the requirements doc:
- 14:53:32 [JR]
- CL: 1. Encourage adoption of ARIA techniques by all UA's
- 14:54:12 [judy]
- judy has left #ua
- 14:55:48 [JR]
- CL: 2. More clearly define UAs as browsers but distinguish testing of compliance to distinguish plugins and ATs
- 14:56:16 [JR]
- CL: 3. Restructure to align more closely with TAG and WCAG
- 14:57:44 [JR]
- CL: 4. Audience - must attract all browser developers to participate as well as accessibility architects for APIs and accessibility markup architects
- 14:59:00 [JR]
- CL: As well as consumers of accessibility APIs (AT developers) and end-users of user agents.
- 14:59:11 [JR]
- KF: Plus Plugin developers
- 14:59:33 [JR]
- UA: Wants to remove "plugin" and use "embedded UA"
- 14:59:53 [JR]
- PP: Plugin to VIW - plugin to chrome
- 14:59:59 [JR]
- VIW=VIEW
- 15:00:42 [JR]
- PP: Use Case: FLASH in a doc has own model and view
- 15:01:15 [JR]
- PP: FLASH implements accessibility API
- 15:02:57 [jallan]
- plug-in vs extension vs model
- 15:02:57 [jallan]
- flash - own ui, implements accessibilty api (part of infrastructure), provides content
- 15:04:13 [JR]
- MODEL: Programmatic access
- 15:04:48 [JR]
- VIEW: Is the UI (the chrome, AT, etc.)
- 15:06:35 [jallan]
- model is the base that everything is built from or overlayed upon
- 15:07:18 [jallan]
- view is the gui (chrome, AT, content view, etc.)
- 15:08:57 [jallan]
- jr: might also split the view into chrome (UI) and content
- 15:10:24 [JR]
- CL: Other views: Firevox, UIUC accessibility extension
- 15:11:05 [jallan]
- use case: UIUC accessibility extension - extension to view (using api to get information), consumer of existing model, extents the browser ui to provide information to end user.
- 15:13:22 [JR]
- JA: Brings up compound docs - where navigation and other things are made more uniform
- 15:19:05 [JR]
- All: Discussion of model-view controller split as related to multimedia
- 15:21:35 [jallan]
- flash/media-player/PDF - own ui, implements accessibilty api (part of infrastructure), provides content , both a model and the view, not part of the HTML DOM , embedded object (in HTML), may have own DOM/API, may expose public API so others can get at the information
- 15:21:53 [JR]
- KF: Good use case - what would plugin developer do - ie Quicktime doesn't expose
- 15:22:20 [JR]
- CL: Other use case - Web applications
- 15:24:13 [JR]
- KF: Ex. tree view controls
- 15:27:48 [JR]
- CL: ARIA doesn't handle keyboard nav at the moment.
- 15:28:18 [JR]
- CL: Becky etc. writes style guides for widget sets specifying how to do keyboard nav
- 15:29:17 [jallan]
- web application - own ui (provided by the author, not the model), repurposes functioning of standard controls and creates custom controls [author must use WEB-ARIA to be accessible], doesn't implement native/platform API.
- 15:30:46 [jallan]
- jr: can have a web application that is an editor
- 15:31:24 [jallan]
- cl: try to get the browser to understand what is going on and provide the information to the APIs
- 15:31:41 [JR]
- JR: Can have web content that is a user agent
- 15:32:07 [jallan]
- cl: may be trouble with ARIA because of implementing its own keyboard navigation
- 15:32:57 [JR]
- CL: It's a SMOP=Simple Matter of Programming
- 15:35:02 [jallan]
- ...not part of chrome, the browser can not interact and allow the user to modify the web-application's key bindings
- 15:36:12 [jallan]
- cl: want to avoid off screen models, heuristics,
- 15:36:46 [JR]
- All: Don't want things to be done site by site
- 15:38:21 [jallan]
- all: problems with javascript, outside of the model, doesn't provide a model of what its doing, not part of the dom
- 15:38:44 [jallan]
- ..can assign keybindings,
- 15:39:38 [JR]
- CL: Not people in accessibility creating this technology - access is reacting.
- 15:40:19 [jallan]
- UAAG is trying to provide direction for developers to make access easier
- 15:42:58 [jallan]
- CL: AT is not a model (may have its own model), it provides a view - consumes the controller model and provides output
- 15:57:48 [jallan]
- Ensure that requirements may be applied across and interoperable with technologies (compound documents, scripting languages, operating systems, platforms (mobile, etc.), APIs, accessibilty architectures
- 15:57:48 [jallan]
- Ensure that the conformance requirements are clear
- 15:57:48 [jallan]
- Design deliverables with ease of use in mind
- 15:57:48 [jallan]
- shift focus back to base browser (make user agent base provide the accessibility model)
- 15:57:48 [jallan]
- explain how to demonstrate compliance through an accessible view using the appropriate UIs (browsesr and extenstions, assistive technology
- 15:57:51 [jallan]
- Clearly identify who benefits from accessible user agents
- 15:57:53 [jallan]
- Ensure that the revision is "backwards and forward compatible"
- 15:57:55 [jallan]
- restructure to more closely align with ATAG and WCAG
- 16:00:49 [jallan]
- http://www.tsbvi.edu/technology/uawg/issues-jan11.htm
- 16:02:10 [JR]
- CL: Also should add note on "reducing redundancy"
- 16:05:04 [JR]
- JR,PP: Should keep stop bliking etc. for known things - "AL's 80-20 rule"
- 16:06:52 [JR]
- JA,CL: Discuss customization - customization can be overload
- 16:07:02 [JR]
- KF: Depends on implementation
- 16:07:24 [JR]
- KF: One button - may do multiple things - plus profiles help
- 16:07:42 [JR]
- JA: Yeah but may still be daunting
- 16:08:08 [JR]
- CL: How do you make customization easier
- 16:08:51 [JR]
- JA: ScrReader have many modes
- 16:09:23 [JR]
- JA: Form in table runs into Form mode/Table mode interaction problems
- 16:10:48 [JR]
- JA: Gives example of checkbox in form cell
- 16:10:59 [JR]
- CL: Yeah but where do you want info pulled from?'
- 16:11:17 [JR]
- JA: Other example - Form with prompts
- 16:11:39 [JR]
- JA: Forms mode make instructions difficult
- 16:12:10 [JR]
- JA: Finds himself on a "bunny trail".
- 16:14:43 [jallan]
- CL: what about flashing things. what is the issue
- 16:14:51 [jallan]
- jr: photo sensitive
- 16:15:14 [jallan]
- JA: there are things that UA doesn't know about,
- 16:15:56 [jallan]
- KF: push back to content develpers to create things that the UA can determine and make accessible control
- 16:16:13 [jallan]
- JR: WCAG role for content developers
- 16:24:51 [jallan]
- CL: UA need to address non-W3 technologies
- 16:30:07 [JR]
- CL: Idea for MathML person - Neal Soiffer - Design Science
- 16:37:16 [JR]
- KF: Let's move on
- 16:40:19 [JR]
- JA: Going through issues doc...
- 16:42:33 [jallan]
- goal 7 restructure to more closely align with ATAG and WCAG simplify but combining similar checkpoints, reducing redundancy
- 16:42:33 [jallan]
- balance roles Author content and UA functionality (repair and control functions)
- 16:44:12 [JR]
- JR: Once again we should be less absolute about compensating for author actions - since these can't always be predicted
- 16:44:58 [JR]
- CL: CSS is a nother thing that author may use in ways that need to be fixed
- 16:47:04 [JR]
- KF: Hard to do - UA has to look in CSS directly and use heuristics
- 16:47:28 [JR]
- PP: In Linux it's easier because this info goes into the Linux access API
- 16:48:23 [JR]
- PP, CL: Discuss bullets - are they content? In FF they are handled as content.
- 16:50:14 [JR]
- JA: Skins...
- 16:50:36 [JR]
- PP: FF uses CSS for XUL.
- 16:50:48 [JR]
- KF: IE does not do this
- 16:51:57 [JR]
- CL: Also access-aiding CSS like magnication style, high contrast style
- 16:52:49 [JR]
- CL: Can cause prob - ex. author says "no scrollbars" but user stylesheet makes content too big too fit
- 16:56:56 [JR]
- JA: Brings up voice settings
- 16:57:19 [JR]
- JR, KF: This should be modular, applying to voice browsers but not to all UAs
- 16:59:38 [JR]
- All: Discuss where to put chrome in the reqs
- 16:59:59 [JR]
- JA: IE does extensions?
- 17:00:14 [JR]
- KF: IE has had extensions for a long time
- 17:02:15 [JR]
- KF: What burden on underlying technology to make extension experience accesible?
- 17:02:44 [JR]
- PP: Right what to do in model...
- 17:03:17 [JR]
- JA: Right - seen extensions in menu bars, other just change functionality, or something in status bar.
- 17:04:05 [JR]
- JR: How much customization do extensions allow?
- 17:04:25 [JR]
- KF: Suppose allow things to be added to areas that are not keyboard accessible.
- 17:04:45 [jallan]
- pp: bad browser
- 17:04:55 [jallan]
- JA: bad developer
- 17:05:22 [JR]
- KF: ex. Toolbars hard to make keyboard accessibler
- 17:05:30 [JR]
- JA: Same way in FF
- 17:06:28 [JR]
- CL: Browser should enable the extension of the environment to be accessible
- 17:06:43 [JR]
- PP: Right - mixed responsibility
- 17:07:11 [JR]
- mixed=shared
- 17:08:48 [JR]
- JA: 4.4...
- 17:11:58 [JR]
- JA: 4.14...
- 17:12:19 [JR]
- PP: User Javascript
- 17:12:27 [JR]
- KF: Customizing the content view
- 17:12:37 [JR]
- CL: Similar to Web Applications
- 17:14:07 [JR]
- JR: Right but should it be a requirement?
- 17:15:07 [JR]
- KF: So does user have to be able to change content?
- 17:18:12 [JR]
- KF: If you enable someone to say linearize a table does this have to be accesible?
- 17:18:16 [JR]
- JA: Yes
- 17:18:31 [JR]
- CL: Right we're trying to figure out the divisions
- 17:18:50 [JR]
- KF: THis goes into good ideas for more accessible views
- 17:19:13 [JR]
- JA: Guideline 6...
- 17:20:24 [JR]
- CL: We want to promote engineered APIs - "usa AN accessibility API"
- 17:20:58 [JR]
- CL: DOM is incomplete - no javascript, no CSS< etc
- 17:21:11 [JR]
- CL: That's why platform API's becoming so important
- 17:21:30 [JR]
- PP: Hard to specify what is meant by "Complete API"
- 17:22:03 [JR]
- CL: We want to promote platform API's over DOM since its also compatible with other desktop applications.
- 17:23:21 [JR]
- CL: But of course Javascript needs to go to the DOM not the platform specific API.
- 17:25:30 [jallan]
- CL: history of accessility
- 17:25:51 [jallan]
- APIs, and work on cross platform accessibility apis
- 17:26:53 [jallan]
- goal(?) promote a platform accessibility API's and the HTML DOM [incomplete because DOM doesn't do extensions, CSS, scripting] since the platform accessibility API is also compatible with other desktop applications.
- 17:28:08 [JR]
- CL: Want to promote implementation of engineered APIs by UAs and embedded UAs PLUS chrome extensions
- 17:29:29 [JR]
- CL: for use by ATs and implementation of HTML-DOM for in process components
- 17:30:38 [JR]
- KF: Active-x controls are in process but should still implement MSAA.
- 18:14:15 [JR]
- JA: We're back
- 18:14:25 [JR]
- JA: We need to spend some time on our charter
- 18:14:47 [JR]
- JA: till 215
- 18:15:08 [JR]
- JA: on our requirements - then we'll get to the charter
- 18:17:28 [JR]
- JA: 6.6...
- 18:18:35 [JR]
- CL: Covered already
- 18:18:53 [JR]
- JA: 6.7...
- 18:20:31 [JR]
- CL: How do we address shifting of controller...
- 18:20:43 [JR]
- PP: Who manages, what constitutes
- 18:22:35 [JR]
- JA: Keyboard conflict stuff should go under goal 1
- 18:23:07 [JR]
- KF: Other issue - conflict with access keys
- 18:23:23 [JR]
- CL: We don't address this in UAAG
- 18:23:47 [JR]
- JA: Actually this comes later...
- 18:24:42 [JR]
- JA: 7.1...
- 18:25:23 [JR]
- JA: Browsers need this functionality even if done by extension
- 18:25:59 [JR]
- KF: ctrl-A enough?
- 18:26:26 [JR]
- JA: Probably more granular better
- 18:27:19 [JR]
- KF: Not disagreeing
- 18:27:36 [JR]
- CL: Maybe controller is something to talk about separeatly
- 18:28:38 [parente]
- MVC reference: http://en.wikipedia.org/wiki/Model-view-controller
- 18:30:52 [JR]
- PP: Keyboard handling at the core
- 18:31:06 [JR]
- CL: Core would also include strcutured nav etc
- 18:31:17 [JR]
- JA: 8.1...
- 18:31:36 [parente]
- wikipedia MVC page has decent definitions of model, view, and controller
- 18:32:40 [JR]
- JR: Handled
- 18:32:50 [JR]
- JA: 9.1...
- 18:34:03 [JR]
- JA: What is the author/UA responsivility split.
- 18:34:41 [JR]
- KF: Interesting...ex. ATs pretty good at dealing with onclick etc.
- 18:35:13 [JR]
- JA: Yes because of people not using mouse but not ScrRead (actually its onMouseOver)
- 18:36:23 [JR]
- JA: 9.2...
- 18:37:37 [JR]
- CL: Covered.
- 18:37:44 [JR]
- JA: 9.3...
- 18:37:53 [JR]
- JA: Consider combining
- 18:39:51 [JR]
- JA: 9.4...
- 18:42:35 [JR]
- JA: Covered.
- 18:44:21 [JR]
- JA: 4.12...
- 18:44:30 [JR]
- JA: 4.13...
- 18:44:38 [JR]
- JA: 6.10...
- 18:46:06 [JR]
- JA: Coverd in API stuff
- 18:46:13 [JR]
- JA: 7.3...
- 18:47:58 [JR]
- KF: Other issues - should browser even do that (inform of these things) - ex. if I'm running browser with SR is that anyone else's business.
- 18:48:56 [JR]
- KF: Personal info.
- 18:52:27 [jallan]
- jr: continue to view user configuration as private information not to go back to the server/net
- 18:54:58 [JR]
- JR, CL: Discussion of types of info involved - platform preference, browser prefs...
- 18:55:51 [jallan]
- added ?how should inprocess javascript etc. be provided platform specific information (high contrast mode), AT settings (yikes!), and user preferences?
- 18:56:05 [jallan]
- as a second item to goal 1
- 18:58:42 [jallan]
- pp: note, javascript may be used to do malicious things with the preference information.
- 18:59:36 [JR]
- 8.2..
- 18:59:57 [JR]
- CL, KF: Remove
- 19:01:19 [JR]
- 9.5...
- 19:01:32 [JR]
- JA: Covered
- 19:01:51 [JR]
- 9.8...
- 19:02:56 [JR]
- JA: Covered
- 19:05:06 [jallan]
- CL: is the requirement that you can search for conditional content for any view.
- 19:05:19 [jallan]
- ...is tooltip part of the view.
- 19:05:28 [jallan]
- pp: should search the view
- 19:06:37 [JR]
- CL: prob browsers only searching visual view
- 19:07:29 [jallan]
- cl: some screenreaders don't allow you to search for all words you have heard, because it only allow search of rendered content
- 19:07:30 [JR]
- KF: Not so straightforward...
- 19:07:42 [JR]
- KF: Let's say SR doesn't show title tags
- 19:08:26 [jallan]
- cl: search the model that was rendered (view) based on user preferences
- 19:08:49 [jallan]
- ...so if titles turned off by user, then can't search for title
- 19:08:53 [JR]
- CL: Searched what is shown
- 19:09:15 [JR]
- KF: SR's allow you to find alt text for images
- 19:11:51 [JR]
- KF: Base requirement would be just to search things that are displayed
- 19:12:44 [JR]
- 9.9...
- 19:14:03 [JR]
- 11.2...
- 19:16:30 [JR]
- JA: Finished review
- 19:17:21 [JR]
- Action JA, JR: Cleanup the goals list.
- 19:18:14 [JR]
- Action: JA, JR Cleanup the goals list
- 19:18:24 [JR]
- Action JR: Test
- 19:18:57 [JR]
- Topic: Charter Update
- 19:20:04 [KFord]
- http://www.tsbvi.edu/technology/uawg/draft_of_UA_charter.html
- 19:21:22 [JR]
- JA: Date stuff will be hanfled later
- 19:21:30 [JR]
- JA: IMportant stuff is scope
- 19:22:55 [JR]
- JR: likely to be 2.0 not 1.1
- 19:23:59 [JR]
- JA: Calling it "new version of WCAG"
- 19:24:47 [JR]
- WCAG=UAAG
- 19:26:09 [JR]
- KF: track implementation of UAAG PERIOD
- 19:26:35 [JR]
- KF: Should we scope #4
- 19:32:13 [JR]
- KF: Should we also have implementation report
- 19:45:34 [jallan]
- 1st quarter 2007
- 19:45:34 [jallan]
- Publish Requirements document for UAAG 2.0
- 19:45:34 [jallan]
- 2nd quarter 2007
- 19:45:34 [jallan]
- recruit appropriate members and invited experts for developing
- 19:45:34 [jallan]
- 4th quarter 2007
- 19:45:35 [jallan]
- Publish Rough Draft of UAAG 2.0
- 19:45:37 [jallan]
- 3rd quarter 2008
- 19:45:40 [jallan]
- Publish Last Call
- 19:45:41 [jallan]
- Produce revised AUAG 1.X Techniques Note.
- 19:51:03 [JR]
- JA: Dependencies...
- 19:52:11 [JR]
- JA: Should we discuss XML...
- 19:54:16 [jallan]
- action: ja bring up XML accessibility in UA to WAI coordinating group
- 20:09:12 [JR]
- Topic: New people etc.
- 20:09:47 [JR]
- KF: whats problem?
- 20:09:59 [JR]
- JA: Many ATs very specific...
- 20:10:08 [JR]
- JA: No one from cognitives...
- 20:10:21 [JR]
- JA: Just a few from dexterity, SRs. keyboards
- 20:10:29 [JR]
- JA: few meetings...
- 20:10:57 [JR]
- CL: Except IBM + blind user input - which led to SR focus
- 20:11:41 [JR]
- JA: Had David P., Earl Johnson, David Clark...
- 20:12:13 [JR]
- JA: WGBH folks, some I people
- 20:12:27 [JR]
- KF: What about Adobe?
- 20:12:56 [JR]
- JR: Bob Regan?
- 20:13:04 [JR]
- CL: Andrew Kirkpatrick
- 20:13:51 [JR]
- CL: New someone from Apple (Safari), Opera
- 20:14:14 [JR]
- KF: Target Doug Geoffey
- 20:14:34 [JR]
- JA: What about someone from ATIA who could then farm it out
- 20:15:40 [JR]
- CL: Need some ARIA people...
- 20:15:56 [JR]
- CL: Maybe someone from Google
- 20:18:07 [JR]
- JA: Maybe also draw from other WG's that we identified in CHarter
- 20:18:55 [JR]
- JR: How many do we want?
- 20:19:13 [JR]
- JA: Call for participation goes out widely.
- 20:21:17 [JR]
- JA: There needs to be a core
- 20:21:27 [JR]
- JA: of 6-8 people
- 20:22:13 [JR]
- JA: Also extension developers
- 20:23:19 [JR]
- CL: People on UVIP mailing list?
- 20:23:32 [JR]
- JA: What about standardista people?
- 20:24:55 [JR]
- JA: Real?
- 20:25:14 [JR]
- JA: What about someone from MS MediaPlayer?
- 20:25:19 [JR]
- KF: Will look into it.
- 20:26:43 [JR]
- What about access API architects.
- 20:29:18 [JR]
- CL: Opera - they also do some multimodal stuff
- 20:34:41 [JR]
- CL: Really need someone from SUN - they own accessibility API on SUN
- 20:38:41 [JR]
- CL: IBM Research?
- 20:45:48 [JR]
- Topic: big UAAG concverns about ARIA
- 20:46:37 [JR]
- PP: KEYBOARD: UA doesn't know what scripting is catching
- 20:47:14 [JR]
- PP: STYLING: CSS doesn't get into the DOM
- 20:48:05 [JR]
- PP: USER PREFERENCES: Platform and UA prefs (eg high contrast ) can't be accessed by scripting.
- 20:50:43 [JR]
- PP: FREEZING: UA can't freeze interaction with script execution the way it could with rendering
- 20:51:23 [JR]
- PP: PARTIAL CHANGE: Live regions being updated without UA knowing extent
- 20:59:27 [Al]
- Al has joined #ua
- 20:59:40 [Al]
- are you still going or are you enroute?
- 21:00:07 [Al]
- G531
- 21:00:17 [Al]
- Gates Tower, i.e. the other one.
- 21:00:28 [Al]
- Find elevators, come to 5th floor, head for W3C
- 21:00:36 [Al]
- We're in the W3C conference room.
- 21:06:45 [JR]
- RRSAgent, make minutes
- 21:06:45 [RRSAgent]
- I have made the request to generate http://www.w3.org/2007/01/23-ua-minutes.html JR
- 21:06:52 [JR]
- RRSAgent, set logs public
- 21:07:21 [JR]
- RRSAgent, bye
- 21:07:21 [RRSAgent]
- I see 3 open action items saved in http://www.w3.org/2007/01/23-ua-actions.rdf :
- 21:07:21 [RRSAgent]
- ACTION: JA, JR Cleanup the goals list [1]
- 21:07:21 [RRSAgent]
- recorded in http://www.w3.org/2007/01/23-ua-irc#T19-18-14
- 21:07:21 [RRSAgent]
- ACTION: JR to Test [2]
- 21:07:21 [RRSAgent]
- recorded in http://www.w3.org/2007/01/23-ua-irc#T19-18-24
- 21:07:21 [RRSAgent]
- ACTION: ja bring up XML accessibility in UA to WAI coordinating group [3]
- 21:07:21 [RRSAgent]
- recorded in http://www.w3.org/2007/01/23-ua-irc#T19-54-16