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

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)

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

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

<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

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)

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

<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

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

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

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

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)