- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:26:11 -0700
- 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 http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/ 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. Regards, 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 disabilities. --------------------------------------------- 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 content. ---------------------------- 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 http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels. ---------------------------- 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 disabilities. 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 nature. --------------------------------------------- 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 disabilities. 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 guidelines. ---------------------------- 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 baseline. ---------------------------- 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 determinable. 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) SOME OF THE SUFFICIENT TECHNIQUES FOR 1.3.1 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) SOME OF THE FAILURES OF 1.3.1 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