IRC log of ua on 2010-11-10

Timestamps are in UTC.

15:27:28 [RRSAgent]: RRSAgent has joined #ua
15:27:28 [RRSAgent]: logging to http://www.w3.org/2010/11/10-ua-irc
15:27:30 [trackbot]: RRSAgent, make logs public
15:27:30 [Zakim]: Zakim has joined #ua
15:27:32 [trackbot]: Zakim, this will be WAI_UAWG
15:27:32 [Zakim]: I do not see a conference matching that name scheduled within the next hour, trackbot
15:27:33 [trackbot]: Meeting: User Agent Accessibility Guidelines Working Group Teleconference
15:27:33 [trackbot]: Date: 10 November 2010
15:27:54 [JAllan]: zakim, code?
15:27:54 [Zakim]: sorry, JAllan, I don't know what conference this is
15:33:11 [Jan]: Jan has joined #ua
15:33:26 [Jan]: zakim, who's here?
15:33:26 [Zakim]: has not yet started, Jan
15:33:27 [Zakim]: On IRC I see Jan, Zakim, RRSAgent, JAllan, trackbot
15:34:12 [sharper]: sharper has joined #ua
15:35:34 [jeanne]: jeanne has joined #ua
15:37:11 [jeanne]: rrsagent, make minutes
15:37:11 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html jeanne
15:37:25 [jeanne]: rrsagent, make logs public
15:37:40 [Kim]: Kim has joined #ua
15:37:45 [jeanne]: chair: JAllan, KFord
15:38:30 [JAllan]: zakim, code?
15:38:30 [Zakim]: sorry, JAllan, I don't know what conference this is
15:39:03 [jeanne]: zakim, this is UAWG
15:39:03 [Zakim]: ok, jeanne; that matches WAI_(UAWG1)10:30AM
15:39:24 [jeanne]: zakim, code?
15:39:24 [Zakim]: 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]: mhakkinen has joined #ua
15:41:10 [Zakim]: +??P0
15:41:31 [jeanne]: zakim, ??P0 is SHarper
15:41:31 [Zakim]: +SHarper; got it
15:41:56 [kford]: kford has joined #ua
15:42:12 [Zakim]: +??P1
15:42:20 [jeanne]: present+ Greg, Jim, Jan, Jeanne, Kim, Mark, Simon
15:42:31 [jeanne]: zakim, ??P1 is Mark
15:42:31 [Zakim]: +Mark; got it
15:44:23 [Zakim]: +[IPcaller]
15:44:25 [JAllan]: scribe: jallan
15:44:42 [Jan]: zakim, [IPcaller] is really Jan
15:44:42 [Zakim]: +Jan; got it
15:44:48 [JAllan]: present+Kelly
15:45:02 [jeanne]: jeanne has changed the topic to: - Master: http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html
15:45:15 [JAllan]: http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/
15:45:19 [jeanne]: http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/
15:45:29 [JAllan]: zakim, topic?
15:45:29 [Zakim]: I don't understand your question, JAllan.
15:46:08 [jeanne]: http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html
15:49:06 [Jan]: Lunch: 1:45 ET
15:51:36 [JAllan]: 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 [JAllan]: ...saved values when the user returns to a state in the history.
15:52:45 [JAllan]: ja: sounds more like an Intent
15:53:28 [JAllan]: jr: there is a big out, if the UA doesn't provide a history they are free of this SC
15:54:38 [kford]: JA: The real requirement is we want UA to maintain the state of all your control.
15:55:34 [JAllan]: gl: do we want to require a history
15:56:04 [JAllan]: jr: need be careful of web apps and dynamic states
15:56:24 [JAllan]: gl: other than page navigation, how does this apply to real player.
15:56:48 [JAllan]: jr: it is complicated. this SC is static oriented.
15:57:18 [JAllan]: 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 [JAllan]: ...the point of regard, content focus, and selection.
15:58:57 [JAllan]: +1 to require a history
15:59:26 [JAllan]: js: this belongs in understanding, more about correcting mistakes than being perceivable
15:59:51 [jeanne]: +1 to requiring a history
15:59:52 [mhakkinen]: +1
16:00:19 [Zakim]: -Mark
16:00:37 [mhakkinen]: back in 5
16:00:55 [JAllan]: gl: craft language for history where it applies for UAs that render discrete documents
16:01:33 [JAllan]: ... 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 [JAllan]: kp: use case: cognitive issue, if you loose your place, should be able to return to a known state.
16:02:37 [JAllan]: kf: editors have undo because they are destructive actions.
16:02:55 [JAllan]: ... undo search should be AA or AAA
16:03:42 [JAllan]: js: all undo actions are in GL 3
16:04:22 [JAllan]: gl: two levels of history, back and forward button, and a list of previous pages
16:05:01 [JAllan]: 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 [JAllan]: 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 [JAllan]: jim's attempt
16:11:21 [JAllan]: 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 [Kim]: 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 [Kim]: ...selection.
16:12:31 [jeanne]: 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 [Zakim]: +??P17
16:13:19 [jeanne]: 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 [JAllan]: zakim, P17 is really Mark
16:13:32 [Zakim]: sorry, JAllan, I do not recognize a party named 'P17'
16:13:40 [JAllan]: zakim, ??P17 is really Mark
16:13:40 [Zakim]: +Mark; got it
16:13:59 [Greg]: Greg has joined #ua
16:14:31 [jeanne]: 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 [Greg]: rsagent, make minutes
16:14:56 [jeanne]: rssagent, make minutes
16:15:16 [jeanne]: rrsagent, make minutes
16:15:16 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html jeanne
16:17:39 [Greg]: 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 [Greg]: I would have said "and have the such and so restored".
16:18:37 [jeanne]: 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 [jeanne]: 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 [Greg]: +1
16:19:29 [JAllan]: +12
16:19:30 [mhakkinen]: +1
16:19:32 [jeanne]: 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 [Jan]: +1
16:20:03 [Kim]: +1
16:20:03 [jeanne]: 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 [mhakkinen]: (e.g., via a back button) ?
16:21:38 [JAllan]: should be level A, current UA behavior, has been level A since UAAG 10
16:22:24 [JAllan]: ... user would have to perform lots of tasks to return to a previous state
16:22:26 [JAllan]: Resolution: 1.8.5 is completed!!!
16:24:02 [jeanne]: http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html
16:25:28 [JAllan]: 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 [JAllan]: kf: 2nd sentence should be Intent
16:27:10 [Greg]: If we take out the 2nd sentence, can we modify the first to say ""with an explicit user request or confirmation"?
16:28:26 [Greg]: Thus: The user has the option of having "top-level" viewports (e.g., windows) with an explicit user request or confirmation.
16:28:47 [Greg]: I don't think we elsewhere put top-level in quotes.
16:29:08 [Greg]: 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 [Greg]: The user has the option of having top-level viewports (e.g. windows) open with an explicit user request or confirmation.
16:30:33 [JAllan]: gl: is a tab a top level window
16:30:47 [Greg]: 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 [JAllan]: kp: should put 'tab' in also
16:31:08 [JAllan]: jr: only with explicit user request
16:31:09 [Greg]: 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 [Greg]: 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 [Greg]: 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 [JAllan]: kf: it is so disruptive, should be A
16:33:15 [JAllan]: kp, mh, ja +1
16:33:44 [JAllan]: gl: also disruptive to have to keep confirming open new window.
16:34:42 [JAllan]: mh: implementation - usability of having a global setting to toggle opening new windows
16:34:49 [Greg]: 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 [JAllan]: js: this seems redundant, if you 'specify' implies a choice
16:35:34 [JAllan]: kp: gregs wording is more clear
16:36:07 [JAllan]: 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 [mhakkinen]: +1 to greg
16:36:26 [sharper]: +1
16:36:36 [Greg]: +1
16:36:43 [JAllan]: ja, kf, kp +1
16:36:44 [Kim]: +1
16:37:02 [Jan]: what's the final wording?
16:37:11 [Greg]: 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 [jeanne]: http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html
16:37:52 [Jan]: +1
16:39:11 [Greg]: 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 [JAllan]: resolution: 1.8.6 is complete!!!
16:40:12 [JAllan]: 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 [Kim]: 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 [mhakkinen]: tabs, also
16:43:04 [Kim]: 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 [JAllan]: ... tabs not necessary if only talking about viewports
16:43:53 [kford]: Scribe: KFORD
16:44:01 [kford]: Scribe: kford
16:44:39 [Kim]: 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 [kford]: KF: If we are defining are refering to viewports, the language should be identical.
16:45:30 [kford]: rrsagent, make minutes
16:45:30 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html kford
16:45:43 [Kim]: 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 [Kim]: 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 [kford]: JS: We have a subtle change. I think originally itsiad it shouldn't take the keyboard focus.
16:46:56 [kford]: JS, now it is a user option.
16:47:12 [kford]: KF: I'm fine with this.
16:47:19 [kford]: JS: It is more coding.
16:48:27 [Kim]: 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 [mhakkinen]: If new top-level...
16:50:09 [kford]: Group discussion if this is global or not. People hearing it different ways.
16:50:54 [Kim]: 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 [mhakkinen]: 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 [jeanne]: +1
16:51:20 [Greg]: In the previous SC we used "request or confirmation".
16:53:34 [Greg]: That was because the UAAG1 version explicitly said confirmation was an acceptable alternative to explicit request.
16:54:08 [Greg]: We can take it out of both or leave it in both.
16:54:41 [Greg]: 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 [mhakkinen]: +1
16:56:18 [JAllan]: kp: top level opens without request or confirmation, the user need to be able confirm focus change
16:57:09 [Kim]: 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 [JAllan]: resolution: 1.8.7 is completed!!
16:58:10 [Greg]: +1
16:58:45 [Greg]: The first half is plural and second half is singular.
16:59:23 [Kim]: 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 [mhakkinen]: new is missing?
17:00:39 [Greg]: 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 [JAllan]: 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 [Kim]: 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 [JAllan]: gl: what's the point
17:03:44 [Greg]: I have concerns about this. What's the goal?
17:04:09 [JAllan]: gl: use case?
17:04:10 [Greg]: Can you provide use-case scenarios?
17:04:41 [JAllan]: jr: in x-window you can have an active window be behind other windows
17:04:56 [Greg]: I worry about conflict with "always-on-top" windows such as used by assistive technology (e.g. on-screen keyboards).
17:04:58 [JAllan]: kf: some application have option to stay on top
17:05:22 [JAllan]: ja: task manager
17:06:57 [JAllan]: jr: giving examples of when active window is not on top
17:08:41 [JAllan]: gl: this is not about stealing focus
17:09:09 [JAllan]: gl: don't see need for it
17:09:31 [JAllan]: kp: if you have a macro that does three things, and in the middle the focus changes
17:09:55 [JAllan]: jr: this doesn't have anything to do with focus change.
17:10:19 [JAllan]: js: intent and examples, talk about top window.
17:10:24 [JAllan]: kf: remove
17:10:46 [JAllan]: ja, kp, mh, js, jr +1
17:11:15 [Greg]: +1
17:11:20 [JAllan]: resolution: 1.8.8 is removed and completed!!
17:11:55 [JAllan]: 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 [Jan]: +1 to rem the 1.8.9 note
17:14:21 [JAllan]: gl: move last sentence of example to intent
17:14:48 [JAllan]: ... use case: ad popup with no close function
17:15:06 [Greg]: 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 [mhakkinen]: +1 to remove the note
17:15:18 [JAllan]: +1 to mark
17:15:21 [Greg]: +1
17:15:34 [JAllan]: resolution: 1.8.9 completed!!
17:15:54 [JAllan]: 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 [JAllan]: 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 [Greg]: Isn't a dialog box a new top-level viewport?
17:17:41 [JAllan]: jr: viewports are what the UA uses to render content
17:17:52 [Greg]: That is, an author-created dialog box written in HTML and launched by a script.
17:18:24 [Jan]: "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 [jeanne]: 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 [Greg]: 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 [JAllan]: 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 [Greg]: 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 [JAllan]: ja: user should have option of full chrome or what the author coded
17:24:22 [Greg]: 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 [jeanne]: 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 [Jan]: 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 [JAllan]: kp: example - user has cognitive issues, always wants an limited UI
17:26:25 [JAllan]: ... all windows should have limited UI
17:26:48 [Jan]: 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 [Greg]: +1
17:27:15 [JAllan]: +1 all
17:27:36 [JAllan]: resolution: 1.8.10 compeleted!!!
17:28:10 [JAllan]: 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 [JAllan]: gl: this is good. put eg in example or intent. substitute 'scroll bars'
17:37:09 [Greg]: I'm not sure how this would apply in a purely audio-output UI.
17:38:25 [JAllan]: ... example, listening to 1 hr audio, does the player have to always tell the user
17:38:55 [JAllan]: kf: if on telephone, listening to web page, how does it indicate where you are on the page
17:38:55 [Jan]: 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 [Greg]: 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 [Greg]: Another approach would be to limit this to visual displays.
17:40:02 [kford]: In the audio only case, you'd want this available likely only on request.
17:40:14 [mhakkinen]: +1 to Jan (and make it an A)
17:41:30 [Greg]: 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 [JAllan]: kf: +1 to Jan
17:41:50 [Jan]: 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 [jeanne]: 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 [JAllan]: discussion of Level
17:44:14 [JAllan]: kf: every UA today does this
17:45:07 [Greg]: 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 [Greg]: "can determine which portion of a viewport's content is currently visible"?
17:48:12 [mhakkinen]: Viewport View Position?
17:48:40 [kford]: 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 [JAllan]: jr: viewport is like a portal on a ship, what you see, is a small portion of the whole scene
17:49:05 [kford]: How about this:
17:49:07 [kford]: Indicate content positionThe user can determine the content's position relative to the total content available in the viewport.
17:50:02 [Greg]: "can determine which portion of the content is currently visible in the viewport"
17:50:18 [JAllan]: The user can determine the content's position in the viewport relative to the total content available.
17:51:14 [Jan]: 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 [Greg]: 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 [Greg]: that's the ambiguity of the phrase "viewport's position".
17:53:02 [Greg]: That's why I would favor saying "the portion of the content being rendered in the viewport (DIV)"
17:53:36 [JAllan]: kf: jan's text is good, should move on
17:53:39 [Greg]: My concern is purely about the wording not the intent.
17:54:01 [JAllan]: 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 [Jan]: +1
17:54:13 [JAllan]: +1
17:54:15 [Kim]: +1
17:54:16 [kford]: +1
17:54:17 [sharper]: +1
17:54:19 [mhakkinen]: +1
17:54:20 [Greg]: +1
17:54:23 [jeanne]: +1
17:54:45 [JAllan]: resolution: 1.8.11 completed!!
17:55:00 [JAllan]: kp: need scroll bars in the intent
17:55:19 [kford]: 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 [JAllan]: 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 [JAllan]: kp: need to have all of the intents for 1.9 done before we smith the SC
17:59:22 [JAllan]: resolution: skipping 1.9 until all 'intent's are completed, moving to 1.10
18:00:30 [JAllan]: gl: should we have upshot for all GK
18:01:07 [JAllan]: topic: 1.10.1Text View: For content authored in text formats, a view of the text source is provided. (Level A)
18:01:53 [jeanne]: For content authored in text formats, the user can view of the text source. (Level A)
18:02:04 [JAllan]: The user can view of the text source for content authored in text formats.
18:02:30 [jeanne]: The user can view the text source of content authored in text formats.
18:02:37 [JAllan]: +1
18:03:44 [JAllan]: kf: what about flash
18:04:25 [JAllan]: jr: level A, for whom is this an accessibility barrier
18:04:37 [JAllan]: gl: reads the intent
18:04:46 [mhakkinen]: is SVG another case?
18:05:17 [Greg]: Jan suggests it's not Level A; would not fail as UA just for lacking this.
18:05:39 [JAllan]: kf: this is useless as written. we don't define what you want...runtime source vs what is in the dom
18:05:58 [JAllan]: jr: javascript source vs rendered source
18:06:30 [JAllan]: kf: leave it in, we understand conceptually. demote to level AA
18:06:36 [Greg]: 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 [JAllan]: js: make it easier for Flash
18:08:24 [JAllan]: gl: is flash written in text?
18:08:40 [JAllan]: js: viewing source would be useful
18:09:03 [JAllan]: mh: could be compiled code, no source
18:09:22 [JAllan]: kf: AAA
18:09:28 [JAllan]: js: +1
18:09:31 [Jan]: JR: AAA
18:09:37 [JAllan]: mh: AAA
18:09:46 [JAllan]: ja: AAA
18:10:12 [JAllan]: gl: say text source is available
18:10:20 [Greg]: Could say that if the text source is available to the user agent, it makes it avialable to the user.
18:11:40 [Greg]: The user can access text source that is available to the user agent
18:12:00 [jeanne]: If text source of content is available to the user agent, the user can access that text source.
18:12:35 [Greg]: or, The user can access text all source that is available to the user agent
18:12:58 [Greg]: The user can access all text source that is available to the user agent
18:14:11 [JAllan]: kp: text is ultimate fall back.
18:14:19 [JAllan]: kf: should be AAA
18:14:59 [JAllan]: ... if trying to solve an accessibility problem, source is last resort, and very difficult
18:15:21 [mhakkinen]: +1 to gl's comment
18:16:36 [Greg]: 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 [JAllan]: ja: this is last resort, is it the lowest priority to have the last resort
18:18:24 [JAllan]: kp: having a last resort is essential, which last resort is a different question
18:18:48 [JAllan]: compromise on AA all agree
18:19:11 [JAllan]: resolution: 1.10.1 at AA with new wording is completed!!
18:19:21 [jeanne]: rrsagent, make minutes
18:19:21 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html jeanne
18:19:29 [JAllan]: 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 [JAllan]: kp: very clear
18:20:35 [JAllan]: kf: who does this
18:20:42 [JAllan]: js: amaya
18:20:51 [JAllan]: gl: ff has an extension
18:20:52 [Greg]: Firefox does it with a popular extension.
18:21:06 [Greg]: (called HeadingsMap)
18:22:16 [JAllan]: gl: this is important for understanding. outline should be navigable
18:23:07 [JAllan]: https://addons.mozilla.org/en-US/firefox/addon/7203/
18:23:29 [JAllan]: kf: opera allows navigating by headings
18:24:00 [JAllan]: resolution: 1.10.2 is completed!!
18:24:22 [JAllan]: 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 [Greg]: (I would like to see 1.10.2 be Level A.)
18:25:21 [JAllan]: gl: note in 1.10.2 should reference 1.10.3
18:26:37 [jeanne]: http://www.w3.org/Amaya/
18:26:54 [JAllan]: gl: this wording is incorrect. searching for new wording
18:28:34 [kford]: 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 [JAllan]: +1
18:29:20 [JAllan]: kf: +1
18:29:25 [Jan]: Jan has joined #ua
18:29:29 [Greg]: The Note for 1.10.2 should reference 1.10.3.
18:29:43 [JAllan]: kf: this is specifics of complying with 10.2
18:31:15 [JAllan]: ja: in June Draft 10.3 was AAA, now is AA
18:35:02 [JAllan]: gl: where does the current 10.3 language come from
18:35:30 [kford]: So, the new 1.10.3should be based off the text I pasted here.
18:35:53 [sharper]: this as Action http://www.w3.org/WAI/UA/tracker/actions/406
18:37:36 [JAllan]: 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 [JAllan]: kp and js: smithing
18:38:27 [JAllan]: gl: +1
18:38:29 [Kim]: 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 [sharper]: +1
18:38:57 [Greg]: 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 [JAllan]: gl: outline vs hierarchical view in 10.2 and 10.3 should be parallel
18:40:04 [JAllan]: Resolution: 1.10.3 is completed at AAA!!
18:40:31 [JAllan]: topic: reopen 1.10.2
18:40:39 [JAllan]: reviewing wording changes
18:40:50 [JAllan]: 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 [JAllan]: 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 [Greg]: 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 [JAllan]: sh: latter, look at visually, implied relationship, but not related to how they are related by position in the DOM
18:43:03 [JAllan]: kf: is it possible we want 2 SC here
18:43:22 [Greg]: 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 [JAllan]: ...one for hierarchy, one for relationship (proximity)
18:43:49 [jeanne]: 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 [jeanne]: and appearance). (Level AAA)
18:44:14 [jeanne]: 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 [JAllan]: jr: could be useful to have 2 SC, relationship view could be regular view
18:44:44 [JAllan]: mh: this seems to be a repair technique. references WCAG2, dom logical order
18:45:25 [JAllan]: jr: +1 to mh, yes repair. when logical labels or semantics are missing then use presentational information
18:45:41 [JAllan]: ... to create hierarchy
18:46:10 [JAllan]: ... this should be in implementing as a repair example
18:46:52 [JAllan]: jr: not implementing, but a new SC (1.2.3)
18:47:56 [JAllan]: 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 [trackbot]: 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 [Zakim]: -Mark
18:49:02 [JAllan]: **** lunch break ****
18:49:08 [JAllan]: rrsagent, make minutes
18:49:08 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html JAllan
18:49:59 [Zakim]: - +1.512.206.aaaa
18:51:57 [Jan]: 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 [Zakim]: -[Microsoft]
19:08:42 [Zakim]: +[Microsoft]
19:08:50 [Zakim]: -MIT262
19:10:20 [Zakim]: +MIT262
19:13:06 [Zakim]: + +1.512.206.aabb
19:13:21 [JAllan]: zakim, aabb is really jallan
19:13:21 [Zakim]: +jallan; got it
19:27:19 [user_]: user_ has joined #ua
19:29:07 [JAllan]: jr: this is recasting 10.3, moving it as a repair item
19:29:36 [JAllan]: ... this is like screen scraping -- finding form labels by proximity
19:29:54 [JAllan]: ... lots of missing structure in the wild.
19:30:11 [JAllan]: ... this is difficult to implement by UA developers
19:30:16 [Mark_mobile]: Mark_mobile has joined #ua
19:30:59 [JAllan]: gl: confused that it has morphed form a hierarchical view, to relationships
19:31:06 [JAllan]: ... looking for use cases
19:31:51 [JAllan]: jr: took 1.10.3 "implied by author-specified presentation attributes (i.e. position and appearance)" to characterize as a repair.
19:32:48 [JAllan]: ... this would inform the 'outline' in 1.10.2
19:33:31 [JAllan]: gl: would an outline view show form labels?
19:33:50 [Greg]: I don't think of document maps or outline views as showing labels for controls, only for larger groupings like forms.
19:34:11 [JAllan]: kf: would depend..., normally outline is html headings. but user could configure the important element to show in outline
19:34:49 [JAllan]: ... screen readers do this already, show headings, forms, tables, etc
19:35:22 [Greg]: So I'd think repairing missing labels for controls would benefit AT users, but not other users.
19:36:46 [JAllan]: jr: how is this testable, how do we do this.
19:40:32 [Greg]: When it's only for AT, can the UA do a better job of applying these heuristics than AT could?
19:40:32 [JAllan]: kf: think we need this as a repair as an AA or AAA
19:41:37 [JAllan]: ... 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 [JAllan]: kf: calls question
19:41:51 [JAllan]: js +1
19:41:54 [JAllan]: ja +1
19:41:58 [Jan]: +1
19:41:59 [sharper]: +1
19:42:14 [Mark_mobile]: would important elements include non-importants with imp aria roles?
19:42:18 [Kim]: +1
19:42:42 [Mark_mobile]: (waiting for my check ... back soon)
19:42:49 [Greg]: +1
19:43:03 [JAllan]: kf: need to make sure glossary reflects aria important elements
19:43:39 [Mark_mobile]: I think +1 for me ... seeing only irc
19:43:56 [JAllan]: 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 [Zakim]: -Jan
19:44:11 [Jan]: doh!
19:44:23 [JAllan]: topic: 1.11.1 Basic Link Information: The following information is provided for each link (Level A)
19:44:49 [JAllan]: link element content, new viewport (whether the author has specified that the resource will open in a new viewport)
19:45:19 [Mark_mobile]: on 1.11.1 and .2 i have question about rel and ref if present on link
19:45:47 [Zakim]: +??P1
19:46:04 [Jan]: zakim, ??P1 is really Jan
19:46:04 [Zakim]: +Jan; got it
19:49:46 [Greg]: 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 [JAllan]: kf: do UA tell users about opening in a new window now.
19:53:21 [JAllan]: ja: no, this is overlap with WCAG. so authors don't have to inform users.
19:53:48 [JAllan]: gl: is the guideline about telling the AT or the user.
19:53:52 [JAllan]: ja: user
19:54:02 [JAllan]: js: user
19:54:20 [JAllan]: gl: if it is just AT, it is programmatic, and should be moved
19:55:40 [JAllan]: jr: this may not be necessary, see viewport SC we just did.
19:55:50 [Greg]: 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 [JAllan]: kf: why do we need this. what is the accessibility reason.
19:57:08 [Zakim]: +??P3
19:57:35 [JAllan]: jr: this should be covered in configuration of viewports above.
19:57:35 [Greg]: 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 [mhakkinen]: zakim, ?PP3 is really Mark
19:57:43 [Zakim]: sorry, mhakkinen, I do not recognize a party named '?PP3'
19:57:55 [mhakkinen]: zakim, ?P3 is really Mark
19:57:55 [Zakim]: sorry, mhakkinen, I do not recognize a party named '?P3'
19:58:11 [mhakkinen]: zakim, ??P3 is really Mark
19:58:11 [Zakim]: +Mark; got it
19:58:42 [JAllan]: kf: what if the content is buttons, or checkbox, silverlight
20:00:46 [JAllan]: gl: lean toward providing this information to the user, except technology type. not sure knowing something is a PDF is important.
20:01:29 [JAllan]: sh: isn't this other information alternative content.
20:01:43 [JAllan]: kf: how to resolve 1.11.1
20:01:54 [Greg]: 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 [JAllan]: kf: inclined to delete 1.11.1
20:04:05 [JAllan]: jr: opening a new viewport, is covered on warning side
20:05:13 [JAllan]: 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 [JAllan]: kf: you know is is going to open, you can already configure if things open in a new window.
20:06:58 [JAllan]: kp: link title is important.
20:07:28 [JAllan]: ja: shouldn't this be covered by title working from the keyboard
20:07:53 [Greg]: 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 [JAllan]: kp: is there a downside to someone opening flash but not being able to
20:10:01 [JAllan]: kf: not comfortable with 11.1
20:10:58 [sharper]: re title we but not filled in we could suggest they point to the title of the destination page
20:11:49 [JAllan]: kf: why should people with disabilities to get more information than every body else
20:12:09 [JAllan]: kp: it is a timing issue
20:13:22 [Greg]: 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 [JAllan]: Action: kelly to revise 1.11.1 and 1.11.2 make proposal to the group
20:14:22 [trackbot]: Sorry, couldn't find user - kelly
20:14:33 [JAllan]: Action: kf to revise 1.11.1 and 1.11.2 make proposal to the group
20:14:33 [trackbot]: Sorry, couldn't find user - kf
20:14:42 [JAllan]: Action: kford to revise 1.11.1 and 1.11.2 make proposal to the group
20:14:42 [trackbot]: Sorry, couldn't find user - kford
20:14:51 [JAllan]: Action: kellyford to revise 1.11.1 and 1.11.2 make proposal to the group
20:14:51 [trackbot]: Sorry, couldn't find user - kellyford
20:16:56 [JAllan]: Action: ja to revise 1.11.1 and 1.11.2 make proposal to the group
20:16:56 [trackbot]: 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 [JAllan]: resolution: Kelly revising 1.11.1 and 1.11.2
20:18:22 [JAllan]: 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 [JAllan]: ja: should swap 3.1.1 and 3.1.2 so the Level A's are in order
20:21:28 [JAllan]: kp: what is definition of non-essential or low priority?
20:22:00 [JAllan]: kf: isn't the covered by support accessibility features of supported technologies
20:22:32 [JAllan]: kf: is this too specific to ARIA
20:23:48 [Greg]: This is going beyond supporting ARIA polite, saying not just "don't interrupt me" but "don't show it at all".
20:23:53 [sharper]: scribe: Harper_Simon
20:23:54 [sharper]: ScribeNick: sharper
20:24:16 [sharper]: gl: this is saying going beyond
20:24:23 [sharper]: kp: important for RSI users
20:24:54 [sharper]: GL: Seems to be going beyond to me
20:25:44 [sharper]: 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 [Jan]: FIY from ARIA: http://www.w3.org/TR/wai-aria/states_and_properties#aria-live
20:26:05 [sharper]: JS: to broad as it is - low priority interrupt.
20:26:16 [sharper]: s/to/too
20:26:42 [Greg]: 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 [Greg]: s/by/from/
20:28:34 [sharper]: JR: We are going to say that the UA knows better than the Author - what if low priority but important
20:30:54 [Greg]: 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 [sharper]: All: discussion as to the ability to switch off updates - or - assume author knows best
20:34:49 [Greg]: 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 [JAllan]: http://lists.w3.org/Archives/Public/w3c-wai-ua/2010OctDec/0050.html
20:36:24 [JAllan]: 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 [sharper]: Action: jAllan to kFord to clean up 3.1.2 and further investigating wording
20:39:33 [trackbot]: Created ACTION-468 - KFord to clean up 3.1.2 and further investigating wording [on Jim Allan - due 2010-11-17].
20:40:05 [sharper]: topic: 3.1.1 (former 5.1.2) Retrieval Progress: Show the progress of content retrieval. (Level A)
20:40:10 [JAllan]: +1
20:40:30 [sharper]: +1
20:40:35 [jeanne]: I like it +1
20:40:42 [mhakkinen]: +1
20:40:49 [Greg]: 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 [jeanne]: http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html
20:41:21 [Greg]: 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 [sharper]: JR: not sure this is teh right place for it - but like the SC
20:41:42 [sharper]: s/teh/the
20:42:11 [sharper]: JS: section 2 under Operating?
20:43:44 [sharper]: JS could be 2.3 - as this is about time based aspects
20:44:47 [Greg]: 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 [Greg]: 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 [Greg]: 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 [Greg]: 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 [jeanne]: zakim, who is making noise?
20:48:08 [Zakim]: jeanne, listening for 10 seconds I heard sound from the following: MIT262 (10%), [Microsoft] (68%)
20:49:51 [Greg]: Kim would prefer the user be able to re-enable individual messages or categories, rather than just re-enabling all messages.
20:50:57 [Greg]: 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 [sharper]: RESOLVED: JS Added an Editors' Note to revisit this at 3.1
20:52:02 [jeanne]: rrsagent, make minutes
20:52:02 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html jeanne
20:52:38 [Greg]: Guideline 3.2 (former 5.2) "Help users avoid and correct mistakes" lacks the SC about Undo.
20:52:44 [sharper]: 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 [sharper]: KF: don't we have a key binding guideline already?
20:56:54 [JAllan]: undo http://www.w3.org/WAI/UA/tracker/issues/59/edit
20:58:05 [JAllan]: http://www.w3.org/2009/11/06-ua-minutes#item05
20:58:58 [sharper]: 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 [trackbot]: 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 [Zakim]: -SHarper
21:00:00 [JAllan]: scribe: jallan
21:02:04 [JAllan]: gl: the enter key is provided by the UA and it submits the form, it is a feature
21:03:19 [JAllan]: gl: the SC 2.1.2 (former 2.1.4) talks about key bindings, and should cover the submitting for forms
21:03:25 [Greg]: 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 [JAllan]: kp: need to include enter/submit on forms on 2.1.2
21:05:07 [JAllan]: kf: no UAs do this now
21:07:04 [JAllan]: kf: is this a problem
21:07:44 [JAllan]: kp: form submission cause problems, more often submit when they don't want to.
21:08:14 [Greg]: 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 [JAllan]: jr: what about just requiring confirmation of form submission
21:09:00 [JAllan]: mh: how many different ways are there to submit a form
21:09:35 [JAllan]: ... most forms submissions are probably javascript and would not be recognized
21:09:48 [JAllan]: js: need to link this with 2.1
21:10:45 [Greg]: Might be 2.1.10 instead of 2.1.2; needs checking.
21:10:52 [Jan]: 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 [Zakim]: -jallan
21:11:22 [Greg]: +1
21:12:10 [Greg]: General agreement that most pages moving away from using submit buttons that the UA can recognize; most using scripted elements.
21:13:17 [kford]: Scribe: KFord
21:13:30 [kford]: KF: What are we doing here, do we need this or kick it out?
21:14:08 [mhakkinen]: 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 [kford]: GL: I think Jan's is better but agree that these are of limited use given the changes of web pages.
21:14:35 [Jan]: JAllan should I add you?
21:15:31 [Jan]: Jim can you hear?
21:16:26 [kford]: 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 [Greg]: "The user can specify that all form submissions made using recognized submission controls require confirmation"
21:18:34 [mhakkinen]: +1
21:18:40 [Kim]: +1
21:19:14 [JAllan]: +1
21:19:22 [Greg]: 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 [JAllan]: Resolution: 3.2.1 is completed. need revision of intent and examples to match new wording
21:20:26 [kford]: Resolution: 3.2.1 using updated text.
21:20:34 [kford]: rrsagent, make minutes
21:20:34 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html kford
21:20:55 [Greg]: Will someone take the task of adding an example about form submission to 2.1.10 or 2.1.2?
21:21:46 [JAllan]: scribe: jallan
21:22:31 [JAllan]: discussion of keybindings, and enter is platform behavior
21:23:43 [JAllan]: 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 [JAllan]: gl: missing Level A
21:23:53 [Greg]: 3.3.1 should be listed as Level A.
21:23:59 [JAllan]: js: fixed
21:24:16 [JAllan]: +1 to current wording
21:25:18 [JAllan]: jr: conformation claims are optional in ATAG
21:25:52 [Jan]: brb
21:25:57 [JAllan]: ...features required to meet ATAG must confom(not sure I heard that right)
21:26:16 [JAllan]: did we close 3.3.1???
21:28:03 [JAllan]: resolution: 3.3.1 is completed!!!
21:28:39 [JAllan]: topic: 3.3.2 Document Accessibility Features: All user agent features that benefit accessibility
21:28:58 [JAllan]: discussion of definition of conformance claims.
21:29:15 [Zakim]: -Mark
21:29:26 [Greg]: We noted need to provide definition of accessibility features as those that contribute to conforming with UAAG.
21:33:23 [JAllan]: zakim, call allanj
21:33:23 [Zakim]: I am sorry, JAllan; I do not know a number for allanj
21:34:52 [Zakim]: -[Microsoft]
21:35:27 [jeanne]: zakim, is there room for 4 now?
21:35:27 [Zakim]: I don't understand your question, jeanne.
21:35:56 [jeanne]: zakim, is there room for 4 today at 16:45?
21:35:56 [Zakim]: I don't understand your question, jeanne.
21:36:54 [jeanne]: zakim, do you have space for 4 people at 16:35P for 90 minutes?
21:36:56 [Zakim]: ok, jeanne; conference Team_(ua)21:35Z scheduled with code 82942 (uawg2) at 16:35 for 90 minutes until 2305Z
21:37:32 [Zakim]: -MIT262
21:37:32 [Greg]: 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 [Jan]: back
21:38:58 [Jan]: zakim, whos' here?
21:38:58 [Zakim]: I don't understand your question, Jan.
21:39:04 [Jan]: zakim, who's here?
21:39:04 [Zakim]: On the phone I see Jan
21:39:06 [Zakim]: On IRC I see Jan, Greg, kford, mhakkinen, Kim, jeanne, Zakim, RRSAgent, JAllan, trackbot
21:39:56 [Zakim]: -Jan
21:39:58 [Zakim]: WAI_(UAWG1)10:30AM has ended
21:40:00 [Zakim]: Attendees were [Microsoft], +1.512.206.aaaa, MIT262, SHarper, Mark, Jan, +1.512.206.aabb, jallan
21:41:48 [jeanne]: zakim, this is UAWG
21:41:48 [Zakim]: sorry, jeanne, I do not see a conference named 'UAWG' in progress or scheduled at this time
21:42:07 [jeanne]: rrsagent, make minutes
21:42:07 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html jeanne
21:43:30 [JAllan]: resolution: 3.3.2 is completed!!
21:43:42 [jeanne]: zakim, this is conference Team_(ua)
21:43:42 [Zakim]: sorry, jeanne, I do not see a conference named 'conference Team_(ua)' in progress or scheduled at this time
21:43:55 [JAllan]: 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 [Greg]: 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 [Greg]: We require apps to document accessibility FEATURES, but not limitations. That is very sad.
21:46:13 [JAllan]: gl: we don't say anywhere that features were removed
21:46:16 [Kim]: Changes to features that affect accessibility since the previous user agent release are documented.
21:48:34 [Jan]: Changes to features that benefit accessibility since the previous user agent release are documented.
21:49:41 [Greg]: Changes to features that benefit OR BENEFITED accessibility since the previous user agent release are documented.
21:50:27 [JAllan]: gl: does this require the announcement of things that were removed.
21:50:51 [JAllan]: kf: it changed they should document it...put it in intent
21:51:46 [Jan]: 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 [JAllan]: resolution: 3.3.3 is complete with new wording
21:52:05 [JAllan]: 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 [JAllan]: change to AAA
21:52:40 [JAllan]: resolution: 3.3.4 is complete with new level AAA!!!
21:52:53 [JAllan]: gl: do we have definition of documentation
21:52:56 [JAllan]: kp: yes
21:53:19 [JAllan]: 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 [JAllan]: +1
21:54:14 [JAllan]: resolution: 3.3.5 is completed!
21:54:39 [JAllan]: 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 [Greg]: The phrase "end user experience such as speech" is the same as "end user experience", so it applies to everything.
21:56:01 [JAllan]: jr: what does this mean.
21:57:41 [JAllan]: resolution: remove 3.3.6
21:58:49 [JAllan]: topic: 3.4.1 Control default focus: The user agent provides a mechanism for setting global configuration of default focus.
21:59:39 [JAllan]: js: should be reviewed in context of 1.9
22:00:18 [JAllan]: kf: GL 3 seems a bunch of shoe horning.
22:00:43 [JAllan]: js: we need an understanding section, for cognitive issues
22:01:28 [Greg]: Didn't we discuss a recommendation on autosummary, for example, which would fit under the Understandable section.
22:01:48 [JAllan]: kp: need to discuss intent of 1.9
22:06:50 [JAllan]: rrsagent, make minutes
22:06:50 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html JAllan
22:17:00 [JAllan]: zakim, please part
22:17:00 [Zakim]: Zakim has left #ua
22:17:13 [JAllan]: rrsagent, make minutes
22:17:13 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/11/10-ua-minutes.html JAllan
22:17:30 [JAllan]: rrsagent, please part
22:17:30 [RRSAgent]: I see 8 open action items saved in http://www.w3.org/2010/11/10-ua-actions.rdf :
22:17:30 [RRSAgent]: 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 [RRSAgent]: recorded in http://www.w3.org/2010/11/10-ua-irc#T18-47-56
22:17:30 [RRSAgent]: ACTION: kelly to revise 1.11.1 and 1.11.2 make proposal to the group [2]
22:17:30 [RRSAgent]: recorded in http://www.w3.org/2010/11/10-ua-irc#T20-14-22
22:17:30 [RRSAgent]: ACTION: kf to revise 1.11.1 and 1.11.2 make proposal to the group [3]
22:17:30 [RRSAgent]: recorded in http://www.w3.org/2010/11/10-ua-irc#T20-14-33
22:17:30 [RRSAgent]: ACTION: kford to revise 1.11.1 and 1.11.2 make proposal to the group [4]
22:17:30 [RRSAgent]: recorded in http://www.w3.org/2010/11/10-ua-irc#T20-14-42
22:17:30 [RRSAgent]: ACTION: kellyford to revise 1.11.1 and 1.11.2 make proposal to the group [5]
22:17:30 [RRSAgent]: recorded in http://www.w3.org/2010/11/10-ua-irc#T20-14-51
22:17:30 [RRSAgent]: ACTION: ja to revise 1.11.1 and 1.11.2 make proposal to the group [6]
22:17:30 [RRSAgent]: recorded in http://www.w3.org/2010/11/10-ua-irc#T20-16-56
22:17:30 [RRSAgent]: ACTION: jAllan to kFord to clean up 3.1.2 and further investigating wording [7]
22:17:30 [RRSAgent]: recorded in http://www.w3.org/2010/11/10-ua-irc#T20-39-33
22:17:30 [RRSAgent]: 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 [RRSAgent]: recorded in http://www.w3.org/2010/11/10-ua-irc#T20-58-58