W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2010

Minutes of the UAWG non-F2F Video conference of 10 November 2010

From: Jeanne Spellman <jeanne@w3.org>
Date: Wed, 10 Nov 2010 17:22:06 -0500
Message-ID: <4CDB1B0E.7020907@w3.org>
To: UAWG <w3c-wai-ua@w3.org>
Minutes:
http://www.w3.org/2010/11/10-ua-minutes.html

IRC Log:
http://www.w3.org/2010/11/10-ua-irc

Summary of Action Items
[NEW] ACTION: Greg to think about UNDO ( 
http://www.w3.org/2009/11/06-ua-minutes#item05 ) and come up with some 
suggestions. [recorded in 
http://www.w3.org/2010/11/10-ua-minutes.html#action08]
[NEW] ACTION: ja to revise 1.11.1 and 1.11.2 make proposal to the group 
[recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action06]
[NEW] ACTION: jAllan to kFord to clean up 3.1.2 and further 
investigating wording [recorded in 
http://www.w3.org/2010/11/10-ua-minutes.html#action07]
[NEW] 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)." [recorded in 
http://www.w3.org/2010/11/10-ua-minutes.html#action01]
[NEW] ACTION: kelly to revise 1.11.1 and 1.11.2 make proposal to the 
group [recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action02]
[NEW] ACTION: kellyford to revise 1.11.1 and 1.11.2 make proposal to the 
group [recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action05]
[NEW] ACTION: kf to revise 1.11.1 and 1.11.2 make proposal to the group 
[recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action03]
[NEW] ACTION: kford to revise 1.11.1 and 1.11.2 make proposal to the 
group [recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action04]

Text of Minutes:

W3C
- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
10 Nov 2010

See also: IRC log
Attendees

Present
     [Microsoft], +1.512.206.aaaa, MIT262, SHarper, Mark, Jan, 
+1.512.206.aabb, jallan, Greg, Jim, Jeanne, Kim, Simon, Kelly
Regrets
Chair
     JAllan, KFord
Scribe
     jallan, KFORD, Harper_Simon

Contents

     * Topics
          1. 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...
          2. 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)
          3. 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)
          4. 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)
          5. 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.
          6. 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)
          7. 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)
          8. 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)
          9. 1.10.1Text View: For content authored in text formats, a 
view of the text source is provided. (Level A)
         10. 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)
         11. 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)
         12. reopen 1.10.2
         13. 1.11.1 Basic Link Information: The following information is 
provided for each link (Level A)
         14. 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)
         15. 3.1.1 (former 5.1.2) Retrieval Progress: Show the progress 
of content retrieval. (Level A)
         16. 3.2.1 (former 5.2.1) Form Submission: The user can redefine 
keyboard shortcuts for submitting and canceling recognized forms. (Level AA)
         17. 3.3.1 Accessible documentation: The product documentation 
is available in a format that conforms to WCAG 2.0 Level "A" or greater.
         18. 3.3.2 Document Accessibility Features: All user agent 
features that benefit accessibility
         19. 3.3.3 Changes Between Versions: Changes to features that 
affect accessibility since the previous version of the user agent are 
documented. (Level AA)
         20. 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. 3.3.5 Context Sensitive Help: There is context-sensitive 
help on all user agent features that benefit accessibility. (Level AAA)
         22. 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.
         23. 3.4.1 Control default focus: The user agent provides a 
mechanism for setting global configuration of default focus.
     * Summary of Action Items

<trackbot> Date: 10 November 2010

<JAllan> scribe: jallan

http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/

<jeanne> http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/

<jeanne> 
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html

<Jan> Lunch: 1:45 ET
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...

UNKNOWN_SPEAKER: saved values when the user returns to a state in the 
history.

ja: sounds more like an Intent

jr: there is a big out, if the UA doesn't provide a history they are 
free of this SC

<kford> JA: The real requirement is we want UA to maintain the state of 
all your control.

gl: do we want to require a history

jr: need be careful of web apps and dynamic states

gl: other than page navigation, how does this apply to real player.

jr: it is complicated. this SC is static oriented.

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...

scribe: the point of regard, content focus, and selection.

+1 to require a history

js: this belongs in understanding, more about correcting mistakes than 
being perceivable

<jeanne> +1 to requiring a history

<mhakkinen> +1

<mhakkinen> back in 5

