- From: Yvette P. Hoitink <y.p.hoitink@heritas.nl>
- Date: Mon, 30 Aug 2004 23:18:27 +0200
- To: "'w3c-wai-gl'" <w3c-wai-gl@w3.org>
- Message-ID: <E1C1tYA-0006oL-3M@frink.w3.org>
Summary of guideline 2.4 Introduction This document is meant to review guideline 2.4 and discuss the open issues with this guideline. The current and proposed wordings are based on the July 30, 2004 working draft [1]. Unless otherwise stated, the current wording is used. The current wording for 2.4 is: Facilitate the ability of users to orient themselves and move within the content. My personal opinions are marked with my initials (YPH). Outstanding issues Issues in Bugzilla The issues in Bugzilla can be found in the status report "Guideline 2.4 (navigation-mechanisms) Issues" [2]. 211. Skip navigation - technique or success criteria? [3] Ben Caldwell wonders if providing a skip link should be an HTML technique or a success criteria. YPH: I think this refers to an older phrasing. Since then, we have generalized the skip link requirement into a broader success criterion at level 2: " Large blocks of material that are repeated on multiple pages, such as navigation menus with more than 8 or more links, can be bypassed by people who use screen readers or who navigate via keyboard or keyboard interface. " Skip link is an example of such a bypass mechanism. A skip link technique is included in the HTML techniques document [4] so I think we can close this issue. 245. ambiguity of "long document" and "major section" [5] Ben Caldwell asks: " What is a major section and what is a long document? Can valid long documents be devoid of paragraphs? " YPH: I think this refers to an old formulation. In the meanwhile, the success criteria have been reformulated to be more specific, for example: " In documents greater than 50,000 words or sites larger than 50 perceived pages, at least one of the following is provided. " I propose to verify with Ben that this answers his question and then close the issue. 319. Add another best practice checkpoint for 2.4 [6] Ben Caldwell proposed in July of 2003 to add a best practice "Where possible, logical tab order has been created." This has been incorporated in the July 2003 draft but the issue was reopened upon discussion in the August 28, 2003 telecon [7] People felt that 'logical' wasn't testable, that we needed something broader then 'tab order', etc. Wendy took an action item to suggest new wording. This is still on the action items list. YPH: I propose to remind Wendy about her action item ;-) 323. Skip Navigation Success Criteria for 2.4 [8] Gregg Vanderheiden suggested to add another success criteria about skipping links: " Users are able to skip over navigational bars or other blocks of links that are greater than 7 when reading with a synthesizer or navigating using keyboard. " This had been incorporated in the July 2003 review draft but has since then been replaced by " Large blocks of material that are repeated on multiple pages, such as navigation menus with more than 8 or more links, can be bypassed by people who use screen readers or who navigate via keyboard or keyboard interface. ". YPH: I think the current phrasing includes Greggs point, so I propose to check with Gregg if he agrees with that and then close this issue. 327. Making 1.5 item #1, level 2 more objective [9] Gregg Vanderheiden commented: Checkpoints have to be objective. The checkpoint 1 which is currently under best practice gets close, but then changes into an (e.g. black and white, small display, model, audio playback). If these are just examples, then it is unclear to the user what else the individual would need to do. Suggest that this is a good one for a "Level 2" checkpoint, but to do so, we would need to make it definite. The checkpoint 1 he refers to is "the structural emphases are chosen to be distinct on different major visual display types (e.g. black and white, small display, mono audio playback). " YPH: Gregg's comment is an ongoing effort to make checkpoints objectively testable. The particular success criteria he chooses as an example has been eliminated since his comment was made. I propose to recognize the ongoing general problem of testability but to close this item because it is no longer valid. 370. structure of large documents [10] Sailesh Panchang commented: " I believe that the minimum limit of 50000 word per doc of 50 page site is not needed. Headings for text sections or groups of links etc reveal structure and organization of content. Absence of these struuctural markups make it inefficient to navigate a page with even less than 10k words. So wherever a hierarchy can be used to reasonably structure the page content, this checkpoint is applicable. The author should use judgment to do so. I am a screen reader user and on numerous sites sensed the need for structural markup. " At this moment, the 50,000 word or 50 page limit is still in place. For these cases, we require that at least one of the following is required: * hierarchical structure * table of contents * alternate display order or alternate site navigation mechanisms YPH: I think Sailesh has a point there. For HTML, I think hierarchical structure becomes necessary for much smaller documents than the document size for which you need tables of contents or alternate display orders. I don't know if the same is true for other types of web content. I don't think removing the size requirements is a good solutions because leaving it up to the author makes it untestable. Perhaps we can explain in 'who benefits' or the examples that this will benefit people in smaller documents as well. Sailesh also asked: ii. While there is mention of headings and titles for text sections, I note the absence of links that can be grouped and given headings. Like product links, links for services offered, links for different contacts etc. Are markup for headings used to group links outside the scope of this checkpoint? " YPH: We already have a SC "Each page or other resource that can be accessed separately and that supports a title has a title that identifies the subject or purpose of the resource. " It seems to me that this should be more generalized to include not only 'pages' but sections or groups of links as well. A page title will then become just one example of a more generic success criterion. 415. Checkpoint text for navigation-mechanisms difficult to interpret [11] Kynn Bartlett says about checkpoint 2.4 "phrasing: Again, a very ugly sentence diagram." The phrasing at that time (the 24 June 2003 WD) was "Structure and/or alternate navigation mechanisms have been added to facilitate orientation and movement in content." The formulation has since been reworked and is now easier to understand. YPH: I propose to close this issue since the sentence Kynn objects to is no longer in place. 416. Fitting "web application" into the page v. site divide [12] Kynn Bartlett comments about an editorial note in the June 2003 WD about navigating within content vs navigating within a site. applying "content" to both pages and sites. He comments that the concept of Web application further weakens the page/site divide. YPH: This comment was about an ednote that is no longer present. The current formulation of guideline 2.4 does not speak about navigating within a site versus navigating within a document so I propose to close this issue. 434. Why aren't navigation mechanims a core checkpoint? [13] Christian Buehler thinks navigation mechanisms should be at level 1. In response, SIDAR feels that all documents should have structure, even if it's so simple as a document consisting of paragraphs. YPH: This is a fundamental problem that needs further investigation. At the moment, 2.4 seems to be about adding extra mechanisms, and not about the basic mechanisms that usually exist in web content (such as headings, paragraphs, etc). I don't think additional navigation items need to be at level 1, but basic mechanisms that also help in navigating (such as paragraphs) should be. This overlaps with guideline 1.3 about the separation of presentation and structure (see below). 441. proposed revisions to required section [14] Cynthia, Kerstin and Wendy propose to delete success criteria 1 and 2 of level 2. They argue that the structure is already available because of 1.3, and propose to add a success criteria instead that says "a user is able to move through the content in an order that follows the visual layout or follows the order the page is read. " This does (to them) feel more like a technique than a success criteria though. YPH: This is one more example of the grey area between guideline 1.3 and 2.4. I think we first need to get the distinction clear, see below. I do think that requiring hierarchical structure or a table of contents or an alternative navigation order is asking more than 1.3 requires, which makes it a valid success criteria for 2.4. 448. add definition for "visual appearance" [15] Cynthia, Kerstin and Wendy remark that we need definitions for "visual appearance" and "auditory characteristic." YPH: This referred to an old formulation " the structural elements present have a different visual appearance or auditory characteristic from each other and from body text. " that is no longer present. I propose to close this issue. 449. add definition for "auditory characteristic" [16] See 448. 450. example 2 needs clarification [17] Cynthia, Kerstin and Wendy remark that the example about data tables is about labels, but the checkpoint is about presentation of structure. Gregg Lowney wants to add that headers should be visually distinct from content cells. YPH: These are remarks for the obsolete 1.5: " Structure has been made perceivable to more people through presentation(s), positioning, and labels. " The example has been moved to 2.4 where it fits perfectly with the level 3 requirement " Diagrams are constructed so that they have structure that users can access ". Since it now fits with the success criteria I propose to close this issue. 453. move additional notes to techniques [18] Sherman Meeds remarks that the list of considerations in the June 2003 draft ( for example: "for visual presentations, use font variations, styles, size and white space to emphasize structure. ") should go to techniques instead of the guidelines document. YPH: This list has since been removed from the guidelines document and the items in the list are now discussed in techniques (mostly in the CSS techniques document). I propose to close this issue. 468. navigation-mechanism should be required [19] Tina Holmboe thinks that 2.4 should be required. In our new terms, that means it should have level 1 requirements. YPH: This really is a duplicate issue for 434, "Why aren't navigation mechanims a core checkpoint?". See 434. 483. sites without alternative navigation should not be allowed to state conformance [20] Konny Eriksson talks about the problems with Javascript-only popups that do not provide a link in the HREF and feels that sites without alternative navigation should not be allowed to state conformance to WAI. YPH: I do not think providing an HREF as well as a Javascript link is what we had in mind when we talk about alternate site navigation mechanisms. I think this issue should be considered in the whole Javascript discussion we're having. 488. does 1.5 require association of table headers and data cells? [21] Gregg Gay wants to know why we don't require the association of table headers and data cells as a core (level 1) requirement for data tables. YPH: Since we want the WCAG to be technology-independent, we can't explicitely require to associate table headers and data cells for data tables because that's HTML-specific. Instead, we now have " Diagrams are constructed so that they have <http://www.w3.org/TR/WCAG20/#structuredef> structure that users can access ". In HTML, one mechanism to do this is associate table headers with data cells, as explained in the techniques document. This SC is at level 3 at the moment. I agree with Gregg Gay that level 3 might be too low for something as important to the access of information as the association of table headers and data cells. I think we should discuss this further. 491. comments and questions on navigation mechanisms [22] Gregg Gay thinks the 50,000 words threshold is too high because documents a lot smaller need navigation mechanisms as well. The WCAG document has less than 15,000 words right now and is a good example of a document in which you need the additional navigation mechanisms that are provided (TOC, headings). Gregg Gay suggests that the table of contents be a feature for page that include more than 5 subsections and 5000 words, and be optional as per the ACCLIP useTableOfContents preference. A screen reader user can benefit from having TOC turned off, while an LD user can benefit from having them turned on. YPH: This is a result of the underlying problem 'large documents' (see below). I think optional TOC's can be a great tool and should be delegated to the techniques documents. Gregg Gay also asks: "what are "dynamic fisheye views"? Is it a TOC? " YPH: This is an example of a site navigation mechanism in the definitions section. I agree with Gregg that this isn't a clear example and should be re-written. 510. bicycle example was confusing [23] The Kansas Web Accessibility Subcommittee thinks the bicycle example is confusing at first and that it might be better to use examples from the domain of web content because that is closer to our audience. YPH: I think the good point about this example is that it isn't HTML-specific. Images with structural relationships in them are covered by the WCAG and this is a good guideline to cover that. I think we should clarify the example to make sure it's understood that this is referring to web content. I propose to explain this to the Kansas Web Accessibility Subcommittee and to close this issue. 564. Not clear what "nav mechanism" checkpoint trying to address [24] The U.S. Access Board writes: We have not provided feedback on this section since it is unclear what the section is trying to address. However, from the explanatory material, it seems that this guideline may be addressing usability more than accessibility. YPH: This is the question of usability versus accessibility that pops up more, see 'underlying issues. I propose to explain this to the US Access Board and close this item. 589. checkpoint is too vague and not a WCAG issue [25] Aries Arditi remarks that our requirement that " structural elements present have a different visual appearance or auditory characteristic from each other and from body text. " is not a WCAG issue. YPH: We agreed that rendering is a user agent issue and not a WCAG issue and removed this SC, making this issue obsolete. I propose to close the issue. 632. Proposed wording for Guideline 2.4 [26] A proposal was made to change the wording of guideline 2.4 to " Make it easy for users to browse the resource, to know their place in it, and to find information they need. " Wendy objected that "browse the resource" would not apply to all web content. YPH: Since this issue was posted, the guideline text has been rewritten, making this issue obsolete. I propose to close the issue. 633. Proposed wording for Guideline 2.4, [level 2] SC 1 [27] Follow-up on issue 441. Cynthia, Kerstin and Wendy altered the text slightly to make it more understandable by writing out the different options. YPH: I think the proposal is easier to understand and should be adopted. I propose to put this on the agenda for a telephone conference. 634. Proposed wording for Guideline 2.4, [level 2] SC 2 [28] Proposal by Cynthia, Kerstin and Wendy to make it sound more like a success criteria for the author than the visitor. YPH: This wording has been adopted in the current WD. I propose to close this issue. 635. Proposed wording for [level 3, item 1] Guideline 2.4 [29] Cynthia, Kerstin and Wendy proposed a new formulation for the strategies for facilitating orientation and movement. YPH: This formulation has been adopted in a slightly altered form (one of the strategies became a stand-alone success criteria). Since the reformulation has been processed, I propose to close this issue. 636. Proposed level 3, item 2 for 2.4 [30] Reformulation about logical reading order. YPH: A slightly altered version of this reformulation has been adopted in the current WD. Since the reformulation has been processed, I propose to close this issue. 637. Proposed level 3, item 3 for 2.4 [31] Reformulation about diagrams, making it easier to understand. John Slatin asks if this should be moved to the 'perceivable' principle instead of 'operable'. YPH: The reformulation has been adopted, so we can close that part. Johns question might be answered by expanding example 4, the data table. This currently reads: "Groups of rows or columns are labeled with headers. " Perhaps we can expand this example to show how this helps blind users to access the information because at the moment the example doesn't explain its accessibility benefits. If we do this, I think we can close this issue. 638. Proposed level 3, item 4 for 2.4 [32] Reformulation about logical tab order, making it easier to understand. YPH: Since then, the formulation has been simplified even more. I propose to close this issue. 675. importance of user control [33] Greg Lowney writes about the importance of user control. This refers to the previous SC about presenting different structures in visually different ways. He thinks it's more important that a UAAG-compliant UA exists for all the different types of content. He wonders if we say that anywhere. YPH: This has since been included in guideline 4.2 as SC 1 of level 1. I propose to close this part of the issue. Greg Lowney also wants to make " users can control the presentation of structural elements or the emphasis on the structure can be varied through alternate presentation formats " to a requirement (equivalent to our current level 1) and add "if supported by the technology". YPH: This SC has since been deleted, if I remember correctly because we think this is a user agent issue. See underlying issues. 676. 1.5 example 1 [34] Greg Lowney objects to the suggestion to make _subtle_ differences between the appearance of titles and section headings. YPH: I agree with Greg. I propose to delete the word 'subtle' from the example and then close this issue. It would then become: * Example 1: documentation for a product. Identifying chapters in the structure of a book is appropriate and accepted use of labeling the structure. Within the chapters, headings identify (label) changes in context and highlight ideas contained in the following text. Differences between the appearance of the chapter title and the section headings helps the user understand the hierarchy and relationship between the title and headings. The difference might be font size and margin indentation when presented visually, and spoken in a different voice or preceded by a sound when presented auditorily. 679. add something about pausing before voice headers to 1.5, ex 3 [35] Greg Lowney suggests to mention that it can be useful to add a pause before voicing headers. YPH: I think this would make the example more complex than necessary. It would be a useful technique though, for example in the CSS techniques document. I propose to hand this issue over to the Techniques Task Force. I do question the validity of the example in question. It was moved to 2.4 when integrating 1.5 and 2.4 but we currently no longer have a success criteria where this is an example for. It used to be an example of how to make structure perceivable in presentation but we deleted those success criteria so we should either delete this example or add a success criteria about making structural elements perceivable. 690. change "added" to "included" in guideline text [36] Greg Lowney proposes an alternative for 'added' in the phrasing of the guideline text. YPH: Since Greg posted his comment, the guideline text has been re-written and doesn't include 'added' or 'included' anymore. This makes his remark obsolete so I propose to close the issue. 691. what is meant by "move through the content" [37] This question is about what is meant by moving through the content, since that is an inherent capability of user agents. Greg Lowney doesn't understand the need for this guideline. YPH: This question refers to a very early version of the guideline, when the guideline text was less clear and the success criteria weren't as clear yet. I propose to check back with Greg Lowney whether he feels the current wording addresses his issue and if so, close it. 692. structural markup and display on different devices [38] This comment is about problems with providing structure in markup or a data model. YPH: This requirement has been deleted making this remark obsolete. I propose to close this issue. 751. Guideline summary (to do) guideline navigation-mechanisms (2.4) [39] Wendy: We need a thorough issue summary for this guideline. YPH: Your wish is my command ;-) 760. define "structural elements" in level 2 criteria [40] We need a definition of "structural elements" for this guideline. YPH: We no longer use the term 'structural elements' so no longer need a definition. I propose to close this issue. 761. Added comment from list: Visual layout is used to group related components so that behavior is predictable. [41] Kerstins feels we should look into "visual layout is used to group related components so that behavior is predictable." Need to look into this. YPH: We deleted all the requirements to make structure perceivable, see underlying issues. I propose to close this issue. 806. Need to think through this guideline with Web applications in mind [42] Andy Snow-Weaver comments that the level 2 SC don't seem to cover web applications. YPH: This is a good point which is still valid for the current wording. I think we should further discuss this. Carol Smith asks what we mean by 'perceived pages', if this means pages in the navigation structure or pages that are linked from other pages in the site. YPH: We definitely need a definition for 'perceived pages'. I propose to create an action item for this. 807. Non-hierarchical relationships covered under content-structure-separation [43] Andi Snow-Weaver proposes to delete the requirement about non-hierarchical relationships since that's already covered in 1.3. YPH: It does seem that this is covered in a level 1 success criteria for 1.3 so it can be deleted. However, it's still present in the current WD. I propose to discuss this further and take a decision to delete this item or not. 808. Benefits rewording proposal [44] Andi Snow-Weaver suggests that because jumping from header to header is currently only possible in assistive technology, we combine the benefits for physical and vision disabilities by saying " Assistive technology used by people with physical and vision disabilities can provide users with the ability to jump from header to header to get an overview or to more quickly "skim" to the section they are interested in." YPH: I like it when the 'who benefits' section adresses the benefits for each type of disability separately. I agree with Andi that we should make it clear that this will require assistive technology in most of the cases. I propose to discuss this on the list and then decide what to do about this example. 829. Linear reading order should be level 1 [45] Michael Cooper proposed to move the linear reading order SC to level 1. There was no consensus to do this in a telecon. There are still issues about the phrasing of 'logical reading order', which are covered in issue 884. YPH: Since there was no consensus and the one part that's still open is covered by another issue, I think we can close this issue. 859. frames included in 2.4, level 3, item 4? [46] The Aktionsbuendnis für barrierefreie Informationstechnik wants to know if "each page or resource that can be accessed independently" refers to frames as well. YPH: This SC does apply to frames as well. This explanation should not be in the guidelines themselves (which are technology-independent) but is covered in the techniques document [47]. I think this would not have been a question if the techniques document had already been linked. I propose to check with the ABI if they agree that this is sufficiently covered by the HTML techniques document and if so, close this issue. 883. This guideline is about "usability", not "accessibility" [48] Andi Snow-Weaver comments that this guideline seems to be more about usability then accessibility. This question is covered in issue 564, see there. 884. Logical tab order is subjective [49] The US access board thinks "Logical tab order" is subjective. YPH: There seems to be an ongoing discussion about this so I propose leave this issue open until we solve this problem. 945. Please clarify need to "look different" [50] James Craig is worried about the need for different structural elements to 'look different' from each other because that's a designer's choice. YPH: This SC has been deleted since so this issue is obsolute and can be closed. 946. Needs examples to understand success criteria for 2.4 [51] James Craig wants examples for different level 3 succes criteria. YPH: There is no example at the moment about providing information to indicate at least one logical sequence in which to read the document. I propose to make an action item of this (I'm willing to volunteer). Diagrams have an example: the data table. Reveiling non-hierarchical relationships are covered in the data table example as well (I think the association of a header cell with a data cell is a non-hierarchical relationship). James Craig also asks how a scalable image of a bicycle would be spoken by a screen reader. If I understand it correctly, these relationships can only be represented in SVG or similar technologies. I don't know how screen readers interact with SVG. I propose to have someone from the SVG field find out and answer back to James Craig, and perhaps help clarify this example. 947. Is logical tab order testable? [52] James Craig is worried that 'logical' tab order isn't testable. YPH: This is a duplicate of 884. I propose to mark this issue as a duplicate and close it. 948. User agent should determine voice style in Example 5 [53] James Craig feels that the example about a more formal voice for headers is something that should be left to the user agents and suggests using "a discernibly different style" instead. YPH: I think we shouldn't treat auditory design any different from graphical design. We think providing different looks for headings is a great idea, so why not do the same for sound? With CSS3, auditory design will hopefully get a lot more attention. It's just an example, I see no harm in using a formal voice in that. We do need to make clear that formal voice is just one possibility, and not _the_ WCAG recommendation. I propose to alter this example and then close this issue. Perhaps we can rewrite it in a similar way as example 1 does for the visual differences: * Example 5: an audio presentation. An audio rendering of a document, generated according to a style sheet, uses a different voice to read titles and headers so the listener can easily identify the words as a title and not part of the running text. This difference might be in pitch, volume or in tone, for example by using a louder, more formal voice. 955. TOCs should include information about presentation modes [54] RNID suggests that contents pages or navigation maps should also contain information about presentation modes available in each area of the site that they refer to. YPH: I don't think I fully understand this remark and worry that we cannot formulate this in a way that our audience will understand it either. This feels to me like something that is applicable to a small number of websites only. Perhaps this can be incorporated in the gateway techniques associated with creating TOCs or navigation maps. 994. Grammatical fix to example 1 [55] RIND suggested to change " accepted use of labelling the structure " to "accepted way of labelling the structure" YPH: I agree this is clearer and propose we adopt this change and then close this issue. 1008. Assertion rather than requirement [56] Ian Jacobs thinks the 'there is a statement asserting' success criteria should be eliminated because they do not help authors when making the content more accessible and are already covered by a conformance statement YPH: This issue applies to other guidelines as well. Personally, I agree with Ian and think the requirements to include statements are very artificial. This is a fundamental issue because it's closely linked to accessibility. I propose we discuss this further, perhaps even at a face-to-face. 1016. When to determine if a site map is needed [57] Andy Budd remarks that the need for a site map depends on the amount of crosslinks between pages. If you can access every page from every other page, you do not need a site map. YPH: This is one more variant of the problem that the threshold for 'large documents' is very arbitrary and it really depends on the content whether you need additional navigation mechanisms or not. We need to discuss the underlying issue before we can decide what to do about this issue. Underlying issues 'Large documents' Several issues come down to the same thing: the arbitrary threshold we have for 'large content'. There are plenty of examples for content that do not meet this threshold (for example the WCAG 2 document with less than 15,000 words) which still really need additional navigation mechanisms to make them operable. Perhaps we should phrase it in such a way that it is clear that it's just an arbitrary threshold and for smaller content, we encourage the authors to use their own judgement. If we cannot find a way to formulate this in a testable manner in the SC text, we could do this in the examples or in a 'who benefits'. Make structure perceivable A lot of the now obsolete issues were about making structure perceivable. If I'm correct we deleted these because the presentation of the structure is a UA issue. I propose to discuss this in a telecon to see if that's indeed what we mean to do and if so, close all the issues about perceivable structure. Usability versus accessibility Several people have pointed out that 2.4 isn't about accessibility but about usability. Navigation in content is disproportionately harder for people with certain types of disabilities, so providing means to facilitate navigation is an accessibility issue. Since several knowledgeable people have pointed this out, we have to do a better job at explaining this in the guidelines document, perhaps in the 'who benefits' section. Dependencies between guidelines Guideline 1.3 - Ensure that information, functionality, and structure are separable from presentation. Guideline 1.3 level 1 SC 1 says that structures and relationships within the content can be derived programmatically . This overlaps with guideline 2.4's requirements to construct diagram so that users can access the structure, and to reveal hierarchical and non-hierarchical relationships. YPH: People wonder if guideline 1.3 already requires an author to make sure the structure and relationships of the content can be derived at level 1, what do we need the level 2 and 3 success criteria in 2.4 for to require to add such structure and relationships to the document? To me it sounds like guideline 1.3 is saying "if the document has structure or relationships, make these available" and guideline 2.4 says to make sure the document has structure and relationships. That's a very subtle difference and one I think we need to work on making that more clear. Rationale Navigation in content is disproportionately harder for people with certain types of disabilities, so providing means to facilitate navigation increases accessibility for people with disabilities. Author This summary was written by Yvette Hoitink, August 2004 Contact: y.p.hoitink@heritas.nl Notes [1]. http://www.w3.org/TR/2004/WD-WCAG20-20040730/ [2]. http://trace.wisc.edu/bugzilla_wcag/issuereports/navigation-mechanisms_issue s.php [3]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=211 [4]. http://www.w3.org/TR/2004/WD-WCAG20-HTML-TECHS-20040730/#linkgroups_skip [5]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=245 [6]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=319 [7]. http://www.w3.org/2003/08/28-wai-wcag-irc.html [8]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=323 [9]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=327 [10]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=370 [11]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=415 [12]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=416 [13]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=434 [14]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=441 [15]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=448 [16]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=449 [17]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=450 [18]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=453 [19]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=468 [20]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=483 [21]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=488 [22]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=491 [23]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=510 [24]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=564 [25]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=589 [26]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=632 [27]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=633 [28]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=634 [29]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=635 [30]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=636 [31]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=637 [32]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=638 [33]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=675 [34]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=676 [35]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=679 [36]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=690 [37]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=691 [38]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=692 [39]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=751 [40]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=760 [41]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=761 [42]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=806 [43]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=807 [44]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=808 [45]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=829 [46]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=859 [47]. http://www.w3.org/TR/2004/WD-WCAG20-HTML-TECHS-20040730/#title [48]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=883 [49]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=884 [50]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=945 [51]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=946 [52]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=947 [53]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=948 [54]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=955 [55]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=994 [56]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1008 [57]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1016
Received on Monday, 30 August 2004 21:18:50 UTC