W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > November 2007

Your comments on WCAG 2.0 Public Working Draft of May, 2007 (1 of 3)

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Sat, 3 Nov 2007 21:26:11 -0700
Message-ID: <824e742c0711032126r74ddb839x244252b519ceffe8@mail.gmail.com>
To: "Gian Sampson-Wild" <gian@tkh.com.au>
Cc: public-comments-WCAG20@w3.org

Dear Gian SampsonWild,

Thank you for your comments on the 17 May 2007 Public Working Draft of
the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group
has reviewed all comments received on the May draft, and will be
publishing an updated Public Working Draft shortly. Before we do that,
we would like to know whether we have understood your comments
correctly, and also whether you are satisfied with our resolutions.

Please review our resolutions for the following comments, and reply to
us by 19 November 2007 at public-comments-wcag20@w3.org to say whether
you are satisfied. Note that this list is publicly archived. Note also
that we are not asking for new issues, nor for an updated review of
the entire document at this time.

Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the
archived copy of your original comment on
http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may
also include links to the relevant changes in the WCAG 2.0 Editor's
Draft of May-October 2007 at

Thank you for your time reviewing and sending comments. Though we
cannot always do exactly what each commenter requests, all of the
comments are valuable to the development of WCAG 2.0.


Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact

On behalf of the WCAG Working Group

Comment 1: LC-1021: testability, cognitive disabilities
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0157.html
(Issue ID: 2033)
Original Comment:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1021)

Cognitive disabilities - People with cognitive disabilities are unfairly
discriminated against within WCAG2. I believe this is due to the usability
and testability requirements. It is generally accepted (and one chair has
said so explicitly) that requirements that assist people with cognitive
disabilities are often general usability techniques. Criteria that assist
people with cognitive disabilities is more likely to fall foul of the
requirement for testability than other criteria, simply because these
criteria recommend changes to the way content is written, not how a site is
coded. For example, in WCAG1 Checkpoint 14.1 - Use the clearest and simplest
language appropriate for a site's content - still has no clear equivalent in
WCAG2 and partiallymaps to Level 3success criteria.

Proposed Change:

Set up a specific taskforce within WCAG WG to identify success criteria that
should be added to ensure WCAG2 addresses the needs of people with cognitive
disabilities (I volunteer to be a part of, or to head up, this taskforce),
or comply with Lisa Seeman's suggestions in her formal objection (which I
have cosigned)

Response from Working Group:

We have added language to the Introduction, the Conformance section, and the
Quick Reference to highlight the fact that WCAG 2 only addresses some of the
needs of people with cognitive, learning, and language disabilities, and to
call out the need for more research in this area. WAI is exploring ways in
which to support and encourage work in this important area.

We have added some best practices for cognitive, learning, and language
disabilities as advisory techniques, and we have proposed 3 new success
criteria in this area.

Response to Working Group:
I still do not believe that the WG is doing enough in the area of cognitive
disability and I believe this is to do with both the testability and
usability requirements (but mostly the former). The recent taskforce and
subsequent changes to WCAG2 do not actually assist people with cognitive

Response from Working Group:

Thank you for your comment.  We also struggled under the testability
constraint, but in the end, the W3C cannot ask authors to conform to
something (or expect them to include the standard in purchases or work
orders) if the authors
cannot tell when they have met the criteria.  It is important to
remember two things:

1) That these are base standards for accessibility. The starting point
that authors should do.

2) WCAG includes both requirements (success criteria) and
recommendations (guidelines and advisory techniques).

  - Only the requirements (the test points or checkpoints) need to be
testable (and this can be machine testable OR human testable OR a
combination of both).

  - The guidelines themselves as well as the advisory techniques do not
need to be testable and they contain much guidance and information on how to
make a page accessible that goes beyond what can be tested.

Thus, WCAG provides a roadmap both for those who only want to (or only will)
do what is required as well as for those that are interested in knowing
what to do, without needing to be required to do it.  The former have a list
of "to do's" that they can be given and held accountable for.   The latter
have a rich listing of advice on things to consider that would make things
more accessible.