gl: craft language for history where it applies for UAs that render 
discrete documents
... if in a long web page, search for 'hello' and jumps down the page, 
should user be able to go back to before search

kp: use case: cognitive issue, if you loose your place, should be able 
to return to a known state.

kf: editors have undo because they are destructive actions.
... undo search should be AA or AAA

js: all undo actions are in GL 3

gl: two levels of history, back and forward button, and a list of 
previous pages

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.

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.

jim's attempt

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.

<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...

<Kim> ...selection.

<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

<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

<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

<Greg> rsagent, make minutes

<jeanne> rssagent, make minutes

<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".

<Greg> I would have said "and have the such and so restored".

<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

<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

<Greg> +1

+12

<mhakkinen> +1

<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.

<Jan> +1

<Kim> +1

<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.

<mhakkinen> (e.g., via a back button) ?

should be level A, current UA behavior, has been level A since UAAG 10

scribe: user would have to perform lots of tasks to return to a previous 
state

Resolution: 1.8.5 is completed!!!

<jeanne> 
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html
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)

kf: 2nd sentence should be Intent

<Greg> If we take out the 2nd sentence, can we modify the first to say 
""with an explicit user request or confirmation"?

<Greg> Thus: The user has the option of having "top-level" viewports 
(e.g., windows) with an explicit user request or confirmation.

<Greg> I don't think we elsewhere put top-level in quotes.

<Greg> The user has the option of having top-level viewports (e.g. 
windows or tabs) with an explicit user request or confirmation.

<Greg> The user has the option of having top-level viewports (e.g. 
windows) open with an explicit user request or confirmation.

gl: is a tab a top level window

<Greg> The user has the option of having top-level viewports (e.g. 
windows or tabs) open with an explicit user request or confirmation.

kp: should put 'tab' in also

jr: only with explicit user request

<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.

<Greg> The user can specify that top-level viewports (e.g. windows or 
tabs) open only with an explicit user request or confirmation.

<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)

kf: it is so disruptive, should be A

kp, mh, ja +1

gl: also disruptive to have to keep confirming open new window.

mh: implementation - usability of having a global setting to toggle 
opening new windows

<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)

js: this seems redundant, if you 'specify' implies a choice

kp: gregs wording is more clear

gl: if we mean, turn on/off should have a word. used to use 'option' we 
are now using 'whether or not'

<mhakkinen> +1 to greg

<sharper> +1

<Greg> +1

ja, kf, kp +1

<Kim> +1

<Jan> what's the final wording?

<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)

<jeanne> 
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html

<Jan> +1

<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)

resolution: 1.8.6 is complete!!!
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)

<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

<mhakkinen> tabs, also

<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

UNKNOWN_SPEAKER: tabs not necessary if only talking about viewports

<kford> Scribe: KFORD

<scribe> Scribe: kford

<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

KF: If we are defining are refering to viewports, the language should be 
identical.

<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

<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

JS: We have a subtle change. I think originally itsiad it shouldn't take 
the keyboard focus.

JS, now it is a user option.

KF: I'm fine with this.

JS: It is more coding.

<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

<mhakkinen> If new top-level...

Group discussion if this is global or not. People hearing it different ways.

<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

<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

<jeanne> +1

<Greg> In the previous SC we used "request or confirmation".

<Greg> That was because the UAAG1 version explicitly said confirmation 
was an acceptable alternative to explicit request.

<Greg> We can take it out of both or leave it in both.

<Greg> UAAG1 said "open it with an explicit request (e.g., by confirming 
a prompt or following a link generated by the user agent)".

<mhakkinen> +1

<JAllan> kp: top level opens without request or confirmation, the user 
need to be able confirm focus change

<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

<JAllan> resolution: 1.8.7 is completed!!

<Greg> +1

<Greg> The first half is plural and second half is singular.

<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

<mhakkinen> new is missing?

<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.
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)

<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

<JAllan> gl: what's the point

<Greg> I have concerns about this. What's the goal?

<JAllan> gl: use case?

<Greg> Can you provide use-case scenarios?

<JAllan> jr: in x-window you can have an active window be behind other 
windows

<Greg> I worry about conflict with "always-on-top" windows such as used 
by assistive technology (e.g. on-screen keyboards).

<JAllan> kf: some application have option to stay on top

<JAllan> ja: task manager

<JAllan> jr: giving examples of when active window is not on top

