Updated Proposals and Issue Summary for Guideline 2.2 (WCAG 2.0 WD)

Proposals

Proposal 1

<sc>L2 SC1</g>

<proposed>

Content does not blink for more than 3 seconds, or a method is available to stop any blinking content in the delivery unit.

</proposed>

<proposed>

A method is available to stop any content in the delivery unit that blinks for more than 3 seconds.

</proposed>

<oldProposal>

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.

</oldProposal>

<current>

A method is provided to stop content that blinks for more than 3 seconds.

</current>

<rationale>The updated proposals avoid that users should stop blinking on an instance-by-instance basis (instead of once for the whole delivery unit).

Combined with proposal 2, 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 teleconference, blinking to attract attention can be helpful for people with cognitive disabilities.

</rationale>

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

</consequences>

Proposal 2

<sc>L1 SC1</sc>

<proposed>

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]

</proposed>

<updatedOldProposal>

Content does not have time-outs unless they are an essential part of the interaction.

Note: 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 purpose of 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.

</updatedOldProposal>

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

</current>

<rationale>This addresses issues 943, 1092 and part of 1044 (which comment on "ten times the default setting" in the second bullet point) and rejects the concern in issues 1346 and 1381 (which say that this success criterion violates usability).

Combined with proposal 1, this could close issue 1044.

(According to the feedback, the old proposal was not acceptable at level 1. The current wording was found helpful, easier to understand and to test against, etc. The last sentence of the old poposal was more tentative and was intended to close issue 1459. However, the fact that Section 504 requires more than WCAG is not a problem, so extensions for time-based testing don't need to be covered here.)

</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 (conflicts with usability) and 1383 (let user request update, rather than postpone automatic update)]</rationale>

<consequences>example 2 should change (issue 1385: non-default user settings harm accessibility)</consequences>

This proposal was rejected in favour of a modification of the current wording:

Non-emergency interruptions, such as the availability of updated content, can be postponed or suppressed by the user.

However, 5 found the proposal better than the current wording, while 5 preferred the current wording.

<updatedProposal>

Non-emergency interruptions, such as the availability of updated content, can be postponed or suppressed by the user on a site-wide basis for the complete set of delivery units.

</updatedProposal>

<rationale>

The modified wording of the current wording and the new proposal reject issue 1348, but neither addressed a question raised in issue 1383: 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? The new proposal addresses this.

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

Resolution from 26 May 2005 teleconference: discuss this benefit on the mailing list. See thread starting at GL 2.2: new benefit (low computer literacy). Comments:

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

Proposal 10

<sc>L2 SCx / L3 SCx</sc>

<proposed>

When an authenticated session has an inactivity timeout, the user can continue his activity without loss of data after re-authenticating.

</proposed>

<current> None. </current>

<rationale>

Server-side timeouts are not covered at level 1; see summary of issue 1525.

</rationale>

Accepted/Rejected Proposals

Proposal 3

This proposal was accepted on 26 May 2005 and closed issue 1500.

<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

This proposal was accepted on 26 May 2005 and closed issue 1501.

The guide document should clarify issues with differences between level 1 and this success criterion, e.g. a test that conforms to level 3 does not have a timeout.

<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 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, closed 31 May 2005).</rationale>

Proposal 7

<x>Benefit 2</x>

In the 13 June internal draft, benefit 2 now has the following wording:

People with physical disabilities can access content that is updated often.

<proposed>

People with physical disabilities can have sufficient time to access content that is updated often in cases

</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) See issue 802 (IBM: reword) and issue 987 (RNID).

However, this issue refers to the wording of the 19 November 2004 Working Draft; the wording in the 11 February 2005 Working Draft is much shorter: People with physical disabilities can access content that is updated often. Do we still consider this issue as relevant?

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

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

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?

Issue relates to L2.

Recommended actions:

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:

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. When 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 presented 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 at level 1. See proposal 10.

Rationale:

Short Issue Overview

L1

L2 (both SCs)

1382 (usability problems)

L2 SC1

L2 SC2

1500 (describe functional outcome and improve readability)