We hope to find people interested in putting together an application note
that is specifically targeted at Cognitive, Language and Learning
disabilities and that organizes all the information in this area in a manner
that does not worry about testability, and presents all ideas in a
simple straightforward manner.

If you are interested in helping on this, please let us know.

We have also added a new success criteria at level three that deals
with the legibility of text.

1.4.8 : For the visual presentation of blocks of text, a mechanism is
available to achieve the following: (Level AAA)

-foreground and background colors can be selected by the user
-width is no more than 80 characters:
-text is not aligned on both the left and the right
-line spacing is at least space-and-a-half within paragraphs, and paragraph
spacing is larger than line spacing
-text is resized without assistive technology up to 200 percent in a
way that does not require the user to scroll horizontally to read a
line of text

and there are Advisory techniques for this Success Criteria also:

Using a hover effect to highlight a paragraph, list items, or table
cells(HTML, CSS)
Presenting text in sans serif font or providing a mechanism to achieve
this (CSS)
Using bulleted/numbered/vertical lists rather than inline lists
Using upper and lower case according to the spelling conventions of
the text language
Providing large fonts by default
Avoiding the use of text in raster images
Avoiding scaling font sizes smaller than the user-agent default
Providing sufficient inter-column spacing
Avoiding centrally aligned text
Avoiding chunks of italic text
Avoiding overuse of different styles on individual pages and in sites
Making links visually distinct
Providing expandable bullets
Show/hide bullet points]
Putting an em-space or two spaces after sentences

Comment 2: LC-1022: alternative text
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0160.html
(Issue ID: 2035)
Original Comment:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1022)

Testability - The decision to comply with the testability requirement has
outlawed some very important success criteria. This requirement has also not
been applied fairly to all success criteria. Some current success criteria
do not comply with the 8 out of 10 rule - for example 1.1.1. This SC
requires that alternatives to non-text content "serve the same purpose and
present the same information". One basic example of this is to require
equivalent ALT attributes for images, but I do not believe that 8 out of 10
people would agree on the same ALT attribute for an image. For instance, in
the Live in Victoria site
(www.liveinvictoria.vic.gov.au) there is an image under the heading
"Business Migrants". When I worked on this site, several people said this
image should have a null ALT attribute as it conveyed no information.
Several other people suggested ALT attributes of "A couple of business
migrants chatting at work" or "Guys chatting at work". Whereas the ALT
attribute that I recommended was "There is a wealth of opportunities for
Business Migrants in Victoria."

Proposed Change:

Remove the requirement for testability and set up a taskforce (I volunteer
to work on or head up this taskforce) to identify criteria that should be
included in WCAG2. Alternatively, develop a set of supplementary guidelines
that are non-testable to be used in conjunction with WCAG2.

Response from Working Group:

The success criteria need to be testable or else people cannot tell when
they have conformed to the success criteria and thus WCAG 2.0.

With regard to SC 1.1.1 the success criterion does not require that ALT text
provided by different people be the same. WCAG 2.0 categorizes different
classes of alt text and provides test procedures to help humans evaluate
whether alt text satisfies the success criterion.

Advisory techniques are used to provide supplemental materials that are
non-testable that can be used in conjunction with WCAG 2.0.  They provide
additional guidance on what can be done beyond the requirements of WCAG.
Response from GSW:
If this SC does not require that alternative text from different people be
the same, then what does it require? It appears to allow the alternative
text of "image". It may be true that in supplementary documents there are
guidelines that indicate that "image" is not an appropriate solution to this
SC but this is not indicated in the *normative* document.

Response from Working Group:

The success criterion requires that the alternative provide equivalent
information.  There may be many different ways to do that. Our
requirement is that  people would agree that the SC was met, not that
they agree on the best way to meet it.

It is not required that people would create the same text alternative
for an image, but that people would agree that the text alternative
provided for an image is acceptable.

