IRC log of ua on 2007-11-06

Timestamps are in UTC.

13:53:50 [RRSAgent]: RRSAgent has joined #ua
13:53:50 [RRSAgent]: logging to http://www.w3.org/2007/11/06-ua-irc
13:53:58 [JR]: Zakim, this will be UAWG
13:53:58 [Zakim]: ok, JR; I see WAI_UAWG(TP)8:00AM scheduled to start 53 minutes ago
13:54:07 [JR]: Meeting: WAI UA
13:54:48 [JR]: Agenda: http://www.w3.org/WAI/UA/2007/nov2007_ua_meeting.html#agenda
13:54:57 [JR]: Scribe: JR
13:55:06 [JR]: Chair: Jim Allan
13:56:52 [Zakim]: WAI_UAWG(TP)8:00AM has now started
13:56:54 [Zakim]: +??P5
14:00:22 [cblouch]: cblouch has left #ua
14:05:00 [cklaws]: cklaws has joined #ua
14:05:41 [JR]: JA: PF thoughts?
14:05:58 [JR]: CL: We really do need a Charles or Aaron type person
14:06:37 [JR]: JA: JR and I talking about service-themselves stuff...
14:07:06 [JR]: JA: If they don't want to do it maybe we can put it in as P3
14:09:17 [JR]: irc.w3.org, port: 6665, channel: #ua
14:11:34 [JR]: test
14:12:24 [oedipus]: oedipus has joined #ua
14:13:04 [Martine]: Martine has joined #ua
14:15:28 [jallan]: CL discussing 6.7 - order of key execution.
14:16:12 [jallan]: CL: adding 2. Establish and document how the user agent resolves key binding conflicts between the user agent user interface, user agent extensions (e.g plug-ins), HTML elements (i.e. accesskeys), and ?JavaScript functions (i.e. keypress events). If a keystroke is not defined by the user agent user interface,the user agent should pass it on to the user agent extensions, HTML elements, then...
14:16:13 [jallan]: ...?JavaScript functions, in that order.
14:16:35 [jallan]: CL: do we really need to be this prescriptive.
14:16:52 [jallan]: JA: I agree
14:17:26 [jallan]: JR: +1
14:18:59 [Martine]: Martine has joined #ua
14:19:26 [chaals]: chaals has joined #ua
14:20:52 [JR]: CL: APIs for keyaborad just took you to a defn of APIs
14:22:46 [JR]: JR: CLs peice should be broken into two
14:23:46 [chaals]: [There should be one requirement to document how this happens - i.e. in what order different things get the keys.
14:24:08 [chaals]: ...and another that the browser use them before handing them to the page]
14:26:23 [chaals]: [There should be a seperate one that the browser ensure, for standard mechanisms (html:@accesskey, ARIA??) that there is an activation mechanism for anything that has a shortcut assigned]
14:26:35 [chaals]: [oops. And a discovery mechanism]
14:27:55 [oedipus]: +1 to chaals' 2 part proposal
14:29:13 [jallan]: split CL proposal into 2 sections. Documentation proposal to be added to GL 12 Documentation, keybinding to be placed in GL6
14:29:33 [JR]: "Provide a discovery mechanism for all author defined keyboard navigation."
14:30:11 [jallan]: previous JR comment added to CP 1.1
14:31:35 [jallan]: CL: provide a feature or function to allow the user to display author defined keyboard bindings that are known to the UA
14:31:40 [JR]: Provide a feature that displays author-defined keyboard bindings that are known to the user agent.
14:32:14 [W3CIRC]: W3CIRC has joined #ua
14:33:18 [jallan]: JR: not 1.1 put in 11.3
14:34:19 [jallan]: JA: can see a regrouping in all of UAAG 1.1 6.7 11.3 etc. are all related to keyboard/device independence
14:34:47 [jallan]: CL: where is "resolve the keyboard conflicts"
14:34:51 [jallan]: JR: 6.7
14:34:56 [lm]: lm has joined #ua
14:34:59 [jallan]: CL: should be in 1.1
14:37:22 [JR]: JA: Really impressed by idea of using AccessKeys for navigation in mobile phones
14:38:48 [JR]: JA: Then there is line-21 on tv broadcasts on mobile phones
14:41:31 [Martine]: Martine has joined #ua
14:44:03 [Martine]: Martine has joined #ua
14:50:24 [jallan]: JR: discussion of UA serving itself (getting keybindings first, then passing off to application)
14:52:04 [jallan]: JA: users get confused when UI doesn't function as normal
14:52:20 [Martine]: Martine has joined #ua
14:53:24 [jallan]: CL: Windows OS grabs ALT keys first, so ALT-F, it is the OS that opens the menu
15:00:19 [oedipus]: but on W3C list archive pages, alt plus a moves focus to the "sort by author" link, even though alt plus a is reserved for "Favorites"
15:00:48 [oedipus]: no consistency in implementation or cascade -- that's what we need to define...
15:03:56 [Martine]: Martine has joined #ua
15:04:37 [JR]: JR: Plus we just tested alt-f and it was grabbed by access key
15:05:20 [oedipus]: JR: with or without an AT?
15:05:30 [JR]: without
15:05:47 [oedipus]: ok, good -- wanted to eliminate AT awareness of accesskey as culprit
15:05:48 [JR]: It did not go to File menu (test in IE)
15:07:35 [jallan]: Cl: in FF if ALT-A with page with accesskey=a, the Favorites list opens
15:07:58 [oedipus]: that's because FF uses shift plus alt as modifier
15:08:36 [jallan]: CL: what is the order of presedence
15:09:13 [oedipus]: GJR: should be up to user - think of it as a "politness level" for accesskeys etc.
15:09:37 [oedipus]: that's politeness (obviously i don't have much experience with that word!)
15:09:41 [JR]: ah yes
15:10:01 [jallan]: ... of keybindings. very inconsistent between OS, application, content
15:12:16 [jallan]: JA: good concept GJR
15:12:35 [JR]: JA: Maybe we have configuration - binary choice between UA user interface grabs first and doc grabs first
15:12:46 [JR]: doc=content
15:13:08 [jallan]: add to 1.1
15:16:53 [JR]: http://www.w3.org/WAI/UA/2007/WD-UAAG20-20071106/WD-UAAG20-20071106.html
15:17:04 [JR]: fyi: here's the draft so far today.
15:21:18 [jallan]: discussing CSS writing to the DOM
15:21:57 [jallan]: JR: abstract: technologies may write to the screen, these technologies should also write to the DOM
15:22:35 [jallan]: CL: the UA knows about the other technologies, and writes to the DOM
15:23:24 [jallan]: CL: with javascript is there anything that ensures that information about an element is written to the DOM
15:24:16 [jallan]: JR: content generation by CSS should be written back to the DOM
15:26:33 [jallan]: CL: when you translate info from other technologies to the DOM - it is not written to the DOM as HTML syntax and elements only as content
15:27:05 [jallan]: when you look at the DOM there is no way to tell if a checkbox was created in HTML or in JS
15:27:26 [jallan]: ... ARIA roles and states helps
15:27:39 [oedipus]: any content generated from embedded operands?
15:29:27 [JR]: JR, CL: Discussing DOMs produced by MathML, SVG, etc.
15:29:46 [JR]: CL: Gets into DOM but source based so ATs can't understand it
15:29:48 [jallan]: CL: when using MATHML is used in a page, it used a different DOM so the UA is unaware, but if the UA converts MATHML properly and writes to the a11yAPI then AT gets the information
15:31:11 [jallan]: CL: UA uses roles to convert JS or whatever into 'recognizable' elements for dom and AT
15:33:06 [JR]: JA: Let's break
15:47:51 [Zakim]: +[IBM]
15:47:52 [Zakim]: -[IBM]
15:47:55 [Zakim]: +[IBM]
15:49:14 [parente]: parente has joined #ua
15:52:21 [oedipus]: i'm joining at the top of the hour, unless instructed otherwise
15:52:24 [lm]: lm has joined #ua
15:52:33 [JR]: zakim, [IBM] is really pparente
15:52:33 [Zakim]: +pparente; got it
15:52:56 [JR]: Back from break.
15:52:57 [oedipus]: ok, will call in
15:53:26 [JR]: Topic: Section 9
15:53:50 [JR]: JA: We've been making reasonable progress.
15:53:57 [Zakim]: +Gregory_Rosmaita
15:54:21 [JR]: http://www.w3.org/WAI/UA/wiki/NavMechanisms
15:54:54 [JR]: PP: Most sections in GL9 had issues
15:55:25 [JR]: PP: Need to update defn of enabled and interactive
15:55:41 [oedipus]: scribe+ oedipus
15:55:46 [oedipus]: scribe: oedipus
15:56:18 [oedipus]: PP: anything can receive focus or be addressed using javascript -- def needs to change -- [reads first sentence]
15:56:33 [oedipus]: PP: could be by spec or author can make content interactive with some code
15:57:17 [oedipus]: PP: remaining needs work; interactive elements -- def doesn't mention -- enabled element piece of content that can be activated through UA or API...
15:57:39 [oedipus]: JA: covers it -- doesn't specifically say authors can do, but not limited to doing what is listed
15:57:45 [oedipus]: JR: scope of change?
15:58:09 [oedipus]: PP: just first sentence needs to be replaced, then 2nd needs to be tweaked to mention "programmatic"
15:58:40 [oedipus]: JA: ckpt remains same -- need to redefine terms, right?
15:59:00 [oedipus]: JR: according to original issue that's what it looks like, unless missed something in original issue
15:59:22 [oedipus]: JR: even in AJAX content focus is still handled by UA or does javascript hand off?
15:59:28 [oedipus]: PP: always UA --
16:00:08 [oedipus]: PP: 2nd issue - Where is the line drawn between what the UA vs Author coding should do to provide for accessibility
16:00:54 [oedipus]: PP: confusing -- example: FF scrollable to display hidden or overflow content -- set to auto, automatically gives focus to div or iframe by UA so scrollbar can be manipulated
16:01:19 [oedipus]: JR: does javascript ever take over and draw focus off
16:01:40 [oedipus]: JA: UA put focus back, or does author have to programmatically indicate
16:01:43 [oedipus]: CL: explain
16:02:05 [oedipus]: JA: taking out of task order - can't just focus unless author provides mechanism to give focus;
16:02:14 [oedipus]: JA: sytling through CSS, rather than UA?
16:02:26 [oedipus]: CL: [can't hear]
16:02:55 [oedipus]: PP: firefox draws border around items that defined as negative 1 in tab order
16:03:12 [oedipus]: CL: do we say they have to do this for all ?
16:03:29 [oedipus]: JR: another compound document/mashup GL?
16:03:36 [parente]: correction: not all with tabindex=-1, things that the browser knows are interactive like scrollable divs
16:04:12 [oedipus]: JA: morphing structure of document to make more functionally based
16:04:33 [oedipus]: CL: some sections all about navigation (such as 9) -- GLs themselves may need to change
16:05:02 [oedipus]: JA: written from perspective of user -- wants keyboard to work; we're flipping it and saying this functionality is for UA devs
16:05:33 [oedipus]: CL: did we already define the term "interactive" -- have "enabled elements"
16:06:18 [oedipus]: CL: need def of "interactive"?
16:06:26 [oedipus]: JA: add PP's second proposal bullet
16:06:46 [oedipus]: PP: might be useful as a clarifying note -- this is what we think UA is responsible for -- if go beyond, great
16:07:00 [oedipus]: JA: written as success criteria -- could be technique if written generically
16:07:25 [oedipus]: JA: need to add UA extensions to chrome -- of is anything in the chrome chrome natively or added by scripting
16:07:49 [oedipus]: PP: 9.2 - one of issues listed there -- if address now, 9.1, might not have to change 9.2
16:08:38 [oedipus]: CL: under 9.2 "provide user interface focus"?
16:08:58 [oedipus]: PP: last issue for 9.1 -- for 9.2 issues are: are extensions to the user interface (chrome) considered part of the 'base' UA? Should extensions conform to UAAG? We think, yes. Does UAAG need addtional checkpoints to cover this? Will adding techniqes to cover this, change the scope of the checkpoint?
16:08:58 [oedipus]: Definition of Content. Related to Compound Documents and DHTML/AJAX. Focus management between base UA and nested/child UA (Object, flash, mathml, svg). Also, applications within web content that create a new user interface. Is this new application with it's own user interface considered a new embedded UA that must conform to UAAG or just more content?
16:09:45 [oedipus]: PP: any extensions to chrome should inform UAAG; base focus -- UA responsible if knows how to render widgets into its own chrome, knows what should receive focus
16:09:49 [oedipus]: JA: and what hotkeys apply
16:10:18 [oedipus]: PP: should be inspectable -- FF extensions written in same language (XUL)
16:10:43 [oedipus]: PP: most other extensions not written with same code
16:11:16 [oedipus]: JA: user interface -- rewrite note or include extensions to User Interface -- reword or note?
16:11:24 [oedipus]: PP: reword -- might get lost in note
16:11:31 [oedipus]: JR: 2 success criteria
16:11:54 [oedipus]: JR: ensure user interface focus operates within chrome extensions; extends to chrome extensions?
16:12:02 [oedipus]: JA: take out "to" and substitute "for"
16:12:18 [oedipus]: JA: or "extensions to the user interface" avoids adding another term need to define
16:12:43 [oedipus]: JR: authoring tool, UI applies to everything -- that's why use term "chrome"
16:13:19 [oedipus]: PP: additional checkpoints? tied into whether going to mash into something larger
16:13:29 [oedipus]: JA: created additional checkpoint
16:13:41 [oedipus]: JR: going to publish new editor's draft
16:13:43 [JR]: http://www.w3.org/WAI/UA/2007/WD-UAAG20-20071106/WD-UAAG20-20071106.html
16:13:56 [oedipus]: JR: 9.x
16:14:17 [oedipus]: JR: things in light pink are new; bold labeled where come from
16:14:36 [oedipus]: GJR +1 to adding checkpoint
16:15:37 [oedipus]: PP: are extensions to the user interface (chrome) considered part of the 'base' UA? Should extensions conform to UAAG? We think, yes. Does UAAG need addtional checkpoints to cover this? Will adding techniqes to cover this, change the scope of the checkpoint?
16:15:37 [oedipus]: Definition of Content. Related to Compound Documents and DHTML/AJAX. Focus management between base UA and nested/child UA (Object, flash, mathml, svg). Also, applications within web content that create a new user interface. Is this new application with it's own user interface considered a new embedded UA that must conform to UAAG or just more content?
16:15:37 [oedipus]: Proposals
16:16:39 [oedipus]: PP: managing focus -- nested should move into it, but outer UA can't count on secondary UA to be focusable -- up to embedded player/UA to be focusable and manipulatable; would be good to provide an escape from widget/embedded UA
16:16:52 [oedipus]: JR: right -- need to state explicitly
16:17:08 [oedipus]: JA: what can parent UA do to get focus back from embedded UA
16:17:14 [oedipus]: PP: not necessarily true
16:17:19 [oedipus]: JA: true in flash
16:18:38 [oedipus]: PP: if have something embedded in page, press tab, UA says "flash, focus moved to you" -- when reach last tabbable element in embedded UA take you out of embedded UA; relies on bi-directional communication -- UA still getting keystrokes before embedded UA gets them -- skip key (perhaps CONTROL TAB
16:18:56 [oedipus]: JR: embedded UA a viewport -- escape from viewport key needed
16:19:17 [oedipus]: JA: don't know if flash misbehaving or UA; update of flash, allows trickle back to parent
16:19:44 [oedipus]: JA: user agent gets keystroke first and passes off to embedded document and then gets back
16:20:13 [oedipus]: PP: could be browser dependent; if thing rendered inside browser, broswer should get first say
16:20:50 [oedipus]: JA: chicken and egg problem -- CDF related
16:21:32 [oedipus]: JR: user agent usually (in HTML) uses native keystrokes -- may be conflict with escape mechanism -- have to thread properly
16:21:47 [oedipus]: JA: editor's note about compound document
16:22:04 [JR]: User agent is responsible for notifying any nested user agent that focus should move into it
16:22:04 [JR]: User agents must be able to escape focus from a nested viewport (including nested viewports that are user agents)
16:22:08 [oedipus]: ACTION Jim: email CDF about threading
16:22:49 [oedipus]: PP: if treating embedded object as UA, embedded user agents need to communicate with primary UA
16:23:00 [oedipus]: CL: not notification, just responsible for moving focus back
16:23:15 [oedipus]: PP: flash can't move focus back, but can indicate that it is no longer needed
16:23:27 [oedipus]: CL: HPR -- screenreader had to get focus back
16:23:37 [oedipus]: CL: HPR knew what was going on
16:24:17 [oedipus]: CL: UA would pass by flash, but now can tab into it -- API communication between flash and browser
16:24:55 [oedipus]: JA: because embedded UAs don't use parent DOM, but use own or don't have one, imperative that API writes to DOM for AT use
16:25:05 [oedipus]: JR: special guidance for embedded UAs?
16:25:42 [oedipus]: JA: SVG has own dom, etc. don't write back to parent dom
16:25:54 [oedipus]: JR: write to DOM
16:26:04 [oedipus]: JR: if DOM in common use, write to it
16:26:09 [oedipus]: CL: only applicable to HTML
16:26:32 [oedipus]: JR: SVG renderer that embeds HTML - HTML viewer could write to HTML DOM
16:26:39 [oedipus]: JA: have to write to Accessibility API
16:27:05 [oedipus]: CL: if UA doing that, they are writing to a11yAPI -- authors not going to write to a11yAPI
16:27:37 [oedipus]: JR: on IE, has to bring in viewer -- is HTML master of SVG? if SVG master and HTML embedded...
16:27:43 [oedipus]: CL: code dependent
16:28:13 [oedipus]: JR: little IE inside larger SVG UA -- writes to a11yAPI, but could also write to HTML DOM because well supported by AT
16:28:22 [oedipus]: CL: can't write to HTML DOM in that case
16:28:44 [oedipus]: JR: for HTML part of compound document; when user gets to HTML portion, uses HTML DOM
16:28:46 [oedipus]: Q+
16:29:32 [oedipus]: JA: realplayer user agent that plays movies and audio, but can also parse HTML, but not writing to a11yAPI -- AT knows nothing about what is occuring in viewport -- not writing to a11yAPI or DOM
16:29:48 [oedipus]: CL: any kind of UA of any kind has to either write to a11yAPI or if HTML write to DOM
16:30:05 [oedipus]: JR: why not say if technology has a DOM, then write to that
16:30:21 [oedipus]: CL: not all DOMs have necessary API to communicate with AT
16:30:36 [oedipus]: JA: flip side - firevox model -- extension
16:30:41 [oedipus]: CL: writing to HTML DOM
16:30:59 [oedipus]: JA: UA for SVG and write extension, UA has to put into SVG DOM
16:31:20 [oedipus]: CL: desired trend is to write to accessibility API; HTML DOM needs to be retained --
16:31:35 [oedipus]: CL: ideal is linux with no DOM
16:32:22 [oedipus]: Doug Schepers (schepers@w3.org) staff contact for CDF and SVG and WebAPI
16:32:44 [oedipus]: ACTION Gregory: contact Doug Schepers about multiple DOMs in CDF and embedded UAs
16:33:26 [oedipus]: JA: recylcable viewports -- with mouse can zoom in but couldn't resize viewport embedded in HTML
16:33:49 [oedipus]: PP: covered 9.2
16:34:14 [oedipus]: JA: what about outermost UA provide way to skip over misbehaving UAs -- solved with escape key?
16:34:16 [oedipus]: PP: right
16:35:11 [oedipus]: JA: plus one
16:35:43 [Zakim]: -??P5
16:35:45 [parente]: what's going on?
16:35:56 [parente]: couldn't hear that last bit
16:37:04 [oedipus]: scribe's note: JA plus one applies to change to 9.3 first requirement; make explicit about moving content focus backwards and forwards, then cut out redundant checkpoint
16:38:17 [JR]: please hold on
16:41:00 [JR]: waiting for Zakim to call us back
16:41:25 [Zakim]: +MediaRoom
16:44:00 [oedipus]: PP: first sentence of note only
16:44:26 [oedipus]: PP: second part see checkpoint 9.9 about structured navigation and other references still relevant
16:44:51 [oedipus]: JR: [reads new verbiage]
16:45:20 [jallan]: action: JR to remove first sentence in 9.3 note. leave second sentence intact
16:45:47 [oedipus]: JR: combine movement forwards and in reverse into 1 checkpoint?
16:46:42 [oedipus]: JR: [reviews http://www.w3.org/WAI/UA/wiki/NavMechanisms]
16:48:39 [oedipus]: JR: repushes editor's draft to reflect changes
16:49:01 [oedipus]: JR: color coding: pink means proposal, yellow means accepted
16:52:15 [oedipus]: JR: visually and programmitically indicate text changes
16:52:37 [oedipus]: ACTION: GJR check and make suggestions for improving a11y of stylesheets
16:53:47 [oedipus]: PP: UA can't restore viewport/state history due to script or user-set override
16:53:52 [oedipus]: JA: global setting
16:54:08 [oedipus]: PP: add extensions to browser -- can effect viewport/state history
16:54:27 [oedipus]: JA: UA settings, UA extensions, and scripts
16:54:45 [oedipus]: JR: content, not so much UA settings
16:54:53 [oedipus]: JA: order doesn't make difference
16:55:02 [oedipus]: JR: content does it the most (breaking back button)
16:55:12 [oedipus]: JA: order not important unless important to JR
16:55:26 [oedipus]: JR: proposing a note
16:55:29 [oedipus]: JA: notes are normative
16:56:03 [oedipus]: PP: if the state has not been affected by content, user agent settings/exceptions, or scripts
16:56:09 [oedipus]: JA: could add to provision 2
16:56:27 [oedipus]: JR: [rereads from editor's draft]
16:57:04 [oedipus]: JR: all we have to say is "in history/viewport mechanism only responsible for certain states
16:57:16 [oedipus]: PP: things can get in way of operation, don't have to overcome that necessarily
16:57:28 [oedipus]: JR: asking to retain viewport/history mechanism?
16:57:42 [oedipus]: JR: are we saying need to have a back button for UAAG 2?
16:57:53 [oedipus]: CL: thought req was somewhere else
16:58:14 [oedipus]: [JR and CL search editor's draft]
16:58:28 [oedipus]: CL: 9.10 perhaps?
16:58:40 [oedipus]: CL: orient user under GL 10
16:58:58 [oedipus]: CL: mentioned in passing in GL 10
16:59:20 [oedipus]: JA: if no req to retain history don't have to say should
16:59:24 [oedipus]: PP: why not?
16:59:52 [oedipus]: CL: in GL10 itself -- need to examine GL as well as checkpoints
17:00:06 [oedipus]: JA: not normative -- checkpoint provisions and notes are normative
17:00:16 [oedipus]: CL: don't think GL10 verbiage normative?
17:00:19 [oedipus]: JA: no
17:00:30 [oedipus]: CL: then why is it here? that's where we mention it
17:00:45 [oedipus]: JR: must have history when history is possible?
17:01:09 [oedipus]: JR: user agent must provide viewport history mech that stores browsing states that are not changeable
17:01:14 [oedipus]: JA: ok with that
17:02:51 [oedipus]: JR: viewport mechanism for each state maintain info on POR, selection
17:03:39 [oedipus]: JA: need good word for available states that are still valid -- bank account balance after paying bill, can't go back
17:03:53 [oedipus]: PP: not "stale" -- that is technical term -- "the cache is stale"
17:04:20 [oedipus]: JR: if remain viable (not affected by content, user agent settings, etc.)
17:04:41 [oedipus]: CL: one concern about viewport history as requirement for UAs not think of as main browser -- applicable to multimedia players?
17:04:53 [oedipus]: JA: or if opens a new window can't go back
17:05:11 [oedipus]: JR: problem multimedia or embedding of multimedia -- multimedia doesn't have viable states
17:05:49 [oedipus]: CL: play a number of videos, retains a list of videos and where stopped for each video? that's what checkpoint impllies
17:05:57 [oedipus]: JA: if implements history mechanism
17:06:28 [oedipus]: JA: page-based navigation
17:06:42 [oedipus]: CL: not saying not possible, questioning whether should require it -- note sure is a11y issue
17:07:18 [oedipus]: CL: return to page, tries to retain focus -- SR needs precise return to focus
17:07:30 [oedipus]: JR: remove selection?
17:07:39 [oedipus]: CL: might need selectable
17:08:02 [oedipus]: JR: select text on page, changed page, return and no selected text
17:08:07 [oedipus]: PP: agree with CL
17:08:22 [oedipus]: JR: if listbox selected and move back will it retain selection?
17:08:33 [oedipus]: CL: glossary definition
17:09:05 [oedipus]: PP: google advanced search has bunch of dropdowns on giant form -- FORM retains state
17:09:09 [oedipus]: JR: UA doing that?
17:09:20 [oedipus]: PP: browser does it -- even with dummy forms
17:09:26 [oedipus]: JR: form controls retain values
17:09:36 [oedipus]: PP: can write script that overrides that action
17:09:49 [oedipus]: CL: should apply to things that persist -- selections and clipboard don't persist
17:09:54 [oedipus]: JR: remove selection?
17:10:28 [oedipus]: CL: already says as part of state history have to retain POR and selection
17:10:42 [oedipus]: JA: definition of selection
17:10:54 [oedipus]: CL: selection includes indicators
17:11:03 [oedipus]: JR: filling form field not a selection
17:11:23 [oedipus]: JA: FF2 preserves selection when focus moved to another doc
17:11:41 [oedipus]: JA: selected text on page -- IE doesn't retain info but FF2 does
17:13:11 [jallan]: GJR: screen reader users, selects text virtually (in the screen reader buffer)
17:13:39 [oedipus]: JA: scenario where cognative impaired need to go back to selection so know where left off
17:13:52 [oedipus]: JR: POR and content focus one priority and selection another, lower priority
17:14:23 [oedipus]: CL: multiple docs in Word -- things still selected when switch documents; not quite the same as UA, but same underlying concept
17:14:36 [oedipus]: JA: something in DOM needs to know what is selected
17:14:42 [oedipus]: CL: in IE not in DOM
17:14:52 [oedipus]: PP: text selection not in DOM of FF
17:15:14 [oedipus]: CL: FF using internal variable to retain select
17:15:26 [oedipus]: CL: probably restoring selection from internal state
17:15:29 [oedipus]: PP: not in DOM
17:15:44 [oedipus]: JA: not in DOM, not in OS, returns us to question
17:17:01 [oedipus]: CL: look at techniques for this one -- often times, things explained more fully in techs; more about forms and stuff in my opinion
17:18:25 [oedipus]: JA: reads browser refresh - example technique 1
17:18:50 [oedipus]: JA: if browser overwrites it is gone; prefer having it in checkpoint rather than burried in techniques
17:19:15 [oedipus]: CL: need to do this a lot more -- look to techniques for context and fuller info
17:19:45 [oedipus]: JA: 3 states allow user to configure
17:19:50 [oedipus]: JR: all of these are "ifs"
17:20:09 [oedipus]: CL: only if chose to implement feature
17:20:16 [oedipus]: JR: probably already had in mind if dev
17:20:27 [oedipus]: JA: not normative -- just suggestions;
17:20:50 [oedipus]: CL: nothing about forms -- that's what i'm most concerned about
17:22:26 [oedipus]: JA: differentiation between normative and informative sections
17:22:41 [oedipus]: CL: selection
17:23:23 [oedipus]: JR: proposed bring in PP's stuff with viable states; keep JR's previous suggestion (if support history, support) and POR and content focus might be P1; selection might be P2
17:23:39 [oedipus]: JR: combine restore verbiage
17:24:06 [oedipus]: JR: still have original wording (marked as such)
17:24:56 [oedipus]: CL: POR perspective
17:25:09 [oedipus]: JR: POR (point of regard) where you are at present moment
17:25:27 [oedipus]: CL: if select a section using the keyboard and move POR from selection, selection would go away
17:25:44 [oedipus]: CL: selection is marking your point of regard (POR)
17:26:03 [oedipus]: PP: 9.4.1 new wording question
17:26:19 [oedipus]: CL: use keyboard to select
17:26:37 [oedipus]: JA: selected with keyboard; shift-tab away, return
17:26:41 [oedipus]: CL: don't use mouse
17:27:23 [oedipus]: JA: cursor browsing on in FF select text from keyboard -- when do SHIFT + TAB selection vanishes; if select with pointer/mouse, select persists
17:27:42 [oedipus]: CL: if leave selection and ALT + LeftArrow -- can mark POR
17:28:27 [oedipus]: JR: selection is one place, focus another, POR on a third; activate link with focus; return with focus and selection
17:28:37 [oedipus]: JA: failing the keyboard -- only works with mouse
17:29:08 [oedipus]: CL: glossary contradictory
17:29:30 [oedipus]: CL: one selection -- assuming that requirement if only 1 selection
17:29:46 [oedipus]: CL: selection there important for history purposes is POR
17:29:51 [oedipus]: JA: keyboard processing broken
17:30:10 [oedipus]: CL: want to enable you to return where you were -- doesn't care if have selection
17:30:22 [oedipus]: CL: some cases POR will be marked to select text
17:30:47 [oedipus]: JR: using keyboard
17:30:55 [oedipus]: JA: virtual cursor remembering where you were
17:31:22 [oedipus]: JR: selection persists when use mouse
17:32:15 [oedipus]: JA: keyboard interface -- either focus or selection or POR -- only going to inform what was last focused; if something highlighted, going to remember; if just in a position with no focus and selection remembers where caret was
17:32:40 [oedipus]: JA: when come back, returns to one that is currently active; mouse can give you all 3 states
17:33:00 [oedipus]: JA: distinguish between keyboard and mouse? where you left off is important state-holder
17:33:14 [oedipus]: JR: want to come back to one of 3 -- which? POR?
17:33:53 [oedipus]: CL: POR really covers it according to glosary def
17:34:13 [oedipus]: JR: only maintaining POR
17:34:41 [oedipus]: JA: most important one; POR most important no matter how browser handles POR
17:34:50 [oedipus]: CL: intent is purely about POR
17:34:53 [oedipus]: JA: agree
17:35:59 [oedipus]: GJR: if POR equals virtual caret ok
17:36:03 [oedipus]: PP: looks fine to me
17:36:13 [jallan]: GJR: agree that point of regard is most important, want to return to same point in page.
17:36:22 [oedipus]: LUNCH BREAK!!!
17:37:06 [oedipus]: pick up on 9.5 in 30 minutes -- CL leaving now, PP meeting at 2pm
17:37:11 [Zakim]: -pparente
17:37:19 [Zakim]: -Gregory_Rosmaita
18:10:23 [JR]: We're starting in a minute
18:10:41 [Zakim]: -MediaRoom
18:10:42 [Zakim]: WAI_UAWG(TP)8:00AM has ended
18:10:43 [Zakim]: Attendees were pparente, Gregory_Rosmaita, MediaRoom
18:11:49 [parente]: dialing in now
18:12:26 [Zakim]: WAI_UAWG(TP)8:00AM has now started
18:12:28 [Zakim]: +MediaRoom
18:12:52 [Zakim]: +[IBM]
18:14:21 [JR]: Zakim, this will be UAWG
18:14:21 [Zakim]: ok, JR, I see WAI_UAWG(TP)8:00AM already started
18:14:42 [jallan]: zakim, [IBM] is pperente
18:14:42 [Zakim]: +pperente; got it
18:17:38 [jallan]: PP: what we really want to say is 'don't change focus on a change of focus'
18:17:55 [jallan]: PP: don't want to block all event handlers
18:22:45 [jallan]: PP: allow configuration so that moving the content focus to or from an enabled element does not cause the UA to change.
18:23:16 [jallan]: ... if a script is on the newly focused element, the UA doesnot know what a script will do
18:23:50 [jallan]: ... the UA should allow the event handler to execute
18:24:25 [jallan]: JR: what are the things we don't want the UA to do
18:24:56 [jallan]: PP: give focus, call event handler.
18:25:26 [jallan]: ... anything beyond that is not up to the UA it is content driven.
18:25:43 [jallan]: PP: this totally changes this checkpoint.
18:26:23 [oedipus]: oedipus has joined #ua
18:28:49 [jallan]: PP: firevox does focus tracking by looking at on-focus events.
18:29:21 [jallan]: PP: UA still cannot tell what what an event hander will do for on-focus.
18:30:00 [jallan]: ... the UA can only move focus, any event is outside UA control
18:30:29 [parente]: http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets#Use_onfocus_to_track_the_current_focus
18:30:32 [jallan]: JR: cannot control for bad authoring. that is a WCAG issue.
18:32:00 [oedipus]: oedipus has joined #ua
18:33:27 [JR]: Allow the user to activate, through keyboard input alone, all input device event handlers that are explicitly associated with the element designated by the content focus.
18:33:27 [JR]: In order to satisfy provision one of this checkpoint, the user must be able to activate as a group all event handlers of the same input device event type. For example, if there are 10 handlers associated with the onmousedown event type, the user must be able to activate the entire group of 10 through keyboard input alone, and must not be required to activate each handler separately.
18:33:43 [jallan]: JR: this is related to 1.2 event handlers
18:34:34 [jallan]: JR: need to add event handers include "on-focus" events. so user must explicitly execute on-focus events.
18:36:36 [jallan]: JR: move provision 9.5.1 to be part of 1.2.1
18:38:02 [jallan]: PP: not sure this helps the screen reader. the UA must block on-focus events.
18:38:16 [jallan]: JR: this may be a P2
18:38:39 [jallan]: PP: this should be possible, just who is responsible
18:38:57 [jallan]: JR: Move 9.6.1 to 1.2
18:39:30 [jallan]: JR: must show events (9.6.1) before you can trigger them (9.5) - both moved to 1.2
18:39:58 [jallan]: PP: 9.7 already done
18:40:17 [jallan]: PP: 9.8 review issues
18:40:17 [KFord]: KFord has joined #ua
18:40:43 [jallan]: PP: review proposals
18:41:32 [jallan]: ... Whether conditional content is rendered or not, it should be searched if it's intended for human consumption, exists in the markup of the page, and is not hidden via a style attribute.
18:42:23 [jallan]: PP: proposal should be searchable.
18:43:22 [jallan]: JA: if hidden and you search, where should the point of regard appear?
18:44:24 [Zakim]: +[IPcaller]
18:44:26 [jallan]: PP: where ever the pointer is in the DOM, if alt on image, the search finds the image. if hidden by css off top of screen, move point of regard to top of screen.
18:44:56 [JR]: Zakim, [IPcaller] is really KFord
18:44:56 [Zakim]: +KFord; got it
18:45:58 [jallan]: PP: correction, regardless of css positioning, the point of regard should match the location on the page in the dom.
18:47:06 [jallan]: JR: why say "if hidden by style"
18:49:06 [jallan]: JR: then say "within rendered text and text alternatives"
18:49:08 [jallan]: http://www.w3.org/WAI/UA/2007/WD-UAAG20-20071106/WD-UAAG20-20071106.html
18:52:15 [jallan]: PP: 9.9 UAAG issues # Change "allow" to "provide", structured navigation should be provided natively, not added on by AT.
18:52:17 [jallan]: # Issue/Technique: add technique or requirement stating that UA must provide object attributes (element name and roles, etc.) to the accessibiltiy API to enable structured navigation function by AT
18:55:22 [jallan]: KF: a screen reader user uses a different viewport, so structured navigation provided by the UA is not relevant
18:56:03 [jallan]: KF: how to synch screen reader viewport with the UA viewport
18:56:52 [jallan]: ... using JAWS and you hit ctrl-f, you are using JAWS find not UA find
18:58:56 [jallan]: KF: screen reader searches through the alternative view not the visually rendered view, and will not get all of the highlighted found items.
18:59:36 [jallan]: ... screen reader should be able to list all of the found items and surrounding text to the user.
19:00:09 [jallan]: ... don't know hwere to draw line, who should provide the enhanced visual view to the AT.
19:00:43 [jallan]: PP: so the UA is not writing the found information to the DOM or a11yapi for the AT
19:00:53 [parente]: i have to head out to another meeting
19:01:01 [parente]: i'll keep this window open to track
19:01:15 [Zakim]: -pperente
19:02:37 [jallan]: KF: UAs doing more with rendered text, need to give more guidance to alternative views.
19:05:28 [jallan]: JA: just tested, UA only highlights first instance.
19:05:55 [parente]: jallan: some extensions higlight multiple
19:06:02 [parente]: e.g. Google Toolbar
19:06:19 [jallan]: KF: but the feature exists. views are getting richer. How does UAWG provide guidance to AT for richer alternative views
19:06:46 [jallan]: KF: info must be communicated some way...DOM or a11yapi.
19:07:10 [jallan]: Peter, what are your thoughts
19:07:45 [jallan]: KF: same thing is true in structured navigation. but reversed...AT has richer navigation than UA
19:09:41 [JR]: JA: So put of regard has moved in DOM
19:09:57 [JR]: JA: AT could then move to that point and do something
19:10:09 [JR]: JA: So if browser does h=next header
19:10:30 [JR]: JA: And Jaws could do nothing
19:10:58 [JR]: JA: But if IE did a q=next quote then JAWS could use the feature
19:11:28 [JR]: KF: We have struggled with this a lot - features we want to add - with this alternat viewport going on.
19:12:15 [JR]: Action KF: Re-raise alternate view at call on Nov 22
19:12:16 [parente]: when any browser feature that moves the point of regard is actived, that information has to be communicated via DOM + A11y API
19:12:45 [JR]: JA: Historically we did get a lot of structured nav push back in uaag1
19:14:08 [JR]: KF: From end user perspective, having struct nav on headers, list, tables has made a huge difference
19:15:00 [JR]: KF: Who does this other than ATs?
19:15:04 [jallan]: JR: not so much mouse user, but for keyboard, screen mag users.
19:15:08 [JR]: JA: Opera
19:15:35 [JR]: KF: Don't know about Opera and AT support
19:15:41 [parente]: Some extensions to FF
19:15:51 [parente]: (or at least it's conceivable)
19:15:55 [JR]: JA: Opera may be missing MSAA
19:16:28 [JR]: JA: We'll pick this up later
19:16:46 [JR]: JA: PP said there are extensions for struct nav
19:17:13 [jallan]: UIUC accessibility extensions do this.
19:17:31 [jallan]: and WAT toolbar in IE
19:18:03 [JR]: JA:We'll leave 9...
19:18:57 [JR]: Topic: Guidelin 7
19:22:58 [JR]: KF: http://lists.w3.org/Archives/Public/w3c-wai-ua/2007OctDec/0043.html
19:23:07 [JR]: JA: This should be moved to GL1...
19:23:21 [JR]: JA: We've been consolidating the doc...
19:23:50 [JR]: JA: My thought on 7.1 is that we are trying to get content selection from the keyboard
19:24:22 [JR]: JA: It's got to work from whatever content selection...
19:24:46 [JR]: KF: Historically Windows good about text selection, but browsers haven't
19:24:53 [JR]: KF: Fine to move it up
19:25:21 [JR]: KF: Browsers doing that now with browsers
19:25:52 [JR]: KF: nytimes lets you doubleclick on any word and look it up
19:26:24 [oedipus]: also highlights for spelling errors in checkboxes -- native in FF, but not programatically expressed
19:26:59 [oedipus]: substitute edit boxes/textareas for checkboxes
19:30:01 [jallan]: JA: tried in FF from keyboard, highlight word, hit enter, no action taken by UA
19:30:49 [oedipus]: have only been able to do when someone tells me a word is underlined, then route cursor to underlined word and simulate a right-mouse click
19:31:04 [oedipus]: exposes suggestions
19:31:12 [jallan]: KF: does not work with a screen reader, unless mouse cursor used
19:32:18 [jallan]: ... user agent accessibility: 1-basic OS keyboard, highcontrast, etc. 2. a11y apis, 3. for some folks, using AT.
19:32:56 [jallan]: ... UAAG provide guidance for AT. but as UA become more robust, and new platforms, web apps.
19:33:56 [jallan]: ... The UA is adding much more robust experience. UAWG needs to provide more guidance to get same/similar experience for the AT users.
19:36:23 [jallan]: KF: example. in Vista. search box. start | search - when you start typing the search results start updating immediately,
19:36:40 [oedipus]: i assume that the underlining (as in the FF example) is achieved through scripting and not included in dom -- needs to be communicated to a11yAPI
19:37:01 [jallan]: ... this is following the apis etc. and should be accessible. AT is reading the highlighted item as it changes rather than the search box which has topic
19:37:54 [jallan]: ... the AT stepped up, to do this. How does UAWG provide this guidance.
19:39:22 [Zakim]: +Gregory_Rosmaita
19:39:55 [jallan]: KF: as UA developer works with UA...remember the end user experience, not just the data model. Are you exposing the "right" information to enhance the AT user experience
19:40:06 [oedipus]: if draw to screen/canvas need to programmtically indicate state/change to a11yAPI
19:40:20 [JR]: KF: Not sure how this all comes together into a guideline doc
19:40:49 [JR]: JA: in google there is the same type of type-ahead thing
19:41:01 [JR]: FF-instant answers
19:42:39 [JR]: GR: Some older implementations are annoying because they actually do the completion as you go along and can mess up what you are looking for
19:43:28 [oedipus]: can only get to FF3 search context info by reviewing status line - either no match or reached end of page, continued from top
19:43:34 [JR]: KF: Has to go look to see where this is
19:46:47 [oedipus]: ARIA would enable AT to say "dropdown available"
19:47:35 [oedipus]: what's needed is 3 states: expose, examine (without acting), perform action
19:48:06 [JR]: JA: So out of box, applications work a certain way, then some features become popular then AT's support them better
19:48:14 [JR]: JA=KF
19:48:30 [JR]: JA: THat's what UAAG is about if someone would follow them.
19:48:43 [oedipus]: server would have to implement ARIA, of course
19:49:15 [JR]: JA: Some widegets like search bar can be HTML
19:49:24 [JR]: GR: Lots of middleware uses XML
19:49:36 [JR]: GR: But wrapped in HTML at last minute
19:50:10 [JR]: KF: RIght then back into a win32 control (in FFwin google bar example)
19:50:22 [JR]: JA: Anything more for 7?
19:50:23 [oedipus]: AT needs to know that a combo box (no matter how defined) is a combo box and communicate that to end-user
19:51:03 [JR]: KF: Are we talking about getting rid of 7?
20:04:28 [Zakim]: -Gregory_Rosmaita
20:10:37 [JR]: JA: JR was saying we moved selection part of 7.1 to 1.X
20:10:58 [JR]: JA: But still 2 other parts - other focus...
20:17:20 [jallan]: KF: 7.2
20:20:22 [jallan]: ... using cell phone, with voice input. new version of lsearch for mobile phones using voice input (but you have to press a key to activate voice search feature).
20:20:56 [jallan]: ... need to pay attention to how to separate voice input to the phone from voice input to application.
20:22:37 [JR]: Topic: 7.3
20:23:23 [JR]: JR: Mentions keyboard access, overlaps 7.2
20:23:40 [JR]: KF: Just saying do what you have to do to be accessible
20:26:05 [JR]: JA: Good idea to look at techs before we start changing things
20:28:10 [JR]: JA: Interesting note, Jaws can't be used with sticky keys since Insert is not sticky keys
20:29:39 [JR]: KF: Good point about following operating environment...and techniques are important to keep
20:31:29 [jallan]: JA: we've already moved 7.1 and 7.2 should we move 3 and 4 somewhere else
20:32:10 [jallan]: KF: OS has expected behaviors for accessibility, don't mess with them.
20:32:59 [jallan]: JR: would not be a bad thing to restate 1.x into a respecting OS guideline.
20:34:10 [jallan]: JR rerwwriting 7.x and refershing
20:34:21 [jallan]: refershing=refreshing
20:48:26 [jallan]: JA: in PF yesterday, order of precedence says the OS gets the key first.
20:49:19 [jallan]: KF: can't rely on that, screen readers for example hook into the OS at the keyboard level
20:49:47 [jallan]: ... so the screen reader can use OS tools.
20:50:13 [jallan]: JA: so we should keep this CP, the remind developers NOT to use reserved keys.
20:51:06 [jallan]: KF: everything in this GL is good software design. be a good neighbor
20:51:06 [KFord]: ssEverything here is really good software design. Play nice in the neighborhood you live.
20:52:11 [jallan]: JR: publish new draft, reviewing changes...
21:03:11 [jallan]: action: KF to email GR, create schema for editing changes
21:06:34 [jallan]: discussing changes to 2.3 http://lists.w3.org/Archives/Public/w3c-wai-ua/2007OctDec/0038.html
21:09:25 [jallan]: JR publishes a new draft to review 2.3
21:11:15 [jallan]: JR: reads conditional content definition.
21:11:41 [jallan]: ... this is inadequate. any content meets this definition.
21:11:50 [jallan]: ... need something new.
21:12:07 [jallan]: JR: perhaps we don't need a configuration
21:12:33 [jallan]: ... the user should be able to access all pieces of conditional content.
21:12:42 [jallan]: JA: when? and How?
21:12:54 [jallan]: JR: that is a UI question.
21:13:46 [jallan]: JR: so provision 2 etc. explains how and why.
21:15:03 [jallan]: ... removing letters 'C' and 'D' replace with real words...conditional content, base content.
21:15:47 [jallan]: JR: what if there is more than one piece of conditional content?
21:16:59 [jallan]: JR: what if conditional content is larger than base content, or is not physical e.g. sound
21:17:32 [jallan]: ... large alt on small image, or a sound replaces an image
21:32:56 [jallan]: all: reviewing 2.3 - ???
21:33:40 [jallan]: JA: perhaps, we need to create a new list of what we want to happen, and them match up or replace current wording.
21:34:40 [jallan]: ... if current wording is so confusing, then...
21:34:54 [jallan]: KF: user cannot deal with base content
21:35:04 [jallan]: ... want access to any and all replace contnet
21:35:11 [jallan]: ... move between them
21:35:22 [jallan]: ... configure a default replace ment
21:35:46 [jallan]: ... without refreshing page, go back to base content
21:38:14 [jallan]: JA: if conditional content is visible then it becomes the base content, and original base content should show in the list of conditional content the user can choose from
21:39:15 [jallan]: JR: there is a stack of content (base + conditionals)
21:40:03 [jallan]: ... user should be able to have access to all conditionals that the UA can understand (render or call a plug-in)
21:42:01 [jallan]: ... user should be alerted to the presence of other non-rendered conditional content
21:42:40 [jallan]: ... given a stack, the user preferred item(s) should be rendered
21:43:16 [jallan]: ... user should be able to have access (step through)
21:46:02 [jallan]: JR: how to render conditional content that is 'larger' than space provided for base content.
21:46:28 [jallan]: ... how to render multiple condtionals simultaneously
21:47:15 [jallan]: from techniquest for 2.3 For an object (e.g., an image) with an author-specified geometry that the user agent does not render, allow the user to configure how the conditional content should be rendered. For example, within the specified geometry, or by ignoring the specified geometry altogether.
21:48:59 [jallan]: ja: discuss size issue
21:49:19 [jallan]: JR: if voice browser. ALT size not a concern
21:49:41 [jallan]: JA: if text only UA ALT size also not a concern.
21:50:22 [jallan]: JA: UA with images off may truncate ALT.
21:50:57 [jallan]: JR: the user should have option of deciding if the base dimensions should be ignored.
21:52:14 [jallan]: JR: if the conditonal content is plain text then the userr should have the option of having it not displayed onscreen but rather in the DOM title
21:53:57 [KFord]: I'm not sure why you don't hear me, but I'm still here.
21:54:29 [jallan]: JR: we are talking about stepping through
21:54:44 [KFord]: Right, I hear you just fine.
21:55:38 [Zakim]: -KFord
21:56:12 [jallan]: JA: scenario: have image on page, screen reader reads alt, indicates additional content, hit a key context menu opens with title: title contents
21:56:42 [jallan]: ... longdesc that is an actionable link, and
21:56:55 [jallan]: ... the alt again.
21:58:00 [jallan]: ... this could also work for a keyboard user without AT, UA inserts a placeholder as an indicator for more conditional content so
21:58:21 [jallan]: ... user can get same menu with all conditionals listed
21:58:47 [Zakim]: +??P1
21:59:01 [JR]: zakim, is [??P1] really KFord
21:59:01 [Zakim]: I don't understand 'is [??P1] really KFord', JR
21:59:07 [JR]: zakim, is ??P1 really KFord
21:59:07 [Zakim]: I don't understand 'is ??P1 really KFord', JR
21:59:19 [JR]: zakim, ??P1 is really KFord
21:59:19 [Zakim]: +KFord; got it
22:00:06 [JR]: User should be able to have access (step through) to any items in a "conditional content stack" that the user agent can understand.
22:00:06 [JR]: Given a stack, the user preferred items should be rendered
22:00:06 [JR]: User should be alerted to the presence of other non-rendered items in the stack
22:00:06 [JR]: If the conditional content has larger onscreen dimensions than the top item in the stack, the user should hvae the option of deciding if the dimensions should be ignored
22:00:07 [JR]: If the conditional content is plain text then the user should have the option of having it not display onscreen but rather in the DOM title.
22:02:00 [jallan]: JR: problem now, can;t get title and alt at the same time with the screen reader
22:02:18 [parente]: parente has left #ua
22:02:19 [jallan]: ... is this an msaa issue,
22:02:50 [jallan]: KF: msaa gives a name to an object and have roles.
22:03:09 [jallan]: ... on html element x map it from this tag
22:03:28 [jallan]: JR: idea of cycling through a stack of conditionals.
22:03:41 [jallan]: ... have image, tooltip of of alt
22:04:15 [jallan]: KF: in msaa tree image link has 2 children
22:04:28 [jallan]: ... name becomes alt
22:04:31 [JR]: JA: What if it has a title?
22:04:46 [JR]: KF: Could we make another child -yeah.
22:04:55 [JR]: JA: Is MSAA the prob for JAWS?
22:05:06 [JR]: KF: No that's JAWS thing
22:05:47 [jallan]: JR: thinking about collisions, on screen
22:06:06 [jallan]: ... things get messy, have movie, image, alt, longdesc
22:06:35 [jallan]: ... how to put them all on the screen at the same time, difficult to put movie and image on screen at the same time.
22:07:13 [jallan]: ... if don't want to change dimensions, difficult to put image and alt on screen simultaneously.
22:07:26 [JR]: JA: Currently can have img and alt at the same time
22:08:29 [JR]: KF: Are we getting too bogged down
22:09:30 [jallan]: JR: yes, getting bogged down, concerned about the media with multiple caption, and audio tracks. only show one of each but not multiples
22:09:48 [JR]: JR: Idea of complimentary conditional content
22:12:24 [jallan]: JA: how to say with a movie...only allow selection of one caption and one audio track at a time to play with the movie
22:14:02 [jallan]: JR: have a SMIL, with video with english and spanish audio, with english audio description
22:14:27 [jallan]: .... the english and english audio description track can play well together.
22:15:14 [jallan]: ... spanish track and english audio may not play well because of timing.
22:15:36 [JR]: KF: Maybe ok not to cover this right now
22:15:41 [jallan]: KF: this is an issue, but may not be critical to this CP
22:16:17 [JR]: Action JR: To follow up on 2.3 and make proposal.
22:23:18 [KFord]: IE web developer toolbar:
22:23:20 [KFord]: http://www.microsoft.com/downloads/details.aspx?FamilyID=E59C3964-672D-4511-BB3E-2D5E1DB91038&displaylang=en
22:24:07 [jallan]: no conference all this week 11/8, next call 11/15
22:28:06 [JR]: RRSAgent, make minutes
22:28:06 [RRSAgent]: I have made the request to generate http://www.w3.org/2007/11/06-ua-minutes.html JR
22:28:08 [Zakim]: -KFord
22:28:09 [jallan]: rrsagent, set logs public
22:28:09 [Zakim]: -MediaRoom
22:28:10 [Zakim]: WAI_UAWG(TP)8:00AM has ended
22:28:11 [Zakim]: Attendees were MediaRoom, pperente, KFord, Gregory_Rosmaita
22:28:20 [JR]: Zakim, bye
22:28:20 [Zakim]: Zakim has left #ua
22:28:25 [JR]: RRSAgent, bye
22:28:25 [RRSAgent]: I see 7 open action items saved in http://www.w3.org/2007/11/06-ua-actions.rdf :
22:28:25 [RRSAgent]: ACTION: Jim to email CDF about threading [1]
22:28:25 [RRSAgent]: recorded in http://www.w3.org/2007/11/06-ua-irc#T16-22-08
22:28:25 [RRSAgent]: ACTION: Gregory to contact Doug Schepers about multiple DOMs in CDF and embedded UAs [2]
22:28:25 [RRSAgent]: recorded in http://www.w3.org/2007/11/06-ua-irc#T16-32-44
22:28:25 [RRSAgent]: ACTION: JR to remove first sentence in 9.3 note. leave second sentence intact [3]
22:28:25 [RRSAgent]: recorded in http://www.w3.org/2007/11/06-ua-irc#T16-45-20
22:28:25 [RRSAgent]: ACTION: GJR check and make suggestions for improving a11y of stylesheets [4]
22:28:25 [RRSAgent]: recorded in http://www.w3.org/2007/11/06-ua-irc#T16-52-37
22:28:25 [RRSAgent]: ACTION: KF to Re-raise alternate view at call on Nov 22 [5]
22:28:25 [RRSAgent]: recorded in http://www.w3.org/2007/11/06-ua-irc#T19-12-15
22:28:25 [RRSAgent]: ACTION: KF to email GR, create schema for editing changes [6]
22:28:25 [RRSAgent]: recorded in http://www.w3.org/2007/11/06-ua-irc#T21-03-11
22:28:25 [RRSAgent]: ACTION: JR to To follow up on 2.3 and make proposal. [7]
22:28:25 [RRSAgent]: recorded in http://www.w3.org/2007/11/06-ua-irc#T22-16-17