RE: Responses to Greg Lowney issues raised during second last call of UAAG 1.0

If you go to http://www.landware.com/products/gotype/gotypeps.html, you
will find information about the GoType! Keyboard for the Palm platform.
This device adds keyboard functionality to the Palm device, adding an
keyboard API to all input that isn't normally built in to the device.

The keyboard is delivered with software that is installed on the Palm to
allow the keyboard to communicate with the standard Palm applications.
This is a custom API that doesn't fit under the rubric of either
accessibility API or system API, so fits under the proposed revised 6.6.
It also can be used to make the Palm accessible to those who use, for
example, a head-stick to type, and wouldn't ordinarily have access to
the Palm platform.

Denis Anson, MS, OTR/L
Assistant Professor
College Misericordia
301 Lake St.
Dallas, PA 18612
 


-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On
Behalf Of Ian Jacobs
Sent: Thursday, March 29, 2001 1:45 PM
To: Greg Lowney
Cc: w3c-wai-ua@w3.org
Subject: Re: Responses to Greg Lowney issues raised during second last
call of UAAG 1.0


Hi Greg,

Thanks for the thorough review. I have a couple of requests:

a) Please indicate whether we can consider substantial comments
   during, rather than before, last call review.

b) Please indicate any strong objections you have that you wish
   us to carry forward on the Recommendation track. You may 
   want to wait until the WG has had a chance to evaluate your
   comments.

Note that we have instituted an issues list [1] for things to do after
UAAG 1.0. We will add to that list any proposals or ideas that we do not
address in this version of UAAG.
   
[1] http://server.rehab.uiuc.edu/ua-issues/issues-linear-new.html

Thank you,

 - Ian

Reference document:
    http://www.w3.org/WAI/UA/WD-UAAG10-20010323/.

------------------------------------------
My replies to your comments (labeled "GL")
------------------------------------------

Note: Sorry folks, this email is pretty long. I suggest
that we break issues into smaller emails for subsequent discussion.

I've split my comments (labeled "IJ2") into five sections:

1) Substantive new issues / new information / proposals
2) Editorial new issues / new information / proposals
3) Substantive disagreement with no new information
4) Editorial disagreement with no new information
5) Agreement

Here's why:

a) I think that we should fix editorial comments to the extent
   possible before we go to last call.

b) I don't think we should spend more time discussing issues
   where there is no new information, and you should register
   an objection where you feel strongly. 

c) For new issues, we should either try to address quickly or move to
   the "future stuff" issues list. Similarly, for new information about
   old issues, we should see whether we want to discuss further. If we
   don't, you should register an objection where you feel strongly.

My proposals are indicated by "IJ-proposal"

====================================================
Substantive new issues / new information / proposals
====================================================

---------------
Issue 393 (Second Last Call): Checkpoint 1.2: Change to P2 for exposing
through other programmatic means.

<IJ> 
  This requirement was folded into a new checkpoint:

    "6.6 Implement standard accessibility APIs (e.g., of the
    operating environment). Where these APIs do not enable the
    user agent to satisfy the requirements of this document, use
    the standard input and output APIs of the operating
    environment." [Priority 1]

  Thus, while the priority of implementing standard i/o APIs was
  not changed to Priority 1, the Working Group agreed that it was
  more important to first use available accessibility APIs (which
  are higher level than the i/o APIs) and to only use the i/o APIs
  in failure mode.
</IJ>

<GL>
This is much better. However, if the platform does not let AT monitor
standard I/O APIs, then using these I/O APIs should not cause the UA to
conform with this checkpoint. I would recommend adding a third sentence,
as follows: 

<GL 6.6>
   "Implement standard accessibility APIs (e.g., of the operating
   environment). Where these APIs do not enable the user agent to
   satisfy the requirements of this document, use the standard input
   and output APIs of the operating environment. Where these APIs do
   not enable the user agent to satisfy the requirements of this
   document, provide UA-specific APIs that meet these requirements."
</GL 6.6> </GL>

<IJ2>
I support your proposal.

I think your intention is currently covered by 6.6 in conjunction with
6.4:

   6.4 Provide programmatic read and write access to user agent user
   interface controls. [Priority 1] User agent only.

       Note: Per checkpoint 6.6, provide programmatic access through
       standard APIs (e.g., platform-independent APIs such as the W3C
       DOM; standard APIs defined for a specific operating system; and
       conventions for programming languages, plug-ins, virtual
       machine environments, etc.). This checkpoint requires user
       agents to provide programmatic access even in the absence of a
       standard API for doing so.

IJ-proposal: However, I would like to adopt your proposal for the
following reason: I think the cascade:

   * Standard accessibility API
   * Standard device API
   * Some (non-standard) API

should apply to other checkpoints than 6.4. We last modified checkpoint
6.4 as a result of issue 457[1] in order to clarify that even when a
standard API didn't exist, communication through an API was required.

[1] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#457

However, the following checkpoints also include the phrase "using
standard APIs" and it's not clear whether access is required even where
standard APIs don't exist:

   6.3 For markup languages other than HTML and XML, provide
   programmatic access to content using standard APIs (e.g.,
   platform-independent APIs and standard APIs for the operating
   environment).

   6.5 Using standard APIs, provide programmatic alert of changes to
   content, user interface controls, selection, content focus, and
   user interface focus.