The term "image" does not provide equivalent information. Therefore,
it would fail based on the success criterion not on the intent section
of the Understanding Document. The role of the intent section of the
Understanding Document is to help the author understand the success
criterion rather than to introduce additional criteria.

Also for this particular example, we have a documented failure (F30).
While this is not normative it is used to help clarify what
constitutes a failure of this success criterion.

Comment 3: LC-1024: conformance levels
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0161.html
(Issue ID: 2036)
Original Comment:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1024)

Conformance schema - The decision to remove the design requirement from
Level 1 has meant there is no appreciable difference between Level 1 and
Level 2. I recall many instances where SC were moved to L2 because of this
design requirement, yet I have not seen any indication that these SC are
being moved back in to L1.

Proposed Change:

Merge Level 1 and Level 2 SC into one group called "Mandatory". Rename Level
3 to "Advisory" or "Optional" Alternatively set up a taskforce (which I
volunteer to be a part of, or head) to review L2 and L3 SC to see if they
can be moved to L1.

Response from Working Group:

The working group feels that there are three categories of success criteria,
so we have retained three levels of conformance. The description of
conformance levels in WCAG 2 has been rewritten to clarify the levels (see
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ):

The word "levels" does not mean that some success criteria are more
important than others. Each success criterion in WCAG 2.0 is essential to
some users, and the levels build upon each other. However, even content that
conforms at AAA (triple-A) may not be fully accessible to every person with
a disability.

*In general, Level A success criteria achieve accessibility by supporting
assistive technology while putting the fewest possible limits on
presentation. Thus people with a wide range of disabilities using a wide
range of assistive technologies, from voice input and eye-tracking devices
to screen readers and screen magnifiers, are able to access content in
different ways. In other words, Level A success criteria support the ability
of both mainstream and specialized user agents to adapt content to formats
that meet their users' needs.

*The success criteria in Level AA provide additional support for assistive
technology. At the same time, they also support direct access to content by
the many people who use conventional user agents without assistive
technology. In general, Level AA success criteria place more limits on
visual presentation and other aspects of content than the success criteria
in Level A.

*Level AAA success criteria increase both direct access and access through
assistive technology. They place tighter limits on both presentation and
Response from GSW:
Firstly I strongly object to the statement: "However, even content that
conforms at AAA (triple-A) may not be fully accessible to every person with
a disability or combination of disabilities, especially certain types of
severe disabilities." I believe that a statement like this is a cop-out: the
WG is chartered to develop guidelines that assist people with disabilities
use the web.

Secondly I do not think this explanation of the levels is clear enough -
although it is more clear than previously. Are you indicating that only SC
at Level AA assist people using browsers etc to modify content to their
preferences? Because this is how it currently reads. What I expect the WG
actually means is that Level A is for assistive technologies and people
using browsers etc but puts as little limit on the design as possible. I
suspect the difference between the three levels is purely one of design and
content limitation, however this is not clear.

Response from Working Group:

While 'design and content limitation' is one factor it is only one
factor that determines levels. ["Understanding levels"] in the
Understanding WCAG 2.0 provides a description of the many factors that
are considered.

Regarding the sentence saying that even level AAA won't meet
everyone's needs:  We feel that it is very important to include the
statement because we believe it is true. We do not want people to
assume that WCAG 2.0 contains all that is required to address all
disabilities, or that all that an author needs to do is to meet these
conformance requirements. We also expect that knowledge about
different disabilities and ways to accommodate them will continue to
grow, and that there will be additional information available, either
in future revisions of these guidelines or from other sources.  We
have strengthened the introduction to ensure that people look at the
full set of guidelines, SC, and techniques (both sufficient and
advisory).  We also recommend that they seek outside help and guidance
as well.

Comment 4: LC-1026: Names of conformance levels
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0162.html
(Issue ID: 2037)
Original Comment:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1026)