L3 SC1

1501 (wording proposal)

L3 SC2

benefit 1

802 (rewording)

benefit 2

987 (Add people who use an interpreter to the benefits)

benefits

1432 (unsolicited transitions confuse: add new benefit: low computer literacy)

examples

Long Issue Overview

Guideline 2.2 has 22 issues (see http://tinyurl.com/dg3a6 or full URL for Guideline 2.2 issues ).

Roberto Castaldo wrote an issue summary on 28 October 2004.

Jason White thought that GL 2.2 is a user agent problem (Wed, 3 Nov 2004 17:53:17); Joe Clark seemed to agree (Wed, 3 Nov 2004 16:57:48).

GL 2.2 was discussed in the 4 November 2004 call:

most of the issues are around parameters in the guidelines

values specified in current draft seem to be subjective

biggest issue from bugzilla is to decide whether we should maintain numerical parameters or if we should try simple and not subjective approach (ex. 3 seconds of blinking vs. not blinking at all)

numerical values can be good for some users, but not any user (ex. chatrooms can be considered live events in that users have difficulty going back through logs, but if only talking with one person, it is no longer a live event)

if we could agree to not set numerical values, most issues would be addressed

John Slatin:

  1. I don't think we can say "no moving content" because that would mean no site w/ video or animation could conform
  2. not sure chat room example works because there isn't necessarily a time limit in the chatroom - it's a funciton of how quickly participants type and whether the user agent allows users to scroll back

Gregg Vanderheiden:

Issue 943: Why 10 times the default?

L1 SC1 second bullet:

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 (…)

James Craig asked: How was the "at least ten times" decided? (public comment, Mon, 10 May 2004 22:27:36)

Roberto Castaldo commented:

Same as before: if we admit that "default timeout" concept has sense (I do not think so), "at least ten times" is just a starting point on which we should think a lot; once again the problem is about fixing numerical references and thresholds which - imho - have no sense at all.

CS: This bullet was introduced in the 24 April 2002 internal Working Draft (and in the 22 August 2002 public Working Draft). It was not in checkpoint 2.4 of the 24 August 2001 public Working Draft or checkpoint 2.4 of the 26 October 2001 internal Working Draft . See Gregg Vanderheiden's WCAG 2 Restructuring Proposal [DRAFT].

Issue 1044: Suggestions for time-limits guideline

Harvey Bingham (27 August 2004) had five comments (three of which are still relevant):

Level 1 Success Criteria for Guideline 2.2: "over a wide range which is at least ten times the length of the default setting"
presumes there is a default setting. Some may wish it to be faster, others slower.

Level 2 Success Criteria for Guideline 2.2: "User is allowed to turn off content that blinks for more than 3 seconds. "
Why not allow total turn-off of blink?

Example of Guideline 2.2: Add "or never allow it" so that it reads, "The content provides an option that allows the user to turn off the blinking +or never allow it.+"
[request for clarification:] The audio channel might be used as an alternative to blinking text?

First comment: see issue 879 (closed; US Access Board said that there is often no default). Further discussion necessary: should we remove or modify that bullet? (Proposal for issue 1381 solves this.)

Second comment: proposed rewording of GL 2.2 L2 SC1:

Content does not blink, or a method is provided available to stop any blinking content in the delivery unit that blinks for more than 3 seconds, or a method is available to disallow blinking entirely in the content of the delivery unit.

Current wording:

A method is provided to stop content that blinks for more than 3 seconds.

If the 3 seconds are somehow important, clarify this in the benefits section. [E.g. If content flashes for less than three seconds, it does not cause photo-sensitive epilepsy?? Is this independent of the frequency? Examples of blinking text can be viewed at: http://www.nics.gov.uk/acc/designers/designdesigners/design_designers2.4.html. Some scientific background can be found in the article "Visual Sensitivity and Epilepsy: A Proposed Terminology Classification for Clinical and EEG Phenomenology" by Dorothée G. A. Kasteleijn-Nolst Trenité et al, in Epilepsia 42 (5): 692-701, 2001.]

Third comment: covered by rewording (see discussion of previous comment).

Consequences of rewording:

Issue 1092: Time limits in Guideline 2.2 are still too small

IBM (Andi Snow-Weaver, 30 July 2004) commented:

SC Level 1 uses a time that is at least 10 times the original setting. 10 times the default can still be a very small number. If the default is 1 ms, the "accessible" time is 10ms, hardly an improvement for a motion impaired user. There should also be a minimum absolute time as well. Something like "adjust the time limit over a wide range which is at least ten times the length of the default setting and a minimum of 30 seconds in duration".

See also issues 879 (there is often no default) and 943 (why ten times?).

In the 4 November 2004 call, Roberto Castaldo's proposal to simple allow the user to request more time and remove the other bullets, was rejected because it was not practical: different choices apply to different types of time limits (Gregg Vanderheiden).

Proposal:

Issue 1346: GL 2.2, SC L1 conflicts with usability

Catherine Brys wrote (10 Januery 2005):

(…) some guidelines seem to be suggesting practices which are questionable from a usability point of view. (…)

Level 1 Success Criteria for Guideline 2.2: 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 1381: GL 2.2,SC L1 - there should be no time limits if not essential

Catherine Brys wrote:

Level 1 Success Criteria for Guideline 2.2

The fact that the user is allowed to deactivate the time limit conflicts with the fact that the time limit would be essential. The fact that the time limit will expire anyway if the user does not react within 10 seconds, means that the user has to keep paying attention to what is going on - this can be a problem in a noisy environment or if the user is performing another activity at the same time. It can also be a problem for users with concentration problems, especially if they are being distracted by other activities going on around them.

The first three options (being able to deactivate the time limit, being able to adjust it and being warned) are not really ideal from a usability point of view. 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.

Either the time limit is essential (e.g. in competitive gaming) or it isn't and in that case the time-limit should not be there.

CS: If timing is essential (e.g. e-learning assessment), why is the user performing this activity in an inappropriate (e.g. noisy) environment? Is it the author's responsibility that activities where timing is essential can be performed in inappropriate environments?

A bold proposal: replace this success criterion with:

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.)

This would also close issues 943, 1092, 1346, 1384, and part of 1044.

To close issue 1459, it would be necessary to change the proposal:

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.

Issue 1459: time limits should not apply to testing

Silvia Caras wrote:

"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."

I believe that the US ADA allows extensions even for time-based testing as a disability accommodation, so I'd like to see this comment be more forgiving.

CS:

Issue 1382: GL 2.2, SC L2 usability problems

Catherine Brys wrote:

Level 2 Success Criteria for Guideline 2.2 Points 1 and 2:

Again this can lead to violation of basic usability guidelines. Should the option to turn off, pause or stop be allowed? Is providing the option to turn off, pause or stop good enough? Should content authors not be encouraged to provide a usable experience for end users? At which level would turning off or pausing/stopping apply? For every individual bit of text? This would mean that it is ok to have a page with 10 blinking pieces of text which the user must click individually to stop the blinking.

CS: See also issue 1044. 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 880: Should blinking and movement be covered?

From Recommendations from City University on the WAI Guidelines (Appendix 2 of DRC report):

In addition, the Guidelines should place special emphasis, in the form of elevated prioritisation, on the following matters already covered:

(…)

US Acess Board (?) writes:

In the explanation of this section, reference is made to what can be summed up as dynamic content. It seems that this section is saying a user should be able to freeze dynamic content. And as pointed out by the authors, taken to its extreme, these guidelines would mean that all live presentations could be frozen or resumed by the viewer.

In our opinion, this is a stretch for timed responses. The original concept was aimed at helping those who may not be able to react fast enough before a form or dialog disappeared. Whether the concept of controlling refresh rates etc should be addressed is not the issue here. the problem here is a clouding of the main purpose of this valuable guideline by trying to have it cover to broad a group of events.

Also, we believe that trying to include blinking events as timed events is inappropriate, the concept being addressed is timed responses required of the user.

Roberto Castaldo writes:

Is this section saying that a user should be able to freeze any kind of dynamic content? If so, all live presentations could be frozen or resumed by the viewer. And more… Considering blinking events as timed events is not appropriate. Then, the guidelines should cover the need to avoid movement in pages until they can be frozen.

My opinion is that we should avoid all temporary concepts in WCAG 2.0; saying "until user agents…" only adds problems in understanding and implementing such guidelines; we will never have the ideal situation where all user agents will permit to froze movement in pages, so all we can do is forbid movement in pages.

The final comment on issue 880 states that the proposal was accepted in the 4 November 2004 conference call and included in the 19 November working draft, and

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.

CS: This is confusing: if the proposal is accepted, why is the issue still open? It would be better to create a new issue specific to success criterion 2 and to close issue 880. (With an appropriate summary or other metadata, it should then become easier to retrieve issues that depend on baseline decisions.)

Issue 1347: GL 2.2, SC L2 conflicts with usability

Catherine Brys wrote:

(…) some guidelines seem to be suggesting practices which are questionable from a usability point of view. (…)

Level 2 Success Criteria for Guideline 2.2: 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.

CS: Add level-3 success criterion: "content does not blink"? Or see proposal 1.

Issue 1499: 2.2 L2 SC1 - describe functional outcome

After the baseline impact analysis, John M Slatin wrote:

The following proposal resulted from a report on the impact of not setting baseline and writing success criterion as functional outcomes:

GL 2.2 level 2 success criterion 1: A method is provided to stop content that blinks for more than 3 seconds

Impacted: no

Note: change suggested to describe functional outcome

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

CS: This is addresed by the proposal for issue 1044.

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

After the baseline impact analysis, John M Slatin wrote:

The following proposal resulted from a report on the impact of not setting baseline and writing success criterion as functional outcomes:

GL 2.2 level 2 success criterion 2: A method is provided to pause and/or permanently stop dynamic (moving or time-based) content

Impacted: no

Note: change suggested to describe functional outcome and improve readability

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

Recommended action: Accept.

Issue 1501: 2.2 L3 SC1 - wording proposal

After the baseline impact analysis, John M Slatin wrote:

The following proposal resulted from a report on the impact of not setting baseline and writing success criterion as functional outcomes:

GL 2.2 level 3 success criterion 1: 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

Impacted: yes

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

Recommended action: Accept.

Issue 1348: GL 2.2, SCL3 conflicts with usability

Catherine Brys wrote:

(…) some guidelines seem to be suggesting practices which are questionable from a usability point of view. (…)

Level 3 Success Criteria for Guideline 2.2, Point 2: Again, 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. Also, interrupting with the option for the user to postpone the interruption makes that the user is not in control - he can merely refuse interruptions which are being forced upon him (but by this process the user is interrupted anyway).

CS: If interruptions can be suppressed (generally for a session, instead of on an instance-by-instance basis), the content should be more usable. See also issue 1383.

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

Catherine Brys wrote:

Level 3 Success Criteria for Guideline 2.2, Point 2

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. Also, interrupting with the option for the user to postpone the interruption makes that the user is not in control. Should it not be the other way around that the user can request an update of the content if he wishes so?

Again, the question raises - 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?

CS: This is almost identical to issue 1348 except for the addition of level at which interruptions can be postponed. The following wording may close issues 1348 and 1383:

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

Current wording:

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

Consequence of rewording: example 2 should change (issue 1385).

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

After the baseline impact analysis, John M Slatin wrote:

The following proposal resulted from a report on the impact of not setting baseline and writing success criterion as functional outcomes:

GL 2.2 level 3 success criterion 2: Any non-emergency interruptions, such as the availability of updated content, can be postponed and/or suppressed by the user

Impacted: no

Note: change suggested to describe functional outcome and improve readability

<proposed>Any non-emergency interruptions, such as updating content, can be postponed or suppressed by the user.</proposed>

Issue 802: Rewording of benefits

IBM (11 March 2004 Working Draft):

Benefits are written as issues instead of benefits. Proposed rewording of first benefit: "People with reading disabilities, cognitive disabilities, and learning disabilities who may need more time to read and comprehend written text will be given additional time to read the information."
Proposed rewording of 2nd bullet: "People with physical disabilities can have sufficient time to process and read information before it is refreshed."

Roberto Castaldo supported this proposal, but it was not discussed in the 4 November 2004 call because it is “informative”.

CS:

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

RNID:

We would welcome some mention of the extra time that may be required by people who are using an interpreter to help them with some of the content on a site, in order to raise awareness among designers that this is one group who they should cater for. This mention would be best placed in the “Benefits of [Guideline 2.2]” section, e.g. in the last sentence: “…by an assistive technology, voice browser, or a sign-language interpreter relating audio content to a user”

CS: I would accept this proposal, but the sentence is not very readable (“cases where ... and ... or when ...”). Unless I misundertand the intention of benefit, it could be reworded as follows:

People with physical disabilities can have sufficient time to access content that is updated often in cases

The current wording is:

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.

Issue 1432: Guideline 2.2 - unsolicited transitions confuse

David Woolley wrote (and Catherine Brys agreed):

In the benefits for 2.2, I think it should be pointed out that 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.

CS: Add benefit:

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

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

IBM (11 March 2004 Working Draft):

Examples of content that must meet the success criteria, last sub-bullet - "shutdown or deactivation of a resource if activity is not received in a set amount of time" sounds like server timeouts which are not under the control of the content. Remove or reword.

CS: I agree; this sounds like a session/server timeout. Server timeouts are not under control of the content in the delivery unit, although the author may have control over this when writing server-side scripts. We have two choices:

  1. Remove this bullet. This brings the examples in line with the resolution of 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).
  2. Revert the resolution of issue 800, and add relevant examples to a techniques document on server-side scripting (which does not exist yet).