Does the WG agree that these functionalities should also be provided,
even in the absence of a standard API? If so, then it makes sense to
adopt Greg's proposal and to factor out the "standard API" part out of
6.3 and 6.5.

The difference between 6.3/6.4/6.5 and 6.6 is "standard API" versus
"standard accessibility API". Is that a substantial difference?

Note that checkpoint 6.7 "trumps" 6.6 because it always requires
standard APIs for the keyboard. </IJ2>

---------------
Issue 414 (Second Last Call): Checkpoint 7.3: Need stronger min
requirements

<IJ>
  There has been no increase in the minimal navigation
  requirements for what is now checkpoint 9.2:

    "9.2 Allow the user to move the content focus to any enabled
    element in the viewport. If the author has not specified a
    navigation order, allow at least forward sequential
    navigation to each element, in document order. The user agent
    may also include disabled elements in the navigation order."

  One reason that there has not been an increase is that there
  are other navigation requirements in the document (search,
  structured navigation). Thus, this checkpoint alone does not
  guarantee simple access (but it does meet the definition of a
  P1 checkpoint), but we anticipate that access will be possible
  by the sum of the navigation requirements.

  Please feel free to suggest alternative minimal requirements. </IJ>

<GL>
Your point is well taken, that search and structural navigation are
covered under a separate checkpoint (9.9). However, those are only Pri
2. I would argue that reasonable keyboard access to enabled elements is
a baseline requirement for accessibility, and single-direction,
sequential navigation alone would not satisfy that. I would not want a
UA to earn single-A compliance with only this level of keyboard
navigation. 
</GL>

<IJ2> As you note below, checkpoints 9.2 and 9.3 (move focus to enable
element, activate) are both P1.  
</IJ2>

<GL>
I consider the ability to move backwards, or the ability to undo the
last navigation, to be considerable help in reducing the amount of work
required to recover from navigating past your intended destination. For
example, take the case where you want to activate the last link in a
list. In a UA that only supports forward navigation between active
elements using the TAB key, you press TAB repeatedly hearing the items
in the list, but you cannot tell that you're at the last one until you
press TAB and hear something clearly outside the list. To continue, you
must back up one link. Without the ability to navigate in reverse order
or undo a navigation command, the user would have to cycle all the way
through the document, which could require over a hundred commands. 
</GL>

I note that the requirement to support structural navigation (9.9) does
require both forward and backward directions. Therefore, I would
conclude that either (a) you should add backwards navigation to 9.2, or
else (b) consider 9.2 just a special case of 9.9, by explicitly
mentioning enabled elements as important structural elements, or (c)
increase 9.9 from Pri 2 to Pri 1. </GL>

<IJ2>
In the past, the WG has not agreed to adding reverse navigation as a
minimal requirement for checkpoint 9.2. Perhaps in light of your
discussion, the WG will want to reconsider or reconfirm that decision.
</IJ2>

---------------
Issue 418 (Second Last Call): Checkpoint 7.5: Search should include alt
text.

<IJ>
  The Working Group felt that any rendered content
  should be part of the search, but undrendered content should
  not since this would be disorienting to the user. Instead, other
  requirements of the document require access to all content, and
  when rendered, that content is subject to the search
  requirement.
</IJ>

<GL>
I disagree: I think it is equally disorienting to be able to see text on
the screen and yet not find it with search just because, unbeknownst to
you, it's represented by an image of text. However, I can live with it.
But maybe make it a lower priority recommendation to provide an option
to search non-rendered equivalents? </GL>

<IJ2>
Our search requirement is on text characters only, not images that
display text. Therefore, the search requirement wouldn't find the image
in question. I would oppose adding a non-text-based search at this time.
I would also oppose 
adding a requiremen to search on unrendered content at this time, not
only because we already agreed not to, but because I don't think we have
any experience with this. </IJ2>

---------------
Issue 426 (Second Last Call): Checkpoint 9.8: Clarify that brief
sequences satisfy this checkpoint

<IJ>
  This is now checkpoint 11.4. In both the 9 March 2001
  draft and the 23 October draft, this checkpoint does not make
  any requirements about the complexity of bindings because those
  requirements are addressed by other checkpoints. Thus, no
  change was required.
</IJ>

<GL>
I don't understand the resolution: it seems clearly to describe bindings
of a single keystroke. I would recommend extending this to include brief
key sequences. It does not seem possible to allow the user to bind a
majority of the functions to single, unmodified keystrokes-there are a
very limited number of keys available for this purpose, if you don't
want to interfere with the user's ability to type in normal text. </GL>

<IJ2>
The WG is already considering this problem as issue 468
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#468
</IJ2>

---------------
Issue 429 (Second Last Call): New requirement: documentation of API for
querying preferences.

<IJ>
  The Working Group did not add these requirements
  today for two reasons:
   - There is no known interoperable API for exchanging user
   preferences. The Working Group intends to pursue this (e.g.,
   with the DOM WG) after UAAG 1.0.
   - The benefit to accessibility has not been studied.
</IJ>