Conformance schema - The documents say that all success criteria are
essential to people with disabilities (see WCAG 2.0 under 'Conformance' -
"The WCAG WG believes that all SC ..."), however by using the WCAG1
labelling system this change is not obvious. In addition to this, the
Conformance section specifically states a hierarchical nature to the to the
SC in WCAG2 by defining Level 1 as
"achiev(ing) a minimum level of accessibility", Level 2 as
"achiev(ing) an enhanced level of accessibility" and Level 3 as
"achiev(ing) additional accessibility enhancements". The Conformance section
is contradictory, because in the subsequent paragraph it says "Each
checkpoint in WCAG 1.0 was assigned a "priority" according to its impact on
accessibility... the system of checkpoints and priorities used in WCAG 1 has
been replaced...". By using the subjective terms Priority 1 / A in WCAG2,
the WG is implying that there is a hierarchical nature to the SC. People are
used to the WCAG1 labelling system and will assume that by following all
Level A SC that they are creating an accessible web site.

Proposed Change:

Merge Level 1 and Level 2 SC into one group called "Mandatory". Rename Level
3 to "Advisory" or "Optional"

Response from Working Group:

The working group feels that there are three categories of success criteria,
so we have retained three levels of conformance. The description of
conformance levels in WCAG 2 has been rewritten to clarify the levels. See
Response from GSW:
Please see my response to comment LC-1024.

I think you misinterpreted my comment. I was not arguing (in this comment)
for changing the numbers of levels I was arguing against the current
terminology. I was arguing that by using the WCAG1 terminology (which had a
hierarchical nature: Level A was more important than Level AA, which, in
turn, was more important than Level AAA), the WG was indicating that the SC
within WCAG2 had an inherent hierarchical nature - which is not the case:
the WG has said very clearly that each and every SC (whether in Level A or
Level AAA) may be integral to a site being accessible to people with

Seeing as WCAG2 does not employ a hierarchical level set like WCAG1 then it
should not use the hierarchical methodology of WCAG1. I recommend using
Level X, Level Y and Level Z or Level P, Level Q and Level R, or even Level
~, Level ^ and Level &. Or you could use Level Blue, Level Green and Level
Red. Whatever the WG chooses should not have an inherent hierarchical

Response from Working Group:

The working group has moved away from the Priority 1, 2, 3 because it
sounded like the items at Level AAA were only 3rd priority things when
they are in fact very important to people with different disabilities.
 Things ended up in Level AAA for a number of reasons including the
fact that they could not alway be applied.  But not because they were
'low priority'.

As you point out, Level 1, 2, 3 give much the same impression because
of their similarity to Priority  1, 2, 3.

However, the Working Group has decided not to adopt a different naming
scheme than A, AA, and AAA. This is for consistency with other W3C
specifications and to avoid potential confusions caused by other
naming schemes that were considered.

We hope the non-numeric levels and the language used in the (new)
introduction help to make the point that people should do all they can
from all three levels.  We have strengthened the introduction to
reflect this better.

Comment 5: LC-1027: making web content accessible to all people
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0163.html
(Issue ID: 2038)
Original Comment:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1027)

Definition of accessibility - In the Baseline document (under the heading
'If the WCAG does not set the baseline, then how can we be sure that a site
will be accessible?) it says "No site or content is ever completely
accessible". In the Conformance document it says "Note that even conformance
to all three levels will not make web content accessible to all people." I
strongly object to these statements. All content can be made accessible. In
some cases, content may not be accessible, but if the problems were
identified it could be made accessible. As the main body representing
accessibility I think it reprehensible that we have these statements.

Proposed Change:

Remove the statements. Merge Level 1 and Level 2 SC into one group called
'Mandatory'. Rename Level 3 to 'Advisory' or 'Optional'

Response from Working Group:

The statements you refer to are meant to reflect the reality that not all
Web content can be made accessible to all people. One of the lessons learned
with WCAG 1.0 was that, for some individuals, even content that meets WCAG
1.0 AAA did not overcome the accessibility barriers faced by those with
certain combinations of disabilities or with certain types of severe

