GL 2.2 proposals and issue summary

Hello all,

Below are proposals and an issue summary for guideline 2.2 (Allow users to control time limits on their reading or interaction). In the attached HTML version attached to this e-mail(WCAG_GL2.2_IssueSummary.20050523.htm), each proposal has an anchor to facilitate references, and issue summaries link to relevant proposals if there are any. The proposals and the issue summary follow (more or less) a format suggested by Wendy.


Proposals


Proposal 1

<sc>L2 SC1</g>

<proposed>
Content does not blink, or a method is available to stop any blinking of content in the delivery unit, or a method is available to disallow blinking entirely in the content of the delivery unit.
</proposed>

<current>
A method is provided to stop content that blinks for more than 3 seconds.
</current>

<rationale>
Combined with proposal 1 ,this closes issue 1044; incorporates John's proposal in issue 1499 (substitute "available" for "provided"). This does not ban blinking altogether, because, as Gregg Vanderheiden indicated in the 4 November 2004 call, blinking to attract attention can be helpful for peole with cognitive disabilities.
</rationale>

<consequences>
Example 1 should be updated if the proposal is accepted.
</consequences>



Proposal 2

<sc>L1 SC1</sc>

<proposed>
Content does not have time-outs unless they are an essential part of the interaction. (Time-outs can be essential for real-time events where no alternative to the time-out is possible, e.g. auctions. Time-outs can also be part of an activity where timing is essential and time limits cannot be extended without invalidating the activity, e.g. competitive gaming or time-based testing.)
Time-outs that are an essential part of the interaction but that can be extended without invalidating the activity, can be extended to accomodate people with disabilities.
</proposed>

<current>
Content is designed so that time-outs are not an essential part of interaction, or at least one of the following is true for each time-out that is a function of the content: [I]
- the user is allowed to deactivate the time-out or; 
- the user is allowed to adjust the time-out over a wide range which is at least ten times the length of the default setting or; 
- the user is warned before time expires, allowed to extend the time-out with a simple action (for example, "hit any key") and given at least 20 seconds to respond or; 
- the time-out is an important part of a real-time event (for example, an auction), and no alternative to the time-out is possible or; 
- the time-out is part of an activity where timing is essential (for example, competitive gaming or time-based testing) and time limits can not be extended further without invalidating the activity. 
</current>

<rationale>
This could close close issues 943, 1092, 1346, 1381, and 1384, which comment on "default setting" (second bullet) or conflicts with usabilty. Combined with proposal 1, this could also close issue 1044. The last sentence is more tentative and could close issue 1459.
</rationale>



Proposal 3

<sc>L2 SC2</sc>

<proposed>
Moving or time-based content can be paused by the user.
</proposed>

<current>
A method is provided to pause and/or permanently stop dynamic (moving or time-based) content.
</current>

<rationale>
Write success criterion as functional outcome and improve readability. Closes issue 1500 (proposal by John).
</rationale>



Proposal 4

<sc>L3 SC1</sc>

<proposed>
Except for real-time events, timing is not an essential part of the event or activity presented by the content.
</proposed>

<current>
With the exception of real-time events, content has been designed in a way that timing is not designed to be an essential part of the activity and any time limits in the content would pass level 1, success criteria 1 for this guideline.
</current>

<rationale>
Write success criterion as functional outcome (rewording). Closes issue 1501 (proposal by John).
</rationale>



Proposal 5

<sc>L3 SC2</sc>

<proposed>
Non-emergency interruptions, such as the availability of updated content, are turned off by default. [V]
</proposed>

<current>
Any non-emergency interruptions, such as the availability of updated content, can be postponed and/or suppressed by the user. [V]
</current>

<rationale>
[may close issues 1348 and 1383]
</rationale>

<consequences>
example 2 should change (issue 1385)
</consequences>



Proposal 6

<x>Benefit 1</x>

<proposed>
People with reading disabilities, cognitive disabilities, and learning disabilities who may need more time to read and comprehend written text can have additional time to read the information.
</proposed>

<current>
People with reading disabilities, cognitive disabilities, and learning disabilities often need more time than most people to read and comprehend written text.
</current>

<rationale>
Benefit was written as issue instead of benefit (issue 802).
</rationale>


Proposal 7

<x>Benefit 2</x>

<proposed>
People with physical disabilities can have sufficient time to access content that is updated often in cases
where content might not be processed and read before being refreshed or 
where content is read out of order an assistive technology, voice browser, or a sign-language interpreter relating audio content to a user. 
</proposed>