<GL>
I disagree with this resolution on two counts. First, my major goal is
to make sure that people writing add-ons and plug-ins for specific user
agents can make them accessible. Thus, I'm not worried about the need
for API that works across multiple user agents. Second, I think my
example makes clear that without this, every add-on and plug-in will
have to provide its own means of allowing users to set configuration
parameters that affect accessibility. In many cases there will be no
convenient place to put UI for this, and in any case it will end up with
gross inconsistency between components. </GL>

<IJ2>
You distinguish plug-in (which I presume to mean "in process") from
other types of communication. Is there a technical reason to distinguish
in-process from out of process? I think the question of interoperability
still applies (since interoperation is still required in-process).

Do you have any examples of such an API? For instance, if browser
preferences are stored in the Windows registry, I would consider that an
instance of your request. Similarly, on 
X Windows, XResources configuration files offer a configuration
standard. 
</IJ2>

---------------
Issue 442 (Second Last Call): Checkpoint 9.4: Does this include default
mouse click behavior?

<IJ>
   Yes it does, but only if you are claiming conformance
   for the pointing device.
</IJ>

<GL>
(1) OK with this since it's only priority 2. However, I have never seen
any browser allow reconfiguring of mouse input mappings. I still think
it should be priority 3, but I won't argue about it. </GL>

<IJ2>
They may not do it, but I don't know that it's a bad idea. Suppose that
I have to do "shift-left-mouse" to accomplish something that I would
like to accomplish instead with a right click alone. That seems useful.
</IJ2>

<GL>
(2) Why limit this only to the same input modality? In theory you should
be able to access all functionality using either mouse or keyboard. 
<GL>

<IJ2>
This device-independent operation is ensured by other requirements of
the document. But for example, you might not easily remap 100 key
bindings to a 3-button mouse. So we keep the reconfiguration requirement
to a per-device requirement. 
</IJ2>

<GL>
In addition, mapping input to underlying functionality should be a valid
way to comply, rather than mapping one input to another input, which is
an indirect mapping to an underlying functionality. For example, if
clicking the secondary mouse button brings up a shortcut menu for the
selected object, then the user should be able to bind that feature to a
keystroke, key combination, or key sequence to bring up that same menu
for the object with the focus. 
</GL>

<IJ2>
Yes, I agree. And that requirement is made by checkpoint 1.1. 
</IJ2>

<GL>
(3) I do not understand why you allow the UA to refuse to remap bindings
just because they are standard for the operating environment. The
standard bindings may not be appropriate for some users, and therefore I
would recommend that the UA allow the user to override them. </GL>

<IJ2>
If this is the case, the operating environment should let the user remap
the keys to something more useful at the operating environment level
first. </IJ2>

---------------
New Issue Regarding checkpoint 10.2:

<GL>
This checkpoint says "Ensure that all of the default highlight styles
for the selection, content focus, enabled elements, recently visited
links, and fee links (1) do not rely on color alone, and (2) differ from
each other, and not by color alone. [Priority 1] Both content and user
agent." I do not agree that this should be Priority 1. I believe that
nearly all checkpoints that merely describe default behavior should be
priority 2 or lower. I consider it not merely infeasible but actually
impossible to create a default configuration that satisfies every user.
Therefore we have to assume that users will be able to successfully
change the configuration. Therefore minimal standards for UA should be
to provide these options, and choosing a good default should be part
considered "beyond the minimum." The exception to this is behavior that
affects the user's ability to change the UA's configuration; therefore,
accessible behavior of the user agent's user interface can be required
as part of the minimum standard. </GL>

<IJ2>
I find this comment very interesting! There are a few checkpoints that
make requirements for default configurations: 
    7.2 (P1), 10.2 (P1), 10.7 (P1), 11.5 (P2).