Regarding the proposal to combine levels A and AA as mandatory and rename
level AAA to advisory or optional, the working group has received a great
deal of feedback on both sides of this issue. We have chosen three levels
because we feel it provides the best options for the different users of the
Response from GSW:
I still stand by my original comment.

Response from Working Group:

We addressed this issue many times and could find no consensus to
group into two levels as you suggest. Some could live with two levels
only if 1 and 2 were combined.  Some could live with two levels only
if levels 2 and 3 were combined as advisory.  Some wanted two levels
with level 3 dropped.   Reviews from outside were equally divided.  In
the end the 3 level system was found to be the best overall approach.

Comment 6: LC-1034: turning off technologies
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0188.html
(Issue ID: 2047)
Original Comment:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1034)

Baseline - Has the WG given any thought to people who decide to turn off
technologies that could be in a baseline (eg. Javascript, Flash
etc) because that is their preferred way of browsing - due to their
disability?  Has the WG given any thought to people who use assistive
technologies that cannot interpret the output of certain technologies (eg.
some screen readers cannot use javascript)?

Proposed Change:

Remove the baseline theory, or allow only UAAG compliant programs in

Response from Working Group:

The working group has debated issues such as these extensively. The concept
of baseline (now "accessibility-supported content
technologies") grew out those struggles. If the assistive technologies that
people use do not support certain technologies, then those technologies are
not accessibility-supported Web technologies. However, people turning off
support for technologies because they prefer not to use them is not an
accessibility issue, since people without disabilities who choose to disable
certain technologies will have equal difficulty accessing the content.

Your proposal is that the only technologies that can be used are those for
which there exist UAAG-compliant user agents. Since there are not yet any
fully UAAG-compliant user agents, this requirement would mean that there
could be no WCAG-complaint content possible. And the existence of a
UAAG-compliant user agent doesn't mean that users have it available to them.
So requiring UAAG-compliant user agents is not a guarantee of accessibility
(although WCAG would be much easier to write if it could rely on UAAG
compliant user agents).
Response from GSW:
My concern was with people turning off technologies because they could not
interact with the content - due to their disability - when that technology
was enabled. For example, someone with a cognitive disability easily
distracted may choose to turn off Flash to turn off that flashing banner
which undermines their ability to read the content - if that then means that
they can't use the Flash navigation then what?

Response from Working Group:

Ah - we see what you mean.  WCAG covers that as follows:

If the Web page conforms to WCAG, it should not be necessary to turn
off a technology in order to access the page. So, a WCAG-conformant
page would not contain a flashing banner unless there was a way to
pause the flashing content.

For example, in the specific example you cite, there would be two
conforming cases:

1) The author relied on Flash. In that case, it would have to be
accessibility supported and there would have to be a way to pause the
Flash banner without turning off Flash.

2) The author did not rely on Flash. In that case, the user can turn
Flash off and the page must still meet WCAG with Flash turned off.

Either way, the person always has access to the full page with the
Flash banner stopped.

Comment 7: LC-1043: which AT?
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0196.html
(Issue ID: 2048)
Original Comment:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1043)

Definition: "For all non-text content one of the following is true.if
non-text content is pure decoration, or used only for visual formatting, or
if it is not presented to users, it is implemented such that it can be
ignored by assistive technology".  What is the definition of assistive
technology?  If one assistive technology behaves one way and another
assistive technology another, then how should this SC be followed?

Proposed Change:

Redefine this SC

Response from Working Group:

Assistive technology is defined in the Glossary at
http://www.w3.org/WAI/GL/WCAG20/appendixA.html#atdef .

Technology-specific techniques define sufficient mechanisms for marking
non-text content so that it will be ignored by AT. If there are differences
in behavior among different AT, these should be noted in the User Agent
notes for that technique.
Response from GSW:
I still believe that this brings up a serious testability concern. How can
this be tested? On which assistive technologies? On which versions? How do
you define "ignore" - only if the assistive technology ignores it on default
or if it is an option the user could choose? There is inconsistency between
screen readers reading alt="" - which is the most basic example of this
success criteria - so even this particular technique could be said not to
fully fulfill this checkpoint.