<JAllan> gl: this is not about stealing focus

<JAllan> gl: don't see need for it

<JAllan> kp: if you have a macro that does three things, and in the 
middle the focus changes

<JAllan> jr: this doesn't have anything to do with focus change.

<JAllan> js: intent and examples, talk about top window.

<JAllan> kf: remove

<JAllan> ja, kp, mh, js, jr +1

<Greg> +1

<JAllan> resolution: 1.8.8 is removed and completed!!
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.

<Jan> +1 to rem the 1.8.9 note

<JAllan> gl: move last sentence of example to intent

<JAllan> ... use case: ad popup with no close function

<Greg> Suggested moving the last sentence of the example to the Intent, 
and adding an example of ad windows that hide controls for closingthem.

<mhakkinen> +1 to remove the note

<JAllan> +1 to mark

<Greg> +1

<JAllan> resolution: 1.8.9 completed!!

<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)
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)

<Greg> Isn't a dialog box a new top-level viewport?

<JAllan> jr: viewports are what the UA uses to render content

<Greg> That is, an author-created dialog box written in HTML and 
launched by a script.

<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. "

<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)

<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.

<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

<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.

<JAllan> ja: user should have option of full chrome or what the author coded

<Greg> Consider revisiting the definition of top-level window to make it 
clearly not apply to authored dialog boxes and authored status windows.

<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)

<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)

<JAllan> kp: example - user has cognitive issues, always wants an limited UI

<JAllan> ... all windows should have limited UI

<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)

<Greg> +1

<JAllan> +1 all

<JAllan> resolution: 1.8.10 compeleted!!!
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)

<JAllan> gl: this is good. put eg in example or intent. substitute 
'scroll bars'

<Greg> I'm not sure how this would apply in a purely audio-output UI.

<JAllan> ... example, listening to 1 hr audio, does the player have to 
always tell the user

<JAllan> kf: if on telephone, listening to web page, how does it 
indicate where you are on the page

<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)

<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!

<Greg> Another approach would be to limit this to visual displays.

In the audio only case, you'd want this available likely only on request.

<mhakkinen> +1 to Jan (and make it an A)

<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.

<JAllan> kf: +1 to Jan

<Jan> Indicate Viewport Position: The user can determine the viewport's 
position relative to the full extent of the rendered content. (Level AAA)

<jeanne> Indicate Viewport Position: The user can determine the 
viewport's position relative to the full extent of the rendered content. 
(Level AAA)

<JAllan> discussion of Level

<JAllan> kf: every UA today does this

<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.

<Greg> "can determine which portion of a viewport's content is currently 
visible"?

<mhakkinen> Viewport View Position?

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)

<JAllan> jr: viewport is like a portal on a ship, what you see, is a 
small portion of the whole scene

How about this:

Indicate content positionThe user can determine the content's position 
relative to the total content available in the viewport.

<Greg> "can determine which portion of the content is currently visible 
in the viewport"

<JAllan> The user can determine the content's position in the viewport 
relative to the total content available.

<Jan> Indicate Viewport Position: The user can determine the viewport's 
position relative to the full extent of the rendered content. (Level AAA)

<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

<Greg> that's the ambiguity of the phrase "viewport's position".

<Greg> That's why I would favor saying "the portion of the content being 
rendered in the viewport (DIV)"

<JAllan> kf: jan's text is good, should move on

<Greg> My concern is purely about the wording not the intent.

<JAllan> proposed Indicate Viewport Position: The user can determine the 
viewport's position relative to the full extent of the rendered content. 
(Level AA)

<Jan> +1

<JAllan> +1

<Kim> +1

+1

<sharper> +1

<mhakkinen> +1

<Greg> +1

<jeanne> +1

<JAllan> resolution: 1.8.11 completed!!

<JAllan> kp: need scroll bars in the intent

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.
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)

<JAllan> kp: need to have all of the intents for 1.9 done before we 
smith the SC

<JAllan> resolution: skipping 1.9 until all 'intent's are completed, 
moving to 1.10

<JAllan> gl: should we have upshot for all GK
1.10.1Text View: For content authored in text formats, a view of the 
text source is provided. (Level A)

<jeanne> For content authored in text formats, the user can view of the 
text source. (Level A)

<JAllan> The user can view of the text source for content authored in 
text formats.

<jeanne> The user can view the text source of content authored in text 
formats.