I think that the reason we made 10.2 and 10.7 P1 checkpoints is that the
user may not easily perceive the problem. I agree that as long as the
user can override the default, this is less severe than the exception
you cite ("by virtue of the inaccessibility of the default
configuration, the user can't make the necessary change").

Just to make sure, can the user override the configs required in 7.2,
10.2, 10.7, and 11.5?

 7.2, 11.5 (input configurations): Override possible at *P2* level 
                                   in checkpoint 11.3.
 10.2, 10.7: (highlighting): Configuration P1 in checkpoint 10.6
                             for selection/focus and *P2* in 10.3 
                             for fee links, etc.


So in essence, it would seem that the WG has chosen the opposite of what
you suggest: The top priority is that these mechanisms be (reasonably)
accessible by default, and that the configuration requirement is a lower
priority. 

I think that the Working Group should discuss these two models.

On a side note:

IJ-proposal: The "For user agents" label is broken in checkpoint 10.6,
since the requirement pertains to selection and *content focus*. It
should be "For content only". </IJ2>

---------------
New Issue Regarding checkpoints 6.3, 6.4, and 6.5:. 

<GL>
I am having second thoughts about requiring standard API as a Priority 1
requirement. I think that the minimum, priority 1 requirement should be
to expose this information through *any* API. If they do it through a
standard API that is even better, so I would make that Priority 2. You
may disagree, but I think it would be a positive thing for users if it
would cause some UA to expose their content through an existing native
object model, when they would otherwise not expose it at all because of 
the high cost of implementing an entirely separate, standard API. It is
better to have an awkward solution than no solution at all. 
</GL>

<IJ2>
This is also an interesting proposal. I think that the Working Group has
argued in the past that "some API" is not sufficient because it makes
implementation more difficult for AT developers. The Working Group
should confirm its decision. </IJ2>


==================================================
Editorial new issues / new information / proposals
==================================================

---------------
Issue 395 (Second Last Call): Checkpoint 3.8: Make images optional

<IJ>
  The requirement now includes a configuration for 
  placeholders. Please refer to checkpoint 3.7 in the 9 March draft.I
agree with this solution. </IJ>

<GL>
However, I am not happy with the phrase "on activation" in the final
sentence, "When placeholders are rendered, allow the user to view the
original author-supplied content on activation of each placeholder." I'm
not sure what this means in practice. In the fragment, <A HREF="#a"><IMG
SRC="b.jpg"></A>, what does it mean to activate the IMG element in order
to view the associated file b.jpg?</GL>

<IJ2>
One answer to your point is to say "activation, in the case of a
placeholder, means replacement with the original content." This is
consistent with saying, for example, "activation, in the case of an HTML
A element, usually replaces the current resource with another in the
same viewport." As the definition of "activation"
says:

   "The effect of activation depends on the type of enabled element or
   user interface control."

IJ-proposal: However, I would not object (and would consider it
editorial) to changing the sentence to something like:

   "When placeholders are rendered, allow the user to view the
   original author-supplied content associated with each 
   placeholder."

Note also our open issue 467:
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#467
</IJ2>

<GL>
Normally one would put the focus on
the A element, and activate that, which would jump to another location.
If UA were required to provide keyboard focus not only to the link but
also to any content inside the link, it would make navigation more
cumbersome. 
</GL>

<IJ2>
I don't think that's the only way one might implement this.
How do people implement longdesc today? That's another case of
two-links-in-one. </IJ2>

<GL>
Also, the process of downloading an image should not be
linked to activating the image, should it?
</GL>

<IJ2>
I'm not sure why not. Or I'm not sure I understand your point. </IJ2>

<GL>
This applies to other checkpoints as well.
</GL>

---------------
Issue 399 (Second Last Call): Checkpoint 4.7: Implementation experience
for this?

<IJ>
  The Quicktime player allows positioning (but not when
  captions are streamed; only when they are downloaded and
  played). The RealPlayer does not (yet) support caption positioning
  for SMIL, but the SMIL specification itself allows this. We are
  working on getting more implementation experience/commitments.
  In the meantime, the Working Group resolved to maintain this as
  a P1 requirement. </IJ>

<GL>
OK.

However, in the sentence "Allow the user to choose from among the same
range of positions available to the author (e.g., the range of positions
allowed by the markup or style language)," should that read "from among
all positions available to the author" to avoid implying that the UA
must support EXACTLY the same range of positions and not a superset of
those positioned available to authors? For example, the UA should be
able to let the user move the captions to a window outside the viewport,
which may not be an option available to the content author. Perhaps this
can be clarified in a note or in the techniques document. </GL>

<IJ2>
IJ-proposal: I agree that the wording of what is now checkpoint 4.6
could be clarified to something like:

    4.6 For graphical viewports, allow the user to position text
    transcripts, collated text transcripts, and captions in the
    viewport. Allow the user to choose from at least 
    the range of positions available to the author 
    (e.g., the range of positions allowed by the markup or style
    language). [Priority 1] Content only. 
</IJ2>

---------------
Issue 409 (Second Last Call): Checkpoint 4.20: If frames are not opened,
what is result?

<IJ> 
  The following Note has been added to checkpoint 5.3:
  "If a viewport (e.g., a frame set) contains other viewports, 
  these requirements only apply to the outermost container viewport." 
</IJ>

<GL>
The resolution proposed is fine, but not directly responding to my
comment. Despite Ian's statement above, the checkpoint wording makes it
sounds like the UA *is* forced to suppress opening frames if the user
does not confirm the action through one means or another. My question
is, is the purpose of this checkpoint to "alert the user" when a new
frame is opening, by making them take some action in response to some
notification? Or is it to ensure that UA "allow the user to [only] open
[the viewport] on demand", which amounts to encouraging users to prevent
new frames from opening by declining some offer? If it's only the
former, there are other ways of notifying the user that are not so
intrusive, such as a standard sound. If the latter, I still wonder if
users will be very confused when the decline to let the viewport open
and then find that the content they're trying to read does not make
sense. </GL>


<IJ2> 
The requirement is actually to prevent new viewports from opening. The
accessibility issue is information overload (and possibly also
navigation complexity among viewports). "Disorientation due to sudden
changes" has been associated more with changes to focus, 
so that's covered in 5.1

As to user confusion, 5.3 includes the requirement to allow the user to
open the viewport on demand, so the user should be able to go back and
get it if they decide they need it.

I would note that in the context of a synchronized presentation, where
the timing of the opening of the viewport is critical to the
presentation, then the user can break the author's intention by
suppressing the viewport creation. We are covered in this case to a
certain extent by checkpoints in Guideline 4 about controlling
presentations, but I suspect there are some scenarios we haven't yet
understood or discussed.  Nonetheless, I don't think that the current
checkpoint is therefore wrong, only that it may not address all possible
scenarios where opening viewports present problems to users. 
</IJ2>

---------------
Issue 430 (Second Last Call): Checkpoint 3.2: Animations, not just
animated images 

<IJ>
  There are several checkpoints related to animations
  in UAAG 1.0: 3.2, 3.3, 4.4, 4.5, and 4.7, 4.8. The Working
  Group felt that the requirement of checkpoint 3.2 was about
  turning off rendering of a block of content that might be 
  be visually disorienting, but not because of the motion; just
  because of the quantity of information. Thus, checkpoint
  3.2 has been limited to "video and animated images", while
  checkpoints 4.4, 4.5, 4.7, and 4.8 (which are about motion) have
  been broadened to include all classes of animations, as you
  suggested. Furthermore, a definition of "animation" has been
  added to the document to clarify what is expected.
</IJ>

<GL>
I appreciate the expanded definition of animation. 

The current checkpoints allow the user to replace different types of
complex presentations with placeholders. These are split up between
checkpoints 3.2 (animated images, video, and audio), 3.3 (animated
text), and 3.7 (static images). However, three examples of "animation"
are given: sequential images, scrolling text, and displacing objects.
The first two are covered by checkpoints 3.2 and 3.3, respectively, but
where is the third type covered? 
</GL>

<IJ2>
Checkpoints 4.4, 4.5, 4.7, and 4.8. The checkpoints in 
Guideline 3 are really about suppressing blocks of content
that may be disorienting. For animations, we only include specific
subclasses (animated images, animated text, video). The most general
class of animation (moving ball) did not lend itself to placeholder
replacement. </IJ2>

<GL>
Also, with regard to 3.2, I'm still not sure why "quantity of
information" is more of a problem with an animated image than with
animated text. It seems like, in many cases, they two are
indistinguishable by the user and therefore should have the same
accessibility requirements. </GL>

<IJ2>
My understanding is that there is a difference to some users with
cognitive disabilities between visually displayed images/graphics and
visually displayed text.  Our goal is not to suppres the rendering of
all content, only images. (Thus, the requirements of 3.3 are not to
suppress rendering of text, only to stop the motion/blinking.)  
</IJ2>


---------------
Issue 432 (Second Last Call): Checkpoint 3.4: Overlaps with 3.2 

<IJ>
  The Working Group disagrees that blinking images
  and animated images are the same: blinking is an on/off effect.
  There is no requirement to slow down this blinking effect (only
  to stop it). There are requirements to slow down animation effects,
  so that users can understand the changes to content.
</IJ>

<GL>
Actually the checkpoint to "Allow the user to configure the user agent
to render blinking images as motionless images" seems to have been
removed, making this point moot. 
</GL>

<IJ2>
Yes. Sorry I missed that in my summary. We deleted that checkpoint
starting in the 26 January draft for a couple of reasons:
 a) The WG was not aware of blinking images on the Web.
 b) Even if they are on the Web, checkpoint 3.2 (animated images)
    seems to cover the requirement sufficiently.
