Re: Guideline 2.2 Issue Summary

Hi Gez and others,

At 14:00 10/10/2005, Gez Lemon wrote:

>Hi Christophe,
>
>On 10/10/05, Christophe Strobbe <christophe.strobbe@esat.kuleuven.be> wrote:
> > 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".
>
>It would be a huge burden for the server to maintain all session
>variables, and also impossible to guarantee as the server could
>restart if it runs out of memory, losing all session data. It would be
>less of a burden if the session data was stored on the user's computer
>using cookies.

I am perfectly aware of the burden to maintain all session variables.
That is exactly why I (tentatively) suggested a technique. Maybe the
technique itself was not completely clear: the intention of the
autosubmit (which seems questionable in other situations, for example
because it is a change of context not requested by the user) was
to enable the server to store the user's data in a persistence mechanism
and close the session, and to retrieve these data again when the user
logs in again. This way it looks to the user as if he/she is continuing
the same session, although technically it is a new session.
If this is not a good technique, we need something else for L3 SC3.
Any ideas?


> > [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?
>
>I think this success criterion is aimed at people who are likely to be
>distracted by blinking content. I'm preparing the guide document for
>this criterion, and will put a note referring to guideline 2.3 for
>photosensitivity.

In previous discussions we left it at 3 seconds because it was long enough
to draw the user's attention to something but not so long as to cause
serious discomfort.


> > 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?
>
>Authors who provide content that blinks presumably do so because they
>want to draw the visitor's attention to that content. In a large
>delivery unit with blinking content at the start and end, with enough
>content between that they could not be seen simultaneously, the
>desired effect will be lost. I intensely dislike blinking content, but
>if we accept this suggestion, would it not be deemed as too
>restrictive?

In Brussels, we accepted
"Content does not blink for more than 3 seconds,
or a method is available to stop any blinking content in the delivery unit"
as a response to issue 1044 
[http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1044]
("Why not allow total turn-off of blink?"). No one found it too restrictive.
Do you think this is too restrictive at Level 2?

>What about suggesting authors provide a mechanism to stop
>all blinking content in the optional techniques (advisory) section of
>the guide document?

If we don't require that blinking can be turned off in the whole delivery
unit with one action, users will have to do it for every instance
separately. If there are 10 blinking items and you have to stop them one
by one, that is very irritating.

Regards,

Christophe


-- 
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 Tuesday, 11 October 2005 09:29:20 UTC