Response from Working Group:

The question of whether "it is implemented such that it can be ignored
by assistive technology" is testable interacts with questions of
accessibility support for the technology.

A sufficient technique for such a requirement can appeal to the
specification for the technology if it indicates that a mechanism is
intended for this purpose. OR it could appeal to the existence of at
least one assistive technology that does ignore content when the
technique is used, in one mode or another.

However, since success criteria can only be satisfied using
accessibility supported techniques, the technique chosen by the author
needs to be supported by his users' assistive technology. If the
behavior of the different AT is sufficiently inconsistent, there may
be no sufficient technique available. However, the success criterion
is still testable.

Comment 8: LC-1052: Level of 2.4.6
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0225.html
(Issue ID: 2064)
Original Comment:

Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer
(Issue ID: LC-1052)

2.4.5: This should be at Level 1. Descriptions, headings, labels etc are
very important for both people who use screen readers and people with
cognitive disabilities. Equivalent checkpoints in WCAG 1.0 are at Level AA

Proposed Change:

Move to Level 1

Response from Working Group:

We have added "descriptive" to SC 2.4.2 (formerly 2.4.3) and moved it to
level A.

SC 2.4.6 (formerly 2.4.5) has been moved to Level AA. It addresses
descriptive headings and labels, which may need to be understood in context.
While headings may not have sufficient descriptive power in isolation, when
viewed in the context of a structured document, they do have sufficient
descriptive power.
Response from GSW:
I still believe headings and labels should be at Level 1. How is a screen
reader user going to understand what to input into a field if it doesn't
include a label? Due to most screen readers' users reliance on headings to
navigate through a page, putting this at Level A is important.

Response from Working Group:

Because of the importance of labels and headings users of screen
readers, we have Level A SC to ensure they are programmatically

The issue of screen readers having access to a field is handled by
4.1.2 which requires that all user interface components (which an
input field would be) have to have a name and role that can be
programmatically determined (that includes being able to be determined
by Assistive technologies including screen readers.  4.1.2 is at level
A so your concern is handled at Level A.

As to headers, 1.3.1 requires that all structure be programmatically determined.
It has several specific failures that deal with this (and 1.3.1 is
also at level A)


G115: Using semantic elements to mark up structure

H42: Using h1-h6 to identify headings (HTML)

H44: Using label elements to associate text labels with form controls (HTML)


F2: Failure of 1.3.1 due to using changes in text presentation to
convey information without using the appropriate markup or text
(e.g. not marking headers as headers)

F43: Failure of SC 1.3.1 due to using structural markup in a way that
does not represent relationships in the content
(e.g. using header markup for formatting non-headers)

F68: Failure of SC 1.3.1 and 4.1.2 due to the association of label and
user interface controls not being programmatically determinable

Comment 9: LC-1121: SC 3.3.3 not testable
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0062.html
(Issue ID: 2322)
Original Comment:

Comment 94:

Source: http://www.w3.org/mid/001f01c695f9$31b504e0$9288b23a@tkhcomputer
(Issue ID: LC-1121)

Situation A - If an application causes a legal transaction.: what is a
"period of time"?  Is this going to be quantified? Should we be doing that?

Proposed Change:

Clarify the Technique

Response from Working Group:

When this technique is completed, guidelines for the period of time will be
qualified within the technique based on the situations provided. For
example, when accepting an on-line loan offer there may be a legal
requirement that the transaction can be reversed within a certain number of
hours or days.  A loan payment, however, may have a much shorter time period
to cancel.
Response from GSW:
If this is correct, then this SC is not testable.

Response from Working Group:

The technique only requires that a period of time be provided.  It is
testable to see if a period of time is provided.  It does not require
a specific period of time.  We have changed the technique to say

"Providing a stated period of time after submission of the form when
the order can be updated or canceled by the user "

It would then require that a period of time be specified for a Web
page and that period of time is provided (both testable).
Received on Sunday, 4 November 2007 04:26:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:45 UTC