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


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

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/11/10 22:17:19 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: jallan
Inferring ScribeNick: JAllan
Found Scribe: KFORD
Inferring ScribeNick: kford
Found Scribe: kford
Inferring ScribeNick: kford
Found Scribe: Harper_Simon
Found ScribeNick: sharper
Found Scribe: jallan
Inferring ScribeNick: JAllan
Found Scribe: KFord
Inferring ScribeNick: kford
Found Scribe: jallan
Inferring ScribeNick: JAllan
Scribes: jallan, KFORD, Harper_Simon
ScribeNicks: sharper, JAllan, kford
Default Present: [Microsoft], +1.512.206.aaaa, MIT262, SHarper, Mark, Jan, +1.512.206.aabb, jallan
Present: [Microsoft] +1.512.206.aaaa MIT262 SHarper Mark Jan +1.512.206.aabb jallan Greg Jim Jeanne Kim Simon Kelly
Found Date: 10 Nov 2010
Guessing minutes URL: http://www.w3.org/2010/11/10-ua-minutes.html
People with action items: greg ja jallan jan kelly kellyford kf kford

[End of scribe.perl diagnostic output]