<current>
People with physical disabilities can access content that is updated often in cases where content might not be processed and read before being refreshed or when read out of order by an assistive technology or voice browser.
</current>

<rationale>
Raise awareness among designers that people who use an interpreter are a group they should also cater for (RNID).
</rationale>


Proposal 8

<x>Benefits</x>

<proposed>
People with low computer literacy, particularly the elderly, do not get confused or are not led to think that they have made a mistake.
</proposed>

<current>(none)</current>

<rationale>
For people with low computer literacy, particularly the elderly, any behaviour that is not the direct result of their action is likely to confuse them and make them think they have made a mistake (Catherine Brys, issue 1432).
</rationale>


Proposal 9

<x>Examples</x>

<proposed>
Remove (or reword) 4th bullet in "examples of content that must meet the success criteria…
</proposed>

<current>
shutdown or deactivation of a resource if activity is not received in a set amount of time
</current>

<rationale>
Session or server timeouts are generally not under the control of the author. After the 4 November 2004 conference call, the words "that is a function of the content" were added to GL 2.2 L1 SC1 to clarify that server timeouts are exluded (issue 800).
</rationale>




Issue Summary

Issues are ordered by sections of the guideline: success criteria, benefits, examples.


Issue 943: Why ten times the default setting?

How was the "at least ten times" decided? Fixing numerical references and thresholds is controversial.

Issue relates to L1 SC1, second bullet.

Recommended action: consider proposal 2 (if accepted, proposal 2 closes this issue and 4-6 others).



Issue 1044: Suggestions for time-limits in L1 (ten times the default) and L2 SC 2 (blinking)

"Ten times the default setting" assumes there is a default setting. Some may want it faster, others slower. 
Why not allow total turn-off of blinking? 

Issue relates to L1 and L2 SC2.

Recommended action: consider proposal 1 and proposal 2.



Issue 1092: Time limits ("ten times the default") in L1 are still too small

10 times the default can still be a very small number. There should be a minimum time as well.

Issue relates to L1.

Recommended action: reject and consider proposal 2 instead.



Issue 1346: L1 success criteria conflict with usability

Allowing the options where the user can deactivate a time limit, adjust it or is warned requires more effort from the user than necessary.

Issue relates to L1.

Recommended action: consider proposal 2 (if accepted, proposal 2 closes this issue).

Comment: it is better to encourage developers to avoid time limits if they are not an essential part of the interaction.



Issue 1381: L1: there should be no time limits if not essential

The fact that the user is allowed to deactivate the time limit conflicts with the fact that the time limit would be essential. 
Why bother the user with having to deactivate or adjust the time limit or respond to a warning? This requires extra effort from the user. 

Issue relates to L1.

Recommended action: consider proposal 2 (if accepted, proposal 2 closes this issue).



Issue 1459: Time limits should not apply to testing

The submitter of the issue believed that the US ADA allows extensions even for time-based testing as a disability accommodation, and would like to see this comment be more forgiving.

Issue relates to L1 (5th bullet).

Recommended action: further discussion.

Comment: first, find out what US ADA actually says about this; then, if necessary, modify L1 or proposal 2.



Issue 880: Should blinking and movement be covered?

- The need to avoid movement in pages until they can be frozen should get a higher priority level. (City University) 
- GL 2.2 is about timed responses (US Access Board): 
  * taken to its extreme, this means that the user should be able to freeze and resume all live presentations;
[this was addressed in the 4 Novermber 2004 conference call: This issue [i.e. should WCAG require freezing live content] shoud already be covered by UAAG. Pending baseline decisions, move success criterion 2 to repair strategies.] 
  * including blinking is a stretch. 

Issue relates to L2.

Recommended actions:
- Discuss higher priority level for L2 SCs. 
- Discuss: leave SC on blinking in 2.2 or move it elsewhere (1.3 ?, 2.3 ?) 



Issue 1382: L2 conflicts with usability

Is providing the option to turn off, pause or stop good enough? At which level would turning off or pausing/stopping apply? For every individual bit of text? In the 4 November 2004 call, Gregg Vanderheiden said that outlawing blinking to attract attention is not a good idea because it can be helpful for people with cognitive disabilities.

Issue relates to L2 SC1 and SC2.

Recommended action: consider proposal 1 (if accepted, proposal 1 closes this issue).



Issue 1347: GL 2.2, SC L2 conflicts with usability

Allowing blinking text with the option to turn it off, pause it or stop it opens again the door for requiring more effort from the user than necessary.

