- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 24 Apr 2001 18:38:13 -0400
- To: w3c-wai-ua@w3.org, tantek@cs.stanford.edu
Hello,
Tantek Çelik and I spent eight hours on 22 April reviewing the 9
April 2001 (last call) draft of UAAG 1.0. [1]. Tantek develops IE
for the Mac and participates in the W3C CSS Working Group. Tantek
and I last reviewed UAAG 1.0 together in early July 2000 (see
notes [2], [3]). I am very pleased to report that Tantek found
the 9 April draft much improved, and we encountered few issues
and ambiguities that I would consider substantial. Tantek also
had some great ideas for improving the usability of the document
(which he claims to have come up with after reading WCAG 1.0, so
there was lots of mutual patting on the back <wink>).
The issues below are not formal last call issues raised by
Tantek. The bulk of the comments come from Tantek, but this is my
own presentation (and filtering) of the discussion. I have also
included some comments from me that are related to the discussion
or are the result of further reflection.
This is the first of three emails:
1) Part one is the most important issues
2) Part two is about minor clarifications
3) Part three is about good ideas to improve the usability
of the document.
I have not reported editorial issues, which I will simply correct
for the next draft.
Many thanks to Tantek for taking the time to scrutinize the
document!
- Ian
P.S. Tantek did not sign off on this email or the other two. He
said he trusted me to communicate our conversation to the
Working Group.
[1] http://www.w3.org/TR/2001/WD-UAAG10-20010409/
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0060
[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0068
================================
1) Checkpoint 1.2: "Start" events are more important than "End"
events.
================================
Many input device events in today's systems are designed as
start/end pairs. Examples include: mousedown/mouseup,
mouseover/mouseout, and key down/up. These events are (to my
understanding) always expected to happen in pairs. Tantek made
the point that designers therefore make assumptions that an "end"
handler will not be executed without execution of a preceding
"start" handler. Checkpoint 1.2 as written breaks this model.
--------
Proposal
--------
Narrow checkpoint 1.2 so that the list of handlers that the user
agent makes available may vary according to different states. In
particular, the user agent should not be required to allow the
user to trigger an "end" handler prior to execution of the
corresponding "start" handler. Similarly, the user agent should
probably not allow the user to trigger another start handler
until the preceding end handler of the same type has been
triggered.
Summary: The user agent should only have to support the sequences
that are available to the user of the native input device (e.g.,
mouse).
There would probably need to be some changes to checkpoint 9.4 as
well, at least to clarify that the "list of available handlers"
may not be the full list due to the current state of interaction
(i.e., you may only get start handlers, not end handlers).
A technique idea: Allow the user to trigger two "start" handlers
in a row (of the same type) and trigger the intervening "end"
handler automatically just before the second "start" handler.
========================================
2) Checkpoint 2.1: Do some UAAG 1.0 requirements override this?
========================================
Checkpoint 2.1 says "render according to spec". However, some of
the requirements in Guideline 3 (and possibly others) require
control of rendering that may not be part of a specification or
may even "contradict" a specification. [Al Gilman has said that
if a W3C specification does not allow the type of control
required by Guideline 3, it is broken. But UAAG 1.0 is not just
for user agents rendering content authored using W3C
specifications.]
--------
Proposal
--------
State clearly in checkpoint 2.1 that for other rendering
requirements elsewhere in the document:
a) If the format spec explains how to provide the
control we require, follow the spec.
b) If the required control does not contradict the
format specification, there is no problem implementing
the required control features. [The fact that the
specificatino says nothing does not mean that the
additional control requirements of UAAG 1.0 do not apply!]
c) If the required control does contradict the format
specification, it is acceptable to violate 2.1 in order to
satisfy the other rendering requirements of UAAG 1.0.
I don't think that the other direction should be permissible:
the UA should not be permitted to conform to UAAG 1.0 by
satisfying 2.1 and by not satisfying the other rendering
requirements. I would guess that in this case, the format
spec probably doesn't satisfy the requirements of checkpoint
8.2 as it would seem to prevent the authoring of content that
conforms to WCAG 1.0.
========================================
3) Checkpoint 2.2: Define text format more formally.
========================================
Checkpoint 2.2 says that text formats "include at least the
following". This is an unbounded requirement as written.
--------
Proposal
--------
Change checkpoint 2.2 to define exactly what we mean by text
formats for this document (i.e., the minimal requirement). For
example, change the phrase to "For the purposes of this
checkpoint, text formats are:...".
========================================
4) Checkpoint 2.3: Scope of "alert" requirement.
========================================
Checkpoint 2.3 requires the user to "alert the user to the
existence of the [unrendered conditional] content and provide
access to it."
Is the alert requirement global (i.e., "there is conditional
content in this page") or element-level?
If the alert requirement is global, I think that a technique that
is just as good as an alert is the ability to query the document
and ask "Is there conditional content in this page?".
If the alert requirement is element level ("there is conditional
content here") this needs to be clarified.
I would like the Working Group to clarify which is intended.
========================================
5) Configuration not required when the user agent always or
never does something?
========================================
Many of the checkpoints involve configuration
requirements. However, configuration may not be necessary if the
user agent always or never provides the critical functionality in
question. We've already incorporated this idea into checkpoint
5.1, which reads:
"5.1 ... Configuration is not required if the current focus can
only ever be moved by explicit user request."
--------
Proposal
--------
Modify the configuration checkpoints as follows:
a) No configuration is necessary if the user agent always provides
the required functionality: 2.3, 2.5
5.4, 5.5: I'm not sure about these two. If it's an extra
effort to confirm a prompt, then maybe configuration is
required.
b) No configuration is necessary if the user agent never
provides the functionality: 5.1, 5.2
For checkpoints 3.2, 3.4, and 3.7, no configuration is
necessary for the placeholder or alert parts (the UA
does the right thing by always providing placeholders in this
case, and always alerting in this case).
c No changes to the following checkpoints (i.e., configuration is
required). In each case, there is a phrase of rationale:
2.4: User may also want automatic rendering.
2.7: User may not want repair text.
2.8: Two options here, so configuration required.
2.9: User may not want automatic rendering.
2.10: User should have access to all content.
3.1: User should have access to all content.
3.2: User may also want automatic rendering.
3.3: Some users may find blinking important or useful
(e.g., users with deafness).
3.4: User should have access to all content.
3.5, 3.6: Automatic behavior also desirable.
3.7: User should have access to all content.
4.1, 4.2, 4.3, 4.9, 4.11, 4.13, 4.14:
More than one on/off setting required.
5.3: May want automatic opening behavior.
5.6: May want automatic closing behavior.
9.5: May want automatic closing behavior.
9.9: More than one on/off setting required.
10.2, 10.4: More than one on/off setting required.
Guideline 11: More than one on/off setting required.
12.4: Documentation checkpoint (not about configurability).
================================
6) Checkpoint 2.9: Automatic rendering of all conditional content
at once required?
========================================
Checkpoint 2.9 reads:
"Allow configuration to render all conditional content
automatically. Provide access to this content according to
format specifications or where unspecified, by applying one of
the following techniques described in checkpoint 2.3: 1a, 2a,
or 1b."
I don't think it's necessary that all conditional content be
rendered automatically in the same viewport at the same time. I
think that it would suffice to have one or more configurations
that allow all conditional content to be rendered automatically
in some viewport at some time. For instance, one setting to
render NOFRAMES content automatically in HTML, another to render
NOSCRIPT content automatically, etc.
--------
Proposal
--------
<NEW 2.9>
Allow configuration to render all conditional content
automatically. Provide access to this content according to
format specifications or where unspecified, by applying one of
the following techniques described in checkpoint 2.3: 1a, 2a, or
1b. The user agent is not required to satisfy this checkpoint by
rendering all conditional content automatically in a single
viewport at one time. The user agent may satisfy this checkpoint
by allowing different configurations to render different types of
conditional content automatically, possibly in different viewports.
</NEW 2.9>
Comments:
- Tantek asked whether alternative style sheets should be
considered conditional content. I didn't think so at first, but
the more I think about it, the more I think they should be
considered conditional content. The definition of conditional
content starts:
"Conditional content is content that, by specification, should
be made available to users through the user interface, generally
under certain conditions (e.g., user preferences or operating
environment limitations)."
Checkpoint 4.16 requires that the user be able to choose from
available author style sheets, which includes alternative style
sheets. I note that the definition says "user interface" rather
than "viewport" specifically (where *content* is rendered).
The proposed change to 2.9 is consistent with providing
alternative style sheets one at a time (instead of all at once,
automatically) as required by 4.16.
========================================
7) Definitions of rendered content / viewport circular.
========================================
The current circular definitions say "rendered content is content
available through a viewport" and "the viewport is where the user
agent renders content".
--------
Proposal
--------
<OLD RENDERED CONTENT>
Rendered content is the part of content capable of being
perceived by a user through a given viewport (whether visual,
auditory, or tactile).
</OLD RENDERED CONTENT>
<NEW RENDERED CONTENT>
Rendered content is the part of content that the user agent makes
available to the user's senses of sight, hearing, or touch (and
only those senses for the purposes of UAAG 1.0). Any content that
causes an effect that may be perceived through these senses
constitutes rendered content. This includes text characters,
images, style sheets, scripts, and anything else in content whose
effect when processed may be perceived.
</NEW RENDERED CONTENT>
At first, I was nervous about this model, but I am unable to draw
a line between style sheets, text content, and binary image
formats: they all require processing to create an effect that is
perceived by the senses. It's easiest to say that when they cause
an effect that may be perceived (by some users, but not
necessarily by all), they are rendered content. Some examples of
content that is generally not rendered: comments. They may be
rendered in the source view.
The only checkpoints that have requirements related to rendered
content are 2.3 and 10.9, and this model is consistent with those
requirements. The definition of "point of regard" refers to
rendered content and is used in 9.3; the usage is also consistent
there.
<NEW VIEWPORT>
The user agent renders content through one or more viewports.
</NEW VIEWPORT>
<OLD VIEWPORT>
The user views rendered content through a viewport.
</OLD VIEWPORT>
Comment: I was thinking about the HTML TITLE element, which most
user agents render in a title bar, separate from the "main"
viewport of the user interface. Should the title bar be
considered a viewport? I think it should. The only checkpoint
that makes me nervous with this approach is 9.1:
"9.1 Allow the user to make the selection and focus of each
viewport (including frames) the current selection and current
focus, respectively."
See the next issue as a way to address this.
========================================
8) Require focus for enabled elements only. Don't require
selection. Clarify that "user interface focus" is not related
to viewports (but instead to other controls of the user
interface).
========================================
My discussions with the SVG Working Group, and the previous issue
in this email lead me to the following proposal regarding focus
and selection requirements.
--------
Proposal
--------
- We should explicitly not require user selection for
conformance. I think that stating this explicitly is not a
significant departure from the way that the following checkpoints
involving selection are written: 6.5, 7.1, 9.1, 9.3, 9.7, 10.2,
10.3, 10.8.
- We should explicitly require content and user interface focus
for conformance, but only when there is something to focus on
(either an "enabled element" or a user interface control).
To implement this proposal:
8a) Fix 9.1, which is broken in a number of ways (that are not
really serious):
<NEW 9.1a>
Allow the user to make the selection of each viewport (including
frames) the current selection. For content only.
Note: UAAG 1.0 does not require a conforming user agent to
implement a user selection. The selection requirements of this
document only apply when the user agent implements a selection.
</NEW 9.1a>
<NEW 9.1b>
Implement one content focus for each viewport where
enabled elements are part of the rendered content. Allow the user
to make the content focus of each viewport (including frames) the
current focus. For content only.
Note: UAAG 1.0 assumes that a viewport has at most one content
focus. The requirements of this document should still make
sense for viewports with more than one focus.
</NEW 9.1b>
<NEW 9.1c>
Implement a user interface focus mechanism. Allow the user
to move the user interface focus to any enabled user interface
control. User agent only.
</NEW 9.1c>
Comment on 9.1c: This is like checkpoint 9.2, but for the UI.
8b) Add an applicability provision related to selection:
"A checkpoint (or part of a checkpoint) applies unless any one
of the following conditions is met:"
<NEW CONDITION>
The checkpoint makes requirements about the selection, but the user
agent does not implement a user selection mechanism.
</NEW CONDITION>
8c) Checkpoint 9.3: I think that the "user interface focus"
should *not* be associated with the viewport for any requirements
in the document, including for checkpoint 9.3. The user
interface focus is set on other controls of the user
interface. Therefore, I think that checkpoint 9.3 should not
include "user interface focus" in the list of state information
that must be part of the *viewport* history.
8d) Change 5.1 so that "current focus" (which includes both
content focus and UI focus) does not refer just to viewports.
<OLD 5.1>
Allow configuration so that the current focus does not move
automatically to viewports that open without explicit user
request.
</OLD 5.1>
<NEW 5.1>
Allow configuration so that the current content focus does not
move automatically to viewports that open without explicit user
request.
</NEW 5.1>
Comment: I'm not sure whether 5.1 *should* include a requirement
about not moving user interface focus. What would the user
agent do in the case of prompts? Would there be a configuration
so that the focus would not move to prompts, e.g., to confirm
a form submission?
8e) Leave 5.2, 10.7 as is.
8f) Fix 10.8. It should be about content only.
8g) Fix definitions of focus, selection, and viewport. In
particular, mention that for UAAG 1.0 there is expected to be
only one of each (but one could imagine an operating environment
or user agent with two focuses per viewport, etc.).
================================
9) Checkpoint 2.10: Is this only about natural language? Or is
this also about scripts?
================================
Checkpoint 2.10 reads:
"Allow configuration not to render content in unsupported
natural languages."
--------
Proposal
--------
I think this requirement needs to mention unsupported scripts
(writing systems) explicitly.
<NEW 2.10>
"Allow configuration not to render content in unsupported natural
languages and scripts (writing systems)."
</NEW 2.10>
================================
10) Checkpoint 4.1: Is access to very small fonts a P1
requirement?
================================
I think it's a P1 requirement to increase the text size (for
users with low vision). I don't think it's a P1 requirement to
shrink the text size to an arbitrarily small value. Gregory has
said in the past that very small fonts allow him to fit more
content on a page and reduce scrolling. But that's not a P1 issue
(that's more like a P3 issue). An analogy: checkpoint 4.4 only
requires slowing of presentations, not speeding up, which we did
not consider a P1 requirement.
--------
Proposal
--------
<OLD part of 4.1>
Allow the user to choose from among the full range of font sizes
supported by the operating environment.
</OLD part of 4.1>
<NEW part of 4.1>
Allow the user to choose from among the full range of font sizes
above 9 pixels supported by the operating environment.
</NEW part of 4.1>
================================
11) Checkpoint 4.9: Clarification that global volume control is for
content and user agent sounds.
================================
Checkpoint 4.9 starts:
"Allow global configuration and control of the volume of all
audio, with an option to override audio volumes specified by the
author or user agent defaults."
--------
Proposed
--------
The user agent may satisfy this requirement by providing a single
control over all sounds, whether they come from content or the
user interface. Distinct volume control for content as opposed to
UI is not required.
Clarify that the global system volume would satisfy this
checkpoint (a little stronger than the current Note).
================================
12) Checkpoint 4.10: P1 for non-style, P2 for style
================================
Checkpoint 4.10 reads:
"Allow independent control of the volumes of distinct audio
sources synchronized to play simultaneously."
--------
Proposed
--------
12a) For consistency with checkpoints 4.4 and 4.5, checkpoint 4.10
should include the following statement:
"The user agent is not required to satisfy this checkpoint for
audio whose recognized role is to create a purely stylistic
effect."
12b) There should be a new P2 checkpoint for volume control
of other audio content.
================================
13) Checkpoint 6.4: Not always obvious to distinguish access
from a Web page from plug-in access.
================================
Tantek had the same reaction as the AOL reviewers [4] that 6.4 as
written may pose some security risks (write access to all user
interface controls). I suggested that access for plug-ins should
be provided, but not for authors (from Web pages). He said that
it's not always easy (or possible?) to distinguish the two,
notably in the javascript case. I don't know how to address this
one and need developer input.
[4]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0068
================================
14) Checkpoint 7.3: What if OS conventions are inferior to what
the user agent developer would implement?
================================
"What if I can do better than the standard or convention?" has
been a recurring comment on all of our checkpoints that involve
following conventions, including:
6.4, 6.5, 6.6: Standard APIs
7.1, 7.2, 7.3, 7.4: Operating environment conventions
There may be others as well (e.g., 8.1).
Jon commented on this in a recent email [5]:
"My main concern is that we want to reduce the reliance on
proprietary or special solutions for individual assistive
technologies, since this will make it harder for developers to
make their software accessible and a smaller number of
assistive technologies may be supported."
[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0070
The argument for conventions is predictability and
interoperability. Our checkpoint 7.3 is a Priority 2, since not
following conventions doesn't necessarily make access impossible.
I find compelling the AOL [4] suggestion that is consistent with
this that it's a P1 requirement to make it work, and a P2
requirement to follow standards and conventions.
I hope we will have further discussion on this topic so that we
can establish a consistent model in the document, and where there
are exceptions, we have rationale to back them up.
================================
15) Definition of "non-interactive element",
checkpoints 9.2 and 9.6
================================
Tantek did not like the definition of "disabled" element as any
element that is not enabled. This means that a paragraph of text,
which might never be enabled in any session, would be considered
a disabled element.
Instead, he proposed adding a definition of "non-interactive
element". Please consider this definition:
"A non-interactive element is piece of content that, by
specification, is not expected to be an enabled element in
any user session."
The definition of disabled element would become:
"A disabled element is an element that is not enabled
in the current user session but could be in some user
session."
Non-interactive elements might be enabled in some sessions
because of how the user agent chooses to handle them.
The following checkpoints would be changed accordingly:
<OLD 9.2>
The user agent may also include disabled elements in the
navigation order.
</OLD 9.2>
<NEW 9.2>
The user agent may also include disabled and non-interactive
elements in the navigation order.
</NEW 9.2>
<OLD 9.6>
The user agent must not include disabled elements in the
navigation order.
</OLD 9.6>
<NEW 9.6>
The user agent must not include disabled elements or
interactive elements in the navigation order.
</NEW 9.6>
================================
16) Checkpoint 9.5: Moving focus without triggering handlers
may be wrong.
================================
Tantek argued that:
a) If there are no focus handlers on a page, this is not necessary.
b) If there are no focus handlers on a page, not firing them
may break the page.
We did not discuss the technical feasibility, only whether it was
a good idea at all.
This functionality (like others in our document) does not
guarantee access, and it may even break some pages. Still, it may
enable access in some cases where access would not otherwise be
possible. Perhaps the best approach is to get more experience
with implementations of this checkpoint and see if it's actually
usage.
A good place to start is to design a test case where we think
that not firing an onfocus handler automatically would improve
access (in conjunction with the other checkpoints for manual
firing).
================================
17) Checkpoint 10.1: "Purpose of table" is vague.
================================
Tantek found the phrase "purpose of each table" to be too
vague. Perhaps we should add a parenthetical such as
"(e.g., as expressed in a summary or caption)".
================================
18) Checkpoint 10.3: What is relationship between black and
white, and color?
================================
This checkpoint reads:
"10.3 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."
What if the content is being rendered in black and white (or more
likely, different pieces of content are being rendered in
different shades of grey)? This checkpoint is designed so that
users with some color deficiencies can hope to distinguish
selection from focus, etc. by default. Can users with color
deficiencies distinguish black from grey? (Obviously, it would
be hard for anyone to distinguish two similar shades of grey. We
don't talk about "contrast" in any of the checkpoints, because we
don't have any requirements that rely on color by default.)
I don't know whether "greying out" disabled elements would be
considered a sufficient mechanism for distinguishing, for
example, "enabled" from "disabled" elements. Similarly, is a
"bold" font distinguishable from "regular" font?
--------
Proposal
--------
State explicitly in the Techniques document that "greying" alone
is considered an effect that relies on color.
Comment: I do not have the technical expertise to back up this
statement, since I'm not a color expert (or a low vision
expert). However, I think that this question reveals that our
requirements stop at "color" and don't get into issues of
contrast, saturation, hue, etc. Information at "The Lighthouse"
about color contrast [6] suggests, however, that the above
statement is on the right track. Here's a quote:
"Don't assume that the lightness you perceive will be the same
as the lightness perceived by people with color deficits. You
can generally assume that they will see less contrast between
colors than you will. If you lighten your light colors and
darken your dark colors, you will increase the visual
accessibility of your design."
[6] http://www.lighthouse.org/color_contrast.htm
=======================================================
19) Checkpoints 10.2, 10.4, 10.7: "Provide a mechanism",
what must be done through the UI?
=======================================================
Can the technique to satisfy these checkpoints be through a style
sheet? An initialization file? These are "mechanisms", even
though they do not directly involve the user interface.
The following paragraph from section 3.7 attempts to address
which requirements must be met through the UI and which don't
have to be:
"The user agent must satisfy all requirements involving user
interaction (both user input and output to the user) through
the user interface of the subject of the claim. This includes
not only the requirements that directly refer to to user
control, configuration, etc., but also requirements that
indirectly involve the user interface (e.g., system
conventions pertaining to the user interface)."
I am afraid that this paragraph might not be sufficient. For
instance, it should be possible to satisfy many of the
"configuration" requirements through configuration files (indeed,
checkpoint 11.5 makes a "profile" requirement so I hope that
these requirements can be satisfied through config files!).
--------
Proposal
--------
19a) Add the following statement after the paragraph of section
3.7:
"The user agent may satisfy the configuration requirements
of this document through configuration files (e.g.,
profiles). The user agent should (also) allow the user to
configure the user agent through the user interface."
19b) Add statements to checkpoints 10.2, 10.4, and
10.7 that since the "mechanisms" themselves
do not require user interaction, they can be implemented
however the developer chooses. But the interaction part
is subject to the paragraph from section 3.7.
=======================================================
20) Checkpoint 12.1: Should be relative priority
=======================================================
Tantek supports the relative priority solution to the priority of
this checkpoint.
=======================================================
21) Checkpoints 12.2, 12.4, 12.5: Definition of features
that benefit accessibility.
=======================================================
We need to harmonize what we intend by "features that benfit
accessibility."
The Note after 12.2 reads (12.5 is similar, 12.4 needs one too):
"For example, review the documentation or help system to
ensure that it includes information about the functions and
capabilities of the user agent that are required by WAI
Accessibility Guidelines, platform-specific accessibility
guidelines, etc."
In checkpoint 8.1 we state:
"The accessibility features of a specification are those
identified as such and those that satisfy all of the
requirements of the "Web Content Accessibility Guidelines 1.0"
[WCAG10]."
--------
Proposal
--------
21a) In checkpoint 8.1, change the statement to:
"For the purposes of this document, the accessibility features
of a specification are those identified as such and those that
enable the author to satisfy the requirements of the "Web
Content Accessibility Guidelines 1.0" [WCAG10], whatever the
priority."
Editorial: Should this read "and those" or "or those"?
21b) Harmonize the language of Guideline 12 Notes as follows:
"For the purposes of this document, features that benefit or
affect accessibility are:
1) The features of specifications (implemented to satisfy the
requirements of this document) that are identified as
accessibility features, and those that enable the author to
satisfy the requirements of the "Web Content Accessibility
Guidelines 1.0" [WCAG10], whatever the priority."
2) The features of the user agent that satisfy the
requirements of UAAG 1.0 and the requirements of operating
environment accessibility guidelines."
19c) I'd like to factor 21b into one Note (e.g., 12.2) then
cross-reference it from the other checkpoints in Guideline 12.
=======================================================
22) Checkpoint 12.5: "All changes" is too broad
=======================================================
Tantek argued that a developer may not be able to document some
changes (e.g., because the information is confidential or
proprietary), would probably not want to document all of them
(because they could very well be numerous), and might not be able
to determine readily (especially for low-level bug fixes) which
ones affect accessibility.
--------
Proposal
--------
22a) Change "all changes" to "important changes". This
allows some filtering, and probably requires no more
interpretation than "all changes" (i.e., it is no more vague
thatn 12.5 already is). This doesn't address the
problem of confidential information, but I don't think we
can do much about that. Instead, it allows developers to
satisfy the checkpoint by providing a reasonable list of
important changes.
22b) Make this checkpoint a Priority 3 checkpoint. [This part
of the proposal can be considered separately.] As a result
of issue 373 [7], we chose not to make this checkpoint a P1
checkpoint (since the full documentation is available, so having
the changes available separately is not a P1
requirement). However, I am not convinced that having the list
of changes available merits even priority 2.
[7] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#373
=======================================================
23) Is the glossary informative?
=======================================================
Tantek asked whether the glossary was informative. I don't think
it is. While some terms are clearly informative (e.g., "assistive
technology), others are clearly not just informative
(e.g,. "recognize", "content", "animation"). In fact, most of the
glossary entries probably include information that is important
for conformance (and thus cannot be considered non-normative).
The references section is split into normative and informative
references (DOM is normative since it must be implemented for XML
content).
--------
Proposal
--------
Add the following Note to the beginning of the glossary:
"This is a normative glossary, although some of the terms (or
parts of explanations of terms) do not affect conformance."
I don't think it's worth trying to identify the normative and
non-normative parts of the glossary. Or rather, it might be worth
it, but I don't want to do it right now.
=======================================================
24) Does "document source" include HTTP headers? What
is the relationship between content negotiation and
conditional content?
=======================================================
The definition of "document source" starts:
"In this document, the term "document source" refers to the
data that the user agent receives as the direct result of a
request for a Web resource (e.g., as the result of an HTTP/1.1
[RFC2616] "GET", or as the result of viewing a resource on the
local file system)."
According to this definition, HTTP headers are part of the
document source. But are they part of content?
The answer is no, not according to our document. We say that the
document object is generally derived from the document source
(and possibly the result of repair, etc.). The user agent is not
required to transfer all of the document source to content (i.e.,
the document object).
We say that content is the document object. And that conditional
content is content. Therefore, conditional content does not
include Web resources in other formats (content negotiation)
or languages (language negotiation) that the user agent could
access but has not due to the user's configuration.
--------
Proposal
--------
No change to the document.
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783
Received on Tuesday, 24 April 2001 18:38:21 UTC