- From: Greg Gay <g.gay@utoronto.ca>
- Date: Tue, 07 Sep 2004 17:50:26 -0400
- To: public-comments-wcag20@w3.org, Greg Gay <g.gay@utoronto.ca>
I probably could have spent much more time reviewing, but have to get back to the other work that's been gathering. Overall I see good progress from the previous review. There are still a few areas that have me worrying about the effects they will have on our evaluation practices. Namely: Design principle 4 "...current and future technologies. (what about slightly older technologies?) 3.1 Level 3 regarding meaning and language use. 4.1 using (non w3c) technologies to specification Comments below ------ WCAG 2.0 Draft 07/30/04 Comments. Conformance Section: Level 1 & 2 success criteria typo "be" The importance of WCAG 1.0 priorities were clearer through the use of words like must, should, and may. These words were helpful for describing guidelines to clients and novice users. In WCAG 2 these words might be minimal, increased, and enhanced accessibility. Bold those words to create parallels between meanings in the priorities of WCAG 1.0 and Levels in WCAG 2.0. It might be helpful to distinguish levels of accessibility along a continuum from innaccessible and unusable to fully accessible and highly usable (0, 1-, 1, 1+, 2-, 2, 2+, 3-, 3 ,3+). Level 1 and level two criteria address more basic accessibility requirements, with level 2 addressing some usability issues as well. Level 3 would be more focused on the trailing end of the continuum which deals more with usability. Conformance Claims authored unit == statement of scope "2. The base URI and a statement of scope describing the content to which conformance does and does not apply" Include the date at which the conformance claim was made. For many sites content changes daily, and in many cases in our experience, content posted after the conformance date is often non-conformant. This is particularly important for reviewers, whose reputation can be damaged if nonconformant content is posted after a conformance review has been completed. In many cases a conformance claim can only apply on the date it was issued. e.g. 4. The date on which the conformance claim was made. Overview of Design Principles Regarding "robust" in principle 4, in WCAG 1.0 one guiding principle was to make content accessible for those who were not using "current and future technologies". I think this principle should include robust with regard to backwards compatibility. I do agree however that limitations need to be set on the range of older technologies that should be supported. In many, if not most cases, users are not using current technologies. Either include a range for backwards compatibility, or define "current" to include say 5 years of older technologies. I don't know how to best define current, but in most cases between 5 to 7 years old roughly represents old technology (or obsolete technology) when matched against the rate at which technology is evolving. Guideline 1.3 I'm not clear on the difference between 1.3 level 1 #3 and level 2 #1 (i.e. ...also available without colour). An example distinguishing between interpreting markup, and not interpreting markup might clarify this confusion. Guideline 1.4 See: Chris's colour experiment. AERT http://snow.utoronto.ca/readtest/ http://www.aprompt.ca/WebPageColors.html Guideline 1.5 Level 3 - How would the average person measure a difference of 20 decibels between foreground and background sounds? (perhaps the reason this is a level 3) Would a transcript or caption be sufficient where it is not possible to distinguish foreground/background audio? For example, producers will often add captioning to video where the speaker's voice is not clearly audible for some reason, or perhaps where a speaker has a thick foreign accent that is difficult to understand for native speakers. If guideline 1.2 level 1 and 2 are met, then 1.5 level 3 might be considered irrelevant. If the author has provided synchronized captioning or a less desireable transcript, they should not be penalized for poor quality audio/video where foreground and background audio are difficult to distinguish, or is outside their control. " ...with the exception of occasional short sounds." creates a subjective decision " ...what constitutes a short sound?" An example comes to mind -- an announcer is interviewing a spectator in the stands at a sporting event, when the home team scores a goal -- the sound of the crowd drowns out the speech of the announcer for 15 seconds, so the producer adds a caption so the inaudible speech can be read. Is the producer still penalized because the speech is not 20 decibles higher than the crowd roar? Perhaps this guideline could be refined to distinguish between sounds that are under the control of the producer and sounds that are not, or naturally occurring sounds. Level 3 #2 might read: 2. Where the difference between naturally occuring foreground and background sounds is less than [20 decibels], or are indistinguishable, provide a caption or text alternative. Who benefit for 1.5 "Individuals with hearing impairments that limit their ability to hear all of the frequencies..." would be better as "Individuals who have hearing impairments that limit their ability to..." it is otherwise not immediately clear what the word "their" is referencing. e.g. individuals that limit their ability... or hearing impairments that limit their ability..." Guideline 2.1 Level 1 #1 I'm not sure what might constitute functionality that "can not" be described in a sentence. Level 2 #1 Could an exception be onclick? In reality onclick is used in a divice independant manner despite "click" suggesting it's mouse dependant. What makes an event handler abstract? Perhaps simpler language could be used here such as "...use event handlers that do not rely on the presence of a specific input device..." or"...use event handlers that are accessible to all input device..." Level 3 #1 I'm not sure what the difference between Level 1 #1 "...operable through a keyboard" and Level 3 #1 "...designed to be operated by a keyboard..." I suspect it means add direct keyboard access via accesskeys for instance, but as a novice the two guidelines would sound the same... Also given the limitations of using accesskeys within various environments, "All functionality of the content...." may make it impossible to meet this requirement. Essentially only number keys are available for Web applications, so if a site had more than 10 functional features, it would fail this guideline. This is really a implementation issue devired from the HTML (and other) specification. The context of accesskeys needs to be defined in addition to the keys themselves. Context might be browser, web page, assistive technology, operating system etc. Note that if Level 3 #1 is referring to direct keyboard access, via accesskeys for example, this criteria may conflict with 4.2 Level 1 #2h where the page in question is a screen in a web application. Guideline 2.2 "Who benefits..." should include those with sensory disabilities as well, giving their assistive technology time to read through content before a time based event occurs. We tend to distinguish between physical disabilites that affect movement, and sensory disabilities that affect perception. Guideline 2.3 How would an average person measure flash threshold? I'll wait for the TRACE utility in the second quarter of 2004 Level 3 General Flash Threshold #2 should be a range rather than an absolute value. For example an old real to real movie would flicker, but perhaps at a rate much faster than three flashes per second. More than about 20 flashes per second (i.e. one flash every 50ms) can not be detected by most viewers so at this rate the content would appear not to be flashing. Within what range does flashing actually induce seizures? Flicker rate between 3 flashes per second and 20 flashes per second should be listed as unacceptable. Guideline 2.4 -#5 This whole guideline seems to be with regard to structuring of content to make it easy to navigate within larger content units. It might read better as "Facilitate the ability of users to orient themselves and move within the content by providing structural and orienting navigation elements" (e.g. paragraphs, headings, list etc and bypass links, return to top, jump to content etc.) Level 2 #1 Why 50 and 50000? A 20000 word document would certainly be more accessible if it had a table of content. How does a hierarchical structure differ from a table of contents or sitemap, which can both be heirarchical structures? A sitemap can take on linear, heirarchical, and global properties. Don't know what Level 2 #1c means "... alternate display order ... or site navigation mechanisms. I'd guess it means allow users to rearrange the order in which they display pages so they could move through them in sequence, via a heirarchy, of in a global (non linear) manner. Perhaps a level 1 criteria could suggest bypass links for more than 25 navigation links. A great many site have 5 to ten navigation link across the top of the screen, and a subject menu down the left (sometimes right) of the screen that together can include 25 or many more links that have to be traversed through before reaching the relevant content. The Level 2 #2 guideline might be phrased as "... at the opening of, and within pages, create direct links to major elements such as a content area, subject menu, or tool bar, that would allow users who might otherwise navigate through a screen in sequence, to bypass elements and jump directly to the relevant content ..." Also in Level 2, would properly nested heading elements represent a heirarchical structure Level 3 - if the default tab order is the logical sequence in which to read a document then additional information should not be required. Level 3 #1 might be reworded using something like "Where the default tab order differs from the logical sequence in which a document should be read, provide information that describes the logical sequence" - define "diagrams". Are they not usually images? How would a screen reader user access the structure of a diagram. Perhaps it is possible, but I'm not familiar with such functionality. In most cases I would expect a long description of a diagram that outlines relationships between components in the diagram, or perhaps a caption, or text description in the surrounding content. -#5b "...clear and informative titles" might be better as "...clear and informative headings" -#5 "... a statement associated with the content..." might be better as ".. a general statement about the content as a whole..." - a statement such as this with every page, as I interpret the current wording, seems to be overkill. Guideline 3.1 - Level 1 #2 "meaning can programatically located" less technical language would make this easier to understand. such as "...meaning can be found by..." -- same for others in guideline 3.1. Programtically located or determined should refer to some form of machine evaluation, that can locate a full version of an abbreviation etc. I understand that these word are probably used to suggest that evaluation tools can programmatically find alternatives for short forms, but I think terminology should explain accessibility for users rather than machines. - Level 2 #1 when might "meaning and pronunciation" not be programatically locatable? When in an image perhaps, but that would be covered by 1.1 - Level 2 #2 perhaps a result of my confusion by the words "programtically determined", but in most case the meaning of idioms is determined from the surrounding language. I'd guess such meaning could not be programmatically determined. It would be "cool" if the meaning of cool could be programatically determined, but I think not. - Level 2 #3 "...foreign language passage or phase..." would be more inclusive as "...foreign language passage or words..". The word phrase could be interpreted as excluding single words. -Level 3 #1 I see no need to include a word's definition if it is not the primary or first meaning expressed in a dictionary (whose dictionary?). Meaning is such cases is usually determine from the surrounding words. How would an evaluation tool determine if the primary meaning was being used. -Level 3 #2 "... read by themselves as a group" sounds like an oxymoron. perhasp" Section headings and link text are understandable when read individually, or read as part of a group -Level 3 #3 should not be an accessibility guideline. Whole disiplines are devoted to good writing, and wrting should not be under the realm of accessibility. I can imagine a very large corporate site, with large amounts of content, that is seeking a Level 3 conformance review. Having to review the language used throughout the site would probably triple the cost of an evaluation having to read an analyze content. It would require expert knowledge of language usr by the evaluator, knowledge of the site's audience, knowledge of content area specific language.... Copy editors do this kind of work, rather than accessibility evaluators. I'm also having a hard time imagining how a accessibility evaluation tool might evaluate language usage, for various audiences, or across various genres. Guideline 3.2 Level 2 #5 should be "Explicit notice is given in advance, or immediately following any extreme change of context". While it is preferable to warn users ahead of time that an extreme change is about to occur, it is not always practical to do so. In some instances it is more effective to inform the user after the change. For example, a collection of context sensitive help windows are found throughout an application that open by clicking a "Help" link next to particular features. An author could include a general statement on each page about help links that informs the user that they open in a new window, but such a statement may go unnoticed, and would add clutter. Title text could be included with links etc that states that a link opens in a new window. This could potentially create large amounts of repetetive text for those listening to pages, and potentially bloat the source code. The best method we have found in cases like this is to consistently include a "close this window" link/button as the first feature in a newly opened window. When used consistently this method informs the users of an extreme change after it has occured. We also use consistent feedback after an extreme change to inform a user of an outcome of a particular action. For example, after saving content being authored in a web based authoring tool, the editor utility closes and users is redirected to the actual display of the content, which includes a notice stating the outcome of the save content action. It would be impratical to inform users on the editor screen that when they save their content they will be redirected to the display screen. There are many other similar action (e.g posting a forum message, filling out a registration form, logging in) that result is extreme changes in context that are better describe after the change has occured. Though there are many cases when users should be informed before a change occurs, there are also many instances when it is more effective to announce the change after it has occured. Authors should not be penalized for using the latter a strategy. Level 2 #6 Good. So "click here" is acceptable as link text provide its meaning can be determined through the surrounding context, such as a linked article title appearing before the click here link. Guideline 4.1 Level 1 #1a Could be hard to enforce. How would an evaluator determine if Javascript has been used to spec? Whether pdf, flash, java has been used to spec? If Java is used to spec but without SWING, it would pass but not be accessible. If Flash MX presentation is used without the accessibility features, it would pass but be innaccessible. A third criteria might be added that requires authors to use accessibility features within a specification where they exists: e.g. "1c. accessibility feature provided in a specification are used." This might be a Level 2 criteria. I see this guideline listed as a level 2 for guideline 4.2. I might argue that it fits better in the "use to specification" guideline. Guideline 4.2 There should be some form of limitation associated with this guideline. For example, SWING enabled applets may be accessible to users of current versions of JAWS, but would not be accessible to those using a two year old version of JAWS. Same for PDF tagging, and Flash MX accesibility extensions. If the intent is to create content that is accessible to current technologies, as describe in design principle 4, this guideline might read "4.2 Ensure that user interface features are accessible to current technologies, or provide an accessible alternative." That said, a "current technology" limitation is somewhat counter to the philosophy behind WCAG 1.0 which was to extend accessibility to include those of older technology (ala "Until User Agents...") I don't have an answer to what consititutes a reasonable limitation on legacy AT support, but it should receive some attention so authors have a concrete defintion to work from. This guideline somewhat precludes accessibility to Lynx users. For example a Flash presentation may now be accessible to an IE6/JAWS 4.5, but would not be accessible to a Lynx/JAWS4.5 user. A limitation in this respect might read: Level 1 #3 When a UAAG conformant plugin, or application is not readily available, provide an accessible alternative to the content" Documenting technology requirements is a good step toward placing limitations on technology/legacy support. Readiliy available might be confirmed by an author providing a link to such a plugin/application. Should "freely available" be included in this criteria? Level 1 #2h Although I agree, item 2h is going to generate resistance, given the current arguments over the implementation of accesskeys. In this case what used to be a Priority 3 checkpoint, is now a level one when it applies to a Web application. Are there plans to improve upon accesskey implementation in UAAG, XHTML,WCAG. For example defining contexts for accesskeys so HTML defined accesskeys do not conflict with UA accesskeys. This may be less relevant for most Web site, but will be highly relevant for Web applications.
Received on Tuesday, 7 September 2004 21:44:44 UTC