<kford> Input focus correctly
transitions between nested user agents (4.2.1), the user can
determine input focus at any time (4.2.2) and input focus never
gets stuck in any nested user agent (4.2.3).

<kford> Possible summaries
for 4.2 and 2.7:

<kford> 4.2

<kford> Input focus correctly
transitions between nested user agents (4.2.1), the user can
determine input focus at any time (4.2.2) and input focus never
gets stuck in any nested user agent (4.2.3).

<kford> 2.7

<kford> The user can
customize user agent settings related to accessibility (2.7.1)
with settings changes being saved between sessions (2.7.2) and
restore settings to default values (2.7.3). Users can have
multiple sets of preferences (2.7.4), have related settings
restored to default as a group (2.7.5) and adjust preferences
outside the user agent main user interface (2.7.6). Users can
also...

<kford> ...transfer settings
between devices (2.7.7) and are offered a wizard to assist in
user customization (2.7.8).

possible summaries for 3.1-3.4

3.1 Users can turn off non-essential messaes
from the author or user-agent.

3.2 Users can choose to confirm form
submissions.

3.3 User documentation is available in an
accessible format (3.3.1), it includes accessbilbity features
(3.3.2), delineates differences between versions (3.3.3),
provides a centralized views of the browser meets UAAG2.0
(3.3.4), and is available as context sensitive help in the UA
(3.3.5).

3.4 Moving the focus allow presentation of
information (e.g. tooltips) but does not cause any other action
(3.4.2). Users can prevent non-requested focus changes
(3.4.1).

proposed Summary for 2.1

<jeanne> Guideline 2.1 -
Ensure full keyboard access.

<jeanne> Users have many ways
to input information into a computer or device, including
mouse, keyboard, gesture, and speech. The keyboard paradigm is
the most universal interface for text input - even devices that
do have a keyboard (like mobile phones) support a software
interface for them. All functions can be operated only using a
keyboard (2.1.1), the focus can be moved by the keyboard
(2.1.2, 2.1.3),

<jeanne> important or
commonly used features of the web page or application should
have shortcut keys for direct navigation (2.1.8). and the user
can override keyboard shortcuts and user interface controls
(2.1.4). Users should have a mechanism to escape keyboard traps
such as embedded objects that do not return focus to the main
web page (2.1.5). Users can set a preference that selecting an
item in a

<jeanne> dropdown list or
menu, does not activate that item or move to that new web page
(2.1.6). Text entry should use the standard keys for that
platform (2.1.7).

Proposed Summary for 2.2

<jeanne> Guideline 2.2 -
Provide sequential navigation

<jeanne> Users need to be
able to move through all the enabled content in the web page in
a logical sequential fashion (2.2.1 and 2.2.2). Unless the
author specifies a different navigation order, the default is
the document order (2.2.3). Users can prevent or request
notification when wrapping to the start of the page, to prevent
unwanted repetition (2.2.4).

<KimPatch> 2.1.2 Keyboard
Focus (former 1.9.1):

<KimPatch> Every viewport has
an active or inactive keyboard focus at all times. (Level
A)

<KimPatch> 2.1.3 Viewport
Navigation (former 1.9.2 & 1.9.4):

<KimPatch> The user can move
the active keyboard focus to any viewport. (Level A)

<sharper_> Users can discover
the keys which facilitate direct navigation and activation
(2.5.1), view their location in the structural hierarchy
(2.5.3), along with the relationships within that hierarchy
(2.5.5), and specify the elements (2.5.7+1.10.3) important to
building and navigate different hierarchical views
(1.10.2).

summary 4.2 Input focus correctly transitions
between nested user agents (4.2.1), the user can determine
input focus at any time (4.2.2) and input focus never gets
stuck in any nested user agent (4.2.3).

summary 4.2 Input focus correctly transitions
between nested user agents (4.2.1), the user can retrieve input
focus at any time (4.2.2) and input focus never gets stuck in
any nested user agent (4.2.3).

2.7.5 summary

The user can customize user agent settings
related to accessibility (2.7.1) with settings changes being
saved between sessions (2.7.2) and restore settings to default
values (2.7.3). Users can have multiple sets of preferences
(2.7.4), have related settings restored to default as a group
(2.7.5) and adjust preferences outside the user agent main user
interface (2.7.6). Users can also...

scribe: transfer settings between
devices (2.7.7) and are offered a wizard to assist in user
customization (2.7.8).

