Re: Last call comments from WCAG working group

Jason White wrote:
> 
> 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.

Thank you Jason, Gregg, and Wendy.  I will incorporate your
editorial suggestions and add other issues to our issues list.
 
> 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.

I think that we should definitely create an executive
summary as a separate document (possibly linked from this
document). However, I don't think that lack of an executive
summary should stop us from advancing to Recommendation.

Added as issue 449:
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#449
 
> 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?

I think this is editorial. I propose including a reference
to the (Draft) Note entitled "How People with Disabilities
Use the Web":

   http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/Overview.html

I would rather have this document published as a TR Note
before we refer to it. I have written Judy Brewer to find
out the publication schedule.

> 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..."

Editorial.
 
> 4. Section 1.2 should refer to AERT rather than ATAG.  AERT is being
> incorporated into ATAG-TECHS.

I don't see any references to ATAG in section 1.2 [1]. There
is a reference to AERT already. The only reference to ATAG10
is in the "Related resources" section.

[1] http://www.w3.org/TR/2000/WD-UAAG10-20001023/#scope

> 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."

Editorial. I am a little reticent to add the proposed phrase
since that would shift focus from what is expected to what
is possible. I'd rather repeat the whole modified sentence
in section 3.

> 5. Guideline 1 rationale typo.  It should say, "Th_e_ users must be able...."

Editorial.

> 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.

Editorial. I will remove the emphasis.

> 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 ...?

Editorial. I propose that we change "almost every platform"
to "many platforms".  People may make conformance claims
about user agents on mobile devices, but that is not our
target audience.

> 7. Guideline 1 uses "output text" as an example that makes it sound like
> the user is  supposed to output text.

Editorial. I propose deleting "(e.g., 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.

Editorial. Ok.
 
> 9. Guideline 1 last sentence is not a sentence. Add "that" after
> 'text  messages" to complete the sentence?

Editorial. Proposed change from Eric Hansen:

  "Text content has the accessibility advantage of being 
   available to people who use graphical displays, speech 
   synthesizers, and braille displays."

> 10. checkpoint 1.1 is hard to read, perhaps say  "every function" or "all
> functionality".

Editorial. As a result of our resolution to issue 345 [2],
we will be modifying this checkpoint fairly significantly
and I believe that it will be much easier to use and
understand. I will account for your proposal in our rewrite.

[2] http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-345

> 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.

Yes.

> If these
> do not use standard devices correctly, what else am I to use? 

We discussed this as part of issue 323 [3] at our recent
face-to-face meeting. We resolved to "Change 1.2 to require
implementation of available standard accessibility APIs, and
where these APIs do not provide required functionality (by
this document), support standard device APIs."  Would this
address your issue?

[3] http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-323

> 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.

"standard accessibility APIs" would include Java.
 
> 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.  

Is that entirely true? I thought that the virtual machine's
job was to interpret byte code, but that you could write
programs to do whatever you want. I am not a Java
programmer...

I will add this discussion to the issues list as issue 450:
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#450

> 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).

Yes, we designed checkpoint 5.4 to allow for this case,
which is why it reads: "Provide programmatic read and write
access to user agent user interface controls using standard
APIs (e.g., platform-independent APIs such as the W3C DOM
..."

> 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.

I agree with you. I don't think that 1.4 is (any longer) a
special case of 1.1. I propose to delete that sentence.
 
> 14. 2.1 and 2.3 seem very redundant or that 2.3 is a technique of 2.1.

Editorial.

The important difference between checkpoints 2.1 and 2.3 is
that checkpoint 2.3 requires access to equivalent
information in context. The user must have "easey" access to
equivalents. Checkpoint 2.1 is only about the global
requirement for access to all content. I propose to add
language to the Note after 2.3 to explain the difference
would be useful. Al Gilman sent me private email on this
topic recently, in fact.
 
> 15. 2.1 is very specific to the "document object."  this does not seem to
> apply to applications.

We don't specify in this document how the document object is
constructed (in fact the definition says that it may come
from a variety of sources).  If part of the document object
is rendered as a user interface (e.g., form controls), and
that is considered "an application", then checkpoint 2.1
covers that content. Can you explain what type of
applications you don't think are covered by 2.1?
 
> 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?

Can you provide examples of other cases? I will add this
as issue 451: 
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#451

Note: We do distinguish "content [not] recognized as
style" in checkpoints 4.5 and 4.6. We have been asked to
clarify that phrase as part of issue 398.
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#398

> 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.

I will add this as issue 452:
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#452

Here are some comments on these options:

1) The WG established that the minimal requirement was to
   turn off timing and require manual interaction from the
   user. Allowing the user to specify time interval
   multipliers (5, 10, etc.) seems like more work for the developer.
   If you limit the menu to two or three multipliers, you
   may not meet the user's needs and you run the risk of the
   granularity being so chunky as to make the presentation
   less usable. Allowing the user to specify an arbitrary
   multiplier seems like a big demand on developers.

2) Issue 360 is also about this checkpoint. We decided at the AOL
   face-to-face meeting to reduce the scope of this checkpoint
   to timing that is recognized from markup, not scripts.
  
    http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-360
  
> 18. 2.3 last item in note could be easier to understand. Perhaps "4. by
> providing readily available links to the equivalents"

Editorial. We used to say "easy access" (which sounds like
"readily available") and we decided to state more
specifically that the link needs to be just before or after
the rendered content. I think the wording of this checkpoint
may change as the result of other issues, but I'm not sure
that "readily available links" is specific enough to satisfy
earlier reviewers' requests for specificity.
 