</IJ2>

<GL>
It might be worthwhile modifying the definition of 'placeholder' to
include the example of using the first significant frame of an animated
image as the placeholder for the animated image. </GL>

<IJ2>
IJ-proposed: I agree with the proposal.
</IJ2>

---------------
New Issue Regarding checkpoint 10.3: 

<GL>
Instead of "The highlight mechanism must not rely on color alone," it
would be more accurate to say, "One or more highlight options must be
provided that do not rely on color alone." The current wording could be
interpreted as meaning that the user must not be allowed to select a
highlighting option which relies solely on color. 
</GL>

<IJ2>
The checkpoints are written to make minimal requirements. This
checkpoint only requires one mechanism, in which case it must not rely
on color alone. The user agent may always implement more than one
mechanism. We do use the "at least" formulation in other checkpoints. I
have no objection to making the suggested editorial change. </IJ2>


================================================
Substantive disagreement with no new information
================================================

---------------
Issue 396 (Second Last Call): New requirement: Allow user to override
absolute values

<IJ>
  The Working Group resolved not to include general
  resizing requirements in UAAG 1.0 (though there are
  requirements for resizing text). This is now clearly listed as
  one of the limitations of UAAG 1.0 (refer to section 1.3 of
  the document). Some specifications (e.g., SVG) will allow for
  resizing as part of conformance to those specifications. </IJ>

<GL>
I do not believe this is necessarily difficult to solve, at least in
specific cases such as absolute sizes of elements. I consider this a
very major deficiency in the guidelines. </GL>

<IJ2>
We did not have a technical reason for not adding this requirement. We
simply decided to stop adding requirements to the document after a
certain point (so that we would someday finish...). </IJ2>

---------------
Issue 403 (Second Last Call): Checkpoint 4.12: Need to require override
of author-specified speeds.

<IJ>
  We did not add this requirement (for user control of
  author-supplied rate changes) for the following reasons:
   1) If speech engine allows user override, that's the speech
   engine's functionality, not the UA's.
   2) We don't require content transformations to strip out
   author-supplied rate changes before sending to the speech
   engine.
