- From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
- Date: Fri, 1 Dec 2000 10:13:16 +1100 (EST)
- To: w3c-wai-ua@w3.org
Hello UAWG, These are the comments from the WCAG WG on the last call draft of UAAG 1.0. This does not represent consensus from the WCAG WG but comments from Jason, Gregg, and Wendy. We apologize for missing the deadline for last call comments. UAAG 1.0 is a good document that should inspire more accessible user agents. 1. We suggest creating an executive summary that policy makers may use to write UAAG into their policies. In the U.S., government agencies will be buying accessible software and will need clear guidance as to which user agents are accessible. 2. Scope. A couple times the document says, "those for braille rendering" are out of scope for the document. This seems vague and probably something that most of your readers will not be familiar with. Is there another example that could be added to help people grasp other types of applications that are not in the scope of this doc? 3. Section 1.1, in the second set of bullets, there is a typo in the 2nd bullet. It should say, "These users are likely _to_ benefit..." 4. Section 1.2 should refer to AERT rather than ATAG. AERT is being incorporated into ATAG-TECHS. also in Section 1.2 - shouldn't players be covered by themselves as well? Perhaps add to end of paragraph 1 "... but these individual components may also act as agents themselves." 5. Guideline 1 rationale typo. It should say, "Th_e_ users must be able...." 6. Guideline 1 says, "Keyboard operation of all functionalities offered through the user interface is one of the most important aspects of user agent accessibility on almost every platform." first of all, "keyboard operation" is italicized. I read this on paper and went to the glossary to find out what this meant. It is not in the glossary. secondly, does this include mobile platforms? I was expecting to find in the glossary some aspect as to why this doesn't apply to mobile or how it might be emulated or ...? 7. Guideline 1 uses "output text" as an example that makes it sound like the user is supposed to output text. 8. Guideline 1 Paragraph 1 is full of "musts". Since these sentences are in the guidelines, perhaps we should avoid that word in the rationale - since they are not P1 checkpoints. Perhaps change the "musts" to "need to" or something. 9. Guideline 1 last sentence is not a sentence. Add "that" after 'text messages" to complete the sentence? 10. checkpoint 1.1 is hard to read, perhaps say "every function" or "all functionality". 11. Checkpoint 1.2 - What are "higher level APIs?" For example, on a windows machine say I use the Microsoft Foundation Classes and implement Active Accessibility - I assume these are the higher level APIs. If these do not use standard devices correctly, what else am I to use? Also, how do I know if they don't use standard devices correctly? What about Java - it is device independent and up to the virtual machine to use the standard devices correctly. 12. Several checkpoints refer to using operating system conventions. What about a user agent that is written in Java? In that case it is up to the virtual machine to use the system conventions. Checkpoints that this might affect: 1.3, 5.8, 8.6, 9.2. Also, section 3.2. Also, what about user agents that are intended to run, with minimal modification, on a variety of operating systems. This is supposedly Mozilla's strategy. In that case the proposal is to use the DOM to provide accessibility to the entire user interface and not just to the document (apparently the user interface is itself written in an XML-based format). 13. How is checkpoint 1.4 a special case of 1.1? As I understand it, 1.1 is programmatic and 1.4 is user interface? Also, does 1.1 mean: a. that i have to implement "activate link" in my input API or b. that I have to implment "onmouseclick activate link" and "on enter activate link" in my input API? The "what this checkpoint does not require" confuses rather than clarifies these questions. 14. 2.1 and 2.3 seem very redundant or that 2.3 is a technique of 2.1. 15. 2.1 is very specific to the "document object." this does not seem to apply to applications. 16. Is there a way to make checkpoint 2.6 more general, perhaps to allow for standardized classes or standardized elements? Null alt-text is just a way to standardize saying, "this is decorative." The WCAG WG has been discussing others. Could we leave this more open or do you want to be very specific? 17. 2.2 - you need to provide more options to companies to address different types of situations and uses for timing. Suggest a 3 option approach 1 - user can turn off all timing OR 2 - user can adjust the timing to 5 times (or 10 times) the default setting. OR 3 - user is offered more time and has at least 10 seconds to respond to offer. 18. 2.3 last item in note could be easier to understand. Perhaps "4. by providing readily available links to the equivalents" 19. Why are checkpoints 3.1 and 3.8 separate? They seem redundant. 20. Could checkpoint 3.5 be more general, e.g. "programmatic objects." 21. 3.6 and 3.7. are they really P2. are pages usable if you don't provide these? 22. there are several checkpoints that within the checkpoint text it says, "for graphical viewports..." However, there is rarely a "for non-graphical viewports...." is that out of scope for this document? Perhaps move this to the note of the checkpoints? 23. Guideline 4 Shouldn't the last word be "presentation" instead of styles. The second paragraph under guideline 4 for example doesn't relate to styles per se. I think presentation might be more accurate description. Less jargony too. 24. 4.5 and 4.6 the phrase "recognized as style" is not clear. And I did not find an explanation of the term in the glossary either. Suggest you add it to style in glossary --- or reword this to be more easily understood? 25. 4.12 remove sentence 2 which states the 120 and 400 word limits. The sentence before already says that it must support the full range of the synthesizer. And if the synthesizer can't go to 120 or 400 then they cannot comply anyway. If the problem is that the agent doesn't know what the synthesizer can do - then maybe reword it to say. "If the range of the synthesizer is unknown, then the minimum speed setting should be not more than 120 and the maximum speed setting not less than 400." 26. Checkpoint 4.17 the "for graphical viewports" is repeated twice with different requirements. Are these alternatives? 27. Isn't 5.3 similar to 1.1? 28. 6.1 could use an example 29. Why is 7.6 a priority 2? I expected it to be P1. 30. Is 8.1 too HTML specific? 31. Is the suggestion in checkpoint 8.2 a good idea? It says, "Do not use color as the only distinguishing factor between visited and unvisited links..." I think this should be part of the style that the user chooses. This statement implies that the user agent will do something other than change the color of links no matter what style the user chooses. I think having something other than color will annoy some people. Perhaps wording it as "always provide some option besides color to distinguish between visited and unvisited links". 32. checkpoint 9.8. If each user agent has their own set of default input configurations, how will an assistive technology that works with multiple UAs deal with this? How does Jaws deal with this today? Does it have to know about all of the keyboard commands for IE, Opera, Word, etc.? 33. I think section 3.2 will encourage multiple solutions rather than pushing people to better the "standard." In other words, instead of "foundation classes" on Linux that support accessibility, we'll end up with several sets of classes that will end up driving AT developers crazy. 34. in glossary - the definition of assistive technology in the last sentence is not as comprehensive as the one used in all current US legislation and regulation. Would suggest looking at and considering using that one here - as it will be useful to other countries as well. Overall, good work!
Received on Thursday, 30 November 2000 18:13:27 UTC