<JAllan> +1

<JAllan> kf: what about flash

<JAllan> jr: level A, for whom is this an accessibility barrier

<JAllan> gl: reads the intent

<mhakkinen> is SVG another case?

<Greg> Jan suggests it's not Level A; would not fail as UA just for 
lacking this.

<JAllan> kf: this is useless as written. we don't define what you 
want...runtime source vs what is in the dom

<JAllan> jr: javascript source vs rendered source

<JAllan> kf: leave it in, we understand conceptually. demote to level AA

<Greg> other issues might be DRM-protected source, or remote source such 
as PHP or ASP that is never sent to the UA.

<JAllan> js: make it easier for Flash

<JAllan> gl: is flash written in text?

<JAllan> js: viewing source would be useful

<JAllan> mh: could be compiled code, no source

<JAllan> kf: AAA

<JAllan> js: +1

<Jan> JR: AAA

<JAllan> mh: AAA

<JAllan> ja: AAA

<JAllan> gl: say text source is available

<Greg> Could say that if the text source is available to the user agent, 
it makes it avialable to the user.

<Greg> The user can access text source that is available to the user agent

<jeanne> If text source of content is available to the user agent, the 
user can access that text source.

<Greg> or, The user can access text all source that is available to the 
user agent

<Greg> The user can access all text source that is available to the user 
agent

<JAllan> kp: text is ultimate fall back.

<JAllan> kf: should be AAA

<JAllan> ... if trying to solve an accessibility problem, source is last 
resort, and very difficult

<mhakkinen> +1 to gl's comment

<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.

<JAllan> ja: this is last resort, is it the lowest priority to have the 
last resort

<JAllan> kp: having a last resort is essential, which last resort is a 
different question

<JAllan> compromise on AA all agree

<JAllan> resolution: 1.10.1 at AA with new wording is completed!!
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)

<JAllan> kp: very clear

<JAllan> kf: who does this

<JAllan> js: amaya

<JAllan> gl: ff has an extension

<Greg> Firefox does it with a popular extension.

<Greg> (called HeadingsMap)

<JAllan> gl: this is important for understanding. outline should be 
navigable

<JAllan> https://addons.mozilla.org/en-US/firefox/addon/7203/

<JAllan> kf: opera allows navigating by headings

<JAllan> resolution: 1.10.2 is completed!!
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)

<Greg> (I would like to see 1.10.2 be Level A.)

<JAllan> gl: note in 1.10.2 should reference 1.10.3

<jeanne> http://www.w3.org/Amaya/

<JAllan> gl: this wording is incorrect. searching for new wording

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)

<JAllan> +1

<JAllan> kf: +1

<Greg> The Note for 1.10.2 should reference 1.10.3.

<JAllan> kf: this is specifics of complying with 10.2

<JAllan> ja: in June Draft 10.3 was AAA, now is AA

<JAllan> gl: where does the current 10.3 language come from

So, the new 1.10.3should be based off the text I pasted here.

<sharper> this as Action http://www.w3.org/WAI/UA/tracker/actions/406

<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)

<JAllan> kp and js: smithing

<JAllan> gl: +1

<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)

<sharper> +1

<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.

<JAllan> gl: outline vs hierarchical view in 10.2 and 10.3 should be 
parallel

<JAllan> Resolution: 1.10.3 is completed at AAA!!
reopen 1.10.2

<JAllan> reviewing wording changes

<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)

<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).

<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)

<JAllan> sh: latter, look at visually, implied relationship, but not 
related to how they are related by position in the DOM

<JAllan> kf: is it possible we want 2 SC here

<Greg> So the easy one is an outline view of explicitly author-specified 
hierarchy (e.g. h1), whereas the latter is harder (heuristics).

<JAllan> ...one for hierarchy, one for relationship (proximity)

<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

<jeanne> and appearance). (Level AAA)

<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)

<JAllan> jr: could be useful to have 2 SC, relationship view could be 
regular view

<JAllan> mh: this seems to be a repair technique. references WCAG2, dom 
logical order

<JAllan> jr: +1 to mh, yes repair. when logical labels or semantics are 
missing then use presentational information

<JAllan> ... to create hierarchy

<JAllan> ... this should be in implementing as a repair example

<JAllan> jr: not implementing, but a new SC (1.2.3)