</IJ>

<GL>
I can live with this, but I disagree with it. As for reason #1,
certainly the UA would not be required to support speech rates outside
the range supported by the speech engine. However, they should support
the full range of rates supported by the engine. That is definitely UA
functionality. As for #2, *why* don't you require UA to strip out, or
replace, author-supplied rate changes before sending to the speech
engine when the speech rate is specified using a standard markup? This
seems easy enough to do. Are there other factors you are not mentioning?
</GL>

<IJ2>
@@
Point 1: 

Point 2:
</IJ2>

---------------
Issue 415 (Second Last Call): Definition of active element: too broad
(checkpoint 7.4)

<IJ>
   There have been a number of changes related to the
   term "active element". In fact, the term has been deleted 
   from the document and replaced with other terms (with clearer
   entries in the glossary):

     * Interactive element
     * Enabled element.

   Furthermore, the definition of "enabled element" states:

     "For the requirements of this document, user selection does
     not constitute user interaction with enabled elements." </IJ>

<GL>
I'm still confused. The definition says "An enabled element is a piece
of content that is subject to user activation through the user interface
or indirectly through an API. The set of elements that a user agent
enables is generally derived from, but is not limited to, the set of
interactive elements defined by implemented markup languages." There are
two problems with this. 

The first problem is that the first sentence defines 'enabled element'
in terms of 'activation', but the latter term is defined as "To trigger
one or more behaviors associated with an enabled element." Term 1 is
defined by referring to term 2, and term 2 is defined by referring to
term 1, and thus we have a cyclical definition.

The second problem is similar. 'Enabled elements' are said to be a
superset of 'interactive elements defined by implemented markup
languages,' but an 'interactive element' is defined as a 'piece of
content that is intended, by specification, to be an enabled element in
some user sessions.' Thus, enabled elements are said to be a superset of
all elements that are intended to be able to be enabled elements. I
guess the additional enabled elements that are not interactive elements
must be things that the UA makes enabled *against* the intentions of the
specification language. Sounds suspicious to me. </GL>

<IJ2> 
I will work to clear up the definitions.

I think the first problem can be cleared up by changing the definition
of enabled element to (something like):

  "Enabled element: A piece of content with associated behaviors that
  may be activated through the UI or through an API"

  "Activate: To trigger the behaviors associated with either
   an enabled element or a user interface control."

  Note addition (and distinction) of UI control.
</IJ2>

---------------
Issue 435 (Second Last Call): Checkpoint 4.14: Is this for content only
or UI as well? 

<IJ>
   Content only. There has been no change to the
   document. However, based on my comments for issue #413, I
   think additional clarification may be required.
</IJ>

<GL>
Please clarify why the user should not have control over attributes of
synthesized speech used as part of the UA's UI. </GL>

<IJ2>
No technical reason, only that the WG chose not to
generalize our content requirements to the user interface
(I can't locate the resolution right now, but could if pressed).
Instead, we resolved to add the following to the (Techniques)
document:

   "Much of the rationale behind the content requirements of User
   Agent Accessibility Guidelines 1.0 also makes sense for the user
   agent user interface (e.g., allow the user to turn off any blinking
   or moving user interface components)."
</IJ2>

---------------
Issue 440 (Second Last Call): Checkpoint 7.5: Should min reqs be moved
to techniques?

<IJ>
  The Working Group believes that the details of the
  required search functionality (now checkpoint 9.8) are
  minimal requirements, and thus belong in the checkpoint. </IJ>

<GL>
(1) OK to leave, although I think it is too detailed and specific. </GL>

<IJ2>
This is the list of search requirements the WG considered "essential".
</IJ2>

<GL>
(2) Should add the option or mechanism to start search from the
beginning of the document rather than from the current selection or
focus. There is no easy way to do this in IE today. Or is there already
a requirement to provide an easy way to move the "focus" or start of
search to the beginning or end of the document. 

(3) Should provide distinct alerts for the three situations listed; the
user should be able to easily tell whether they have searched all the
content, or whether they merely reached the end of the document and now
need to wrap to the beginning.

(4) There are a lot of additional variations that could be included as
priority 3. For example, should add the ability to search backwards
through content, possibly as a priority 3 checkpoint. That is part of
forgiveness, allowing the user to avoid having to start over if they
accidentally go one search too far.

(5) If the user has not indicated a start position for the search, the
search should start from the beginning of that portion in the viewport
(as far as the user agent is concerned-it does not have to deal with
whether portions of its window is obscured by other applications or
operating systems windows).

(6) Should ideally provide the option of searching through alternative
representations (such as ALT text) and source (e.g. you know the page
was found by a search engine looking for a specific term, but normal
search cannot find it, it would be nice to have it inform you that it
found the text in metadata or other non-rendered portions of the source.
This would be lower priority. </GL>

<IJ2>
All of this should go in the Techniques document.
</IJ2>

---------------
Issue 441 (Second Last Call): New requirement (part of 8.5): Add
information about the resource being at the same or a different domain.


<IJ>
  This was not added. However, there is a requirement
  to provide information about whether the link is internal
  to the same resource.
</IJ>

<GL>
I disagree with this decision but can live with it.
<GL>

<IJ2>
Ok.
</IJ2>

==============================================
Editorial disagreement with no new information
==============================================

---------------
Issue 389 (Second Last Call): Conformance: Hard to test conformance in
an objective fashion. 

<IJ>
  We've done a lot to improve the document in terms of
  conformance since the last call draft, including the following:
   a) Introduction of content type labels and input modality
      labels to allow greater flexibility in conformance.
   b) Clarifying checkpoints (notably those of Guideline 1).

   However, as you recall from our 25 January 2001 discussion [4]
   you maintained your concern that the Guidelines are not 
   technology-specific, making it difficult to objectively measure 
   conformance. We will take these comments to the Director, but
   for now we have left the Guidelines (and conformance scheme)
   technology-independent, as was the case for WCAG 1.0 and ATAG 1.0.
