15:27:28 RRSAgent has joined #ua 15:27:28 logging to http://www.w3.org/2010/11/10-ua-irc 15:27:30 RRSAgent, make logs public 15:27:30 Zakim has joined #ua 15:27:32 Zakim, this will be WAI_UAWG 15:27:32 I do not see a conference matching that name scheduled within the next hour, trackbot 15:27:33 Meeting: User Agent Accessibility Guidelines Working Group Teleconference 15:27:33 Date: 10 November 2010 15:27:54 zakim, code? 15:27:54 sorry, JAllan, I don't know what conference this is 15:33:11 Jan has joined #ua 15:33:26 zakim, who's here? 15:33:26 has not yet started, Jan 15:33:27 On IRC I see Jan, Zakim, RRSAgent, JAllan, trackbot 15:34:12 sharper has joined #ua 15:35:34 jeanne has joined #ua 15:37:11 rrsagent, make minutes 15:37:11 I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html jeanne 15:37:25 rrsagent, make logs public 15:37:40 Kim has joined #ua 15:37:45 chair: JAllan, KFord 15:38:30 zakim, code? 15:38:30 sorry, JAllan, I don't know what conference this is 15:39:03 zakim, this is UAWG 15:39:03 ok, jeanne; that matches WAI_(UAWG1)10:30AM 15:39:24 zakim, code? 15:39:24 the conference code is 82941 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), jeanne 15:40:34 mhakkinen has joined #ua 15:41:10 +??P0 15:41:31 zakim, ??P0 is SHarper 15:41:31 +SHarper; got it 15:41:56 kford has joined #ua 15:42:12 +??P1 15:42:20 present+ Greg, Jim, Jan, Jeanne, Kim, Mark, Simon 15:42:31 zakim, ??P1 is Mark 15:42:31 +Mark; got it 15:44:23 +[IPcaller] 15:44:25 scribe: jallan 15:44:42 zakim, [IPcaller] is really Jan 15:44:42 +Jan; got it 15:44:48 present+Kelly 15:45:02 jeanne has changed the topic to: - Master: http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html 15:45:15 http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/ 15:45:19 http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/ 15:45:29 zakim, topic? 15:45:29 I don't understand your question, JAllan. 15:46:08 http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html 15:49:06 Lunch: 1:45 ET 15:51:36 topic: 1.8.5 Viewport History: If the user agent maintains a viewport history mechanism (e.g., via the "back button") that stores previous "viable" states (i.e., that have not been negated by the content, user agent settings or user agent extensions). It maintains information about the page and embedded controls, including viewport scrolling, selection and keyboard focus. It restores the... 15:51:38 ...saved values when the user returns to a state in the history. 15:52:45 ja: sounds more like an Intent 15:53:28 jr: there is a big out, if the UA doesn't provide a history they are free of this SC 15:54:38 JA: The real requirement is we want UA to maintain the state of all your control. 15:55:34 gl: do we want to require a history 15:56:04 jr: need be careful of web apps and dynamic states 15:56:24 gl: other than page navigation, how does this apply to real player. 15:56:48 jr: it is complicated. this SC is static oriented. 15:57:18 for review: 9.4 Restore viewport state history (P1) Techniques for checkpoint 9.4 For user agents that implement a viewport history mechanism, for each state in a viewport's browsing history, maintain information about the point of regard, content focus, and selection. When the user returns to any state in the viewport history (e.g., via the "back button"), restore the saved values for... 15:57:20 ...the point of regard, content focus, and selection. 15:58:57 +1 to require a history 15:59:26 js: this belongs in understanding, more about correcting mistakes than being perceivable 15:59:51 +1 to requiring a history 15:59:52 +1 16:00:19 -Mark 16:00:37 back in 5 16:00:55 gl: craft language for history where it applies for UAs that render discrete documents 16:01:33 ... if in a long web page, search for 'hello' and jumps down the page, should user be able to go back to before search 16:02:12 kp: use case: cognitive issue, if you loose your place, should be able to return to a known state. 16:02:37 kf: editors have undo because they are destructive actions. 16:02:55 ... undo search should be AA or AAA 16:03:42 js: all undo actions are in GL 3 16:04:22 gl: two levels of history, back and forward button, and a list of previous pages 16:05:01 9.4 Restore viewport state history For user agents that implement a viewport history mechanism, for each state in a viewport's browsing history, maintain information about the point of regard, content focus, and selection. 16:07:13 When the user returns to any state in the viewport history (e.g., via the "back button"), restore the saved values for the point of regard, content focus, and selection. 16:11:16 jim's attempt 16:11:21 Viewport History: If the user agent maintains a viewport history mechanism for each state in a viewport's browsing history, maintain information about the point of regard, content focus, and selection. When the user returns to any state in the viewport history (e.g., via the "back button"), the saved values for the point of regard, content focus, and selection are restored. 16:12:14 9.4 Restore viewport state history For user agents that implement a viewport history mechanism, for each state in a viewport's browsing history, the user can return information about the point of regard, content focus, and selection. When the user returns to any state in the viewport history (e.g., via the "back button"), restore the saved values for the point of regard, content focus, and... 16:12:15 ...selection. 16:12:31 For user agents that implement a viewport history mechanism, the user can return any state in the viewport history with the saved prior point of regard, content focus and selection 16:13:02 +??P17 16:13:19 For user agents that implement a viewport history mechanism, the user can return to any state in the viewport history with the saved prior point of regard, content focus and selection 16:13:32 zakim, P17 is really Mark 16:13:32 sorry, JAllan, I do not recognize a party named 'P17' 16:13:40 zakim, ??P17 is really Mark 16:13:40 +Mark; got it 16:13:59 Greg has joined #ua 16:14:31 For user agents that implement a viewport history mechanism, the user can return to any state in the viewport history with the saved prior point of regard, input focus and selection 16:14:47 rsagent, make minutes 16:14:56 rssagent, make minutes 16:15:16 rrsagent, make minutes 16:15:16 I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html jeanne 16:17:39 I think the word "with" is a little disconcerting, because can mean "using" as in "return with the back button" or "and have restored" as in "with saved focus". 16:18:03 I would have said "and have the such and so restored". 16:18:37 For user agents that implement a viewport history mechanism, the user can return to any state in the viewport history with the and restore the prior point of regard, input focus and selection 16:19:01 For user agents that implement a viewport history mechanism, the user can return to any state in the viewport history restoring the prior point of regard, input focus and selection 16:19:26 +1 16:19:29 +12 16:19:30 +1 16:19:32 For user agents that implement a viewport history mechanism, the user can return to any state in the viewport history, restoring the prior point of regard, input focus and selection. 16:19:33 +1 16:20:03 +1 16:20:03 For user agents that implement a viewport history mechanism, the user can return to any state in the viewport history (e.g. back button), restoring the prior point of regard, input focus and selection. 16:20:56 (e.g., via a back button) ? 16:21:38 should be level A, current UA behavior, has been level A since UAAG 10 16:22:24 ... user would have to perform lots of tasks to return to a previous state 16:22:26 Resolution: 1.8.5 is completed!!! 16:24:02 http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html 16:25:28 topic: 1.8.6 Open on Request: The user has the option of having "top-level"viewports (e.g., windows) only open on explicit user request. In this mode, instead of opening a viewport automatically, notify the user and allow the user to open it with an explicit request (e.g., by confirming a prompt or following a link generated by the user agent). (Level AA) 16:26:22 kf: 2nd sentence should be Intent 16:27:10 If we take out the 2nd sentence, can we modify the first to say ""with an explicit user request or confirmation"? 16:28:26 Thus: The user has the option of having "top-level" viewports (e.g., windows) with an explicit user request or confirmation. 16:28:47 I don't think we elsewhere put top-level in quotes. 16:29:08 The user has the option of having top-level viewports (e.g. windows or tabs) with an explicit user request or confirmation. 16:29:41 The user has the option of having top-level viewports (e.g. windows) open with an explicit user request or confirmation. 16:30:33 gl: is a tab a top level window 16:30:47 The user has the option of having top-level viewports (e.g. windows or tabs) open with an explicit user request or confirmation. 16:30:48 kp: should put 'tab' in also 16:31:08 jr: only with explicit user request 16:31:09 The user has the option of having top-level viewports (e.g. windows or tabs) open only with an explicit user request or confirmation. 16:32:04 The user can specify that top-level viewports (e.g. windows or tabs) open only with an explicit user request or confirmation. 16:32:42 The user can specify that top-level viewports (e.g. windows or tabs) open only with an explicit user request or confirmation. (Level AA) 16:33:00 kf: it is so disruptive, should be A 16:33:15 kp, mh, ja +1 16:33:44 gl: also disruptive to have to keep confirming open new window. 16:34:42 mh: implementation - usability of having a global setting to toggle opening new windows 16:34:49 The user can specify whether or not top-level viewports (e.g. windows or tabs) open only with an explicit user request or confirmation. (Level AA) 16:35:14 js: this seems redundant, if you 'specify' implies a choice 16:35:34 kp: gregs wording is more clear 16:36:07 gl: if we mean, turn on/off should have a word. used to use 'option' we are now using 'whether or not' 16:36:11 +1 to greg 16:36:26 +1 16:36:36 +1 16:36:43 ja, kf, kp +1 16:36:44 +1 16:37:02 what's the final wording? 16:37:11 The user can specify whether or not top-level viewports (e.g. windows or tabs) open only with an explicit user request or confirmation. (Level AA) 16:37:14 http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html 16:37:52 +1 16:39:11 The user can specify whether or not top-level viewports (e.g. windows or tabs) open only with an explicit user request or confirmation. (Level A) 16:39:54 resolution: 1.8.6 is complete!!! 16:40:12 topic: 1.8.7 Do Not Take Focus: When configured to allow top-level viewports to open without explicit user request, the user has the option to specify that if a top-level viewport opens, it does not take the active keyboard focus . (Level AA) 16:40:37 When top-level viewports are configured to open without explicit user request, the user has the option to specify that if a top-level viewport opens, it does not take the active keyboard focus 16:40:56 tabs, also 16:43:04 When top-level viewports are configured to open without explicit user request, the user can specify whether or not, when a top-level viewport opens, it takes the active keyboard focus 16:43:14 ... tabs not necessary if only talking about viewports 16:43:53 Scribe: KFORD 16:44:01 Scribe: kford 16:44:39 When top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not, a top-level viewport takes the active keyboard focus when it opens 16:44:48 KF: If we are defining are refering to viewports, the language should be identical. 16:45:30 rrsagent, make minutes 16:45:30 I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html kford 16:45:43 If top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not a top-level viewport takes the active keyboard focus when it opens 16:46:24 If top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not the top-level viewport takes the active keyboard focus when it opens 16:46:48 JS: We have a subtle change. I think originally itsiad it shouldn't take the keyboard focus. 16:46:56 JS, now it is a user option. 16:47:12 KF: I'm fine with this. 16:47:19 JS: It is more coding. 16:48:27 If a top-level viewport (e.g. windows or tabs) is configured to open without explicit user request, the user can specify whether or not the top-level viewport takes the active keyboard focus when it opens 16:49:55 If new top-level... 16:50:09 Group discussion if this is global or not. People hearing it different ways. 16:50:54 If top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not a top-level viewport takes the active keyboard focus when it opens 16:50:54 If new top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not the top-level viewport takes the active keyboard focus when it opens 16:51:17 +1 16:51:20 In the previous SC we used "request or confirmation". 16:53:34 That was because the UAAG1 version explicitly said confirmation was an acceptable alternative to explicit request. 16:54:08 We can take it out of both or leave it in both. 16:54:41 UAAG1 said "open it with an explicit request (e.g., by confirming a prompt or following a link generated by the user agent)". 16:55:15 +1 16:56:18 kp: top level opens without request or confirmation, the user need to be able confirm focus change 16:57:09 If new top-level viewports (e.g. windows or tabs) are configured to open without explicit user request or confirmation, the user can specify whether or not the top-level viewport takes the active keyboard focus when it opens 16:58:04 resolution: 1.8.7 is completed!! 16:58:10 +1 16:58:45 The first half is plural and second half is singular. 16:59:23 If top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not top-level viewports take the active keyboard focus when they open 17:00:10 new is missing? 17:00:39 If top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not such viewports take the active keyboard focus when they open. 17:02:16 topic: 1.8.8 Stay on Top: The user has the option of having the viewport with the current focus be displayed and remain on top of all other viewports with which it overlaps. (Level AA) 17:02:25 If new top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not top-level viewports take the active keyboard focus when they open 17:03:41 gl: what's the point 17:03:44 I have concerns about this. What's the goal? 17:04:09 gl: use case? 17:04:10 Can you provide use-case scenarios? 17:04:41 jr: in x-window you can have an active window be behind other windows 17:04:56 I worry about conflict with "always-on-top" windows such as used by assistive technology (e.g. on-screen keyboards). 17:04:58 kf: some application have option to stay on top 17:05:22 ja: task manager 17:06:57 jr: giving examples of when active window is not on top 17:08:41 gl: this is not about stealing focus 17:09:09 gl: don't see need for it 17:09:31 kp: if you have a macro that does three things, and in the middle the focus changes 17:09:55 jr: this doesn't have anything to do with focus change. 17:10:19 js: intent and examples, talk about top window. 17:10:24 kf: remove 17:10:46 ja, kp, mh, js, jr +1 17:11:15 +1 17:11:20 resolution: 1.8.8 is removed and completed!! 17:11:55 topic: 1.8.9 Close Viewport: The user can close any top-level viewport. (Level AA) Note: Dialog boxes or other special purpose viewports that provide limited functionality, do not have to spawn all the user-requested features that do not apply to that special function. 17:13:09 +1 to rem the 1.8.9 note 17:14:21 gl: move last sentence of example to intent 17:14:48 ... use case: ad popup with no close function 17:15:06 Suggested moving the last sentence of the example to the Intent, and adding an example of ad windows that hide controls for closingthem. 17:15:09 +1 to remove the note 17:15:18 +1 to mark 17:15:21 +1 17:15:34 resolution: 1.8.9 completed!! 17:15:54 tpoic: 1.8.10 Same UI: The user has the option of having all top-level viewports follow the same user interface configuration as the current or spawning viewport. (Level AA) 17:16:31 topic: 1.8.10 Same UI: The user has the option of having all top-level viewports follow the same user interface configuration as the current or spawning viewport. (Level AA) 17:17:11 Isn't a dialog box a new top-level viewport? 17:17:41 jr: viewports are what the UA uses to render content 17:17:52 That is, an author-created dialog box written in HTML and launched by a script. 17:18:24 "view, viewport: The user agent renders content through one or more viewports. Viewports include windows, frames, pieces of paper, loudspeakers, and virtual magnifying glasses. A viewport may contain another viewport (e.g., nested frames). User agent user interface controls such as prompts, menus, and alerts are not viewports. " 17:19:31 The user has the option of having all top-level viewports (e.g. windows or tabs) follow the same user interface configuration as the current or spawning viewport. (Level AA) 17:21:49 Note that this does not say that all new windows are the same, but rather that new windows inherit from the window that spawned them. Thus this would not give the user control over new windows that are NOT spawned by an existing window, e.g. a new window opened by a request from another application. 17:22:42 intent - authors can open new windows without user interface. user has not ability to scroll, back button is missing. if text is large it may expand beyond the boundries of the new window and the user has no scroll bars 17:22:59 It's not a major thing but if you wanted to mean that all new windows had the same UI, we should say that instead of talking about inherited. 17:23:27 ja: user should have option of full chrome or what the author coded 17:24:22 Consider revisiting the definition of top-level window to make it clearly not apply to authored dialog boxes and authored status windows. 17:24:50 Same UI: The user has the option of having all top-level viewports (e.g. windows or tabs) follow the same user interface configuration as the current or spawning viewport. (Level AA) 17:26:11 Same UI: The user has the option of having all top-level viewports (e.g. windows or tabs) follow the current user interface configuration. (Level AA) 17:26:13 kp: example - user has cognitive issues, always wants an limited UI 17:26:25 ... all windows should have limited UI 17:26:48 Same UI: The user can specify that all top-level viewports (e.g. windows or tabs) follow the current user interface configuration. (Level AA) 17:27:14 +1 17:27:15 +1 all 17:27:36 resolution: 1.8.10 compeleted!!! 17:28:10 topic: 1.8.11 Indicate Viewport Position: Indicate the viewport's position relative to rendered content (e.g., the proportion along an audio or video timeline, the proportion of a Web page before the current position ), and what proportion of the content is currently visible in the viewport along either vertical or horizontal dimension. (Level AAA) 17:36:44 gl: this is good. put eg in example or intent. substitute 'scroll bars' 17:37:09 I'm not sure how this would apply in a purely audio-output UI. 17:38:25 ... example, listening to 1 hr audio, does the player have to always tell the user 17:38:55 kf: if on telephone, listening to web page, how does it indicate where you are on the page 17:38:55 Indicate Viewport Position: The user is able to determine the viewport's position relative to the full extent of the rendered content. (Level AAA) 17:39:03 We would not want it to automatically keep interrupting to give a time progress notice. Or at least, the user should be able to turn that off! 17:39:54 Another approach would be to limit this to visual displays. 17:40:02 In the audio only case, you'd want this available likely only on request. 17:40:14 +1 to Jan (and make it an A) 17:41:30 I believe that in a visual UA, users should be able to have display of the position always available (e.g. scrollbars) rather than have to query the position. 17:41:39 kf: +1 to Jan 17:41:50 Indicate Viewport Position: The user can determine the viewport's position relative to the full extent of the rendered content. (Level AAA) 17:41:56 Indicate Viewport Position: The user can determine the viewport's position relative to the full extent of the rendered content. (Level AAA) 17:44:00 discussion of Level 17:44:14 kf: every UA today does this 17:45:07 Unfortunately like we discussed yesterday, "viewport's position" is ambiguous; we really mean to discuss which portion of the viewport's content is scrolled or panned into the visible region. 17:47:53 "can determine which portion of a viewport's content is currently visible"? 17:48:12 Viewport View Position? 17:48:40 Indicate content positionThe user can determine the content's position relative to the total content available in the viewport.the full position relative to the full extent of the rendered content. (Level AAA)   17:48:47 jr: viewport is like a portal on a ship, what you see, is a small portion of the whole scene 17:49:05 How about this: 17:49:07 Indicate content positionThe user can determine the content's position relative to the total content available in the viewport. 17:50:02 "can determine which portion of the content is currently visible in the viewport" 17:50:18 The user can determine the content's position in the viewport relative to the total content available. 17:51:14 Indicate Viewport Position: The user can determine the viewport's position relative to the full extent of the rendered content. (Level AAA) 17:52:14 Imagine a document A, that's two pages long. In the middle of it is a DIV with scrollbars showing a view onto five pages of content (B). So is the DIV's "position" which portion of B it's showing, or where it is located in A? That 17:52:25 that's the ambiguity of the phrase "viewport's position". 17:53:02 That's why I would favor saying "the portion of the content being rendered in the viewport (DIV)" 17:53:36 kf: jan's text is good, should move on 17:53:39 My concern is purely about the wording not the intent. 17:54:01 proposed Indicate Viewport Position: The user can determine the viewport's position relative to the full extent of the rendered content. (Level AA) 17:54:12 +1 17:54:13 +1 17:54:15 +1 17:54:16 +1 17:54:17 +1 17:54:19 +1 17:54:20 +1 17:54:23 +1 17:54:45 resolution: 1.8.11 completed!! 17:55:00 kp: need scroll bars in the intent 17:55:19 We should revisit the intent for 1.8.11 and ensure the scroll bar cases and such are captured. Greg has some excellent examples of scroll behavior. 17:56:55 topic: 1.9.1 Keyboard Focus: At least one keyboard focus is provided for each viewport (including frames), where enabled elements are part of the rendered content. (Level A) 17:57:35 kp: need to have all of the intents for 1.9 done before we smith the SC 17:59:22 resolution: skipping 1.9 until all 'intent's are completed, moving to 1.10 18:00:30 gl: should we have upshot for all GK 18:01:07 topic: 1.10.1Text View: For content authored in text formats, a view of the text source is provided. (Level A) 18:01:53 For content authored in text formats, the user can view of the text source. (Level A) 18:02:04 The user can view of the text source for content authored in text formats. 18:02:30 The user can view the text source of content authored in text formats. 18:02:37 +1 18:03:44 kf: what about flash 18:04:25 jr: level A, for whom is this an accessibility barrier 18:04:37 gl: reads the intent 18:04:46 is SVG another case? 18:05:17 Jan suggests it's not Level A; would not fail as UA just for lacking this. 18:05:39 kf: this is useless as written. we don't define what you want...runtime source vs what is in the dom 18:05:58 jr: javascript source vs rendered source 18:06:30 kf: leave it in, we understand conceptually. demote to level AA 18:06:36 other issues might be DRM-protected source, or remote source such as PHP or ASP that is never sent to the UA. 18:06:51 js: make it easier for Flash 18:08:24 gl: is flash written in text? 18:08:40 js: viewing source would be useful 18:09:03 mh: could be compiled code, no source 18:09:22 kf: AAA 18:09:28 js: +1 18:09:31 JR: AAA 18:09:37 mh: AAA 18:09:46 ja: AAA 18:10:12 gl: say text source is available 18:10:20 Could say that if the text source is available to the user agent, it makes it avialable to the user. 18:11:40 The user can access text source that is available to the user agent 18:12:00 If text source of content is available to the user agent, the user can access that text source. 18:12:35 or, The user can access text all source that is available to the user agent 18:12:58 The user can access all text source that is available to the user agent 18:14:11 kp: text is ultimate fall back. 18:14:19 kf: should be AAA 18:14:59 ... if trying to solve an accessibility problem, source is last resort, and very difficult 18:15:21 +1 to gl's comment 18:16:36 Kelly argued that text source no longer corresponds closely with what's actually being rendered due to scripts, etc. and that text sources is no longer easy to read. 18:17:56 ja: this is last resort, is it the lowest priority to have the last resort 18:18:24 kp: having a last resort is essential, which last resort is a different question 18:18:48 compromise on AA all agree 18:19:11 resolution: 1.10.1 at AA with new wording is completed!! 18:19:21 rrsagent, make minutes 18:19:21 I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html jeanne 18:19:29 topic: 1.10.2 Outline View: An "outline" view of rendered content is provided, composed of labels for important structural elements (e.g. heading text, table titles, form titles, and other labels that are part of the content). (Level AA) 18:20:29 kp: very clear 18:20:35 kf: who does this 18:20:42 js: amaya 18:20:51 gl: ff has an extension 18:20:52 Firefox does it with a popular extension. 18:21:06 (called HeadingsMap) 18:22:16 gl: this is important for understanding. outline should be navigable 18:23:07 https://addons.mozilla.org/en-US/firefox/addon/7203/ 18:23:29 kf: opera allows navigating by headings 18:24:00 resolution: 1.10.2 is completed!! 18:24:22 topic: 1.10.3 Configure Set of Important Elements:The user can be presented with a hierarchical view of the rendered content that conveys associations implied by author-specified presentation attributes (i.e. position and appearance). (Level AA) 18:24:25 (I would like to see 1.10.2 be Level A.) 18:25:21 gl: note in 1.10.2 should reference 1.10.3 18:26:37 http://www.w3.org/Amaya/ 18:26:54 gl: this wording is incorrect. searching for new wording 18:28:34 3.12.3 Configure Set of Important Elements: The user has the option to configure the set of important elements for the "outline" view, including by element type (e.g., headers). (Level AAA) 18:29:01 +1 18:29:20 kf: +1 18:29:25 Jan has joined #ua 18:29:29 The Note for 1.10.2 should reference 1.10.3. 18:29:43 kf: this is specifics of complying with 10.2 18:31:15 ja: in June Draft 10.3 was AAA, now is AA 18:35:02 gl: where does the current 10.3 language come from 18:35:30 So, the new 1.10.3should be based off the text I pasted here. 18:35:53 this as Action http://www.w3.org/WAI/UA/tracker/actions/406 18:37:36 kf: lets closes on 10.3 Configure Set of Important Elements: The user has the option to configure the set of important elements for the "outline" view, including by element type (e.g., headers). (Level AAA) 18:37:54 kp and js: smithing 18:38:27 gl: +1 18:38:29 3.12.3 Configure Set of Important Elements: The user can configure the set of important elements for the "outline" view, including by element type (e.g., headers). (Level AAA) 18:38:39 +1 18:38:57 I'm fine with that wording, although if we change 1.10.2 to say "heirarchical view" instead of "outline view" we'd change that here, too. 18:39:07 gl: outline vs hierarchical view in 10.2 and 10.3 should be parallel 18:40:04 Resolution: 1.10.3 is completed at AAA!! 18:40:31 topic: reopen 1.10.2 18:40:39 reviewing wording changes 18:40:50 current: Outline View: An "outline" view of rendered content is provided, composed of labels for important structural elements (e.g. heading text, table titles, form titles, and other labels that are part of the content). (Level AA) 18:41:02 proposed: The user can be presented with a hierarchical view of the rendered content that conveys associations implied by author-specified presentation attributes (i.e. position and appearance). 18:42:03 A significant difference is that the former talks about explicit heirarchy (e.g. h1, h2), whereas the latter seems to focus on implied, rather than explicit, heirarchy (e.g. positions) 18:42:50 sh: latter, look at visually, implied relationship, but not related to how they are related by position in the DOM 18:43:03 kf: is it possible we want 2 SC here 18:43:22 So the easy one is an outline view of explicitly author-specified hierarchy (e.g. h1), whereas the latter is harder (heuristics). 18:43:43 ...one for hierarchy, one for relationship (proximity) 18:43:49 Hierarchical View: The user can be presented with a hierarchical view of the rendered content that conveys associations implied by author-specified preseHierarchical View: The user can be presented with a hierarchical view of the rendered content that conveys associations implied by author-specified presentation attributes (e.g. position and appearance). (Level AAA)ntation attributes (e.g. position 18:43:49 and appearance). (Level AAA) 18:44:14 Hierarchical View: The user can be presented with a hierarchical view of the rendered content that conveys associations implied by author-specified presentation attributes (e.g. position and appearance). (Level AAA) 18:44:14 jr: could be useful to have 2 SC, relationship view could be regular view 18:44:44 mh: this seems to be a repair technique. references WCAG2, dom logical order 18:45:25 jr: +1 to mh, yes repair. when logical labels or semantics are missing then use presentational information 18:45:41 ... to create hierarchy 18:46:10 ... this should be in implementing as a repair example 18:46:52 jr: not implementing, but a new SC (1.2.3) 18:47:56 action: Jan to create new SC in repair guidelines, using language "The user can be presented with a hierarchical view of the rendered content that conveys associations implied by author-specified presentation attributes (i.e. position and appearance)." 18:47:56 Created ACTION-466 - Create new SC in repair guidelines, using language "The user can be presented with a hierarchical view of the rendered content that conveys associations implied by author-specified presentation attributes (i.e. position and appearance)." [on Jan Richards - due 2010-11-17]. 18:49:00 -Mark 18:49:02 **** lunch break **** 18:49:08 rrsagent, make minutes 18:49:08 I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html JAllan 18:49:59 - +1.512.206.aaaa 18:51:57 My action item (from Action 466): New SC1.2.3: Repair Missing Associations: The user can specify whether or not the user agent should attempt to predict associations from author-specified presentation attributes (i.e. position and appearance). (Level AA - level is tricky since the need is high but technical feasibility is uncertain) 19:08:21 -[Microsoft] 19:08:42 +[Microsoft] 19:08:50 -MIT262 19:10:20 +MIT262 19:13:06 + +1.512.206.aabb 19:13:21 zakim, aabb is really jallan 19:13:21 +jallan; got it 19:27:19 user_ has joined #ua 19:29:07 jr: this is recasting 10.3, moving it as a repair item 19:29:36 ... this is like screen scraping -- finding form labels by proximity 19:29:54 ... lots of missing structure in the wild. 19:30:11 ... this is difficult to implement by UA developers 19:30:16 Mark_mobile has joined #ua 19:30:59 gl: confused that it has morphed form a hierarchical view, to relationships 19:31:06 ... looking for use cases 19:31:51 jr: took 1.10.3 "implied by author-specified presentation attributes (i.e. position and appearance)" to characterize as a repair. 19:32:48 ... this would inform the 'outline' in 1.10.2 19:33:31 gl: would an outline view show form labels? 19:33:50 I don't think of document maps or outline views as showing labels for controls, only for larger groupings like forms. 19:34:11 kf: would depend..., normally outline is html headings. but user could configure the important element to show in outline 19:34:49 ... screen readers do this already, show headings, forms, tables, etc 19:35:22 So I'd think repairing missing labels for controls would benefit AT users, but not other users. 19:36:46 jr: how is this testable, how do we do this. 19:40:32 When it's only for AT, can the UA do a better job of applying these heuristics than AT could? 19:40:32 kf: think we need this as a repair as an AA or AAA 19:41:37 ... outline view and what it does...do we have enough. (10.2 is ok), using Jan's, moving it somewhere, and removing 10.3 is ok 19:41:45 kf: calls question 19:41:51 js +1 19:41:54 ja +1 19:41:58 +1 19:41:59 +1 19:42:14 would important elements include non-importants with imp aria roles? 19:42:18 +1 19:42:42 (waiting for my check ... back soon) 19:42:49 +1 19:43:03 kf: need to make sure glossary reflects aria important elements 19:43:39 I think +1 for me ... seeing only irc 19:43:56 resolution: remove 1.10.3, create new 1.2.3 Repair Missing Associations: The user can specify whether or not the user agent should attempt to predict associations from author-specified presentation attributes (i.e. position and appearance). (Level AAA) 19:44:05 -Jan 19:44:11 doh! 19:44:23 topic: 1.11.1 Basic Link Information: The following information is provided for each link (Level A) 19:44:49 link element content, new viewport (whether the author has specified that the resource will open in a new viewport) 19:45:19 on 1.11.1 and .2 i have question about rel and ref if present on link 19:45:47 +??P1 19:46:04 zakim, ??P1 is really Jan 19:46:04 +Jan; got it 19:49:46 The Note for 1.10.2 should have added: "What constitutes the important structural elements may be configured by the user (see 1.10.3)." 19:52:35 kf: do UA tell users about opening in a new window now. 19:53:21 ja: no, this is overlap with WCAG. so authors don't have to inform users. 19:53:48 gl: is the guideline about telling the AT or the user. 19:53:52 ja: user 19:54:02 js: user 19:54:20 gl: if it is just AT, it is programmatic, and should be moved 19:55:40 jr: this may not be necessary, see viewport SC we just did. 19:55:50 1.11.1 says "provide" the info but the Intent and first example are about programmatically exposing the info. If it's about AT compat should be included in that section. If as Jim says we want to have the UA display it to the user, then can keep here but need to reword, replace Intent and first example. 19:57:01 kf: why do we need this. what is the accessibility reason. 19:57:08 +??P3 19:57:35 jr: this should be covered in configuration of viewports above. 19:57:35 But even if some UA can display that for the user automatically, pages still have to authored to display that info when viewed in older browsers (to comply with WCAG). 19:57:43 zakim, ?PP3 is really Mark 19:57:43 sorry, mhakkinen, I do not recognize a party named '?PP3' 19:57:55 zakim, ?P3 is really Mark 19:57:55 sorry, mhakkinen, I do not recognize a party named '?P3' 19:58:11 zakim, ??P3 is really Mark 19:58:11 +Mark; got it 19:58:42 kf: what if the content is buttons, or checkbox, silverlight 20:00:46 gl: lean toward providing this information to the user, except technology type. not sure knowing something is a PDF is important. 20:01:29 sh: isn't this other information alternative content. 20:01:43 kf: how to resolve 1.11.1 20:01:54 I think knowing what content type a link goes to is more important than the others, that is more prominent use case for accessibility (e.g. a content type traps you). Of course the most important is link content, but everyone already renders that. 20:03:00 kf: inclined to delete 1.11.1 20:04:05 jr: opening a new viewport, is covered on warning side 20:05:13 mh: author can provide an icon or some indication that content opens in a new window. is there any benefit to UA doing this. 20:05:55 kf: you know is is going to open, you can already configure if things open in a new window. 20:06:58 kp: link title is important. 20:07:28 ja: shouldn't this be covered by title working from the keyboard 20:07:53 Just want to make sure people don't think that it's an accessibility case for knowing the content type that a link goes to. 20:08:10 kp: is there a downside to someone opening flash but not being able to 20:10:01 kf: not comfortable with 11.1 20:10:58 re title we but not filled in we could suggest they point to the title of the destination page 20:11:49 kf: why should people with disabilities to get more information than every body else 20:12:09 kp: it is a timing issue 20:13:22 To address the AT compatiblity aspect of formerly in 1.11, let's add to 4.1.6 (Properties) the additional list items "10. link content 11. link target URI 12. link target content type, when recognized". 20:14:22 Action: kelly to revise 1.11.1 and 1.11.2 make proposal to the group 20:14:22 Sorry, couldn't find user - kelly 20:14:33 Action: kf to revise 1.11.1 and 1.11.2 make proposal to the group 20:14:33 Sorry, couldn't find user - kf 20:14:42 Action: kford to revise 1.11.1 and 1.11.2 make proposal to the group 20:14:42 Sorry, couldn't find user - kford 20:14:51 Action: kellyford to revise 1.11.1 and 1.11.2 make proposal to the group 20:14:51 Sorry, couldn't find user - kellyford 20:16:56 Action: ja to revise 1.11.1 and 1.11.2 make proposal to the group 20:16:56 Created ACTION-467 - Revise 1.11.1 and 1.11.2 make proposal to the group [on Jim Allan - due 2010-11-17]. 20:17:30 resolution: Kelly revising 1.11.1 and 1.11.2 20:18:22 topic: 3.1.1 Option to Ignore: The user can turn off rendering of non-essential or low priority text messages or updating/changing information in the content based on priority properties defined by the author (e.g., ignoring updating content marked "polite" ). (Level AA) 20:20:07 ja: should swap 3.1.1 and 3.1.2 so the Level A's are in order 20:21:28 kp: what is definition of non-essential or low priority? 20:22:00 kf: isn't the covered by support accessibility features of supported technologies 20:22:32 kf: is this too specific to ARIA 20:23:48 This is going beyond supporting ARIA polite, saying not just "don't interrupt me" but "don't show it at all". 20:23:53 scribe: Harper_Simon 20:23:54 ScribeNick: sharper 20:24:16 gl: this is saying going beyond 20:24:23 kp: important for RSI users 20:24:54 GL: Seems to be going beyond to me 20:25:44 KF: Can live with it at the level it is - but then we say mark with 'polite' we should add the work ARIA 20:26:00 FIY from ARIA: http://www.w3.org/TR/wai-aria/states_and_properties#aria-live 20:26:05 JS: to broad as it is - low priority interrupt. 20:26:16 s/to/too 20:26:42 Discussion seems to be saying it has two benefits: one to avoid having to respond to interruptions, and the other to avoid distractions by updating information. 20:27:06 s/by/from/ 20:28:34 JR: We are going to say that the UA knows better than the Author - what if low priority but important 20:30:54 i agree with Jan that it's dangerous to hide things that author said were low priority but still should be displayed, but as Kim says it's more important to be able to avoid things that require a response. 20:31:06 All: discussion as to the ability to switch off updates - or - assume author knows best 20:34:49 Kelly makes an interesting point that IE is moving away from popups, BUT that has a downside, which is that the user is likely to overlook a subtle notification in a portion of the window they're not looking at or having read to them, and thus not understand why the file the link they clicked had no effect--because IE won't download the file until the user clicks on the notification area to confirm downloading it. 20:35:34 http://lists.w3.org/Archives/Public/w3c-wai-ua/2010OctDec/0050.html 20:36:24 sh: I'm hearing via xtech (I think) that some browser are thinking of removing Mutex Events to make their processing faster - I think if this is the case we need to add something to our guidelines to say we need to catch this and make sure dynamic changes to the DOM are handled even in the event of no ARIA markup. 20:39:33 Action: jAllan to kFord to clean up 3.1.2 and further investigating wording 20:39:33 Created ACTION-468 - KFord to clean up 3.1.2 and further investigating wording [on Jim Allan - due 2010-11-17]. 20:40:05 topic: 3.1.1 (former 5.1.2) Retrieval Progress: Show the progress of content retrieval. (Level A) 20:40:10 +1 20:40:30 +1 20:40:35 I like it +1 20:40:42 +1 20:40:49 I'm fine with the SC, but the second sentence of the Intent is not applicable here: "Users who cannot see visual indications need to have feedback indicating a time delay and have an idea of where they are in the retrieval process." 20:41:14 http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html 20:41:21 The problem with that is that the SC seems to be about providing visual feedback in a visual browser. That sentence is about AT compatibility. 20:41:32 JR: not sure this is teh right place for it - but like the SC 20:41:42 s/teh/the 20:42:11 JS: section 2 under Operating? 20:43:44 JS could be 2.3 - as this is about time based aspects 20:44:47 If we move 3.1.2 that leaves only one AA item in Guideline 3.1 "Help users avoid unnecessary messages". If we keep 3.1 we should probably move it later in the section. 20:45:46 We could consider adding to this section a recommendation that messages have a checkbox that lets the user avoid getting the message again. 20:46:18 But I'm not sure how we could write it to have an appropriate scope, that is only apply to messages where it's appropriate 20:46:57 AND when you do have those check boxes, it's also useful to have something in the application's settings that allows the user to reset those to their default, thus making all the messages visible again. 20:47:54 zakim, who is making noise? 20:48:08 jeanne, listening for 10 seconds I heard sound from the following: MIT262 (10%), [Microsoft] (68%) 20:49:51 Kim would prefer the user be able to re-enable individual messages or categories, rather than just re-enabling all messages. 20:50:57 I think it might be asking too much to expect an app to have a central list of all messages that have been turned off. 20:51:58 RESOLVED: JS Added an Editors' Note to revisit this at 3.1 20:52:02 rrsagent, make minutes 20:52:02 I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html jeanne 20:52:38 Guideline 3.2 (former 5.2) "Help users avoid and correct mistakes" lacks the SC about Undo. 20:52:44 topic: 3.2.1 (former 5.2.1) Form Submission: The user can redefine keyboard shortcuts for submitting and canceling recognized forms. (Level AA) 20:55:02 KF: don't we have a key binding guideline already? 20:56:54 undo http://www.w3.org/WAI/UA/tracker/issues/59/edit 20:58:05 http://www.w3.org/2009/11/06-ua-minutes#item05 20:58:58 Action: Greg to think about UNDO ( http://www.w3.org/2009/11/06-ua-minutes#item05 ) and come up with some suggestions. 20:58:59 Created ACTION-469 - Think about UNDO ( http://www.w3.org/2009/11/06-ua-minutes#item05 ) and come up with some suggestions. [on Greg Lowney - due 2010-11-17]. 20:59:59 -SHarper 21:00:00 scribe: jallan 21:02:04 gl: the enter key is provided by the UA and it submits the form, it is a feature 21:03:19 gl: the SC 2.1.2 (former 2.1.4) talks about key bindings, and should cover the submitting for forms 21:03:25 2.1.2 and 2.1.10 are both about changing keyboard bindings; 2.1.2 seems to cover remapping the submit key. 21:04:36 kp: need to include enter/submit on forms on 2.1.2 21:05:07 kf: no UAs do this now 21:07:04 kf: is this a problem 21:07:44 kp: form submission cause problems, more often submit when they don't want to. 21:08:14 Seems like changing the submit key (3.1.2) is just one example of changing command keys (2.1.2), so could be one example there. Both are currently AA, but Jeanne thinks 2.1.2 might have been intended to be A. 21:08:29 jr: what about just requiring confirmation of form submission 21:09:00 mh: how many different ways are there to submit a form 21:09:35 ... most forms submissions are probably javascript and would not be recognized 21:09:48 js: need to link this with 2.1 21:10:45 Might be 2.1.10 instead of 2.1.2; needs checking. 21:10:52 3.2.1 (former 5.2.1) Confirm Form Submission: The user can specify whether or not recognized form submissions must be confirmed. (Level AA) 21:11:17 -jallan 21:11:22 +1 21:12:10 General agreement that most pages moving away from using submit buttons that the UA can recognize; most using scripted elements. 21:13:17 Scribe: KFord 21:13:30 KF: What are we doing here, do we need this or kick it out? 21:14:08 If an author uses a script to submit a form based on a user action that would otherwise not trigger an onsubmit event (for example, a form submission triggered by the user changing a form element's value), the author SHOULD provide the user with advance notification of the behavior. Authors are reminded to use native host language semantics to create form controls, whenever possible. 21:14:11 GL: I think Jan's is better but agree that these are of limited use given the changes of web pages. 21:14:35 JAllan should I add you? 21:15:31 Jim can you hear? 21:16:26 Confirm Submit: When users submit information to a web page with a recognized submit control, provide the option to confirm such submission before data is transmitted. 21:18:15 "The user can specify that all form submissions made using recognized submission controls require confirmation" 21:18:34 +1 21:18:40 +1 21:19:14 +1 21:19:22 Jan's original wording of "The user can specify whether or not recognized form submissions must be confirmed" was at least as good. 21:20:15 Resolution: 3.2.1 is completed. need revision of intent and examples to match new wording 21:20:26 Resolution: 3.2.1 using updated text. 21:20:34 rrsagent, make minutes 21:20:34 I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html kford 21:20:55 Will someone take the task of adding an example about form submission to 2.1.10 or 2.1.2? 21:21:46 scribe: jallan 21:22:31 discussion of keybindings, and enter is platform behavior 21:23:43 topic: 3.3.1 Accessible documentation: The product documentation is available in a format that conforms to WCAG 2.0 Level "A" or greater. 21:23:53 gl: missing Level A 21:23:53 3.3.1 should be listed as Level A. 21:23:59 js: fixed 21:24:16 +1 to current wording 21:25:18 jr: conformation claims are optional in ATAG 21:25:52 brb 21:25:57 ...features required to meet ATAG must confom(not sure I heard that right) 21:26:16 did we close 3.3.1??? 21:28:03 resolution: 3.3.1 is completed!!! 21:28:39 topic: 3.3.2 Document Accessibility Features: All user agent features that benefit accessibility 21:28:58 discussion of definition of conformance claims. 21:29:15 -Mark 21:29:26 We noted need to provide definition of accessibility features as those that contribute to conforming with UAAG. 21:33:23 zakim, call allanj 21:33:23 I am sorry, JAllan; I do not know a number for allanj 21:34:52 -[Microsoft] 21:35:27 zakim, is there room for 4 now? 21:35:27 I don't understand your question, jeanne. 21:35:56 zakim, is there room for 4 today at 16:45? 21:35:56 I don't understand your question, jeanne. 21:36:54 zakim, do you have space for 4 people at 16:35P for 90 minutes? 21:36:56 ok, jeanne; conference Team_(ua)21:35Z scheduled with code 82942 (uawg2) at 16:35 for 90 minutes until 2305Z 21:37:32 -MIT262 21:37:32 Kelly got cut off while trying to conference Jim in, and now we can't get into the conference call because of the "access restricted" message that other people got earlier. 21:38:40 back 21:38:58 zakim, whos' here? 21:38:58 I don't understand your question, Jan. 21:39:04 zakim, who's here? 21:39:04 On the phone I see Jan 21:39:06 On IRC I see Jan, Greg, kford, mhakkinen, Kim, jeanne, Zakim, RRSAgent, JAllan, trackbot 21:39:56 -Jan 21:39:58 WAI_(UAWG1)10:30AM has ended 21:40:00 Attendees were [Microsoft], +1.512.206.aaaa, MIT262, SHarper, Mark, Jan, +1.512.206.aabb, jallan 21:41:48 zakim, this is UAWG 21:41:48 sorry, jeanne, I do not see a conference named 'UAWG' in progress or scheduled at this time 21:42:07 rrsagent, make minutes 21:42:07 I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html jeanne 21:43:30 resolution: 3.3.2 is completed!! 21:43:42 zakim, this is conference Team_(ua) 21:43:42 sorry, jeanne, I do not see a conference named 'conference Team_(ua)' in progress or scheduled at this time 21:43:55 topic: 3.3.3 Changes Between Versions: Changes to features that affect accessibility since the previous version of the user agent are documented. (Level AA) 21:44:07 Wouldn't it be nice if, say, a word processor that drops the menu bar had to call out in the documentation that this decreases accessibility. 21:46:07 We require apps to document accessibility FEATURES, but not limitations. That is very sad. 21:46:13 gl: we don't say anywhere that features were removed 21:46:16 Changes to features that affect accessibility since the previous user agent release are documented. 21:48:34 Changes to features that benefit accessibility since the previous user agent release are documented. 21:49:41 Changes to features that benefit OR BENEFITED accessibility since the previous user agent release are documented. 21:50:27 gl: does this require the announcement of things that were removed. 21:50:51 kf: it changed they should document it...put it in intent 21:51:46 From ATAG2 B.3.2.3 Instruction Index: The documentation contains an index to the instructions for using the accessible content support features. (Level AAA) 21:51:49 resolution: 3.3.3 is complete with new wording 21:52:05 topic: 3.3.4 (former 5.3.4) Centralized View: There is a centralized view of all features of the user agent that benefit accessibility, in a dedicated section of the documentation. (Level AA) 21:52:10 change to AAA 21:52:40 resolution: 3.3.4 is complete with new level AAA!!! 21:52:53 gl: do we have definition of documentation 21:52:56 kp: yes 21:53:19 topic: 3.3.5 Context Sensitive Help: There is context-sensitive help on all user agent features that benefit accessibility. (Level AAA) 21:53:59 +1 21:54:14 resolution: 3.3.5 is completed! 21:54:39 topic: 3.3.6 Appropriate Language: If characteristics of the user agent involve producing an end user experience such as speech, the user agent reacts appropriately to language changes. 21:55:45 The phrase "end user experience such as speech" is the same as "end user experience", so it applies to everything. 21:56:01 jr: what does this mean. 21:57:41 resolution: remove 3.3.6 21:58:49 topic: 3.4.1 Control default focus: The user agent provides a mechanism for setting global configuration of default focus. 21:59:39 js: should be reviewed in context of 1.9 22:00:18 kf: GL 3 seems a bunch of shoe horning. 22:00:43 js: we need an understanding section, for cognitive issues 22:01:28 Didn't we discuss a recommendation on autosummary, for example, which would fit under the Understandable section. 22:01:48 kp: need to discuss intent of 1.9 22:06:50 rrsagent, make minutes 22:06:50 I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html JAllan 22:17:00 zakim, please part 22:17:00 Zakim has left #ua 22:17:13 rrsagent, make minutes 22:17:13 I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html JAllan 22:17:30 rrsagent, please part 22:17:30 I see 8 open action items saved in http://www.w3.org/2010/11/10-ua-actions.rdf : 22:17:30 ACTION: Jan to create new SC in repair guidelines, using language "The user can be presented with a hierarchical view of the rendered content that conveys associations implied by author-specified presentation attributes (i.e. position and appearance)." [1] 22:17:30 recorded in http://www.w3.org/2010/11/10-ua-irc#T18-47-56 22:17:30 ACTION: kelly to revise 1.11.1 and 1.11.2 make proposal to the group [2] 22:17:30 recorded in http://www.w3.org/2010/11/10-ua-irc#T20-14-22 22:17:30 ACTION: kf to revise 1.11.1 and 1.11.2 make proposal to the group [3] 22:17:30 recorded in http://www.w3.org/2010/11/10-ua-irc#T20-14-33 22:17:30 ACTION: kford to revise 1.11.1 and 1.11.2 make proposal to the group [4] 22:17:30 recorded in http://www.w3.org/2010/11/10-ua-irc#T20-14-42 22:17:30 ACTION: kellyford to revise 1.11.1 and 1.11.2 make proposal to the group [5] 22:17:30 recorded in http://www.w3.org/2010/11/10-ua-irc#T20-14-51 22:17:30 ACTION: ja to revise 1.11.1 and 1.11.2 make proposal to the group [6] 22:17:30 recorded in http://www.w3.org/2010/11/10-ua-irc#T20-16-56 22:17:30 ACTION: jAllan to kFord to clean up 3.1.2 and further investigating wording [7] 22:17:30 recorded in http://www.w3.org/2010/11/10-ua-irc#T20-39-33 22:17:30 ACTION: Greg to think about UNDO ( http://www.w3.org/2009/11/06-ua-minutes#item05 ) and come up with some suggestions. [8] 22:17:30 recorded in http://www.w3.org/2010/11/10-ua-irc#T20-58-58