- From: David Poehlman <poehlman1@home.com>
- Date: Thu, 29 Mar 2001 10:28:38 -0500
- To: "Greg Lowney" <greglo@microsoft.com>, "Ian Jacobs" <ij@w3.org>
- Cc: <w3c-wai-ua@w3.org>
is there implementation experience for an inaccessible api being
accessible through a third party app? even with ie for instance, we
have special features. you could claim that netscape is accessible when
put together with a screen reader and if someone can justify that claim,
I think we have room for it. the upshot is that you can state your
claim for accessibility in any fashion that you wish but if you are a
developper, you need to speak for your product unless you are
developping in cooperation with the 3rd party and have been designated
by that party as the person responsible on the claim. If you make a
claim as an individual or an organization, you have a freer hand so you
can say for instance, that, "ua x is accessible in combination with app
1".
----- Original Message -----
From: "Greg Lowney" <greglo@microsoft.com>
To: "Ian Jacobs" <ij@w3.org>
Cc: <w3c-wai-ua@w3.org>
Sent: Wednesday, March 28, 2001 7:45 PM
Subject: RE: Responses to Greg Lowney issues raised during second last
call of UAAG 1.0
Hi Ian,
Thanks for all the work you put in summarizing the resolutions for me. I
have looked them all over and most look great. Here are some comments
and follow-up on some, as well as a number of new comments sparked by my
investigation of the older issues. I apologize for not making the 3/27
deadline that you requested, but feel free to handle these comments and
responses as you see fit.
All of the guidelines quotations are from
http://www.w3.org/WAI/UA/WD-UAAG10-20010323/. All of the quotes marked
<IJ>...</IJ> are from your email of March 16, 2001.
Please keep in mind that, as always, I am voicing my own opinions and
these do not reflect an official position by my employer.
Keep up the good work.
Thanks,
Greg
---------------
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>
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.
---------------
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>
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.
---------------
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>
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: "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."
---------------
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>
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? 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. Also, the process of downloading an image should not be
linked to activating the image, should it? This applies to other
checkpoints as well.
---------------
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>
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.
---------------
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>
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. 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.
---------------
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>
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.
---------------
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>
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.
---------------
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>
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?
---------------
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>
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.
---------------
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>
Fine. But is there a checkpoint that recommends UA use standard system
notification or alert mechanisms when doing things like closing
viewports?
---------------
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>
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.
---------------
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>
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.
---------------
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>
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.
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.
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.
---------------
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>
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.
---------------
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>
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?
---------------
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>
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.
---------------
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>
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.
---------------
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>
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.
---------------
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>
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?
Also, with regard to 3.2, I'm still not sure why "quantify 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.
---------------
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>
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.
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.
---------------
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>
Please clarify why the user should not have control over attributes of
synthesized speech used as part of the UA's UI.
---------------
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>
(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.
---------------
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>
(1) OK to leave, although I think it is too detailed and specific.
(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.
---------------
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>
I disagree with this decision but can live with it.
---------------
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>
(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.
(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. 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.
(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.
---------------
New Issue Regarding checkpoint 10.3:
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.
---------------
New Issue Regarding checkpoint 10.2:
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.
---------------
New Issue Regarding checkpoints 6.3, 6.4, and 6.5:.
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.
Thanks,
Greg
Received on Thursday, 29 March 2001 10:29:35 UTC