<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>
<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]
- 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 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>
<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;>
<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:
A decision was made to only include benefits that related specifically to people with disabilities.
Even if we do decide to include descriptions of how our SC benefit older users, we should not include identify possible benefits for people with limited computer skills. That would seriously weaken the credibility of WCAG.
</rationale>
<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>
<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>
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>
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>
<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>
<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>
Issues are ordered by sections of the guideline: success criteria, benefits, examples.
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).
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.
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.
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.
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).
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.
Should blinking and movement be covered?
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.]
Issue relates to L2.
Recommended actions:
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).
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.
2.2 L2 SC1 - rewrite as functional outcome
Recommended action: Accept if proposal 1 is rejected.
Proposal 1 takes this issue into account.
2.2 L2 SC2 - describe functional outcome and improve readability
Recommended action: accept (this is proposal 3)
2.2 L3 SC1 - wording proposal (describe functional outcome)
Recommended action: accept (this is proposal 4).
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)
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)
2.2 L3 SC2 - describe functional outcome and improve readability
Recommended action: accept if proposal 5 is rejected.
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.
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.
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).
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:
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.
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.
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.
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:
Issue relates to: L1.
Recommended action: Reject at level 1. See proposal 10.
Rationale:
1382 (usability problems)
1500 (describe functional outcome and improve readability)
1501 (wording proposal)
802 (rewording)
987 (Add people who use an interpreter to the benefits)
1432 (unsolicited transitions confuse: add new benefit: low computer literacy)
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:
- I don't think we can say "no moving content" because that would mean no site w/ video or animation could conform
- 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:
- only 2 items that talk about timing is time for users to respond (10 seconds) and letting things blink for 3 seconds
- chat room example doesn't apply to criteria with 10 second req.
applies to a single action- numbers are based on years of work with inidiv. who have physical disabilities
- flip side is that if you set times too long, then you have someone at a banking site and when users stop interacting, sites need to sign you off if the user is no longer there
- if we don't put down 10 seconds, people often choose times that are inadequate
- trying to outlaw any blinking to attract attention is a problem because it can be helpful for people with cognitive disabilities if you want to attract attention to it
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].
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
providedavailable to stop any blinking content in the delivery unitthat blinksfor 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:
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:
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.
(…)
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.
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:
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.
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:
(…)
- the need to avoid movement in pages until they can be frozen.
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.)
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.
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 secondsImpacted: 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.
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) contentImpacted: 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.
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 guidelineImpacted: 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.
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.
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).
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 userImpacted: 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>
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:
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
- 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.
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.
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.
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:
that is a function of the contentwas 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 issue was not discussed in the 4 November 2004 conference call because it is “informative”.
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?
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.
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.
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:
- it should be clear to the user what has happened.
- the user should be given the opportunity to re-authenticate themselves.
- 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.
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.
--
Christophe Strobbe