</IJ>

<GL>
I am still concerned that there may be places where the Note text adds
details that apparently will be taken as a legally binding extension to
the checkpoint wording itself, and how examples given in Techniques can
confuse things by not distinguishing examples from recommendations.
However, I'll have to see if I can find an example. </GL>

---------------
Issue 438 (Second Last Call): Checkpoint 7.3: For some devices, is
direct navigation of active elements sufficient? 

<IJ>
   This has been clarified because the checkpoints of
   what is now Guideline 9 have been made much more specific
   to the content focus (whatever input devices are used
   to control the content focus). There are no requirements in
   the document for direct navigation through a pointing device,
   but if the user agent allows the user to move the focus with
   the pointing device, the desired functionality is achieved. </IJ>

<GL>
(1) I can live with this; I understand the reason for it, but I still
feel that you're heaping so many expectations on the UA that none will
ever conform to this level. That is to say, no UA will conform with
respect to pointing devices.

(2) Where it says "The user agent may also include disabled elements in
the navigation order," the key factor is that the user should be able to
move only to active elements. The ability to move to inactive elements
can be a user-controllable option, but should not be unalterable
behavior. 
</GL>

<IJ2>
Unless I have misunderstood the comment, your requirement is covered at
a P2 level by checkpoint 9.7. Note that it was considered a P1
requirement to get to the enabled elements at all (with possibly other
elements in between), and a P2 requirement to get to them without
"interruption" by disabled elements. </IJ2>

=========
Agreement
=========

---------------
Issue 392 (Second Last Call): Checkpoint 1.4: Overly broad

<IJ> 
  This is a conformance issue: a claim of conformance
  may include any number of software components. Therefore, a
  user agent alone might not satisfy one of the requirements, but
  the user agent in conjunction with another piece of software
  (e.g., an on-screen keyboard that comes with the OS) might.
  There is no longer a notion of "what is the responsibility of
  the user agent, the operating system, and third-party
  accessibility aids"; there are simply requirements that must
  be met, by whatever means the claimant has available.
</IJ>

<GL>
The new wording is fine. 

However, I'm worried about this approach whitewashing the difference
between a UA that is designed to be accessible, and one that uses
inaccessible design but has at least one dedicated third-party vendor
who creates a hack solution. I believe we owe it to customers trying to
make purchasing decisions to help clarify this, and we also owe it to
customers who want a wide range of AT products for use with their UA. 
</GL>

<IJ2>
I think our conformance claim requirements will help inform consumers. I
do not have other suggestions at this time. </IJ2>

---------------
Issue 398 (Second Last Call): Checkpoint 4.5 (4.6, 4.8, 4.9): Need
definition of "not recognized as style"

<IJ>
   There were two changes to the document:
   a) The following statement in checkpoint 4.4 et al. is
      clearer:
      "The user agent is not required to satisfy this checkpoint
      for audio and animations whose recognized role is to create
      a purely stylistic effect."
   b) The Note of checkpoint 4.4 states:
      "Note: Purely stylistic effects include background sounds,
      decorative animated images, and effects caused by style
      sheets. The style exception of this checkpoint is based on
      the assumption that authors have satisfied the requirements
      of the "Web Content Accessibility Guidelines 1.0" [WCAG10]
      not to convey information through style alone (e.g.,
      through color alone or style sheets alone)."
</IJ>

<GL>
Acceptable, but I'm not wholly comfortable with saying that the UA can
avoid making accessible anything that is authored in a way that is
supposed to be reserved for purely stylistic touches, because we all
know that authors abuse these mechanisms. 
</GL>

<IJ2>
We have acknowledged the potential for abuse by authors, but we
explicitly excluded this repair for this checkpoint. 
</IJ2>

<GL>
In many cases authors will
convey information using background sounds or sounds specified in style
sheets, and it would be to the user's benefit to be able to have access
to and control over those sounds. </GL>

<IJ2>
(Checkpoints 4.7 and 4.8 address this at a P2 level.)
</IJ2>


---------------
Issue 400 (Second Last Call): Checkpoint 4.11: Why limited to sources
synchronized to play simultanously?

