- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:31:57 -0700
- To: "Greg Gay" <g.gay@utoronto.ca>
- Cc: public-comments-WCAG20@w3.org
Dear Greg Gay, Thank you for your comments on the 17 May 2007 Public Working Draft of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0 http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group has reviewed all comments received on the May draft, and will be publishing an updated Public Working Draft shortly. Before we do that, we would like to know whether we have understood your comments correctly, and also whether you are satisfied with our resolutions. Please review our resolutions for the following comments, and reply to us by 19 November 2007 at public-comments-wcag20@w3.org to say whether you are satisfied. Note that this list is publicly archived. Note also that we are not asking for new issues, nor for an updated review of the entire document at this time. Please see below for the text of comments that you submitted and our resolutions to your comments. Each comment includes a link to the archived copy of your original comment on http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may also include links to the relevant changes in the WCAG 2.0 Editor's Draft of May-October 2007 at http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/ Thank you for your time reviewing and sending comments. Though we cannot always do exactly what each commenter requests, all of the comments are valuable to the development of WCAG 2.0. Regards, Loretta Guarino Reid, WCAG WG Co-Chair Gregg Vanderheiden, WCAG WG Co-Chair Michael Cooper, WCAG WG Staff Contact On behalf of the WCAG Working Group ---------------------------------------------------------- Comment 1: LC-469: Resizing with no horizontal scrolling Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0068.html (Issue ID: 1986) ---------------------------- Original Comment: ---------------------------- > Source: http://www.w3.org/mid/20060515151645.E147A6636B@dolph.w3.org > (Issue ID: LC-469) > > Comment (Including rationale for any proposed change): > There is currently no item number relevant to this comment. Technique > G96 seems to be the only place within the WCAG 2.0 documents that > mentions anything about "relative positioning", or more specifically > use of relative measures. Using relative measures is particularly > important for low vision users who use a browser function to blow up > the text size. It is also important for those using small screens like > PDAs. > > Proposed Change: > This requirement seems to fit best under WCAG principle 4, regarding > robust. Perhaps a new guideline 4.1.3, at level 2. something like > "Ensure that content can be resized without losing its symmetry" Then > in the techniques describing the use of relative measures for sizing > block level items, text, images, etc. > > ---------------------------- > Response from Working Group: > ---------------------------- > > Although resizing is primarily a user agent function, we have added > new success criteria to address the author's responsibility for > supporting text resizing: > > Level AA: Visually rendered text can be resized without assistive > technology up to 200 percent and down to 50 percent without loss of > content or functionality. > > Level AAA: Visually rendered text can be resized without assistive > technology up to 200 percent and down to 50 percent without loss of > content or functionality and in a way that does not require the user > to scroll horizontally. > ---------------------------- Response from Greg Gay: ---------------------------- The Level AA criteria should be good. Though it should apply to content in general. Not just text. At Level AAA, I don't think eliminating horizonatal scrolling addresses the issue. When increasing the size of a presentation, it is often necessary to push the content off the side of the screen in order to maintain the layout. At 200% it may not be a big problem, but for those who need text (and images etc.) presented larger than 200%, say 400% for sake of argument, the text can end up in a one or two words wide column, and potentially disrupt the layout of the page enough that it makes it difficult to comprehend the overall structure of a page, which can often carry significant meaning. Having the entire presentation increase in size at the same rate, while it does require the users to scroll horizontally, maintains the symmetry of the overall presentation, making it easier to understand. The presentation or layout of content should look the same at 200% , or 400%, as it does at 100%, rather than having, for example, 400% text squeezed into a 100% container. The container should also be enlarged to 400%, much like magnification software presents content, with text, images, and their containers all magnified at the same rate. This same effect can be reproduce in a web browser window through strict use of relative measures. As an example, IE 7 functions this way by default, ignoring absolute measures, acting like a screen magnifier does (I'm not a big IE fan, but I do like this particular new feature). Presentation at 400% in IE, is much easier to comprehend, even having to scroll horizontally, than the same presentation in other browsers that do enforce absolute measures, and attempt to squeeze everything magnified into the same amount of space unmagnified. This issue applies to other types of content besides text. Content in general should resize, including images (which often contain text), as well as the layout (i.e. containers for text and images). Authors generally don't have to do anything to make text resizable. Making everything on a page resizeable is more of a challenge, though if relative measures are used throughout, it's relatively straight forward to accomplish. Perhaps word the guideline: Level AAA: Visually rendered <content> can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality and in a way that does not require the user to scroll horizontally. Beyond 200 percent, content should resize maintaining the layout and relative visual presentation/locations of the content as it would be presented between 100 precent and 200 precent magnification. I might also question whether 200% magnification is sufficient for the majority with low vision users. For purposes of defining when scrolling should not be required, it's probably okay, but my general sense is that the majority of users that require large text, would probably opt for something larger than 200%. Is there research to suggest 200% is the optimal size for a diverse population of users with low vision? I'm just curious where the numbers came from. Similarly, 50% may not be enough either, given PDA or perhaps cell phone screens are smaller than 50% of you standard 17 in monitor resolution. The numbers here are probably fine, but it might save argument later if there is some reasoning provided why these values were choosen. (Maybe there is. I just haven't found it yet) --------------------------------------------- Response from Working Group: --------------------------------------------- We agree that text cannot be significantly enlarged without adapting the layout. The type of layout adaptation discussed in the comment is called "zoom" - in which the layout regions expand with the text, frequently beyond the range of the viewport - and is discussed in Understanding SC 1.4.4 and Understanding SC 1.4.7. The Working Group expects large scale (greater than 2x or 4 times the area) zoom functionality generally to be provided by assistive technology, and does not provide content authoring requirements to support this because at a minimum zoom tools can enlarge the image written to the screen. In many situations tools can provide better support by redrawing text at larger sizes, rather than simply enlarging the pixels, but the features necessary to support this are believed to be covered by other Success Criteria. SC 1.4.4 and 1.4.7 are not intended to address large scale zoom functionality. Users needing zoom greater than 2x are expected to use assistive technology. But the Working Group recognizes that text size presents a problem for many users who have difficulty reading small text, but whose difficulty is not so extreme that they would use assistive technology. Thus, these success criteria are about the ability for text to be scaled within mainstream browsers using the features built into the browsers. At Level AA, SC 1.4.4 simply requires that the text can be scaled by 200% and down to 50% but doesn't forbid text from going offscreen. Zoom features in the browsers are usually used for this function. At Level AAA, SC 1.4.7 requires that text scaling be possible where the text would reflow so that horizontal scrolling is not required. This makes it very much easier to read blocks of text that would otherwise always be half on and half off screen. The range of up to 200% is provided because a limit to the requirement had to be set. This limit is based on the scaling supported by today's browsers and what the Working Group considered a reasonable degree of scaling within a well-designed layout. Users needing scaling beyond this limit should not have expectations about the usefulness of the scaling in mainstream browsers and should use assistive technologies. ---------------------------------------------------------- Comment 2: LC-535, LC-536: Audio descriptions and full text alternatives Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0068.html (Issue ID: 1987) ---------------------------- Original Comment: ---------------------------- > Source: http://www.w3.org/mid/20060511195339.A362647BA5@mojo.w3.org > (Issue ID: LC-535) > > Item Number: Success Criterion 1.2.2 > Part of Item: > Comment Type: TE > Comment (Including rationale for any proposed change): > > Guideline 1.2 > > Guidelines 1.2.2 and 1.2.3 are not mutually exclusive. Perhaps it > should be, if an audio description is provided, compliance is at > level 2. If a transcript is provided instead, compliance is at level > 1. > > 1.2.2 "Audio descriptions of video, or... are provided for > prerecorded multimedia." > > 1.2.3 "Audio descriptions of video are provided for prerecorded > multimedia. > > Proposed Change: > > Drop "Audio descriptions of video" from 1.2.2. Audio description are > relatively difficult to implement, while text transcripts are quite > easy. Leave the transcript at level 1, which is attainable by > everyone, and keep audio descriptions to level 2. > > ---------------------------- > Response from Working Group: > ---------------------------- > > SC 1.2.2 and 1.2.3 are indeed not mutually exclusive. If they were, we > couldn't have them both as success criteria. However, making the > change you suggest would remove options for authors at level A. In > some cases it is easier and/or more effective to provide the full text > alternative. In other cases it is easier and/or more effective to > provide the audio equivalents. The current wording allows the author > to chose at level A, but does require them to use audio description at > level AA. Audio description would of course satisfy both level A and > AA if it were provided. Therefore removing Audio Description from > level A would make it harder for authors, not easier since it removes > an option. ---------------------------- Response from Greg Gay: ---------------------------- See my response to Comment 9 below > > ---------------------------------------------------------- > Comment 9: > > Source: http://www.w3.org/mid/20060511195927.48A1833205@kearny.w3.org > (Issue ID: LC-536) > > Item Number: Success Criterion 1.2.7 > Part of Item: > Comment Type: TE > Comment (Including rationale for any proposed change): > > Guidelines 1.2.2 and 1.2.7 are not mutually exclusive. > > 1.2.2 "... a full multimedia text alternative including any > interaction, are provided for prerecorded multimedia." > > 1.2.7 "For prerecorded multimedia, a full multimedia text alternative > including any interaction is provided > > Proposed Change: > > Drop 1.2.7 in favour 1.2.1 at level 1, with Audio descriptions removed > in favor of keeping them with 1.2.3 at level 2. > > ---------------------------- > Response from Working Group: > ---------------------------- > > Correct. SC 1.2.2 and 1.2.7 are not mutually exclusive. If they were > we could not require both. The option is provided at Level A. At > level AA Audio descriptions are required (which would also satisfy > level A). At level AAA the text description is required, which would > be in addition to the audio description required in level AA. The > working group did not want to require SC 1.2.7 at level A but did want > to have it as an option there and as a level AAA success criterion if > it was not provided at level A. > ---------------------------- Response from Greg Gay: ---------------------------- I'm still not sure about this one. If I provide a full text alternative (but no audio descriptions) does the content comform at level 1 or level 3? Assuming all level 2 items are required for level 3 items to conform, it makes sense that it would conform at level 1 only. If however I provide an audio description, but not a full text alternative, does the content conform with level 1 or level 2? It would make sense that it conforms at level 2, but it's not clear that is the case when audio descriptions are also included at level 1. The logic behind 1.2.2, 1.2.4 and 1.2.7 together is incorrect. It reads like this (assuming lower levels must be satified first) level 1 = audio description || full text description level 2 = audio description && (full text description || audio description) level 3 = full text description && (audio description && (full text description || audio description)) level 1 = level 2 if only audio descriptions are provided (but not text) level 1 + level 2 = level 3 + level 2 if both audio and text are provided instead level 1 full text level 2 audio and full text level 3 eliminate 1.2.7 I'm still not sure I have the logic right myself. But either way, I could find no way to make the three agree with each other without creating confounds. I believe they need to be reduced to two guidelines audio or text at level 1 and audio and text at level 2, or text at level 2 and audio and text at level 3 (depending on the importance, or weight, assigned to audio equivalents and to text equivalents) Some more thought needs to go into these three guidelines I think. --------------------------------------------- Response from Working Group: --------------------------------------------- It is true that SC 1.2.2, 1.2.4, and 1.2.7 are somewhat redundant with each other. This is to give the author some choice at the minimum conformance level, and to provide additional requirements at higher levels. At Level A in SC 1.2.2, authors do have the choice of providing either an audio description or a full text alternative. If they wish to conform at Level AA, under SC 1.2.4 authors must provide an audio description - a requirement already met if they chose that alternative for 1.2.2, otherwise an additional requirement. At Level AAA under SC 1.2.7 they must provide an extended text description. This is an additional requirement if both 1.2.2 and 1.2.4 were met by providing an audio description only. If 1.2.2 was met, however, by providing a text description, and the 1.2.4 requirement for an audio description was met, then 1.2.7 does not add new requirements. In order to clarify this, explanation has been added to the Understanding documents for the three Success Criteria. ---------------------------------------------------------- Comment 3: LC-537, LC-538: Move Luminosity Contrast Ratio to techniques Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0068.html (Issue ID: 1988) ---------------------------- Original Comment: ---------------------------- > Source: http://www.w3.org/mid/20060511200217.4083633205@kearny.w3.org > (Issue ID: LC-537) > > Item Number: Success Criterion 1.4.1 > Part of Item: > Comment Type: GE > Comment (Including rationale for any proposed change): > > Guideline 1.4 > > Luminosity Contrast Ratio in its current form appears to be a less > than perfect measure of contrast. For example black text on a white > background is more readable than white text on a black background, yet > both have the same ratio. In the future as the algorithms for > measuring contrast become better, the suggested 5:1 ratio in 1.4.1, > may no longer be valid. > > Proposed Change: > > A general statement should be made in the guideline, something like > ...use foreground and background colours that provide sufficient > contrast...", and move LCR and the suggested ratio to the techniques > document, where it can be adjusted as measure of contrast become > better defined. > > ---------------------------- > Response from Working Group: > ---------------------------- > > The change you propose would make the success criteria untestable. > All success criteria need to be testable to qualify. So we need to > provide specific description of what 'sufficient contrast' is. > ---------------------------- Response from Greg Gay: ---------------------------- I don't see a difference in testability between including LCR in the guidelines or in the techniques. In the techniques it would allow the option to alter the threshold levels should these measures need adjustment after WCAG 2 becomes stable. The rewritten 1.4 guidelines have changed. I'll give them some more attention for the final review of this draft. > ---------------------------------------------------------- > Comment 11: > > Source: http://www.w3.org/mid/0060511200418.D1BC733205@kearny.w3.org > (Issue ID: LC-538) > > Item Number: Success Criterion 1.4.3 > Part of Item: > Comment Type: TE > Comment (Including rationale for any proposed change): > > As suggested for 1.4.1, Luminosity Contrast Ratio in its current form > appears to be a less than perfect measure of contrast. For example > black text on a white background is more readable than white text on a > black background, yet both have the same ratio. In the future as the > algorithms for measuring contrast become better, the suggested 10:1 > ratio in 1.4.1, may no longer be valid. > > Proposed Change: > > A general statement should be made in the guideline, something like > ...use foreground and background colours that provide *high* > contrast...", and move LCR and the suggested ratio to the techniques > document, where it can be adjusted as measure of contrast become > better defined. > > ---------------------------- > Response from Working Group: > ---------------------------- > > The change you propose would make the success criteria untestable. > All success criteria need to be testable to qualify. So we need to > provide specific description of what 'sufficient contrast' is. > > It is not always true that black text on a white background is more > readable. For older people and people with impaired vision white on > black is generally more readable because there is less light scatter > (for media opacities) and fewer problems with adaptation levels. > ---------------------------- Response from Greg Gay: ---------------------------- This would seem to strengthen the argument that LCR values should be separated from the text of the guidelines. Sufficient contrast should be explicitly defined, since it would seem to be relative to the individual. Taking colour blindness, or age, or visual acuity into consideration, levels of contrast seem to be a subjective measure. The fact that the guidelines have moved contrast into level 2 and 3, makes it less critical that it was when it was in level 1, though given the nature/relative newness of the measure, including explicit measure in the guidelines could be troublesome in the future. --------------------------------------------- Response from Working Group: --------------------------------------------- All the success criteria need to have sufficient specificity that using only the success criteria (and their definitions which are also normative) you can get most people to all agree. Without a specific definition of contrast including the metrics - this would not be true. You can't make the success criteria more restrictive in the techniques then they were in the success criteria. Only the success criteria are normative. The techniques are just informative. Hence we need to provide testable specifics in the success criteria (including their definitions.) Accessibility is ALWAYS relative to the individual. However, standards need to be relative to populations. The calculations for contrast are based on population measures of color blindness, age and acuity. (see Understanding SC 1.4.3). Standards that people can design to are then established. The current guidelines are based on established industry standards and research on color blindness and visual acuity. They will also undergo implementation testing before the guidelines are finally released. Does this answer your questions? ---------------------------------------------------------- Comment 4: Use Headings as well as make them meaningful Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0207.html (Issue ID: 2024) ---------------------------- Original Comment: ---------------------------- In addition to headings being descriptive, it should state that headings must be used to structure content (and be descriptive). It reads now as ".. if you use heading they must be descriptive". Headings are generally meaningful by default. What\'s more important is that heading markup be used (properly) instead of using other means to visually present heading. Proposed Change: \"Headings and labels are used and are descriptive\" --------------------------------------------- Response from Working Group: --------------------------------------------- We believe these issues are already covered. SC 1.3.1 requires that if headings are used, then are marked up properly. See technique "H42: Using h1-h6 to identify headings" and failures "F2: Failure of SC 1.3.1 due to using CSS to create variations in presentation of text that conveys information without also using the appropriate markup or text" and "F64: Failure of SC 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text". SC 2.4.6 requires that headings that are used are sufficiently descriptive so they can help orient the user within the content. It is true that most headings are descriptive, but they may rely on the existing logical structure too much to help orient the user. SC 2.4.9 requires the use of headings where appropriate in the content. ---------------------------------------------------------- Comment 5: Limits on pronunciations Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0209.html (Issue ID: 2025) ---------------------------- Original Comment: ---------------------------- I might question how relevant this is to accessibility. This is really only applicable when words appear without a context from which to derive meaning. I'm having trouble understanding how such ambiguity would be tested, and if it can be tested, how to test whether a pronunciation has been provided. --------------------------------------------- Response from Working Group: --------------------------------------------- In some languages, there are many words that have alternate meanings and pronunciations. Although people who visually read and have good cognition may be able to determine the meaning, it is still sometimes ambiguous. To handle such languages, there are ways to mark up the text so that its proper pronunciation (and therefore meaning) can be determined. This is helpful to all but particularly to people with cognitive disabilities who may have more trouble than most with this type of content - and with those using screen readers where mispronunciation is worse than ambiguous pronunciation (which is what visual presentation gives.) Although the Success Criterion only requires it when it is strictly ambiguous, advisory techniques on this Success Criterion recommend it when it is not as obvious or even when ambiguous without context. ---------------------------------------------------------- Comment 6: Limits on user controlled timed events Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0203.html (Issue ID: 2049) ---------------------------- Original Comment: ---------------------------- Refers to the Users' ability to control timed events. An exception could be when timed tests are being presented. In such a case one might not want a student to have control over the time limits, but rather allow a third party (e.g. the teacher) to grant extra time as appropriate given the test takers limitations. In most academic institutions a suitable extended time is determined through evaluation of a student's ability (e.g. psycological, physical, occupational assessments) and granted, for instance: time and a half, double time etc, on tests. Proposed Change: Perhaps as an additional line with Essential Exceptions - "In cases where users control over timed events would invalidate the outcome, a third party can control timed events for the user (for example, granting double time on a test)" --------------------------------------------- Response from Working Group: --------------------------------------------- Since it's possible to extend the time limit in such cases, then the time limits would not be essential. We have removed "(for example, time-based testing)" from 2.2.1 to avoid confusion, and added explanation to Understanding 2.2.1 about timed tests. ---------------------------------------------------------- Comment 7: Level A SC for link text Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0204.html (Issue ID: 2050) ---------------------------- Original Comment: ---------------------------- I would agree that if context gives meaning to otherwise non-meaningful link text, the link text should not need its purpose to be programmatically determined, unless programmatically determined includes a test that checks for contextually rendered meaning (i'm guessing this might require human testing). An example might include news items in which the title, in addition to some non-meaningful link text (e.g. "more"), are provided in sequence when moving through the links on a page. In this case the meaning of "more" can be determined by a human tester through a linked title that appears immediately before the more link. Proposed Change: At level A the guideline might read: "The purpose of each link can be determined from the link text or through the link's immediate context" --------------------------------------------- Response from Working Group: --------------------------------------------- The Success Criterion is now: 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. We believe that "programmatically determinable link context" is clearer than "immediate context". Support by assistive technology for showing the user the context of the link is weaker than we would like, as is recorded in the User Agent Notes for the different techniques. We hope that this will change as more content satisfies this success criterion. ---------------------------------------------------------- Comment 8: Headings (2.4.9) as Level AA Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0208.html (Issue ID: 2052) ---------------------------- Original Comment: ---------------------------- This should probably be a level AA guideline. Structuring content with properly used heading markup can greatly improve the usability of content, allowing AT user to quickly generate a summary of the content, and allowing them to easily navigate to sections within a page. Without them, particularly for longer pages, discovering if the content on the page contains the information one is looking for, can take much longer than it needs to if a user has to read an entire page to discover information later in the page, or perhaps to discover the information is not found on the page. Proposed Change: This guideline could possibly be combined with 2.4.6 as an AA guideline. --------------------------------------------- Response from Working Group: --------------------------------------------- In order to be a AA or A requirement, it must possible for all types of content to meet the requirement. In addition, all success criteria must be reliably testable. After a great deal of effort, the working group was unable to craft a criterion that met both requirements. By defining a section in a way that allowed reliable agreement between parties on what is and is not a section, some types of longer-form text content (e.g. novels) cannot pass. Because of this limitation, the Success Criterion must remain level AAA. Below is the text of the SC and the definition of section 2.4.10 Section Headings: Section headings are used to organize the content. Note: "Heading" is used in its general sense and includes titles and other ways to add a heading to different types of content. Note: This success criterion covers sections within writing, not user interface components. User Interface components are covered under Success Criterion 4.1.2. Section Headings: Where content is organized into sections, the sections are indicated with headings. Note: "Heading" is used in its general sense and includes titles and other ways to add a heading to different types of content. section: A self-contained portion of written content that deals with one or more related topics or thoughts. NOTE: A section may consist of one or more paragraphs and include graphics, tables, lists and sub-sections. ---------------------------------------------------------- Comment 9: Use alternative versions only when necessary C Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0210.html (Issue ID: 2053) ---------------------------- Original Comment: ---------------------------- 4.) An accessible link from the nonconformant version to a conformant version (and back again) seems straight forward (am I perhaps missing something here?). The idea though that alternate versions only be used when the original version can not be made accessible, seems to have been dropped. This is important because it is fairly well known that secondary versions tend not to be updated at the same frequency as the primary version (I don\'t have a referecne). Instead of saying "...does not meet all of the success criteria..." say ".., can not be made to meet all success criteria.. Fallback #2 seems insufficient. Users should be able to find an accessible version directly from the less accessible version. #2 suggests something similar to using a transcript instead of captioning for a video. A transcript, while useful when captions can not be provided, or used in place of a video where a video player is not available, is not all that useful when watching a video and trying to match the lines of the transcript with the apparent dialogue and actions it contains. Similarly a list of accessible alternate pages has limited utility, forcing the user to perhaps leave a sequence of page, or loose the consistency provided by the primary version, and its environment. Fallback #1, I'm not sure about. What constitutes "...WCAG conformant links?" and is it relevant that future technologies many not conform to them. Should it not be a requirement that future technologies conform if they are to be judge accessibility supported? Any "link" that is readable by assistive technologies (contains readable text) and is device independent (keyboard accessible) should conform. Both of these are already requirements (1.1, 2.1) --------------------------------------------- Response from Working Group: --------------------------------------------- Fallback #1 won't work because it assumes that the non-conforming page conforms. The one option that talks about a link from the non-conforming page is stated as having to conform because one has to assume that part of the page doesn't conform (since it is non-conforming) and this option states that at least the link to the conforming version would conform. Other options are also now provided for times when the non-conforming page cannot contain a conforming link. Regarding: Saying that Alternate Pages should only be used when original versions cannot - we have added "Note that providing an alternate version is a fallback option for conformance to WCAG and the preferred method of conformance is to make all content directly accessible."
Received on Sunday, 4 November 2007 04:32:14 UTC