Issue summary for Guideline 2.2

The following issues for Guideline 2.2 have landed on our plate since
the last time we went through issues. Here are proposals for them.
Michael

---

1383: GL 2.2, SC L3 - let user request update, rather than postpone
automatic update
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1383

Users should be able to request updates of content rather than have to
stop/pause updates. 

Change to 2.2.5 was made in response to this, but 2.2.3 remains
unaddressed. However, issue 1644 below seems to be more specific to
that.

Proposal: CLOSE (SC updated).

---

1622: ended with "and/or" instead of "or",
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1622

Suggests the bullets in 2.2.1
<http://www.w3.org/WAI/GL/WCAG20/guidelines.html#N1052D> should be
joined with "and/or" instead of "or" to allow them to be used in
conjunction.

Proposal: CLOSE and make no change to SC. The use of "or" does not
mandate exclusivity but does state the minimum condition to meet the
success criterion.

---

1643: 2.2 L2 SC1 Change "any" to "all"
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1643

For 2.2.2 <http://www.w3.org/WAI/GL/WCAG20/guidelines.html#N1054E>
"Content does not blink for more than 3 seconds, or a method is
available to stop any blinking content in the delivery unit" Change
"any" to "all" because use of "any" implies that the user can be
required to turn off each blinking item independently.

Proposal: Adopt change to SC and CLOSE.

---

1644: 2.2 L2 SC2 Change to "...paused by the for at least N minutes"
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1644

A time duration during which a user-requested pause of moving content
should be provided, or alternately it should be specified that pause
means "stop indefinitely until user requests restart".

Proposal: add a definition to the glossary for "paused" in the SC -

Paused: timing or movement stops when user requests, and does not
restart unless the user requests.

Then CLOSE the issue.

---

1645: 2.2 L3 SC3 not feasible to let the user resume
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1645

SC 2.2.6 as currently worded ("When an authenticated session has an
inactivity timeout, the user can continue the activity without loss of
data after re-authenticating") does not specify how long after the
user's session times out they should be able to submit data (and
therefore the server keep a cache). Therefore it is indefinite, which is
not reasonable.

Techniques for this SC do not involve the server keeping any cached
information until the time that a user attempts to submit data after a
session timeout. At that point, the only thing that is necessary is for
the user to re-authenticate, and the cache needs to be kept only that
long. A note to that effect has been added to one of the techniques
<http://tinyurl.com/r2s5a>. Therefore, this does not require indefinite
maintenance of user state information.

Proposal: CLOSE with above explanation.

---

1768: Clarify "invalidate the activity"
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1768

SC 2.2.1 "Invalidate the activity" presumably means something like
"defeat the purpose of the activity", and should I think be defined as a
term or a substitute such as the above should be used in its place.

Proposal: Adopt suggestion to replace "Invalidate the activity" with
"defeat the purpose of the activity" and CLOSE the issue.

---

1826: SC 2.2.6 should be level 2
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1826

SC 2.2.6 is sufficiently useful for all web users that it ought to be
level 2, rather than 3.

Proposal: LEAVE OPEN and revisit after Last Call.

---

1827: Clarify example for SC 2.2.6
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1827

Example saying "...The user is prompted to re-authenticate in a separate
viewport..." needs clarification of what's meant by a "viewport".

Proposal: CLOSE (overcome by events). Current version of How to Meet
2.2.6 <
http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20/#time-limits-ser
ver-timeout> does not use this language.

---

1828: inactivity timeout vs session timeout
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1828

SC 2.2.6 only talks about _inactivity_ timeouts (i.e. timed from the
last access), but some sites could be using a _session_ timeout (i.e.
timed from the last authentication).  Is there a consensus that the
latter is "not a good idea", and if so should this be made clear in the
success criteria ? Should there be definitions for these terms?

Proposal: Reword SC 2.2.6 as follows and CLOSE.

When an authenticated session <del>has an inactivity
timeout</del><ins>expires</ins>, the user can continue the activity
without loss of data after re-authenticating.

Received on Monday, 20 March 2006 15:28:05 UTC