- From: John M Slatin <john_slatin@austin.utexas.edu>
- Date: Sat, 23 Apr 2005 13:33:12 -0500
- To: <w3c-wai-gl@w3.org>
Yvette, then Wendy:
<blockquote>
>676. 1.5 example 1 [7]
>
>Greg Lowney objects to the suggestion to make _subtle_ differences
>between the appearance of titles and section headings.
>
>YPH: (same as previous summary) I agree with Greg. I propose to delete
>the word 'subtle' from the example and then close this issue. It would
>then
>become:
>
>
sounds good to me.
</blockquote>
It might be possible to address this by combining 2.4 Examples 1 and 5. <blockquote> * Example 5: an audio presentation.
An audio rendering of a document, generated according to a style sheet, uses a different, more formal voice to read titles and headers so the listener can easily identify the words as a title and not part of the running text. </blockquote>
829 (move reading order to L1): agree with Michael and Wendy-- should be L1.
946 (how would SVG of cicycle be spoken)- Wendy suggests a mp example based on John Gardner's work. In General Techniques for the L3 SC images have structure that users can access, I included references to some work on SVG and accessible mapping that was done in Canada. URIs are in the Resources section for that General Technique; may be something we can use there.
1214 (Skipping blocks of repeated material to L1 for harmonization with US Section 508) Not sure whether this is a SC or a technique. In the current state of the Web it should remain a SC, but it's on its way to becoming a technique. XHTML 2.0 will include a role attribute that can have values such as "navigation" and "primary," "secondary," etc. (for content or navigation. And there is ongoing discussion about developing techniques for doing this in HTML 4.01 by using the <link> element, e.g., <link rel="navigation" href="#sitenav" title="Sections of this site">, where the href points to a div with id="sitenav"; the UA would add the title (e.g., Sections of this site) to an automatically generated list of links; selecting this link would take you to the navbar for the site, etc. There'd be a similar thing for the maincontent. Another piece of this is for Uas (not just AT) to provide a set of standard accesskeys, so that in [your favorite browser here] pressing (for example) alt+n would always take you to the navbar on whatever site you were visiting and alt+m would always take you to the main content area, etc. Authors wouldn't assign accesskeys, just define roles.
1391 (Content sequence). I don't think this SC (currently L3 SC1, though see previous discussion re 829 moving it to L1) isn't about keyboard navigation. It's about reading order, e.g., for screen readers when the reading order can't be inferred from presentation. (See example in General Techniques of online newsletter with pullquotes, sidebars, etc; visual layout forces readers to choose reading order but makes the context available to help them choose; screen readers and other talking devices have to choose but don't have a way to let reader make informed choices.) In Maximum Accessibility I discussed a page on the Metropolitan Museum of Art site where layout tables were used in such a way that part of the navbar interrupted the screen reader's reading of the text-- there was a heading that said "Description" (of an image), but from there JAWS went and read the navbar instead of reading the text of the description. Visually, the text of the description was directly below the heading, but in the reading order there were something like 35 HTML elements between the heading and the description. Because of the table layout, JAWS *had* to read the navbar even though no sentient human would have done so.
1393 (paragraphs)
Wendy writes:
<blockquote>
WAC: This seems related to 3.1. I don't think "logical" clarifies it and
is not testable.
</blockquote>
Interesting issue. A lot of work on document design and plain language converges in recommending that text be "chunked" into relatively short paragraphs separated by white space, etc., and this is also recommended by most people who talk about how design can support people with reading disabilities. All of that is related to making text easier to read and understnd and thus to 3.1. The question here is, does dividing text into paragraphs help people with disabilities find content, orient themselves within it, or navigate through it? If so, which disabilities, and how does paragraphing help?
1503:
Thanks Wendy for catching that we missed the intent. Agree that this one needs more work.
1130 (WWAC proosal to require skip links near top of page) Agree with Wendy that this is a technique and not SC. Relates to previous discussion re role attribute in XHTML 2.0 and possible use of <link> element in HTML 4.01 plus UA.
Overlap between 1.3 and 2.4:
Wendy writes:
<blockquote>
My opinion is that 1.3 should address
providing structure and metadata related to presentation, structure, and
behavior and 2.4 should address providing additional navigation
mechanisms and in some cases semantics that can not be derived from
structure. Would be great if we could boild it down to: 1.3 is about
structure and 2.4 is about navigation mechanisms and semantics...but
that's too broad since structure can provide meaning... </blockquote>
What about something like this:
1.3 is about identifying structures, relationships, and behaviors in such a way that they persist through arbitrarily adapted presentations; 2.4 is about any additional mechanisms that authors have to provide to support the user in finding content, oreinting him/herself to it, or navigating through it (i.e., anything needed to allow UAAG-conforming user agents to provide automatic navigation support, plus useful stuff not provided by the UA); 3.1 isn't so much about "meaning" as it is about *language* (though it isn't necessarily limited to language); 3.2 is about using design to support understanding... John
"Good design is accessible design."
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/
-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Wendy Chisholm
Sent: Thursday, April 21, 2005 2:58 pm
To: Yvette Hoitink
Cc: w3c-wai-gl@w3.org
Subject: Re: [2.4] Summary of issues for guideline 2.4
Hello Yvette,
Great summary! Responses provided in-line. Sorry I didn't get this out
further before the call, however I hope this will be useful feedback to
whoever takes the action items to further develop proposals for next week.
>** Issues that can be closed **
>
>
Agree that issues 434, 564, 859, 1169, 1395
>1394. Good structure can't be captured accurately [30]
>
>
<snip>
>YPH: I think Catherine's argument is valid for the entire guidelines:
>you can never completely define accessibility either, in the end it's
>up to the skill of the author. Simply following guidelines isn't
>enough, you have to know how to apply them. However, I think this group
>feels that producing these guidelines, success criteria and techniques
>helps developers even if it's not a 100% guaranteed recipe for an
>accessible website. I propose to explain this to the original poster
>and then close this issue.
>
>
I agree that we should discuss and assuming other people will have this
concern, we could explain this in the intro of the document. e.g.,
modify "Purpose" to read:
<current>
This document outlines design principles for creating accessible Web
content. When these principles are ignored, individuals with
disabilities may not be able to access the content at all, or they may
be able to do so only with great difficulty. When these principles are
employed, they also make Web content accessible to a variety of
Web-enabled devices, such as phones, handheld devices, kiosks, network
appliances. By making content accessible to a variety of devices, that
content will also be accessible to people in a variety of situations. </current> <additional-paragraph> Employing these guidelines does not guarantee that conforming content is
accessible. However, it greatly increases the chances that the content
will be accessible. To truly determine if content accessible, the
content should be tested by a variety of people with a variety of
disabilities.
</additional-paragraph>
To avoid too much confusion or consternation this should be tweaked, but
feel this basic idea could be expressed at this point in the document. I
thought we already had wording to this effect but did not find it with a
quick skim.
Also, I wonder if the following ought to be clarified: "Designing Accessible Web Content
These guidelines provide the basic requirements for designing accessible
Web content. This document is not designed to provide the background
needed to learn about accessible Web design in a thorough or effective
manner for those interested in learning. Readers are therefore referred
to the Education and Outreach Working Group of the Web Accessibility
Initiative."
>** Issues that might be closed after some small changes and/or
>discussion **
>
>510. bicycle example was confusing [5]
>
>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: (same as previous summary) 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.
>
>
>
Does the clarification in General Techniques accomplish this? http://tinyurl.com/cv9sg
>676. 1.5 example 1 [7]
>
>Greg Lowney objects to the suggestion to make _subtle_ differences
>between the appearance of titles and section headings.
>
>YPH: (same as previous summary) I agree with Greg. I propose to delete
>the word 'subtle' from the example and then close this issue. It would
>then
>become:
>
>
sounds good to me.
>808. Benefits rewording proposal [8]
>
>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: (Same as previous summary) 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.
>
>
WAC: I propose to leave them as is, because the functionality is not
limited to assistive technologies. Opera provides a way to jump between
headers (s and w keys) - http://www.opera.com/features/keyboard/index.dml.
>829. Linear reading order should be level 1 [9]
>
>Michael Cooper proposed to move the linear reading order SC to level 1.
>
>YPH: There was no consensus to move the requirement to have a logical
>reading order in a telecon on July, 2004. Since then, a lot of
>re-writing has been done. The current phrasing is: "When content is
>arranged in a sequence that affects its meaning, that sequence can be
>determined programmatically". I think less people will have trouble
>with the current wording being at level 1. I propose to re-vote on the
>level of this success criterion and then close this issue.
>
>
WAC: I support moving this to Level 1. Especially since this is an
important aspect of making Web applications accessible.
>946. Needs examples to understand success criteria for 2.4 [10]
>
>
>
snip
>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.
>
>
WAC: A better example may be a map based on the demo we received from
John Gardner a while back which is based on his work described in this
paper from CSUN (2001): <http://www.csun.edu/cod/conf/2001/proceedings/0103gardner.htm>
or from his site: <http://www.viewplus.com/products/software/IVEO>
minutes from linz meeting where john demoed his talking browser with an
svg map - does *not* contain a good description of what the browser read
or how he navigated two images (map of U.S., heart): <http://www.w3.org/WAI/GL/2002/07/f2f-minutes.html#Monday>
>948. User agent or content author should determine voice style in
>Example 5 [11]
>
>James Craig feels that the example about a more formal voice for
>headers is something that should be left to the user agents or content
>author and suggests using "a discernibly different style" instead.
>
>YPH: I think this example was meant to show how the content author
>could use auditory style sheets to make distinguish between different
>types of content. I think the example should be re-written to make that
>clear.
>
>Perhaps we can rewrite it in a similar way as example 1 does for the
>visual
>differences:
>
>Example 5: an audio presentation.
>
>A style sheet defines a different voice to read the headers. This
>difference might be in pitch, volume or in tone, for example by using a
>louder, more formal voice. This way, the listener can easily hear the
>difference between a header and the main text.
>
>I propose to vote on this new phrasing and then close this issue.
>
>
WAC: I like it.
>955. TOCs should include information about presentation modes [12]
>
>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: (same as previous summary) 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.
>
>I propose to discuss what to do with this item and then assign some
>action items to create appropriate techniques.
>
>
>
WAC: Agree that this seems like content for the Guide or Techniques.
>1214. 2.4: 1194.22-like SC should be level 1 [21]
>
>Loretta Guarino Reid feels that the skip-link requirement should be at
>level 1 to harmonize with section 508.
>
>YPH: I propose to take a vote and decide what level this SC should be
>at. Perhaps, we first need to find out how people feel about following
>the 508 levels in WCAG.
>
>
WAC: Currently, our "skip link" requirement is the level 2 criterion,
"Blocks of repeated material, such as navigation menus and document
headers, are marked up so that they can be bypassed by people who use
assistive technology or who navigate via keyboard or keyboard interface." If we agree to move the other item to level 1 - "When content is
arranged in a sequence that affects its meaning, that sequence can be
determined programmatically. " then the only piece missing is the markup
that groups the repeated material. However, that *could* be covered by
the existing level 1 criterion, "Structures and relationships within the
content can be programmatically determined." Then, the current level 2
criterion for bypassing repeated material could become a technique.
Or...is that stretching it too much?
>1387. "find content" unclear [23]
>
>Catherine Brys thinks the "Find content" in the description of the
>guideline could be misinterpreted to mean search functionality.
>
>YPH: I agree with Catharine. I propose someone take an action item to
>re-formulate this.
>
>
WAC: Agree with John "So I would say that we should explain to the
reviewer that the guideline *does* include site search and close the issue."
>1388. Don't repeat GL 1.3 SC in GL 2.4 [24]
>
>At the moment, the level 1 SC for 1.3 and 2.4 are the same: Structures
>and relationships within the content can be programmatically
>determined. Catherine Brys thinks we should delete the item at 2.4.
>
>YPH: I propose we vote to either have it in 1.3 only, in 2.4 only or in
>both.
>
>
WAC: Related to discussion of new proposal and issue summary for
Guideline 1.3 <http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0150.html>
Which seems to suggest that we remove it from 2.4 and clarify in the
techniques. I'm fine with that. Seems that the Guide would provide
useful interpretation of the overlap.
>1389. "document" not appropriate to web [25]
>
>Catherine Brys is confused by the word 'document' and feels this
>doesn't refer to web content.
>
>YPH: I propose we either explain to Catherine Brys that online
>documents are meant, reformulate the wording or include a definition
>for document.
>
>
WAC: It seems to me that this criterion is specific to documents and
does not apply to web apps. Either way, this is subtle and should be
clarified either through a definition (of document) or a Note: related
to the criterion.
>1390. GL2.4, SC L2 is not sufficient [26]
>
>Catherine Brys feels that just requiring two ways to get to content is
>not sufficient. In many cases, the 'findability' of the page depends on
>the quality of the metadata.
>
>YPH: I do not see how we can make this into a testable requirement. My
>proposal is to keep the SC as it is but to include an extra example
>which shows two or more ways to get to content, and to create general
>techniques about how to use metadata effectively.
>
>
WAC: sounds like a good approach.
>1391. content sequence SC too vague [27]
>
>Catherine Brys thinks the requirement "When content is arranged in a
>sequence that affects its meaning, that sequence can be determined
>programmatically." is too vague since sequence will always almost
>influence meaning.
>
>YPH: I don't really see a problem with this, it just means that the
>"when" part is almost always true, so you have to make sure the
>sequence can be determined programatically almost allt he time. I
>propose to check if the group feels the same way and then close this
>issue.
>
>
WAC: If the when is always true, are we basically saying that the
keyboard navigation sequence makes sense? If so, what about "A
meaningful sequence is provided or can be determined programmatically"
In other words, either the meaningful sequence is provided by default
via the object model or an alternative order is programmatically
determined. However, "meaningful" is subjective..
>1392. what is structure for images? [28]
>
>Catherine Brys wants to know what is meant by structure for images.
>
>YPH: For people that are unfamiliar with SVG, this requirement would
>seem very strange. I propose to expand the bike example (nr. 2) by
>explaining that there are technologies which allow structural grouping
>of visual objects. If we explain this to Catherine, I think we can
>close this issue.
>
>
WAC: yes, believe this is covered by above proposals re: SVG and the
bicycle example. Also covered by the Guide.
>1393. what does "paragraph" imply? [29]
>
>Catherine Brys wonders if the word 'paragraph' refers to the logical
>paragraphs or visual paragraphs.
>
>YPH: I think we just mean logical paragraphs, as you can never know how
>a paragraph is rendered for a specific user. Perhaps we could add the
>word 'logical' to make this more clear. Also, I think the fact that we
>mean the logical paragraphs will be clear from the techniques for this
>SC. I propose to explain this to the original poster and then close
>this issue.
>
>
WAC: This seems related to 3.1. I don't think "logical" clarifies it and
is not testable.
>1503. 2.4 L2 SC1 - proposed wording [33]
>
>New proposal for baseline-free wording: "Multiple navigation mechanisms
>are available for collections of 5 or more delivery units."
>
>YPH: I propose to vote on this new wording.
>
>
WAC: This does not mean the same thing as the original wording. Original
said, "Documents that have five or more section headings and are
presented as a single delivery unit include a table of contents with
links to important sections of the document. "
Therefore, to keep the same meaning with the new format, it would be
something like, "A collection of delivery units with 5 or more section
headings that is presented as a single perceivable unit has multiple
navigation mechanisms." In other words, a document with 5 or more
section headings presented as a single perceivalbe unit is not the same
as a collection of 5 or more delivery units. This needs more work.
Sorry I didn't catch this when the proposals were sent.
>1504. 2.4 L2 SC2 - proposed wording change [34]
>
>New proposal for baseline-free wording: Multiple ways to find specific
>content within a set of delivery units are available.
>
>YPH: I propose to vote on this new wording.
>
>
WAC: Again, I think we're saying that the multiple ways of finding info
is provided in the delivery unit such that the perceivable unit provides
this functionality. Think it needs work.
>1505. 2.4 L2 SC3 - proposed wording change [35]
>
>New proposal for baseline-free wording: Blocks of repeated material are
>implemented so that they can be bypassed by people who use assistive
>technology or who navigate via keyboard or keyboard interface.
>
>YPH: I propose to vote on this new wording.
>
>1506. 2.4 L3 SC2 - proposed wording change [36]
>
>New proposal for baseline-free wording: When a delivery unit is
>navigated sequentially, elements receive focus in an order that follows
>relationships and sequences int he content
>
>YPH: I propose to vote on this new wording.
>
>
WAC: Sounds good. Now I need to go back and rethink comments to previous
issue...
>1508. 2.4 L3 SC 5&6 need further exploration re: baseline impact [38]
>
>During the analysis of the impact of not setting a baseline assumption,
>it was found that the following SC need further exploration:
>
>Text is divided into paragraphs
>
>Documents are divided into hierarchical sections and subsections that
>have descriptive titles
>
>YPH: I propose to create an action item for someone to work on this.
>
>
WAC: agree.
>** Issues that may require additional success criteria **
>
>
WAC: Agree with Yvette's suggestion discussion points and action items.
>1130. Add clear in-page link such as "skip-to-content" near the top of
>the page [14]
>
>WWAAC propose to require a skip-to-content and skip-to-links links near
>the top of the page.
>
>YPH: As John Slatin wrote, the current re-write doesn't fully address
>this point since it recognizes skiplinks as _a_ way to meet the
>guidelines and not as the only way. It might be useful to require those
>explicit links at level 3.
>
>I propose to discuss adding another success criterion that requires
>explicit links to the most important parts of the content. If the group
>feels this is a good idea, we can make it into an action item to come
>up with a proposal.
>
>
WAC: Yes, let's discuss. My opinion: this is a technique and is related
to the baseline issue (which set of techniques someone chooses to use).
I do not think we need an additional criterion.
>** Issues that may require deleting success criteria **
>
>1507. 2.4 L3 SC3 - proposed deletion [37]
>
>After the impact analysis of not setting a baseline, Ben Caldwell
>proposes to delete the success criterion "Images have structure that
>users can access"
>
>YPH: I propose we take a vote on this.
>
>
WAC: Could depend on our definition of "non-text content." If
"Structures and relationships within the content can be programmatically
determined." we could say, "this includes non-text content within the
content...but within reason" similar to the idea I brought up yesterday
with respect to labeling functional non-text content and recursive
application of these criterion.
>** Issues that need serious discussion ("elephants") **
>
>Overlap with guideline 1.3
>
>YPH: As can be seen from the duplicate SC at level 1, there seems to be
>major overlap with guideline 1.3.
>
>We need to decide what 2.4 is about. Is it about adding structure so
>people can navigate? Is it about additional navigation mechanisms
>besides that which you get when providing structure? What do we want to
>go in 1.3 and what needs to be in 2.4?
>
>
WAC: Yes, should discuss. My opinion is that 1.3 should address
providing structure and metadata related to presentation, structure, and
behavior and 2.4 should address providing additional navigation
mechanisms and in some cases semantics that can not be derived from
structure. Would be great if we could boild it down to: 1.3 is about
structure and 2.4 is about navigation mechanisms and semantics...but
that's too broad since structure can provide meaning...
>** Author **
>
>This summary was written by Yvette Hoitink, April 2005
>Contact: y.p.hoitink@heritas.nl
>
>** Notes **
>
>[1].
>http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0512.html
>[2]. http://www.w3.org/TR/2004/WD-WCAG20-20041119/
>[3].
>http://trace.wisc.edu/bugzilla_wcag/issuereports/navigation-mechanisms_issue
>s.php
>[4]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=434
>[5]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=510
>[6]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=564
>[7]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=676
>[8]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=808
>[9]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=859
>[10]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=946
>[11]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=948
>[12]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=955
>[13]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1016
>[14]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1130
>[15]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1131
>[16]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1132
>[17]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1136
>[18]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1137
>[19]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1169
>[20]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=829
>[21]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1214
>[22]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1319
>[23]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1387
>[24]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1388
>[25]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1389
>[26]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1390
>[27]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1391
>[28]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1392
>[29]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1393
>[30]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1394
>[31]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1395
>[32]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1441
>[33]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1503
>[34]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1504
>[35]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1505
>[36]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1506
>[37]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1507
>[38]. http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1508
>
>
--
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--
Received on Saturday, 23 April 2005 18:33:29 UTC