<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)." [recorded in 
http://www.w3.org/2010/11/10-ua-minutes.html#action01]

<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].

<JAllan> **** lunch break ****

<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)

<JAllan> jr: this is recasting 10.3, moving it as a repair item

<JAllan> ... this is like screen scraping -- finding form labels by 
proximity

<JAllan> ... lots of missing structure in the wild.

<JAllan> ... this is difficult to implement by UA developers

<JAllan> gl: confused that it has morphed form a hierarchical view, to 
relationships

<JAllan> ... looking for use cases

<JAllan> jr: took 1.10.3 "implied by author-specified presentation 
attributes (i.e. position and appearance)" to characterize as a repair.

<JAllan> ... this would inform the 'outline' in 1.10.2

<JAllan> gl: would an outline view show form labels?

<Greg> I don't think of document maps or outline views as showing labels 
for controls, only for larger groupings like forms.

<JAllan> kf: would depend..., normally outline is html headings. but 
user could configure the important element to show in outline

<JAllan> ... screen readers do this already, show headings, forms, 
tables, etc

<Greg> So I'd think repairing missing labels for controls would benefit 
AT users, but not other users.

<JAllan> jr: how is this testable, how do we do this.

<Greg> When it's only for AT, can the UA do a better job of applying 
these heuristics than AT could?

<JAllan> kf: think we need this as a repair as an AA or AAA

<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

<JAllan> kf: calls question

<JAllan> js +1

<JAllan> ja +1

<Jan> +1

<sharper> +1

<Mark_mobile> would important elements include non-importants with imp 
aria roles?

<Kim> +1

<Mark_mobile> (waiting for my check ... back soon)

<Greg> +1

<JAllan> kf: need to make sure glossary reflects aria important elements

<Mark_mobile> I think +1 for me ... seeing only irc

<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)

<Jan> doh!
1.11.1 Basic Link Information: The following information is provided for 
each link (Level A)

<JAllan> link element content, new viewport (whether the author has 
specified that the resource will open in a new viewport)

<Mark_mobile> on 1.11.1 and .2 i have question about rel and ref if 
present on link

<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)."

<JAllan> kf: do UA tell users about opening in a new window now.

<JAllan> ja: no, this is overlap with WCAG. so authors don't have to 
inform users.

<JAllan> gl: is the guideline about telling the AT or the user.

<JAllan> ja: user

<JAllan> js: user

<JAllan> gl: if it is just AT, it is programmatic, and should be moved

<JAllan> jr: this may not be necessary, see viewport SC we just did.

<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.

<JAllan> kf: why do we need this. what is the accessibility reason.

<JAllan> jr: this should be covered in configuration of viewports above.

<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).

<JAllan> kf: what if the content is buttons, or checkbox, silverlight

<JAllan> gl: lean toward providing this information to the user, except 
technology type. not sure knowing something is a PDF is important.

<JAllan> sh: isn't this other information alternative content.

<JAllan> kf: how to resolve 1.11.1

<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.

<JAllan> kf: inclined to delete 1.11.1

<JAllan> jr: opening a new viewport, is covered on warning side

<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.

<JAllan> kf: you know is is going to open, you can already configure if 
things open in a new window.

<JAllan> kp: link title is important.

<JAllan> ja: shouldn't this be covered by title working from the keyboard

<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.

<JAllan> kp: is there a downside to someone opening flash but not being 
able to

<JAllan> kf: not comfortable with 11.1

<sharper> re title we but not filled in we could suggest they point to 
the title of the destination page

<JAllan> kf: why should people with disabilities to get more information 
than every body else

<JAllan> kp: it is a timing issue

<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".

<JAllan> ACTION: kelly to revise 1.11.1 and 1.11.2 make proposal to the 
group [recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action02]

<trackbot> Sorry, couldn't find user - kelly

<JAllan> ACTION: kf to revise 1.11.1 and 1.11.2 make proposal to the 
group [recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action03]

<trackbot> Sorry, couldn't find user - kf

<JAllan> ACTION: kford to revise 1.11.1 and 1.11.2 make proposal to the 
group [recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action04]

<trackbot> Sorry, couldn't find user - kford

