- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:31:51 -0700
- To: "Chris Ridpath" <chris.ridpath@utoronto.ca>
- Cc: public-comments-WCAG20@w3.org
Comment 15: Source: http://www.w3.org/mid/20060602140636.9B52533205@kearny.w3.org (Issue ID: LC-670) Part of Item: Tests Comment Type: TE Comment (including rationale for proposed change): First step in test should be to check if longdesc is required. Proposed Change: Add first step \"Check if short text alternative is sufficient for image\". If not sufficient then go on to step 2. ---------------------------- Response from Working Group: ---------------------------- Since this technique is specifically about using a longdesc and a list of related techniques describing alternative techniques for including text alternatives is provided, the Working Group does not believe that the test procedure needs to determine whether or not a short text alternative is sufficient. A developer implementing this technique has already determined that a longdesc is necessary; the test procedure just needs to check whether the longdesc has been created correctly. ---------------------------------------------------------- Comment 16: Source: http://www.w3.org/mid/20060602141352.7FA5033205@kearny.w3.org (Issue ID: LC-671) Part of Item: Applicability Comment Type: TE Comment (including rationale for proposed change): HTML technqiues H46 and H53 are also referenced from SC 1.1.1. In SC 1.1.1 they are used for \"Providing long description for non-text content that serves the same purpose and presents the same information\". In SC 1.2.7 they are used for \"Providing a full multimedia text alternative including any interaction\". Are these the same thing? If different then there should be 2 techniques. Proposed Change: Clarify the use of H46 and H53 or create new techniques. ---------------------------- Response from Working Group: ---------------------------- These are technology specific techniques for providing any type of alternate content. They must be used in conjunction with a General technique that specifies what needs to be provided by the technique. The techniques are not sufficient by themselves. This is clearer in our new way of listing sufficient techniques. To see what this looks like go to the Quick Reference sheet and look up SC 1.2.7 http://www.w3.org/WAI/WCAG20/quickref/ ---------------------------------------------------------- Comment 17: Source: http://www.w3.org/mid/20060602141709.EB37733205@kearny.w3.org (Issue ID: LC-672) Part of Item: Applicability Comment Type: TE Comment (including rationale for proposed change): H51 seems to be the same as F34 \"using white space characters to format tables in plain text content\". Proposed Change: Remove either H51 or F34 or describe difference between them. ---------------------------- Response from Working Group: ---------------------------- Technique H51 is specific to HTML and F34 is specific to plain text. F34, Failure due to using white space characters to format tables in plain text content, does prevent tabular data in plain text content. An author using plain text must present the data in a format other than tabular (e.g. linear format). ---------------------------------------------------------- Comment 18: Source: http://www.w3.org/mid/20060602142221.3736133207@kearny.w3.org (Issue ID: LC-673) Part of Item: Applicability Comment Type: TE Comment (including rationale for proposed change): Contains the text \"Use of layout tables is not recommended...\". The text \"not recommended\" is unclear. Does this mean \"must not\" or \"should not\"? Proposed Change: Remove text \"not recommended\" or define its meaning. ---------------------------- Response from Working Group: ---------------------------- Layout tables may be used but we don't want to encourage their use. H39 has been modified to clarify the recommendation. ---------------------------------------------------------- Comment 19: Source: http://www.w3.org/mid/20060602142448.327CE33205@kearny.w3.org (Issue ID: LC-674) Part of Item: Applicability Comment Type: GE Comment (including rationale for proposed change): There needs to be a technique on the use of layout tables. Proposed Change: Add a technique describing the use of layout tables. Layout tables are OK as long as they are not nested too deep (more than 4 levels). They should not have too many rows or colums (not more than 4 X 4). ---------------------------- Response from Working Group: ---------------------------- The working group has previously considered creating a technique on using layout tables. We decided not to, however, because we don't want to encourage their use. Even though layout tables are supported by assistive technologies and create no accessibility problems on legacy sites, we do not want to encourage their use on new or modified sites. One issue with layout tables, however, is the failure to make sense when linearized which is addressed by technique F49. To clarify this, we have changed the title of F49 to "Failure of SC 1.3.3 due to using an HTML layout table that does not make sense when linearized". ---------------------------------------------------------- Comment 20: Source: http://www.w3.org/mid/20060602143220.B27BB33205@kearny.w3.org (Issue ID: LC-675) Part of Item: Tests Comment Type: TE Comment (including rationale for proposed change): The example showing an implicit label association is misleading: \"First name \" This label is explicitly associated with the form control (the label contains the form control, it is not implied). Technique H65 states this is OK \"...by including the form control within the label element\". If there was more than one control within the label element then it is ambiguous and wrong. If the label does not contain the form control then there is an implicit relationship. The \"note 2\" text is incorrect: \"Labels for these elements are implicitly associated via the value attribute\". Using an attribute of the element is an explicit association, not implicit. Proposed Change: Do not use the word \"implicit\" to describe relationship of label containing control or label using attribute. ---------------------------- Response from Working Group: ---------------------------- Our use of the term "implicit" to describe the relationship of a label element that contains a form control is correct per the HTML 4.01 specification. See http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1 which contains the following sentence "To associate a label with another control implicitly, the control element must be within the contents of the LABEL element." However, we see how the current wording creates a problem and have included the following revisions to address this issue: We have removed "either explicitly via the for attribute or by including the form control within the label element" from step one of the procedure for H65. In Technique H44, we have merged notes 1 and 2 as follows: Note 1: The label element is not used for the following because labels for these elements are provided via the value attribute (for Submit and Reset buttons), the alt attribute (for image buttons), or element content itself (button). * Submit and Reset buttons (input type="submit" or input type="reset") * Image buttons (input type="image") * Hidden input fields (input type="hidden") * Script buttons (button elements or ) We have also repeated the user agents notes from H65 in H44. ---------------------------------------------------------- Comment 21: Source: http://www.w3.org/mid/20060602143356.46E9A33205@kearny.w3.org (Issue ID: LC-676) Part of Item: Applicability Comment Type: TE Comment (including rationale for proposed change): Labeling of form controls is covered by H44 so these 2 techniques should be rolled into one. Proposed Change: Combine H65 and H44 into one technique or clarify differences between the two. ---------------------------- Response from Working Group: ---------------------------- The Working Group strives to make each individual technique as specific as possible. Both techniques are about labelling form controls but they use two different strategies to provide the label. H44 uses the label element and H65 describes the use of the title attribute on a form control and are applicable in different situations. Thus, the Working Group believes that the techniques should remain separate. ---------------------------------------------------------- Comment 22: Source: http://www.w3.org/mid/20060602144924.A4300DAF01@w3c4-bis.w3.org (Issue ID: LC-677) Part of Item: Description Comment Type: ED Comment (including rationale for proposed change): The use of the word \"label\" can be confusing. Its use here does not refer to the label element. Proposed Change: Use the word \"name\", \"identifier\" or something similar so readers do not think this is a technique about using the label element. ---------------------------- Response from Working Group: ---------------------------- Thank you for pointing out this potential source of confusion. The title for H71 has been changed to "Providing a description for groups of form controls using fieldset and legend elements" The description for H71 has been changed to "The objective of this technique is to associate a description (such as a prompt or question) with a related group of radio buttons or checkboxes using the fieldset and legend elements. Generally, a set of radio buttons or checkboxes is related when they share the same value for the name attribute. Using fieldset and legend to associate a description with a group of form controls creates a programmatic association between the description and the group of form controls. This makes it possible for people using screen readers to hear the description as well as the available responses." ---------------------------------------------------------- Comment 23: Source: http://www.w3.org/mid/20060602145548.E2641DAF01@w3c4-bis.w3.org (Issue ID: LC-678) Part of Item: Description Comment Type: TE Comment (including rationale for proposed change): Technique is poorly defined. There are several ways to group related sentences other than using a P element (i.e. lists, tables). Technique may not apply to other languages. Technique deals with writing style which is difficult to describe and test for. Proposed Change: Clarify the use of P element in relation to other text structuring elements. ---------------------------- Response from Working Group: ---------------------------- The working group agrees that this technique is poorly defined and should be removed. Upon examination based on your comment, we have determined that, even though elements are useful for accessibility, determining when they should be required is highly subjective. ---------------------------------------------------------- Comment 24: Source: http://www.w3.org/mid/20060602150228.D3276DAF01@w3c4-bis.w3.org (Issue ID: LC-679) Part of Item: Description Comment Type: TE Comment (including rationale for proposed change): Does not mention other semantic markup used improperly in layout tables (see H43). Proposed Change: Include other semantic markup SCOPE, ID, HEADERS in list of elements to avoid. ---------------------------- Response from Working Group: ---------------------------- The working group does not see scope and headers as "common failures" while the abuse of th, caption, and summary in layout tables is rather common. Therefore, we want to keep focus on the failures most commonly occurring by naming them in the title of the technique. And the working group does not feel that id attributes should be prohibited in layout tables as there are valid uses for them in layout tables (scripts, CSS, etc.). We do agree, however, that if scope and headers are used in layout tables, it would be a failure. Therefore, we have added the following to the end of the first paragraph in F46: Although not commonly used in a layout table, the following structural markup would also be failures of SC 1.3.1 if used in a layout table: - headers attributes - scope attributes ---------------------------------------------------------- Comment 25: Source: http://www.w3.org/mid/20060602150453.DCEA247BA5@mojo.w3.org (Issue ID: LC-680) Part of Item: Description Comment Type: TE Comment (including rationale for proposed change): All layout tables have no summary? What about first first layout table with description? Could be others too. A description of layout table is beneficial in some cases. Proposed Change: Allow for summary on first level layout table if summary describes navigation of table. ---------------------------- Response from Working Group: ---------------------------- The working group has received a lot of feedback that users do not want summaries on layout tables because their use can cause assistive technologies to announce unnecessary information about tables or to attempt to parse the table as though it were a data table. In light of the above, if you have data that supports your suggestion that a summary on the first layout table is beneficial, please submit it for our consideration. ---------------------------------------------------------- Comment 26: Source: http://www.w3.org/mid/20060602150742.37C3F47BA5@mojo.w3.org (Issue ID: LC-682) Part of Item: Description Comment Type: TE Comment (including rationale for proposed change): Should also include Applet, Object and Embed. Proposed Change: Include other examples of applet, object and embed that make use of pattern and color. ---------------------------- Response from Working Group: ---------------------------- Since this is a general technique the working group does not want to refer to the HTML specific applet and embed elements. However, we have modified the description to refer to non-text content rather than specifically to images. We have also added an additional example. ---------------------------------------------------------- Comment 27: Source: http://www.w3.org/mid/20060602151623.A117347BA5@mojo.w3.org (Issue ID: LC-688) Part of Item: Description Comment Type: TE Comment (including rationale for proposed change): Very vague and difficult to test for. The words \"meaningful sequence\" are not defined. As this is a level 1 it should be clearly defined. Proposed Change: Provide clear examples of when this problem occurs and how to test for it. Define \"meaningful sequence\". ---------------------------- Response from Working Group: ---------------------------- We have modified the test procedure in G57 to describe how to test that content is meaningful. This removes the need to define "meaningful sequence". We believe the description of the technique provides an example. ---------------------------------------------------------- Comment 28: Source: http://www.w3.org/mid/20060602151938.9B90B47BA5@mojo.w3.org (Issue ID: LC-690) Part of Item: Description Comment Type: TE Comment (including rationale for proposed change): Seems similar to H1. What is the difference between using DIR attribute on inline and block elements? Proposed Change: Roll H1 and H56 into one technique or describe differences between use of DIR attribute on inline vs. block elements. ---------------------------- Response from Working Group: ---------------------------- Based on comments from the internationalization working group, we have determined that text direction is only an accessibility issue when mixing text directions is done in a way that affects the sequencing of the text. So we have removed technique H1. ---------------------------------------------------------- Comment 29: Source: http://www.w3.org/mid/20060602152633.9E1F933205@kearny.w3.org (Issue ID: LC-695) Part of Item: Description Comment Type: TE Comment (including rationale for proposed change): Very difficult to test for this. Says to use Q element which fails under IE. WCAG doc itself does not use Q element. Should be techniques about misuse of semantic markup for presentation. Proposed Change: Describe clearly when this applies. Do not recommend use of Q element. Add techniques that discourage use of semantic markup for presentation (i.e. misuse of Hx, BLOCKQUOTE etc.) ---------------------------- Response from Working Group: ---------------------------- We have provided additional information about the issues surrounding use of the Q element, and suggested approaches for minimizing these issues. The Working Group continues to see the Q element as valuable in spite of inconsistent user agent support at this time, and therefore decided to retain the technique with its caveats.
Received on Thursday, 17 May 2007 23:32:15 UTC