For comments and recommended action: see issue 1382.



Issue 1499: 2.2 L2 SC1 - rewrite as functional outcome

Recommended action: Accept if proposal 1 is rejected.

Proposal 1 takes this issue into account.



Issue 1500: 2.2 L2 SC2 - describe functional outcome and improve readability

Recommended action: accept (this is proposal 3)



Issue 1501: 2.2 L3 SC1 - wording proposal (describe functional outcome)

Recommended action: accept (this is proposal 4).



Issue 1348: GL 2.2, SCL3 conflicts with usability

Allowing the option that the user can postpone non-emergency interruptions such as updating of content is requiring more effort than necessary from the user.

Recommended action: consider proposal 5 (which also addresses issue 1383)



Issue 1383: GL 2.2, SC L3 - let user request update, rather than postpone automatic update

Allowing the option that the user can postpone non-emergency interruptions such as updating of content is requiring more effort than necessary from the user. If the user can postpone interruptions - at which level should this happen? One for the page? Once for the site? For every individual occurrence of frequently updated content?

Recommended action: consider proposal 5 (which also addresses issue 1348)



Issue 1502: 2.2 L3 SC2 - describe functional outcome and improve readability

Recommended action: accept if proposal 5 is rejected.



Issue 802: Rewording of benefits

Benefits are written as issue instead of benefits.

Issue relates to: Benefits.

Recommended action: consider proposal 6 (first benefit) and proposal 7 (second benefit); if accepted, these proposals close the issue.



Issue 987: Add people who use an interpreter to the benefits

People who use a sign language interpreter may need extra time.

Issue relates to: Benefits.

Recommended action: proposal 7 could close this issue.



Issue 1432: Guideline 2.2 - unsolicited transitions confuse

For people with low computer literacy, particularly the elderly, any behaviour that is not the direct result of their action is likely to confuse them and make them think they have made a mistake.

Issue relates to: Benefits.

Recommended action: accept (proposal 8 adds a new benefit).



Issue 803: Example not applicable (server-side timeouts?)

The last sub-bullet in the list of examples (shutdown or deactivation of resource if activity is not received in a set amount of time) seems to talk about server timeouts, which are generally not under control of the content author.

Issue relates to: Examples.

Recommended action:
Either remove this bullet to bring the examples in line with the issue 800 (4 November 2004 conference call), when the text that is a function of the content was added to GL 2.2 L1 SC1 to clarify that server timeouts are exluded (because, generally, server administrators, not content authors, control server timeouts). This corresponds to proposal 9. 
Or the resolution of issue 800, and add relevant examples to a techniques document on server-side scripting (which does not exist yet). 



Issue 1349: GL 2.2 Example 2 conflicts with usability

Having the option to turn off updating of content in a separate 'user preferences' part of the web site opens the door to web sites which are accessible in theory but not in practice. Only a small percentage of users ever change default settings. Also, it would very much depend on the rest of the site whether or not this feature would be discoverable.

Recommended action: Leave open until there is a decision on proposal 5, which has consequences for this example.



Issue 1384: GL 2.2 examples conflicts with guideline?

The example "dialog that disappears after a short period" seems to be in conflict with the third bullet in L1 (at least 20 seconds).

Recommended action: Leave open until there is a decision on proposal 2; proposal 2 could close this issue.



Issue 1385: Non-default user settings harm accessibility

Having the option to turn off updating of content in a separate 'user preferences' part of the web site opens the door to web sites which are accessible in theory but aren't in practice. Only a small percentage of users ever change default user settings. Also, it would very much depend on the rest of the site whether or not this feature would be discoverable

Issue relates to: example 2.

Recommended action: Leave open until there is a decision on proposal 5; if proposal 5 is accepted, the example needs to be revised.



Issue 1525

An important scenario is not covered: that of an authenticated session suffering an inactivity timeout, particularly if this happens when the user submits a form. Whent this happens, Philip Naylor suggests that:
1. it should be clear to the user what has happened. 
2. the user should be given the opportunity to re-authenticate themselves. 
3. once they are re-authenticated they should be presened with the same "page" as they would have received if the timeout had not occurred. In particular, any form input should be carried across the authentication process, so that it does not have to be re-entered. 

Issue relates to: L1.

Recommended action: Reject.

Rationale:
- Server timeouts are not covered (unless we reject proposal 9 / issue 803). 
- This is primarily a usablity issue, although the problem is graver for people with disabilities. 


Regards,

Christophe Strobbe



-- 
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/