<JAllan> ACTION: kellyford to revise 1.11.1 and 1.11.2 make proposal to 
the group [recorded in 
http://www.w3.org/2010/11/10-ua-minutes.html#action05]

<trackbot> Sorry, couldn't find user - kellyford

<JAllan> ACTION: ja to revise 1.11.1 and 1.11.2 make proposal to the 
group [recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action06]

<trackbot> Created ACTION-467 - Revise 1.11.1 and 1.11.2 make proposal 
to the group [on Jim Allan - due 2010-11-17].

<JAllan> resolution: Kelly revising 1.11.1 and 1.11.2
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)

<JAllan> ja: should swap 3.1.1 and 3.1.2 so the Level A's are in order

<JAllan> kp: what is definition of non-essential or low priority?

<JAllan> kf: isn't the covered by support accessibility features of 
supported technologies

<JAllan> kf: is this too specific to ARIA

<Greg> This is going beyond supporting ARIA polite, saying not just 
"don't interrupt me" but "don't show it at all".

<sharper> scribe: Harper_Simon

<sharper> ScribeNick: sharper

gl: this is saying going beyond

kp: important for RSI users

GL: Seems to be going beyond to me

KF: Can live with it at the level it is - but then we say mark with 
'polite' we should add the work ARIA

<Jan> FIY from ARIA: 
http://www.w3.org/TR/wai-aria/states_and_properties#aria-live

JS: to broad as it is - low priority interrupt.

s/to/too

<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.

<Greg> s/by/from/

JR: We are going to say that the UA knows better than the Author - what 
if low priority but important

<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.

All: discussion as to the ability to switch off updates - or - assume 
author knows best

<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.

<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2010OctDec/0050.html

<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.

<scribe> ACTION: jAllan to kFord to clean up 3.1.2 and further 
investigating wording [recorded in 
http://www.w3.org/2010/11/10-ua-minutes.html#action07]

<trackbot> Created ACTION-468 - KFord to clean up 3.1.2 and further 
investigating wording [on Jim Allan - due 2010-11-17].
3.1.1 (former 5.1.2) Retrieval Progress: Show the progress of content 
retrieval. (Level A)

<JAllan> +1

+1

<jeanne> I like it +1

<mhakkinen> +1

<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."

<jeanne> 
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101109/MasterUAAG20101109.html

<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.

JR: not sure this is teh right place for it - but like the SC

s/teh/the

JS: section 2 under Operating?

JS could be 2.3 - as this is about time based aspects

<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.

<Greg> We could consider adding to this section a recommendation that 
messages have a checkbox that lets the user avoid getting the message again.

<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

<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.

<Greg> Kim would prefer the user be able to re-enable individual 
messages or categories, rather than just re-enabling all messages.

<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.

RESOLUTION: JS Added an Editors' Note to revisit this at 3.1

<Greg> Guideline 3.2 (former 5.2) "Help users avoid and correct 
mistakes" lacks the SC about Undo.
3.2.1 (former 5.2.1) Form Submission: The user can redefine keyboard 
shortcuts for submitting and canceling recognized forms. (Level AA)

KF: don't we have a key binding guideline already?

<JAllan> undo http://www.w3.org/WAI/UA/tracker/issues/59/edit

<JAllan> http://www.w3.org/2009/11/06-ua-minutes#item05

<scribe> ACTION: Greg to think about UNDO ( 
http://www.w3.org/2009/11/06-ua-minutes#item05 ) and come up with some 
suggestions. [recorded in 
http://www.w3.org/2010/11/10-ua-minutes.html#action08]

<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].

<JAllan> scribe: jallan

gl: the enter key is provided by the UA and it submits the form, it is a 
feature
... the SC 2.1.2 (former 2.1.4) talks about key bindings, and should 
cover the submitting for forms

<Greg> 2.1.2 and 2.1.10 are both about changing keyboard bindings; 2.1.2 
seems to cover remapping the submit key.

kp: need to include enter/submit on forms on 2.1.2

kf: no UAs do this now
... is this a problem

kp: form submission cause problems, more often submit when they don't 
want to.

<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.

jr: what about just requiring confirmation of form submission

mh: how many different ways are there to submit a form
... most forms submissions are probably javascript and would not be 
recognized

js: need to link this with 2.1

<Greg> Might be 2.1.10 instead of 2.1.2; needs checking.

<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)

<Greg> +1

<Greg> General agreement that most pages moving away from using submit 
buttons that the UA can recognize; most using scripted elements.

<kford> Scribe: KFord

KF: What are we doing here, do we need this or kick it out?

<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.

GL: I think Jan's is better but agree that these are of limited use 
given the changes of web pages.

<Jan> JAllan should I add you?

<Jan> Jim can you hear?

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.

<Greg> "The user can specify that all form submissions made using 
recognized submission controls require confirmation"

<mhakkinen> +1

<Kim> +1

<JAllan> +1

<Greg> Jan's original wording of "The user can specify whether or not 
recognized form submissions must be confirmed" was at least as good.

<JAllan> Resolution: 3.2.1 is completed. need revision of intent and 
examples to match new wording

Resolution: 3.2.1 using updated text.

<Greg> Will someone take the task of adding an example about form 
submission to 2.1.10 or 2.1.2?

<JAllan> scribe: jallan

discussion of keybindings, and enter is platform behavior
3.3.1 Accessible documentation: The product documentation is available 
in a format that conforms to WCAG 2.0 Level "A" or greater.

gl: missing Level A

<Greg> 3.3.1 should be listed as Level A.

js: fixed

+1 to current wording

jr: conformation claims are optional in ATAG

<Jan> brb

jr: features required to meet ATAG must confom(not sure I heard that right)

did we close 3.3.1???

resolution: 3.3.1 is completed!!!
3.3.2 Document Accessibility Features: All user agent features that 
benefit accessibility

discussion of definition of conformance claims.

<Greg> We noted need to provide definition of accessibility features as 
those that contribute to conforming with UAAG.

<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.

<Jan> back

resolution: 3.3.2 is completed!!
3.3.3 Changes Between Versions: Changes to features that affect 
accessibility since the previous version of the user agent are 
documented. (Level AA)

<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.

<Greg> We require apps to document accessibility FEATURES, but not 
limitations. That is very sad.

gl: we don't say anywhere that features were removed

<Kim> Changes to features that affect accessibility since the previous 
user agent release are documented.

<Jan> Changes to features that benefit accessibility since the previous 
user agent release are documented.

<Greg> Changes to features that benefit OR BENEFITED accessibility since 
the previous user agent release are documented.

gl: does this require the announcement of things that were removed.

kf: it changed they should document it...put it in intent

<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)