<IJ>
  The answer is that the requirement for independent
  volume control is not necessary when sources of audio may be
  played one after the other. In that case, global control
  suffices (another checkpoint). Thus, this is an expression of
  the minimal functional requirement. We added a Note to
  checkpoint 4.10:

   "Note: Sounds that play at different times are distinguishable
   and therefore independent control of their volumes is not part
   of this checkpoint (volume control per checkpoint 4.9
   suffices). The user agent may satisfy this checkpoint by
   allowing the user to control independently the volumes of all
   distinct audio sources. The user control required by this
   checkpoint includes the ability to override author-specified
   volumes for the relevant sources of audio."
</IJ>

<GL>
Acceptable. 

However, note that there are at least three good reasons for strongly
recommending that all sounds are independently configurable: (1) sounds
which are not synchronized may end up playing simultaneously, and (2) if
the user cannot anticipate when a sound will play they cannot adjust the
global volume control at appropriate times to affect this sound, and (3)
it is extremely inconvenient for the user to have to frequently adjust
global volume to accommodate sounds about to be played, especially when
this leads them to frequently switch back and forth between different
volume settings. Therefore I would recommend making this a separate Pri
3 checkpoint. </GL>

<IJ2>
What if, instead, we strengthen the Note after 4.10. Change "may" to
"should" in:

    "The user agent may satisfy this checkpoint by allowing the user
    to control independently the volumes of all distinct audio
    sources.  

I am not very much in favor of adding checkpoints at this time. I would
like to include your rationale in the Techniques document for 4.10 in
any case. </IJ2>

---------------
Issue 406 (Second Last Call): Checkpoint 4.18: Lower to Priority 3

<IJ>
  The Working Group felt that the orientation problems
  were significant enough that this checkpoint (now 5.1) should
  remain a priority 2 checkpoint.
</IJ>

<GL>
I disagree, but I can live with it.

However, you should then add a requirement that says the UA must notify
the user when opening or closing viewports, when that is not the direct
result of explicit user request. After all, it is worse for the UA to
open a new window and not tell the user than it is to open a window and
move focus to it. </GL>

<IJ2>
I believe that both of those requirements are already covered in the
document:

For notification (in fact, prompting) before opening, checkpoint 5.3.
For notification (in fact, prompting) before closing, checkpoint 5.6.
(In both cases, when not on explicit user request). </IJ2>

---------------
Issue 407 (Second Last Call): Checkpoint 4.20: Include requirement to
control automatic closing of viewports

<IJ>
 This is now checkpoint 5.6 (Priority 3).
</IJ>

<GL>
Fine. But is there a checkpoint that recommends UA use standard system
notification or alert mechanisms when doing things like closing
viewports? </GL>

<IJ2>
That is covered (P2 level) by checkpoint 7.3:

   7.3 Follow operating environment conventions that benefit
   accessibility.

IJ-proposal: Change "that benefit accessibility" to "that do not
interfere with accessibility". [I make this proposal only for checkpoint
7.3 and not for checkpoints in Guideline 12.]  
</IJ2>

---------------
Issue 413 (Second Last Call): Checkpoint 6.2: Does this only apply to
content?

<IJ>
  Yes, this applies only to content. There has been
  no change to the document because it was considered that
  the label in the document "Checkpoints for content" was
  sufficient, but given other changes to the document
  subsequently, I think this requires an additional (editorial)
  clarification to the checkpoint. (I will write a proposal
  to the Working Group.)
</IJ>

<GL>
I'll wait to see your proposed modifications, but I strongly favor
writing all checkpoints so that their meanings are not significantly
changed when quoted out of context. I consider relying on headings
outside the checkpoint itself to be dangerous, even if the headings are
present in every guidelines document and summary published by the W3C,
because they will be quoted out of context on occasion. </GL>

<IJ2>
This is done as of the 23 March 2001 draft: we have labels
in each checkpoint. 

IJ-proposal: I think the label for 10.2 should read "For content only"
instead of "For content and user agent". This is because the highlight
styles for selection, content focus, etc. only refer to interacting
styles within content. It is possible to have selection and focus in the
UI, but that's not what this checkpoint is intending to address. I
consider this editorial and will fix it. </IJ2>


---------------
Issue 424 (Second Last Call): Checkpoint 9.3: Do author-specified
shortcuts include active elements that take mouse input? 

<IJ>
  Bindings accomplished through scripting are not part
  of the requirements of this document. This is covered by our
  "applicability" provision in general. Furthermore, the
  following statement has been added to section 3.2 of the
  document (as an example of when one would consider applicability): 
    "Some input device behavior may be controlled by scripts in a
    manner that the user agent cannot recognize."
</IJ>

<GL>
I disagree with this resolution. In many cases the UA knows when an
object handles different types of input events. For example, with
javascript the UA knows if the script declares a handler for onClick
events. Thus, it is entirely reasonable for it to provide keyboard
mechanisms for putting focus on and simulating mouse input to these
elements. </GL>

<IJ2>
Actually, I think we are in agreement, but I expressed the resolution
incorrectly. Just because something is in a script doesn't exclude it
from the requirements of the document. It is more likely that knowledge
embedded in scripts will be harder for the user agent to recognize.
However, it is not impossible, and there are many things done in scripts
(e.g., opening a viewport) where the user agent knows very well what is
about to happen. The case you site is an example of what the user agent
should recognize. Therefore, I think our document already reflects your
expectation. </IJ2>

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

Received on Thursday, 29 March 2001 15:23:03 UTC