- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 29 Mar 2001 13:44:51 -0500
- To: Greg Lowney <greglo@microsoft.com>
- CC: w3c-wai-ua@w3.org
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 13:45:07 UTC