- From: Jeanne Spellman <jeanne@w3.org>
- Date: Wed, 10 Nov 2010 17:22:06 -0500
- 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