Users can customize user agent settings
related to accessibility (2.7.1) with settings being saved
between sessions (2.7.2) and restore settings to default values
(2.7.3). Users can have multiple sets of preferences (2.7.4),
have related settings restored to default as a group (2.7.5)
and adjust preferences outside the user agent main user
interface (2.7.6). Users can also transfer settings...

scribe: between devices (2.7.7)
and are offered a wizard to assist in user customization
(2.7.8).

summary for GL 3.1 -3.4

3.1 Users can turn off non-essential messaes
from the author or user-agent.

3.2 Users can choose to confirm form
submissions.

3.3 User documentation is available in an
accessible format (3.3.1), it includes accessbilbity features
(3.3.2), delineates differences between versions (3.3.3),
provides a centralized views of the browser meets UAAG2.0
(3.3.4), and is available as context sensitive help in the UA
(3.3.5).

3.4 Moving the focus allow presentation of
information (e.g. tooltips) but does not cause any other action
(3.4.2). Users can prevent non-requested focus changes
(3.4.1).

gl: what about an SC requiring
spell checking for folks with reading or writing
disabilities.

3.3 User documentation is available in an
accessible format (3.3.1), it includes accessibility features
(3.3.2), delineates differences between versions (3.3.3),
provides a centralized views of conformance UAAG2.0 (3.3.4),
and is available as context sensitive help in the UA
(3.3.5).

proposed Summary for 2.1

Users have many ways to input information into
a computer or device, including mouse, keyboard, gesture, and
speech. The keyboard paradigm is the most universal interface
for text input - even devices that do have a keyboard (like
mobile phones) support a software interface for them. All
functions can be operated only using a keyboard (2.1.1), the
focus can be moved by the keyboard (2.1.2, 2.1.3),

important or commonly used features of the web
page or application should have shortcut keys for direct
navigation (2.1.8). and the user can override keyboard
shortcuts and user interface controls (2.1.4). Users should
have a mechanism to escape keyboard traps such as embedded
objects that do not return focus to the main web page (2.1.5).
Users can set a preference that selecting an item in a

dropdown list or menu, does not activate that
item or move to that new web page (2.1.6). Text entry should
use the standard keys for that platform (2.1.7).

Proposed Summary for 2.2

Guideline 2.2 - Provide sequential
navigation

Users need to be able to move through all the
enabled content in the web page in a logical sequential fashion
(2.2.1 and 2.2.2). Unless the author specifies a different
navigation order, the default is the document order (2.2.3).
Users can prevent or request notification when wrapping to the
start of the page, to prevent unwanted repetition (2.2.4).

<scribe> scribe: jallan

kf: first couple of sentences
read more like an intent.

JS: move first 2 sentences to
intent of 2.1.1

<Greg> "important or commonly
used features should have shortcut keys for direct navigation
(2.1.8)"

<KimPatch> Users can operate
all functions (2.1.1), and can move focus (2.1.2, 2.1.3) using
just the keyboard.

<KimPatch> Users can operate
all functions (2.1.1), and move focus (2.1.2, 2.1.3) using just
the keyboard. Users can activate important or common features
with shortcut keys, (2.1.8), override keyboard shortcuts and
user interface controls (2.1.4), escape keyboard traps (2.1.5),
specify that selecting an item in a dropdown list or menuoes
not activate that item or move to that new web page
(2.1.6),...

<KimPatch> ...and use
standard keys for that platform (2.1.7).

<sharper_> Users can discover
the keys which facilitate direct navigation and activation
(2.5.1), view their current location in the structural
hierarchy (2.5.3) as well as the relationships within that
hierarchy (2.5.5), and specify the elements (2.5.7+1.10.3)
important to building and navigating different hierarchical
views (1.10.2).

Simon's proposal for 2.5

<KimPatch> Users can operate
all functions (2.1.1), and move focus (2.1.2, 2.1.3) using just
the keyboard. Users can activate important or common features
with shortcut keys, (2.1.8), override content and interface
keyboard shortcuts (2.1.4), escape keyboard traps (2.1.5),
specify that selecting an item in a dropdown list or menuoes
not activate that item or move to that new web page (2.1.6) and
use...

<KimPatch> ...standard keys
for that platform (2.1.7).

need lots of discussion about 1.10.2 1.10.3
and 2.5.7 and 2.5.4

<KimPatch> Users can operate
all functions (2.1.1) and move focus (2.1.2, 2.1.3) using just
the keyboard. Users can activate important or common features
with shortcut keys (2.1.8), override content and interface
keyboard shortcuts (2.1.4), escape keyboard traps (2.1.5),
specify that selecting an item in a dropdown list or menu
doesn't activate or move item to that new web page (2.1.6).
User can use...