- From: Greg Gay <g.gay@utoronto.ca>
- Date: Fri, 08 Jun 2007 16:00:55 -0400
- To: Loretta Guarino Reid <lorettaguarino@google.com>, public-comments-WCAG20@w3.org
---------------------------- Responses from Greg Gay: ---------------------------- On first glance, the new draft seems much improved over the previous one. I'll give it a thorough review in the next week or two. For now my replies to WG replies to my comments on the previous draft are mixed in below. Loretta Guarino Reid wrote: > > ---------------------------------------------------------- > Comment 1: > > Source: http://www.w3.org/mid/20060511202531.694EBBDA8@w3c4.w3.org > (Issue ID: LC-465) > > Item Number: Success Criterion 4.2.1 > Part of Item: > Comment Type: GE > Comment (Including rationale for any proposed change): > 4.2.1 also suggests that the accessible version be the primary > version, with a link to the inaccessible version. In reality that is > never the case, nor would you likely be able convince a > client/developer to use an HTML version of their splash page in favour > of a fancy Flash version > > Proposed Change: > Ideally there should be reciprocol links between the two versions. > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have moved discussion of alternate versions of content to the > Conformance section of the Guidelines. > > "Alternate Versions: If the Web page does not meet all of the success > criteria for a specified level, then a mechanism to obtain an > alternate version that meets all of the success criteria can be > derived from the nonconforming content or its URI, and that mechanism > meets all success criteria for the specified level of conformance. The > alternate version does not need to be matched page for page with the > original (e.g. the alternative to a page may consist of multiple > pages). If multiple language versions are available, then conforming > versions are required for each language offered." > > We have also added an advisory technique titled, "Providing reciprocal > links between conforming and non-conforming versions." > ---------------------------- Response from Greg Gay: ---------------------------- Good. > ---------------------------------------------------------- > Comment 2: > > Source: http://www.w3.org/mid/20060511202657.E6605BDA8@w3c4.w3.org > (Issue ID: LC-466) > > Item Number: Success Criterion 4.2.1 > Part of Item: > Comment Type: ED > Comment (Including rationale for any proposed change): > Wording of 4.2.1 is easily misinterpreted. > > Proposed Change: > "Where content is presented using a technology that is not in the > baseline, or is in the baseline but does not meet level 1 success > criteria, provide reciprocol links between that version and another > version of that same content, with equivalent functionality, that does > meet level 1 success criteria." > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have moved discussion of alternate versions of content to the > Conformance section of the Guidelines. > > Alternate Versions: If the Web page does not meet all of the success > criteria for a specified level, then a mechanism to obtain an > alternate version that meets all of the success criteria can be > derived from the nonconforming content or its URI, and that mechanism > meets all success criteria for the specified level of conformance. The > alternate version does not need to be matched page for page with the > original (e.g. the alternative to a page may consist of multiple > pages). If multiple language versions are available, then conforming > versions are required for each language offered. > > We have also added an advisory technique titled, "Providing reciprocal > links between conforming and non-conforming versions." > ---------------------------- Response from Greg Gay: ---------------------------- Good > ---------------------------------------------------------- > Comment 3: > > 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) > ---------------------------------------------------------- > Comment 4: > > Source: http://www.w3.org/mid/20060511192524.6DF3847BA5@mojo.w3.org > (Issue ID: LC-531) > > Item Number: (none selected) > Part of Item: > Comment Type: TE > Comment (Including rationale for any proposed change): > There doesn't seem to be a place to comment on the Baseline Document, > so I'll post it here: > > http://www.w3.org/WAI/WCAG20/baseline/ > > The potential for many baselines is possible, and each baseline will > have an overall level of accessibility associated with it. For > example, a baseline that includes only HTML 4, is going to be more > universally accessible than a baseline that includes HTML 4, Flash, > Java, and Javascript. For clients or developers using the latter > baseline, we would essentially tell them that if their content made > full use of the Flash, Java, and Javascript accessibility features, > they can comply at Level 2 (hypothetically speaking). But, for a > client who creates the same site that uses the first baseline (HTML 4 > only), and has gone to the trouble of creating alternatives for their > Flash, Java, and Javascript content, will have created a more > accessible site than the site that uses second baseline and does not > have any alternative formats. What motivation would there be for the > developer of the site using the first baseline, if they can just place > all the technologies in the baseline, and forget about creating more > accessible alternative content. > > Proposed Change: > > The solution to this may be associating some base accessibility value > with a variety of standard baselines, baselines which remain > non-normative, and evolve as technologies evolve. > > ---------------------------- > Response from Working Group: > ---------------------------- > > The conformance section of WCAG2 has been completely rewritten. The > term "baseline" has been replaced by "accessibility-supported Web > technologies". The issue of what it means to be an > accessibility-supported Web technology is addressed in the section " > Accessibility Support of Web Technologies", at > http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support . > ---------------------------- Response from Greg Gay: ---------------------------- I kind of got used to using "baseline technologies" in discussions of WCAG 2, but the new system seems ok. I'll give it some more attention with the final comments on the draft. > ---------------------------------------------------------- > Comment 5: > > Source: http://www.w3.org/mid/20060511193210.21A3447BA5@mojo.w3.org > (Issue ID: LC-532) > > Item Number: Technology assumptions and the > Part of Item: > Comment Type: ED > Comment (Including rationale for any proposed change): > > For the section prior to ...assumptions and the baseline... which > isn't included in the items that can be commented on. > > References are made to Level 1 2 3, then Note 1 that follows refers to > Triple-A conformance. Prior to this though, there has been no mention > of A, AA, AAA confomance rankings. Novices to the guidelines may not > make the connection if it is not described explicitely. Not until much > further down the page is the association made. > > Proposed Change: > > Perhaps a note explaining the association, or a reference to an anchor > further down the page would be appropriate here. > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have completely rewritten the introduction and the conformance > section, and conformance levels are now defined before they are used. ---------------------------- Response from Greg Gay: ---------------------------- I'll comment on this with the my response to the draft > > ---------------------------------------------------------- > Comment 6: > > Source: http://www.w3.org/mid/20060511194049.172C847BA5@mojo.w3.org > (Issue ID: LC-533) > > Item Number: Technology assumptions and the > Part of Item: > Comment Type: TE > Comment (Including rationale for any proposed change): > > There is a relatively easy possibility of Level AAA compliance by > virtue of ommision. By default, the vast majority of sites will meet > 50% of the level 3 guidelines without trying. The following are > arguably not relevant on most Web sites. > > --------------------- > > Irrelevant for most sites > > 1.2.5 (w/ no MM) > 1.2.6 (w/ no MM) > 1.2.7 (w/ no MM) > 1.4.3 (use standard B/W) > 1.4.4 (with no audio content) > 2.1.2 (with no time dependence) > 2.2.4 (no timed events) > 2.2.5 (no auto updated content) > 2.2.6 (no timeout) > 2.3.2 (use no flashing components) > 2.4.6 (don\'t use tab to create inconsitent tab ordering > 3.1.6 (write in an alphabetic language) > 3.2.5 (use no auto redirects) > 4.2.4 (use only baseline technologies) > > --------------------------- > > Potentially 13 L3 met by omission > > So without any extra effort, a site without any of the above > technologies would meet enough level 3 criteria to comply, even though > none of the guidelines are relevant. > > Things that could be done relevant to the content of the majority of > sites > > Relevant to most sites > > 2.4.5 (use descriptive titles, headings, and labels) > 2.4.7 (use breadcrumb links to navigate, and identify location within > a hierarchy) > 2.4.8 (use meaningfult link text) > 2.5.4 (describe expected input for form fields) > 3.1.3 (provide a glossary) > 3.1.4 (expand all abbreviations) > 3.1.5 (Use low level language) > > --------------------------- > > Potentially 7 L3 relevant to most sites. > > Proposed Change: > > Perhspa 75% of level 3 items would be more appropriate, or maybe 50%, > which includes at least 4 or 5 items (or maybe all) from the second > list of more common level 3 items. > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have changed the definition of Level AAA conformance so that all > Level AAA Success Criteria that apply to the content types used must > be satisfied. > ---------------------------- Response from Greg Gay: ---------------------------- Good. > ---------------------------------------------------------- > Comment 7: > > Source: http://www.w3.org/mid/20060511194643.C7BD247BA5@mojo.w3.org > (Issue ID: LC-534) > > Item Number: Conformance claims > Part of Item: > Comment Type: GE > Comment (Including rationale for any proposed change): > > Re: Conformance notes. > > http://www.w3.org/TR/2006/WD-WCAG20-20060427/conformance.html#conformance-claims > > > The Note suggests that the default version of the content displayed > (i.e. Web unit that is returned when no negotiation is conducted) is > the one that must comply. This would mean that myself for example, as > a fully able user with no content negotiation enabled, would be forced > to view the most accessible version of a content unit, despite, > perhaps, a less accessible, more interactive, "flashy" version being > more appropropriate for my needs. > > Proposed Change: > > I think the second statement (in parentheses) "...one of the > negotiated forms must comply" makes more sense as the default here, > with perhaps the added note that "...the most accessible version is > easily accessed should the primary version not be accessible". A > common example is the Flash splash page that includes a link to an > accessible HTML version of the same content. In the initial > statement it suggested that as a developer I would have to default to > the HTML version of the page, with a link to the Flash version > instead. Developers and their clients will not agree to this, but > they will agree to a link that leads to a more accessible version.. > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have removed discussion of content negotiation and moved > requirements related to alternate versions to the Conformance section > of the Guidelines. The revised conformance criteriaon now reads: > > > Alternate Versions: If the Web page does not meet all of the success > criteria for a specified level, then a mechanism to obtain an > alternate version that meets all of the success criteria can be > derived from the nonconforming content or its URI, and that mechanism > meets all success criteria for the specified level of conformance. The > alternate version does not need to be matched page for page with the > original (e.g. the alternative to a page may consist of multiple > pages). If multiple language versions are available, then conforming > versions are required for each language offered. > ---------------------------- Response from Greg Gay: ---------------------------- Good > ---------------------------------------------------------- > Comment 8: > > 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. > ---------------------------------------------------------- > Comment 10: > > 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. > ---------------------------------------------------------- > Comment 12: > > Source: http://www.w3.org/mid/20060511200749.A05E433205@kearny.w3.org > (Issue ID: LC-539) > > Item Number: Success Criterion 2.2.1 <-- this appears to be a typo > Part of Item: > Comment Type: GE > Comment (Including rationale for any proposed change): > > I'm not sure about the distinction between 2.1.1 and 2.1.2. Does it > mean if there is required time dependant content, such as a reaction > time test, the web unit can not comply at level 3. This could > potentially be an issues, albeit unlikely, if a site were pursuing > Level 2 or 3 conformance, but had a time dependant test, for example. > > Proposed Change: > > In such a case I would expect an accessibility statement or statement > of scope to exclude the timed test, thus rendering the guideline > irrelevant to a claim of Level 2 or 3 compliance. 2.1.2 sounds like > it may not be enforcable. Perhaps remove it. > > ---------------------------- > Response from Working Group: > ---------------------------- > > It is the specific intent that timed content such as timed tests not > be able to conform to this success criterion. The goal is to encourage > the development of other non-time-based forms instead. ---------------------------- Response from Greg Gay: ---------------------------- I would agree that timing of tests always needs to be optional, or at least adjustable, or overidable if results become invalid without timing. The way the 2.2.1 guidelines read now is good. > > ---------------------------------------------------------- > Comment 13: > > Source: http://www.w3.org/mid/20060511201228.7F4DA33207@kearny.w3.org > (Issue ID: LC-540) > > Item Number: Success Criterion 3.1.5 > Part of Item: > Comment Type: TE > Comment (Including rationale for any proposed change): > > Though for public content, guideline 3.1.5 would apply, for non-public > content, such as an online course aimed at a professional audience, > there should be no requirement that it be "lower secondary" . > > How will evaluators measure language level. Perhaps using a FOG index > for English. How would they assess across languages, where a FOG index > is not valid? Would lower secondary be too high when an audience is > from a third word country, where reading levels tend to be much lower? > There has to be some acknowledgement of the audience reading the > content. I thought I had suggested in a previous review of a WCAG 2 > draft, that audience be worked into the baseline, though I can't find > the specific reference at the moment. I understand that would > complicate things significantly. If not included in the baseline, > there does need to be some way to define the acceptable level of > language for the intended audience. > > With regard to including the audience in a measure of readability, see: > > http://en.wikipedia.org/wiki/Readability > > Proposed Change: > > It might read something like "Where information is aimed at a non > specific audience, for which reading level is unknown....use lower > secondary..." > > ---------------------------- > Response from Working Group: > ---------------------------- > > Even specific target audiences may contain people who can understand > the subject matter but have disabilities that make it difficult to > deal with complex text. While reducing the complexity of the text will > help all such people, the success criterion only requires additional > supplementary material that will assist some of those users. > > We agree that all computerized readability programs have limitations, > but they can be helpful in providing an easy check for whether the > language used is clearly above or below the lower secondary level. > > The working group has no solution to problems of differing literacy > levels, except as this is reflected in the definition of lower > secondary level for different cultures. Low literacy levels as a > result of lack of education, rather than cognitive disabilities, is > outside the charter of the working group. > ---------------------------- Response from Greg Gay: ---------------------------- I still disagree. Its my opinion that audience has to be considered when the reading level of the audience is known, whether that is high level professionals, or low level grade school kids or perhaps a reader with a cognitive disability. In general, I agree, when audience is unknown, I would even suggest writing at a grade 7 or 8 level. Given it is now a level 3 guideline (3.1.5), it is probably okay there as is. > ---------------------------------------------------------- > Comment 14: > > Source: http://www.w3.org/mid/20060511201705.12011BDA8@w3c4.w3.org > (Issue ID: LC-542) > > Item Number: How to Meet Success Criterion 3.1.5 > Part of Item: Intent > Comment Type: GE > Comment (Including rationale for any proposed change): > > The statement "help people with reading disability" in the intent > section of the How to meet 3.1.5 section is incorrect. The ability to > comprehend high level language is not related to reading disability. > Reading disability is strictly associated at a more general level with > lessened ability to mentally convert visual textual information, into > verbal auditory information (phonemic awareness). There is no concept > of sematic disability associated with reading disability. By > definition, a person with a reading disability does not have a sematic > processing disability, with normal or above normal intelligence. There > are several references throughout the HowTo document that refer to > reading disability as an inability to understand. These statements > need to be removed. They are not true (see: howto 3.1.6). Reading > disability does not affect a person's ability to understand. > > Proposed Change: > > Remove references to to simplified language being an accomodation for > those with a reading disability. > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have revised the descriptions of the benefits of different success > criteria for people with cognitive disabilities by using descriptions > that are based on functional limitations. > ---------------------------- Response from Greg Gay: ---------------------------- Good. > ---------------------------------------------------------- > Comment 15: > > Source: http://www.w3.org/mid/Heteronyms &Capitonyms > (Issue ID: LC-543) > > Item Number: Success Criterion 3.1.6 > Part of Item: > Comment Type: QU > Comment (Including rationale for any proposed change): > > Is guideline 3.1.6 relevant to alphabetic langauges. I was unable to > determine the meaning of this guideline as it applies to English, or > other alphabetic languages. If it is relevant to alphabetic languages, > examples should be provided, or it should be stated that it applies to > syllabic, or orthographic languages. > > Proposed Change: > > ---------------------------- > Response from Working Group: > ---------------------------- > > Guideline 3.1.6 is indeed relevant to alphabetic languagues. Examples > have been added to the "Intent of this success criterion" section of > "How to Meet 3.1.6" to illustrate this. The revised section reads as > follows: > > "For example, in the English language heteronyms are words that are > spelled the same but have different pronunciations and meanings, such > as the words desert (abandon) and desert (arid region). Additionally, > in some languages certain characters can be pronounced in different > ways. In Japanese, for example, there are characters like Han > characters(Kanji) which have multiple pronunciations. Screen readers > may speak the characters incorrectly without the information on > pronunciation. When read incorrectly, the content will not make sense > to users." > ---------------------------- Response from Greg Gay: ---------------------------- I'm not sure what I was referring to here. The guideline seems to have moved. I will look into it some more for the final review of the current draft. > ---------------------------------------------------------- > Comment 16: > > Source: http://www.w3.org/mid/20060511202206.8DAC5BDA8@w3c4.w3.org > (Issue ID: LC-544) > > Item Number: Success Criterion 4.1.1 > Part of Item: > Comment Type: TE > Comment (Including rationale for any proposed change): > > In guideline 4.1.1 does "parsed unambiguosly" mean "well formed" or > "valid"? The techniques seem to suggest that markup must be valid, > though you would be hard pressed to find invalid code that disrupts > any relatively recent screen reader's ability to read a Web unit. It > takes severely broken markup to affect accessibility, or specific > types of errors (such as broken table structures). While I am all for > valid markup, it is *not* a requirement for accessibility in most > cases, particularly at level 1. I can see this requirement at level 2 > perhaps. > > Proposed Change: > > What would be appropriate here to have a well formed requirement at > level 1, and valid at level 2. And still this really has to do with > compatibility with future technologies, rather than affects on > accessibility using current technologies. > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have reworded SC 4.1.1 to require that content can be parsed > without error. > > The working group looked at this topic carefully over an extended > period of time and concluded that requiring strict adherence to all > aspects of specifications does not necessarily result in an increase > in accessibility. For example, it is possible to create invalid pages > that present no accessibility barriers. It is also possible in certain > situations to enhance accessibility through the use of markup that is > not part of the specification. > > The working group must work within its charter and only include things > that directly affected accessibility. Some aspects of "use > technologies according to specification" and validity do relate to > accessibility. However, others do not. So requiring validity would > take us beyond our charter. We do recommend it though and it is our #1 > technique listed for conforming to SC 4.1.1. ---------------------------- Response from Greg Gay: ---------------------------- Glad to hear this! I agree, validity is certainly an indicator of quality, and as such should be a goal of any web developer. But in terms of accessibility, only on rare occasions does invalid markup present barriers. > > ---------------------------------------------------------- > Comment 17: > > Source: http://www.w3.org/mid/20060511202433.8FF65BDA8@w3c4.w3.org > (Issue ID: LC-545) > > Item Number: Success Criterion 4.2.1 > Part of Item: > Comment Type: ED > Comment (Including rationale for any proposed change): > > Guideline 4.2.1 > > This guideline does not read like a guideline (same with 4.2.3), is > not immediately clear what it means without reviewing the HowTo, and > can be interpreted in different ways (i.e. ...may [also] be, or ...may > [instead] be...). I interpret it first as meaning I can include a link > from the accessible version to the innaccessible version. In fact it > should be the opposite that is true (and I'm sure based on the howto > that is what was intended), including a link from the innaccessible > version to the accessible one. > > Proposed Change: > > Ideally there should be reciprocol links between the two versions. > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have moved discussion of alternate versions of content to the > Conformance section of the Guidelines, and we have clarified by adding > the following conformance requirement > > Alternate Versions: If the Web page does not meet all of the success > criteria for a specified level, then a mechanism to obtain an > alternate version that meets all of the success criteria can be > derived from the nonconforming content or its URI, and that mechanism > meets all success criteria for the specified level of conformance. The > alternate version does not need to be matched page for page with the > original (e.g. the alternative to a page may consist of multiple > pages). If multiple language versions are available, then conforming > versions are required for each language offered. > > We have also updated the understanding document to clarify situations > when different sufficient techniques would apply. > ---------------------------- Response from Greg Gay: ---------------------------- Good.
Received on Friday, 8 June 2007 20:03:28 UTC