> 19. Why are checkpoints 3.1 and 3.8 separate?  They seem
> redundant.

Checkpoint 3.1 is about background images specifically - the
accessibility issue is that users may not be able to
perceive content (e.g., text) above a background image. This
is a P1 issue. Checkpoint 3.8 is about images in general,
and the accessibility issue is more related to potential
confusion caused by too much visual information. The WG has
repeatedly maintained that this is only a P2 accessibility
issue. (Refer, for example, to discussions on this topic
at 19 April 2000 teleconf:
  http://www.w3.org/WAI/UA/2000/04/wai-ua-telecon-20000419.html)
 
> 20. Could checkpoint 3.5 be more general,
> e.g. "programmatic objects."

As part of resolving issue 364, we agreed to add "plug-ins"
to this list. I will add your proposal as issue 453:
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#453

http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-364
 
> 21. 3.6 and 3.7. are they really P2. are pages usable if you don't  provide
> these?
 
In the previous last call document, these were P3 requirements:
   http://www.w3.org/TR/1999/WD-WAI-USERAGENT-19991105/

At the 20 January face-to-face, we raised the priority of
these checkpoints to P2.
  http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0152.html

I will add the question of the priority of these checkpoints
as issue 454:
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#454

> 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?

Editorial.

There are two cases here:

1) Some requirements have to do with positioning in space,
   and therefore we limited their scope to graphical
   viewports. These include checkpoints 4.7 4.21, and 9.9.

2) Some checkpoints include minimal requirements for
   graphical viewports (4.16, 4.17, 4.19. 8.2, and 8.3) 
   related to colors and fonts. The WG did not choose to
   include minimal requirements for other types of viewports
   (I believe for at least two reasons: lack of experience
   and these were not the target user interfaces).

I propose addressing this by including a sentence in the
section on the "scope" of this document.
 
> 23. Guideline 4 Shouldn't the last word be "presentation" instead of
> styles. 

Editorial.

In this document, we only use the term "presentation" to
mean "a collection of information, consisting of one or more
Web resources, intended to be rendered simultaneously, and
identified by a single URI" (that's part of the
definition). 

I think "rendering" might be a better term in this light.
I will add this as issue 455:
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#455

> 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?
 
Yes, refer to issue 398.
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#398

> 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."

We will be modifying the wording of this checkpoint
(including the minimal requirements) based on issue 328:
   http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-328

Requirement: Allow the user to configure playback rate 
             according to the range offered by the speech synthesizer. 

The following will be informative only:
  - Rate depends on language 
  - Provide some example ranges for English and other languages 
  - Tell developers that for ease of use, need to have
    granularities for control (e.g., big jumps or small
    jumps, ability to change rate on the fly). 

I believe that these changes will subsume your issue.

> 26. Checkpoint 4.17 the "for graphical viewports" is repeated twice with
> different requirements. Are these alternatives?

Editorial. I can merge the two sentences.

> 27. Isn't 5.3 similar to 1.1?

Checkpoint 5.3 is about the exchange of information about UI
controls (e.g., input and output). Checkpoint 1.1 is about
device-activation of user agent functionalities (input only,
through keyboard, mouse, voice, etc.).
 
> 28. 6.1 could use an example

Editorial. I don't think this is necessary since the Note
clear states where this information may be found: "The
Techniques document [[UAAG10-TECHS]] provides information
about the accessibility features of some specifications,
including W3C specifications."
 
> 29. Why is 7.6 a priority 2? I expected it to be P1.

The following requirements are P1:
1) 2.1 Access to all content
2) 2.3 Easy access to equivalents
3) 7.1 Navigation to all viewports
4) 7.3 Navigation to all active elements.

More convenient access to content is considered a P2
requirement on top of these. This would include checkpoints
7.5 and 7.6.

> 30. Is 8.1 too HTML specific?

Do you have a counter-proposal? I don't think it hurts to
have a table-specific requirement (tables are complex,
important, etc.). The checkpoint doesn't call out HTML
specifically, either.
 
> 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".

We discussed this checkpoint as part of issue 353
  http://www.w3.org/WAI/UA/2000/11/minutes-20001116#issue-353

We resolved to include the following requirements:

 - P2: The default highlighting mechanisms required by 
       the document (for selection, focus, etc.) must 
       not rely on color alone. 

 - P2: The default highlighting mechanisms .... must differ
       from each other and not by color alone. 

I hope that this re-expression of the requirements addresses
your concern.
 
> 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.?

Need more information. 

I'm not sure I understand the comment. Checkpoint 9.8 is
about which functionalities must have bindings. Checkpoint
9.2 says don't interfere with system bindings. Checkpoint
5.8 says use system conventions for bindings. 

Combining these requirements suggests that all conforming
user agents on the same system will have the same minimal
set of bindings and those bindings will be in line with
system conventions. We don't go so far as to require
specific bindings.
 
> 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.

Need more information. 

Section 3.2 is about using OS features as part of
conformance claims. I'm not sure I understand your
comment. Also, do you have an alternative conformance scheme
to suggest? Please note that the Working Group has worked
extremely hard to come up with this conformance scheme and I
don't think the WG will readily change it without a very
concrete counter-proposal.
 
> 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.

Editorial. Do you have a URI? I think that the definition of
assistive technology in this document is not a critical
issue and doesn't affect conformance. It's merely
informative.

Thank you,

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Tuesday, 5 December 2000 18:07:54 UTC