Re: Guideline 2.2 Issue Summary

Hi Ben,

At 18:50 6/10/2005, you wrote:

>Hi guys,
>
>Just took a look through the open 2.2 issues (only 13) and roughed out 
>some ideas for how to close them.

Since I wrote the previous issue summary for this guideline
(http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0994.html),
I thought I should have a very close look ;-)
I found some more issues: I put most of them below related issues;
one other issue is not related to existing issues and is right below.

Issue 1645
[http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1645]
L3 SC3:
"it would be a large burden for servers to maintain state of each session
indefinitely".

At the Brussels F2F, two techniques were mentioned, but I did not manage
to write them down.
Would the following be an acceptable technique?
A short time before the session expires, warn the user about the time out
and auto submit the data; when the user logs in again, display the data
again and tell the user that they were autosubmitted because of a
session timeout and that he/she should check them again. After the
user has checked (and possibly corrected) the data, the session
continues as normal.


>Many of them are things that I think we need to clarify in the guide docs. 
>Here's where I
>think we are on these:
>
>-------------------------
>Issue 880
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?880>
>Not sure what to do with this one. It includes a couple of assertions
>that blinking events and the ability to pause dynamic content are not
>appropriate for a guideline on time limits and raises a number of
>questions about how this applies to live content. The resolution that
>was recorded in a Nov. 2004 telecon on this was:
>
>resolved: This issue shooed already be covered by UAAG. Pending baseline
>decisions, move success criterion 2 to repair strategies.
>
>It's not clear whether this was meant to apply to one or both of the
>level 2 SC. Do we still feel that either of these should be moved to
>techniques?

Issue 1644
[http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1644]
L2 SC2: reviewer writes:
'Change to "...paused by the user for at least N minutes" (with N to be
filled in before publication) because allowing the user to pause the content
only for a short time period should not be sufficient to comply.
Alternatively you could say "...paused indefinitely..." but I don't believe
that is always feasible.'

If a user can activate 'pause' and 'play' (to resume playing), the lenght of
the pause is under the user's control. So why whould these N minutes by
necessary? If the reviewer can't give examples where pausing indefinitely
is not feasible, I think we should close this issue.




>-------------------------
>Issue 943 and 1092
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?943>
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?1092>
>These issues are requests for references on "10 times the default 
>setting." Do we have references for this to include in the L1 SC1 guide doc?
>
>-------------------------
>Issue 987
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?987>
>Includes a couple suggestions for  the benefits section. The first is to 
>include mention of individuals with hearing disabilities who need more 
>time because they are receiving help from a sign language interpreter 
>Suggest adding people who are deaf and hard of hearing to the first benefit:
>
>People with reading disabilities, cognitive disabilities, learning 
>disabilities and who are deaf or hard of hearing who may need more time to 
>read and comprehend written text can have additional time to read the 
>information.
>
>The second suggestion relates to physical disabilities. Suggest revising 
>the second benefit to read:
>
>People with physical disabilities can take additional time to access and 
>interact with content.
>
>-------------------------
>Issue 1044
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?1044>
>Includes a number of suggestions for 2.2.
>
>The first comment is about presuming that there is a default setting, 
>suggesting that some may wish times to be slower, others faster. Not sure 
>I understand the comment - if there is no default time, then how can it be 
>a time out in the first place? Since there is no proposal for this, 
>suggest we close this portion of the issue.
>
>The second comment relates to "more than 3 seconds," asking why no allow 
>total turn off of blink. Since this is about distraction, suggest that 
>this could be covered by UA configuration as well as by an advisory 
>technique about global settings and preferences for this. However, there 
>is no reason to require authors not to use movement in content if it stops 
>after a short period.
>
>There is also a suggestion to revise example 1. Suggest we revise as follows:
>
>Example 1: blinking text.
>Client-side scripting is used to create blinking text. The content 
>provides an option that allows the user to turn off the blinking or 
>configure the content so that it does not occur at all.


Issue 1550
[http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1550]
"2.2 L2 SC1:Content does not blink for more than 3 seconds ..."
Are there international health and safety standards for blinks (as in 2.3)?
3 seconds seems a very long time to be looking at maybe 10 blinks that
could cause a convulsion or altered state.  Could that be reduced to two
seconds?




>-------------------------
>Issue 1349 and 1385
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?1385>
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?1349>
>Requests clarification on what is sufficient for satisfying SC that allow 
>users to turn off updating g content. I think this needs to be clarified 
>in the guide doc. If an option to turn off updating content is in a 
>separate preferences are of a site, do we consider that to be sufficient?
>
>-------------------------
>Issue 1382
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?1382>
>This is a request to clarify at which level interruptions can be postponed 
>(each instance?, whole delivery unit?, whole site?). This is something 
>that would need clarification in the guide doc for L3 SC2.

Issue 1643
[http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1643]
Reviewer writes:
'Change "any" to "all" because use of "any" implies that the user can be
required to turn off each blinking item independently. While that level of
control can be useful for many users, it would be impractical for users who
need to stop large number of blinking elements, especially if new ones might
continually start blinking over time.'

The addition of "a method is available to stop any blinking content in the 
delivery unit" in the latest draft was meant ensure that all blinking 
content in a delivery unit could be turned off at once. Any objections to 
the proposed change?



>-------------------------
>Issue 1383
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?1383>
>Suggests that users should be able to request, rather than postpone, the 
>availability of updated content (L3 SC2). Should be clarified in the guide doc.
>
>-------------------------
>Issue 1384
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?1384>
>This issue suggests that one of the examples of functionality that must 
>meet the success criteria ("dialog that disappears after a short period") 
>conflicts with guideline?
>
>"Level 1 Success Criteria for Guideline 2.2 itself uses a warning which
>times out after at least 10 seconds. Is this not conflicting?"
>
>The time in the current draft(s) is 20 seconds, but the question still 
>needs an answer. I don't see a conflict; it is just an example of
>something that has to meet the L1 SC.
>
>-------------------------
>Issue 1432
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?1432>
>Makes a suggestion for the benefits section, pointing out that "I think it 
>should be pointed out that for people with low computer literacy, 
>particularly the elderly, any behavior that is not the direct result of 
>their action is likely to confuse them and make them think they have made 
>a mistake."
>
>I wonder if this is a better fit under 3.2?
>
>People with reading disabilities, cognitive disabilities and learning 
>disabilities are likely to be confused by changes in context that are not 
>a direct result of their action.
>
>We've typically kept benefits for other audiences such as the elderly out 
>of the guidelines, but we could include benefits like this in the guide 
>doc if appropriate.
>
>-------------------------
>Issue 1459 and 1552
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?1459>
><http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=?1552>
>Both issues are about the parenthetical in 2.2 L1 SC1, "(for example, 
>competitive gaming or time-based testing)." and argue that extensions 
>(even for time-based testing) are allowed in some cases and do not 
>invalidate the activity.
>
>Given our definition of an activity where timing is essential, I think the 
>SC is clear without the parenthetical. However, we should clarify this in 
>the guide doc and include references to ADA info on extensions in the 
>guide doc references.

Issue 1642
[http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1642]
2.2 L1 SC1: Reviewer thinks that
"to achieve L1 time-based testing should be designed so that
administrators can extend the allowed time (e.g. for students with certain
disabilities) even if the end user cannot."


>Thoughts?

I'll try to make suggestions later.

Regards,

Christophe Strobbe



>--
>Ben Caldwell | <caldwell@trace.wisc.edu>
>Trace Research and Development Center <http://trace.wisc.edu>

-- 
Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group on 
Document Architectures
Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/ 


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Monday, 10 October 2005 11:15:40 UTC