Fwd: FW: UAAG 1.0 last call comments

>Reply-To: <gv@trace.wisc.edu>
>From: "Gregg Vanderheiden" <gv@trace.wisc.edu>
>To: "AlGilman [Asgilman@Iamdigex.Net] (E-mail)" <asgilman@iamdigex.net>
>Subject: FW: UAAG 1.0 last call comments 
>Date: Wed, 24 Jan 2001 00:13:36 -0600
>X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
>Importance: Normal
>
>Here are my uaag comments
>
>The one you want is right after #13
>
>G
>
>
>-- ------------------------------
>Gregg C Vanderheiden Ph.D.
>Professor - Human Factors
>Depts of Ind. and Biomed. Engr. - U of Wis.
>Director - Trace R & D Center
>Gv@trace.wisc.edu, <http://trace.wisc.edu/>http://trace.wisc.edu/
>FAX 608/262-8848
>For a list of our listserves send "lists" to listproc@trace.wisc.edu
>
>
>-----Original Message-----
>From: Gregg Vanderheiden
[<mailto:gv@trace.wisc.edu%5D>mailto:gv@trace.wisc.edu]
>Sent: Tuesday, November 28, 2000 10:14 PM
>To: Wendy (E-mail); JasonWhite (E-mail)
>Cc: Ggg (E-mail)
>Subject: FW: UAAG 1.0 last call comments
>
>Hi Wendy, Jason
>SEE ALL CAPS BELOW WITH THE WORD [WENDY  IN FRONT OF THEM
>ALSO ITEMS WITH X INSTEAD OF NUMBER AT FRONT ARE NEW ITEMS I ADDED.
>
>
>
>
>-- ------------------------------
>Gregg C Vanderheiden Ph.D.
>Professor - Human Factors
>Depts of Ind. and Biomed. Engr. - U of Wis.
>Director - Trace R & D Center
>Gv@trace.wisc.edu, <http://trace.wisc.edu/>http://trace.wisc.edu/
>FAX 608/262-8848
>For a list of our listserves send "lists" to listproc@trace.wisc.edu
>
>
>-----Original Message-----
>From: Wendy A Chisholm [<mailto:wendy@w3.org%5D>mailto:wendy@w3.org]
>Sent: Monday, November 27, 2000 5:01 PM
>To: Jason White; po@trace.wisc.edu
>Subject: UAAG 1.0 last call comments
>
>Hello,
>
>I read the UAAG 1.0 last call draft today per my action item from the CG
>call.  Since the WCAG WG needs to send an "official" set of comments, I
>wanted to pass these by you two before sending them on to the UAWG.
>To the 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.   We apologize for
>missing the deadline for last call comments.   UAAG 1.0 is a good document
>that should inspire more accessible user agents.
>
>We are concerned that it is very technical.  As we found out with WCAG 1.0,
>one of our primary audiences is policy makers.  Therefore, if you only
>listen to one comment, heed this advice:  create 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.
>Here are the rest of our 25 comments:  [Wendy - NUMBER OF COMMENTS HAS NOW
>CHANGED]
>1. Scope.  A couple times the document says, "those for braille rendering"
>are out of scope for the document.  I think this is a vague example and
>probably one that people 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?
>2. 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..."
>3. Section 1.2 should refer to AERT rather than ATAG.  AERT is being
>incorporated into ATAG-TECHS.
>X.   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."
>4. Guideline 1 rationale typo.  It should say, "Th_e_ users must be
>able...."
>5. 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
>...?
>6. Guideline 1 uses "output text" as an example that makes it sound like the
>user is  supposed to output text.
>X.   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.
>7. Guideline 1 says "pre-rasterize."  In WCAG 2.0 we are very aware that
>policy  makers are one of our primary audiences.  I'm not sure that you will
>have the same issue, although I expect that you will.  therefore, I would
>recommend using less technical language, or creating an executive summary
>that policy makers find easy to use and understand.   [WENDY - I AM LESS
>CONCERNED ABOUT THIS SINCE USER AGENT CREATORS ARE USUALLY PROGRAMMERS AND
>VERY TECHNICAL - UNLIKE PAGE AUTHORS]
>X.  Guideline 1 last sentence is not a sentence.  Add "that" after 'text
>messages" to complete the sentence?
>X.  checkpoint 1.1   Hard to read and make sense of.   "every function" or
>"all functionality" I think would be better English as well but you might
>ask a grammarian.
>8. Checkpoint 1.2 only applies to rendering?  what about interaction?  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.
>9. 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.
>10. 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?
>
>Also, with 1.1, I think the "what this checkpoint does not require" confuses
>me more than helps.
>11. It  might be easier to pick  up the main points of the rationales if
>unordered lists were used.
>12. 2.1 and 2.3 seem very redundant to me or that 2.3 is a technique of 2.1.
>13. 2.1 is very specific to the "document object."  this does not seem to
>apply to applications.
>XX. 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.
>X.  2.3  last item in note could be easier to understand.  Perhaps "4. by
>providing readily available links to the equivalents"
>14. 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."  We've been discussing others.
>Could we leave this more open or do you want to be very specific?
>15. Why are checkpoints 3.1 and 3.7 separate?  They seem redundant.
>[WENDY - ARE WE LOOKING AT THE SAME DOCUMENT.   THEY SEEM TOTALLY DIFFERENT
>IN THE COPY I'm LOOKING AT.  3.1 IS BACKGROUND IMAGES.  3.7 IS CONTENT
>REFRESH]
>16. Why are checkpoints 3.2 and 3.4 separate?  Couldn't a static frame of a
>movie be provided rather than the entire animation if the user request it?
>[WENDY - THESE LOOK DIFFERENT TO ME.  IF PUT TOGETHER I THINK 3.4 WOULD BE
>LOST IN 3.2]
>17. Could checkpoint 3.5 be more general, e.g. "programmatic objects."
>X.   3.6 and 3.7.  are they really P2.  are pages usable if you don't
>provide these?
>18. there are several checkpoints that within the checkpoints 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?
>X.  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.
>X .. 4.5 and 4.6  the phrase  "recognized as style"  is not at all 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?
>X.   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."
>19. Checkpoint 4.17 the "for graphical viewports" is repeated twice with
>different requirements.  Are these alternatives?   [WENDY I EDITED THIS ONE.
>BY ADDING THE WORDS AFTER 'TWICE']
>20. Isn't 5.3 similar to 1.1?
>X.   6.1  could use an example
>X.  6.2  should that be "support html 4.0"   conform seems to be not quite
>the right word for a user agent...but am not sure.
>X.   7.1  shouldn't the word 'keyboard' be in the checkpoint.  You can
>always navigate using the mouse....
>21. Why is 7.6 a priority 2? I expected it to be P1.
>22. Is 8.1 too HTML specific?
>23. I am not sure that the suggestion in checkpoint 8.2 is 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.
>Perhaps wording it as "always provide some option besides color to
>distinguish between visited and unvisited links".   [WENDY I ADDED THE LAST
>SENTENCE TO THIS ITEM]
>X.   8.7 and 8.10  You might describe somewhere how you highlight a
>viewport.
>24. 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.?
>25. 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.  X.
>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.
>
>--
>wendy a chisholm
>world wide web consortium
>web accessibility initiative
>madison, wi usa
>tel: +1 608 663 6346
>/--
>

Received on Thursday, 25 January 2001 14:15:52 UTC