resolution: 3.3.3 is complete with new wording
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)

change to AAA

resolution: 3.3.4 is complete with new level AAA!!!

gl: do we have definition of documentation

kp: yes
3.3.5 Context Sensitive Help: There is context-sensitive help on all 
user agent features that benefit accessibility. (Level AAA)

+1

resolution: 3.3.5 is completed!
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.

<Greg> The phrase "end user experience such as speech" is the same as 
"end user experience", so it applies to everything.

jr: what does this mean.

resolution: remove 3.3.6
3.4.1 Control default focus: The user agent provides a mechanism for 
setting global configuration of default focus.

js: should be reviewed in context of 1.9

kf: GL 3 seems a bunch of shoe horning.

js: we need an understanding section, for cognitive issues

<Greg> Didn't we discuss a recommendation on autosummary, for example, 
which would fit under the Understandable section.

kp: need to discuss intent of 1.9
Summary of Action Items
[NEW] ACTION: Greg to think about UNDO ( 
http://www.w3.org/2009/11/06-ua-minutes#item05 ) and come up with some 
suggestions. [recorded in 
http://www.w3.org/2010/11/10-ua-minutes.html#action08]
[NEW] ACTION: ja to revise 1.11.1 and 1.11.2 make proposal to the group 
[recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action06]
[NEW] ACTION: jAllan to kFord to clean up 3.1.2 and further 
investigating wording [recorded in 
http://www.w3.org/2010/11/10-ua-minutes.html#action07]
[NEW] 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)." [recorded in 
http://www.w3.org/2010/11/10-ua-minutes.html#action01]
[NEW] ACTION: kelly to revise 1.11.1 and 1.11.2 make proposal to the 
group [recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action02]
[NEW] ACTION: kellyford to revise 1.11.1 and 1.11.2 make proposal to the 
group [recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action05]
[NEW] ACTION: kf to revise 1.11.1 and 1.11.2 make proposal to the group 
[recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action03]
[NEW] ACTION: kford to revise 1.11.1 and 1.11.2 make proposal to the 
group [recorded in http://www.w3.org/2010/11/10-ua-minutes.html#action04]

[End of minutes]
Received on Wednesday, 10 November 2010 22:22:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:39 UTC