Proposed clarification to checkpoint 3.9

Hello,

Note: At the bottom of this long email there is a proposed 
new version of checkpoint 3.9. Given the history of this
checkpoint (outlined below), I believe this change to be
a clarification of the Working Group's intent. The actual
wording of the proposal (and whether there should be
one or two checkpoints in the end) may have to change.

At the 9 May teleconference, we discussed minimal requirements
for checkpoint 3.8 of the 7 May draft [2]:

<OLD>
3.8 For automatic content changes specified by the
    author (e.g., redirection and content refresh), allow the 
    user to slow the rate of change. 
</OLD>

Up until the 20 December 1999 draft [3], this checkpoint was
two checkpoints that were more specific. For example, from
the 6 December 1999 draft [4]:

<6 December 1999>
3.9 Allow the user to turn on and off author-specified
    forwards that occur after a time delay and without
    user intervention. [Priority 3] 

3.10 Allow the user to turn on and off automatic content 
    refresh. [Priority 3] 
</6 December 1999>

At the 9 December face-to-face meeting in Austin we made
some changes to these checkpoints as part of discussing
issue 145 [5]. The changes were made in response to
a last call review comment from Gregg Vanderheiden [6].

   > GV#16 -----------------------------
   > 3.10
   > Why is blinking and animation a priority 1  but   
   > auto refreshing (which can have the same effects) 
   > only a priority 3?

The Austin minutes suggest the following:

 1) We stated that content refresh would not be fast
    enough to cause "flashing" might trigger seizures.
 2) Refreshing content and content changes might
    disorient users (either with CD or who are using
    assistive technologies). Screen readers need
    time to get to the bottom of a page before
    content refreshes.
 3) It is not enough simply to stop page refresh; the
    user agent needs to notify the user that new content
    is available. Thus, the requirement to turn on/off
    was insufficient.

We decided to merge 3.9 and 3.10 and the approximate
text proposed was: "Allow the user to set a minimal 
interval for author-specified forwards or refeshes that occur
without user intervention. (Setting to "0" or a large 
number would turn off the change.)"

Jim Allan then got an action item to propose a new checkpoint
to the list, and his proposal [7] was:

<JIMALLAN>
3.9 Allow the user to set a minimum rate for author specified
forwards and/or refreshes that occur after a time delay and
without user information.
</JIMALLAN>

We raised the priority of the checkpoint to P2 as a result
of the 20 January teleconference [8].

I do not have evidence of how Jim's proposed wording was
modified between when he proposed it on 10 December and
when it appeared in the 20 December draft [3] as:

<20 December 1999>
3.9 For automatic content changes specified by the author 
(e.g., content refresh and page forwards), allow the 
user to slow the rate of change. [Priority 3] 
</20 December 1999>

This is the same text as the 7 May 2000 draft. Apparently
I am responsible for the change, which I must have deemed
editorial at the time.

Having explored the history of the checkpoint and in light of
today's teleconference discussion, I'd like to propose
this modification to the checkpoint: 

<NEW>
3.9a Allow configuration so that author-specified 
    "client-side redirects" (i.e., those initiated by
    the user agent, not the server) do not change content 
    automatically. Allow the user to access the new 
    content on request (e.g., by following a link).
</NEW>

<NEW>
3.9b Allow configuration so that author-specified 
     content refreshes do not change content automatically.
     Allow the user to access the new content on
     request (e.g., by activating a button).
     Advise the user to refresh content according to the
     same schedule as the automatic refresh, and indicate
     persistently that the user has not yet refreshed 
     content.
</NEW>

Notes:

 - For the purposes of considering the issues, I prefer to
   have these checkpoints separate. I think notification
   is more important to 3.9b than 3.9a (but I could be
   wrong).

 - This rephrasing of the checkpoints is more specific than
   it has been. The phrase "do not change content automatically"
   hints at the rationale of the checkpoint. I think it may
   be worthwhile to be specific in the checkpoint about
   what we want, and then explanation of the minimal
   requirements (access on request, notification, persistent
   indication) becomes a minor issue.

  - The definition of "client-side redirects" needs review.
    For more discussion on redirects and refreshes,
    refer to comments from Al Gilman on 29 February 2000 [9].

Comments welcome,

 - Ian

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0327.html
[2] http://www.w3.org/WAI/UA/WD-UAAG10-20000507/
[3] http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19991220/
[4] http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19991206/
[5] http://www.w3.org/WAI/UA/1999/12/ftf-19991209#issue-145 
[6] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0507.html
[7] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0679.html
[8] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0152.html
[9] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0412.html
-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Tuesday, 9 May 2000 18:46:32 UTC