This issue was not discussed in the 4 November 2004 conference call because it is “informative”.

Issue 1349: GL 2.2 Example 2 conflicts with usability

Catherine Brys wrote:

(…) some guidelines seem to be suggesting practices which are questionable from a usability point of view. (…)

Example 2 of Guideline 2.2 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. For example, if the link to the preferences section would be at the very bottom of a page, chances are small that e.g. screen-reader users would encounter the option.

CS: Updating of content should be turned of by default?

Issue 1384: GL 2.2 examples conflicts with guideline?

Catherine Brys wrote:

Examples of Guideline 2.2: "dialog that disappears after a short period"

Does this mean that the user must be able to avoid that the dialog box will disappear? But Level 1 Success Criteria for Guideline 2.2 itself uses a warning which times out after at least 10 seconds. Is this not conflicting?

CS: The proposal for issue 1381 closes this issue. The example is relevant: a dialog can only disappear after a short period if that kind of behaviour is essential to the interaction.

Issue 1385: non-default user settings harm accessibility

Catherine Brys wrote:

Examples of Guideline 2.2 Example 2:

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. For example, if the link to the preferences section would be at the very bottom of a page, chances are small that e.g. screen-reader users would encounter the option.

CS: The example should be revised if the proposal for issue 1383 is accepted. until then, the issue should be left open.

Issue 1525

Philip Naylor wrote:

Guideline 2.2 doesn't obviously cover an important scenario - that of an authenticated session suffering an inactivity timeout, particularly if this happens when the user submits a form. I would suggest that when this happens:

  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.

CS: This is primarily a usability issue. If we don't cover server timeouts (see issues 800 and 803), then there is no need to add this to the guideline.

Current State of GL 2.2

Level 1 Success Criteria for Guideline 2.2

  1. 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.

Level 2 Success Criteria for Guideline 2.2

  1. A method is provided to stop content that blinks for more than 3 seconds. [I]
  2. Moving or time-based content can be paused by the user. [I] [26 May 2005, closed issue 1500]

Level 3 Success Criteria for Guideline 2.2

  1. Except for real-time events, timing is not an essential part of the event or activity presented by the content. [V] [26 May 2005, closed issue 1501]
  2. Non-emergency interruptions, such as the availability of updated content, can be postponed or suppressed by the user. [V] [26 May 2005]

--
Christophe Strobbe