W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2000

Last call comments from WCAG working group

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
Message-ID: <Pine.SOL.4.10.10012011011250.12254-100000@ariel.ucs.unimelb.edu.au>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:22 GMT