- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 22:09:55 -0700
- To: "Sailesh Panchang" <spanchang02@yahoo.com>
- Cc: public-comments-WCAG20@w3.org
Dear Sailesh Panchang, 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: Problem with H39 Description Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Feb/0000.html (Issue ID: 1925) ---------------------------- Original Comment: ---------------------------- Refer: HTML techniques #H39 - Description Problem text : "The objective of this technique is to identify data tables using the caption element. The caption is shown on the screen and reported by screen readers. This technique may be a good choice when tables are difficult to identify, for example, when text immediately preceding the table does not refer directly to the table, or when there are multiple tables in the same Web unit. The caption element is similar to a heading. Unlike a heading element (h1-h6), however, the caption element is part of the table itself. Therefore, using caption ensures that information identifying the table is always kept with the table." Comment type: Description is too verbose and imprecise. Caption is a table identifier and is useful regardless of whether there is one or more tables on a page. In the absence of captions too one can navigate to different tables as well as identify them distinctly using a screen reader. A caption can also be marked up with an h<n> tag. Proposed: The caption for a table is a table identifier and is like a title or heading for the table. A caption is the appropriate markup for such text and it ensures that the table identifier appears along with the table. Screen reading software allows one to navigate directly to the caption for a table if one is present. --------------------------------------------- Response from Working Group: --------------------------------------------- We have rewritten the description section of H39 to address your concerns. ---------------------------------------------------------- Comment 2: The use of SCOPE for a simple table in cells that use is futile Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Feb/0001.html (Issue ID: 1927) ---------------------------- Original Comment: ---------------------------- Issue#2: Refer: Example 1 under H63 HTML Techniques in Techniques for WCAG 2.0 Comment: i. The use of SCOPE for a simple table in cells that use <TH> is futile. In fact if TD is used then SCOPE should be used for such a simple table. Some screen readers that do not support SCOPE do not read any headers as they are programmed to do for simple tables. So I would not recommend this example. ii. The statement ' Following the HTML 4.01 specification, it is marked as a td element because it is both a data cell and a header cell.', too is unnecessary in the light of the text proposed above under description. Also it is not the objective of this document to educate the reader about the HTML specs. Proposed: Include an example with column#1 containing serial numbers for rows in the table and the second column containing the key value for the row. The cells in the second column may then use scope=row. The cells in the first row too are marked up with <td> and use scope=col. <table border="1"> <caption>Contact Information</caption> <tr> <td></td> <td scope="col">Name</td> <td scope="col">Phone#</td> <td scope="col">Fax#</td> <td scope="col">City</td> </tr><tr> <td>1.</td> <td scope="row">Joel Garner</td> <td>412-212-5421</td> <td>412-212-5400</td> <td>Pittsburgh</td> </tr><tr> <td>2.</td> <td scope="row">Clive Lloyd</td> <td>410-306-1420</td> <td>410-306-5400</td> <td>Baltimore</td> </tr><tr> <td>3.</td> <td scope="row">Gordon Greenidge</td> <td>281-564-6720</td> <td>281-511-6600</td> <td>Houston</td> </tr> </table> --------------------------------------------- Response from Working Group: --------------------------------------------- We have changed this technique as shown below. We kept your previous example and included the link to Assistive Technology Reading Tables, authored with David MacDonald and Jim Thatcher, in the Resources section. User Agent and Assistive Technology Support Notes The row and col values of the scope attribute are currently supported to a large extent by most current versions of JAWS. However, there are still some problems and WindowEyes' support for scope is inconsistent. The same is true for Japanese versions of these screen readers. Versions of JAWS prior to version 5 have inconsistent support for scope. At the current time, those who want to ensure consistent support across Assistive Technologies for tables where the headers are not in the first row/column may want to use the technique for complex tables [H43: Using id and headers attributes to associate data cells with header cells in data tables (HTML)]. For simple tables that have headers in the first column or row we recommend the use of the [th/td elements]. Description The objective of this technique is to associate header cells with data cells using the scope attribute. The scope attribute may be used to clarify the scope of any cell used as a header. The scope identifies whether the cell is a header for a row, column, or group of rows or columns. The values row, col, rowgroup, and colgroup identify these possible scopes respectively. For data tables where the header is not in the first row or column, like the one in Example 1, this technique can be used. Based on screen reader support today, its use is suggested in two situations both relating to simple tables: 1) data cells marked up with td that also function as row header or column header 2) header cells marked up with td instead of th. Sometimes, authors use this to avoid the display characteristics associated with th and also do not choose to use CSS to control the display for th. Note: for simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope. Note: for complex tables use id's and headers as in [H43: Using id and headers attributes to associate data cells with header cells in data tables (HTML)]. ---------------------------------------------------------- Comment 3: H74 and H75 - unclear why id attributes should be unique Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Feb/0002.html (Issue ID: 1928) Status: VERIFIED PARTIAL/OTHER ---------------------------- Original Comment: ---------------------------- Refer HTML Techniques H74 and H75 Comment: Both have " Ensuring that all id attribute values are unique" as an objective. It is unclear why this should be so. Proposed: Make " Ensuring that all id attribute values are unique" a separate technique. H74 and H75 can retain the remaining parts of their statements or may even be combined. --------------------------------------------- Response from Working Group: --------------------------------------------- We have revised the technique about unique ids as a failure for success criterion 4.1.1. Since the concept of well-formedness does not apply to HTML 4.01, we have chosen not to combine H74 and H75. ---------------------------------------------------------- Comment 4: H73: table summary- wrong classification Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Apr/0001.html (Issue ID: 1929) ---------------------------- Original Comment: ---------------------------- Issue: i. The table summary is an aid to understanding table content (G3.1 make content readable and understandable, Principle #3) and is not related to structure versus presentation (G1.3). Table summary helps understanding in the same way as expansion of acronyms/ abbreviation helps understanding content. ii. The summary attribute is not required for all data tables. - The summary is generally necessary for complex tables and may be a vital aid for quick comprehension of such tables. - The summary is useful for simple tables with many columns. It can also be used to convey the purpose of the table when the caption is not used. iv. In other cases it may be a nuisance . The explanation following the H73 technique is apt Recommendation: i. H73 should be a technique against G3.1 and not G1.3 ii. For complex tables the summary should be at level 1 iii. For the other two uses it may be at Level 3 or Level 2. --------------------------------------------- Response from Working Group: --------------------------------------------- {not accept} The 'summary' attribute value for a table conveys information about the relationship of the data as it is conveyed visually. The layout of data can be quickly ascertained by visual users, whereas this information is most usefully described to screen reader users via the 'summary' attribute. This means it is an appropriate technique for Success Criterion 1.3.1 (which is under Guideline 1.3). This is a sufficient technique for Success Criterion 1.3.1. Success criterion 1.3.1 is required at Level A Having a 'summary' for simple tables with many columns provides information that the table is a data table, as opposed to a layout table, and a user can still find it useful to have a description of the layout of data. A simple description may be sufficient and it is enough to let the user know that the layout is a simple one and does not require much cognitive effort to understand the layout - useful to know when the user can not ascertain this visually. Having a 'summary' for simple tables with two columns is still useful if the table is a data table with column or row headers. If the data in the table is simple enough to not require column or row headers, then a data table implementation may not be the most appropriate method to present the data (or may not be necessary). Since 'techniques' cannot have levels and 'simple' and 'complex' are hard to define objectively (and the technique can still be useful for non-complex tables for some people) we have handled it in this fashion. ---------------------------------------------------------- Comment 5: F61: Test Procedure #4 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0131.html (Issue ID: 1934) ---------------------------- Original Comment: ---------------------------- F61 reads: Failure of SC 3.2.5 due to complete change of main content through an automatic update that the user cannot disable from within the content Test Procedure 4 states: check if there are settings within the content to disable automatic changes Expected Results state:If both 3 and 4 are true, then this failure condition applies and the content fails this success criterion. Comment: If test procedure 4 is true, the content passes the test because the content contains settings that disable automatic updates. So change the expected results or re-word test procedure 4 as: Confirm that the content does not contain any settings to disable automatic changes. --------------------------------------------- Response from Working Group: --------------------------------------------- We have revised test procedure #4 as proposed. ---------------------------------------------------------- Comment 6: F42: state that items are not tab-navigable Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0074.html (Issue ID: 1993) Status: VERIFIED ACCEPTED ---------------------------- Original Comment: ---------------------------- Refer to Common Failure F42 on http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#F42 At present the description states: "... or they may be recognized as interactive controls but still not recognized as links. Such elements do not appear in the links list generated by user agents or assistive technology." Comment: A control or link created in this manner cannot be tabbed to from the keyboard and does not gain keyboard focus. Stating these are not tab-navigable is a more direct way of conveying the issue than stating "does not appear inn a link list". I think this is important and missing from the description. Yes one cannot perceive this to be a control or a link but it is also an 'operability' failure under 2.4.1. Suggestion: 1. State these are not tab-navigable and cannot be accessed from the keyboard like other controls / links 2. Consider this to be a failure under 2.4.1 as well. --------------------------------------------- Response from Working Group: --------------------------------------------- Thank you. We have modified the description of F42 to read: This failure occurs when JavaScript event handlers are attached to elements to "emulate links." A control or link created in this manner cannot be tabbed to from the keyboard and does not gain keyboard focus like other controls and/or links. We have also added F42 to the list of common failures in 2.1.1 and have updated the title to "Failure of SC 1.3.1 and 2.1.1 due to using scripting events to emulate links." ---------------------------------------------------------- Comment 7: SC 2.4.1: use of term "block of content" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0076.html (Issue ID: 1994) ---------------------------- Original Comment: ---------------------------- Comment: The examples for block of content list navigation links, heading graphics, and advertising frames. G1.3 and SC 1.3.1 require structural markup so that content is programatically determinable. That means user agents and assistive technology can access these blocks of content. So having stated this already why repeat this again under 2.4.1? Why make content developers responsible to provide a mechanism to skip any and all repetitive blocks of content? User agents now and in the future may incorporate this function. But like WCAG 13.6 and S508 (para o of 1194.22) content authors could be required to provide mechanism to skip groups of links including repetitive ones. This is especially useful when links are not contained in a separate frame, list or grouped under a heading tag etc. In this case a "skip left navigation" or "skip to content" link may be useful. In other cases SC 1.3.1 will already have made the author mark up the block of content with structural markup and left user agents / AT to do the rest. Suggestion: replace "block of content" in SC 2.4.1 with groups of links" Groups of links may be defined as four or more links placed one after another and include such groups that are repeated across multiple Web pages. --------------------------------------------- Response from Working Group: --------------------------------------------- Success criterion 2.4.1 is intended to apply to all largish blocks of repetitive content, not just links, although navigation links is one of the common cases. We have clarified the intent to indicate that small bits of repeated content are excluded. Note: It is worded as "a mechanism is available" because of success criterion 1.3.1. If the document structure provided under 1.3.1 allows user agents to support skipping the content, then a mechanism is available and this success criterion is satisfied. We have added a technique to indicate that using an accessibility supported technology which allows structured navigation is sufficient. Where it cannot be ascertained by the author that the user agents can provide directly, or work with AT to provide such a feature on the basis of the structure provided, it would require the author to provide an explicit mechanism. ---------------------------------------------------------- Comment 8: Consider this technique for 2.4.1 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0077.html (Issue ID: 1995) ---------------------------- Original Comment: ---------------------------- Sub: Documenting additional technique for skipping over links (SC2.4.1) Technology: HTML / XHTML with CSS and Java scripting Description of technique: Expandable / collapsable menu Consider a list of image links: Animals, Flowers, Birds in a menu There is an image (plus and minus) or arrow marks that convey if menu is expanded or collapsed next to each of the above menu item. These may be assigned null alt. Using CSS and JS a menu item maybe expanded to reveal a list of additional links in that group.. The alt for the image should be set to Animals ... menu item expanded or Animals ... menu item collapsed Flowers ... menu item expanded or Flowers ... menu item collapsed and so forth. So by collapsing the menu item-links a user is able to skip over groups of links. No other mechanism to skip over the links may be needed. --------------------------------------------- Response from Working Group: --------------------------------------------- Thank you. we have added a placeholder technique titled "Using an expandable and collapsible menu". Would you be able to write this one up and submit it? The technique submission form can be found at http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/ . ---------------------------------------------------------- Comment 9: Not ok with use of term Level-A, Level-AA, AAA Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0233.html (Issue ID: 2357) ---------------------------- Original Comment: ---------------------------- Refer to the following statements from WCAG 2.0: "They (meaning the SC) are similar to the "checkpoints" in WCAG 1.0 WCAG 2.0 success criteria are organized into three levels of conformance. 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 or combination of disabilities, especially certain types of severe disabilities. It is recommended that even if content does not conform at a specific level, that it conform to the extent possible." Comment: The document does state that the SC are akin to WCAG 1 checkpoints. WCAG 2 also uses level-A, AA and AAA conformance like WCAG 1.0. Although the WCAG2 doc clarifies that '"levels" does not mean that some success criteria are more important than others', I feel the terminology used will lead to a lot of confusion to the detriment of accessibility. Most will interpret a level-A SC as superior in terms of accessibility than a level-AA SC. (see example below) It is as if I am saying my Web content is superior in terms of accessibility if I meet a level-A SC than a level-AAA SC (Present definition of level-AAA: Level AAA success criteria increase both direct access and access through assistive technology) This type of competition is bad for accessibility. Suggestion: WCAG2 is about enhancing accessibility. The three types of SC should be simply called Category-1, Category-2 and Category-3 - they simply are three buckets into which various methods of meeting a guideline can be dumped. Let developers decide which method they wish to use. There may be those, who in the interests of accessibility, may choose to implement a level-AAA (or Category-3- my term) method to provide enhanced accessibility instead of a level-A method. Alternative terms are Tier-1, Tier-2, Tier-3 or simply, Type-1, Type-2, Type-3. Example - a level-AAA SC being regarded as inferior than level-A SC: In "WCAG 2.0 - Polishing the rough edges", Jared Smith rightly argues that transcripts are a superior method for implementing accessibility (SC 1.2.7) than captions. He also makes a case for labeling transcripts as a level-A (or Category-1 method in my parlance). That is another point. But when he states, "_relegating_ transcripts to level AAA is a mistake", I believe he too interprets that WCAG2 regards transcripts as an inferior method as compared to captions. Sailesh Panchang Spanchang02@yahoo.com Phone 571-344-1765 --------------------------------------------- Response from Working Group: --------------------------------------------- We have looked at several different conformance models including one that has just SHALL and SHOULD provisions. It was found that that approach would not work for the variety of sites and uses the guidelines would have to meet. In the end, and after much discussion , it was determined that the three tier approach would work best. As to naming we also looked at a number of different approaches including ones that were non-hierarchical. However, the levels are hierarchical. You must conform at level A before claiming AA etc. So non-hierarchical names would be confusing. Regarding Jared's comment - he was not referring to level of access but rather probability of implementation. Since level A is required, any that is not in level A is less likely to be applied.
Received on Sunday, 4 November 2007 05:10:12 UTC