Formal response to SVG WG third last call comments on UAAG
1.0

The UAWG would like to
thank the SVG WG for the time and effort they committed to
reviewing the User Agent Accessibility Guidelines 1.0 in last call.
The current document is the UAWG's formal response to those
comments. The UAWG decided at their
14 July 2001 teleconference to send these comments to the SVG WG
even though
issue 516 has not yet been resolved.

Note: The UAWG has produced several WG drafts
since the
9 April 2001 last call draft to account for other issues as well
as those raised by the SVG WG.
For continuity, the comments below refer to the 9 April 2001 draft
unless otherwise noted, in which case they refer to the
14 July
2001 draft.

Status of this Document

This document has not been reviewed by anyone and does not
represent consensus of the UAWG. This document was prepared by Ian
Jacobs for the UAWG.

UAAG 1.0 needs to do a better job of explaining the very
important concept of "
applicability". Many of the SVG WG concerns are addressed by
the idea that checkpoints don't apply if information cannot be
recognized from markup or the markup language does not enable
the required control or configuration. This applies to scripts,
background images, animated text, and other content for which UAAG
1.0 includes requirements.

UAAG 1.0 does not convey the conformance model effectively,
that some components may not be part of a conformance claim. For
instance, the SVG WG wrote:

There is the issue that in many scenarios there isn't a single
UA but instead multiple UAs which have to interoperate. Many
graphics and multimedia formats are commonly supported by browser
plugins. If a given UAAG checkpoint isn't working properly when a
plugin is invoked to view content, whose fault is it? For example,
what if an HTML browser is capable of keyboard navigation around an
HTML page, and an SVG plugin is capable of navigating around an SVG
page, but the HTML browser cannot navigate from the HTML browser
into this particular SVG plugin?

The answer to these questions and similar ones is: if it's part
of the subject of the claim, then it has to satisfy the
requirements of the document. "Fault" does not enter into the
discussion; if a plug-in or other component does not satisfy a
requirement, then the ensemble cannot conform. It doesn't matter to
the UAWG whose fault it is, only that a requirement has not been
met. If a browser vendor wishes to claim conformance when used with
a plug-in, then the vendor should ensure that the plug-in provides
the necessary accessibility.

UAAG 1.0 does not convey sufficiently well that the
requirements will not guarantee access for all combinations of
content and users. This means that some requirements may not make
content more accessible in some cases. However, this does not mean
that the requirements should not be included in the document, only
that the WAI accessibility model requires contributions from
authors as well as user agent developers. The UAAG 1.0 requirements
include configuration requirements so that when they don't work,
they can be turned off. This also means that the required
functionality (e.g., keyboard access, font family configuration,
etc.) is not imposed on all users, just available to all
users.

A.1 Checkpoint 2.4: Doesn't make sense for SMIL 2.0 timing

This checkpoint is unimplementable as written for language built
on the SMIL2 timing model. There is no way for a UA to be able to
tell whether user input is restricted to a finite time
interval.

There is no way that a UA can make up for content that isn't
structured to allow pausing. This checkpoint should be removed from
UAAG. This is a WCAG item only.

Response:

The "applicability" provision of UAAG 1.0 means that if a
specification does not allow the control that's being asked for,
then the UA doesn't have to satisfy the checkpoint. So if SMIL 2
simply doesn't allow this technically, then it is not
required by UAAG 1.0.

The UAWG expects that this checkpoint will only apply in the
SVG case to animations where the user agent can determine in
advance the definite end times of intervals for user input. The
user agent should be able to insert a flag to pause (i.e., stop the
animation clock) at that time.

What does it mean to structure content to allow pausing? If the
content is structured to allow pausing, then the UA is required to
do so per checkpoint 2.1. If not, then it's precisely the
accessibility problem we are trying to address. It is not an author
error to specify a finite time interval for interaction.
It is nonetheless an issue for some user agents that the user agent
must assist in solving.

A.2 Checkpoints 4.4/4.5: Complicated for nested time
containers

For checkpoints 4.4 and 4.5, the SVG WG wrote:

This checkpoint talks about controlling particular animations on
an individual basis. This is not practical with SMIL and SVG as
this goes against the basic data models inherent in the languages.
In SMIL and SVG (and QuickTime), there are time containers which
are masters over time-based content such as individual animations.
The time container is the master that drives the animation as a
slave. The animation just responds to commands such as "update
yourself to what you should look like X.Y seconds into the
animation". The only thing that is reasonable is to allow the
ability to pause, accelerate or decelerate the time containers.
However, if you have nested time containers, things can still get
very complicated as the nested time containers themselves are just
slaves to their parent time containers. Selecting these nested time
containers would require extensive user interface work on the part
of UA developers which would represent large amounts of work just
to support this checkpoint.

Response:

The SVG WG seems to agree that the desired control is possible
for SMIL and SVG, when time containers are controlled. That's good
news, and confirms previous comments to this effect from
Aaron Cohen and
Patrick Schmitz.

The UAWG believes that this
Refer to discussion at the
28 June teleconference. There seems to be agreement that in the
case of nested time containers, it is sufficient for the user agent
to provide control of a parent time container when the parent
controls the timing of its descendents. Thus, while all animations
must be controllable, when content is synchronized, control of the
"master" element suffices.

A.3 Conformance icons

The SVG WG believes that conformance icons are "likely to be a
lightning rod for disputes due to the extraordinary complexity in
making claims and in determining whether the claims are valid."

The SVG WG accurately noted that UAAG 1.0 does not address the
question of who verifies that a claim is valid?

Response:

WAI and W3C do not currently verify conformance claims for any
W3C specifications. A Quality Assurance Activity is in development
that is likely to address this issue.

Like other W3C WGs, the UAWG will do all it can to provide test
suites and other supporting material to facilitate assessments of
conformance.

Due to the large number of XML-based grammars being produced by
the W3C it is unrealistic for a User Agent to expect that the W3C
User Agent group will write a verification tool for every
renderable XML grammar.

The SVG WG wrote:

The SVG group's overall opinion is that conformance icons only
make sense in two main scenarios:

The icon only means that claims have been made. Instead of
loose language about the need for retraction if "it may be
demonstrated", just say that it is expected that UA developers
would retract the icon if they can no longer make conformance
claims

The icon actually means some real verification has occurred. In
the general case, there are two viable ways to verify conformance
claims:

(a) when there is an automated tool to verify conformance (e.g.,
the HTML validator) or

(b) there is a certifying organization in place.

In the case of UAAG, (2a) is impossible because the UAAG covers
an application (which has an infinite number of operating
scenarios, usually dependencies on particular configurations and
infinite numbers of potential inputs) and not a file format and
(2b) will not happen before UAAG become a Recommendation.
Therefore, the SVG group recommends either that the whole notion of
UAAG icons get dropped or that scenario (1) is used.

We want to point out that (1) seems more useful in a WCAG
scenario than a UAAG scenario. With WCAG, a site could put a WCAG
icon on their home page where it can be seen by all. In the case of
user agents, sometimes the agent needs to render content
unobtrusively, such as a browser plugin which is supposed to render
some content potentially without the user being aware that the
plugin was invoked, in which case there may not be a place for the
icon to appear.

If (1) is pursued, we suggest that the UAAG say that the icons
SHOULD be hyperlinked to the claims.

Response:

At their
28 June teleconference, the UAWG resolved that conformance
icons should only represent unverified claims. This is consistent
with both the suggestions of the SVG WG and the UAWG's
expectations.

The ability to turn off JavaScript is already available in many
browsers, so turning scripting on and off is a reasonable request.
However, providing an option to alert the user about scripts being
available on particular content seems like it this might be an
unreasonable burden on the UA in many cases. In SVG, the entire
document would have to be analyzed to look for all <script>
elements and all event attributes (e.g., "onactivate="). Given XML
namespaces, it is possible that scripting might be present packaged
in another namespace but the SVG user agent might not be able to
detect it.

Thus, there is significant cost. How much accessibility benefit?
We are dubious that this checkpoint would actually prove useful.
The reliability of the checks and the potential large number of
generated messages might make this a feature which is hardly used.
This should be demoted to a Priority 2, at best.

Response:

Clarification: the alert requirement is a single alert
indicating that one or more scripts / event handlers is present
somewhere in content. A number of developers have stated that the
implementation burden for this is very low (e.g., in the HTML DOM,
a single API call will return a set of SCRIPT elements). There
doesn't seem to be a technical reason why such a query of the
content would be impossible or costly in the case of SVG.

For the part about scripts in other xml namespaces, if they are
not recognized as scripts, the user agent is not required to
satisfy the checkpoint for them.

Scripts may cause effects that disorient the user, cause
problems with assistive technologies, etc. However, since many
scripts are useful, and may even benefit accessibility, users must
know when they are present so they can choose to reactivate them.
This is the rationale behind the alert requirement.

B.2 Checkpoint 4.2: Control of font families burdensome in
SVG

For checkpoint 4.2, the SVG WG wrote:

This is a feature that makes the UA start looking like an
authoring tool. This facility can already be achieved via user
agent style sheets for text-oriented content like HTML. For
graphics such as SVG, fonts are one of the more complicated parts
of the code. Changing the font may make the content inaccessible
due to missing glyphs, puts a huge implementation burden, and often
will result in unreadable documents because reformatting is often
necessary and SVG doesn't have the notion of text formatting. This
checkpoint should be removed or at least demoted to a Priority 2,
at best, or at least explain that it applies only to markup
languages with the ability to reformat text content.

Response:

It is not clear why a global font-family requirement is any
more difficult for SVG than for HTML or CSS. Dean Jackson claims to
have already implemented this for SVG and considers that it is not
burdensome. Apache Batik has a CSS2 DOM API implementation that we
understand allows for configuration of font families.

Like the UAWG, it would seem that the SVG WG does not want
authors to draw pictures of letters using splines, etc. but rather
to render real characters (from the document character set)
visually using fonts. Given the SVG/CSS model where an ordered list
of fonts is used to represent character data, it is not clear why
the user's preferred font could not appear first in the
cascade.

This checkpoint does not require reflow.

If a format forbids the user from changing font families, then
increased coordination with WAI PF is required.

B.3 Checkpoint 6.5: Alert of changes to UI burdensome

For checkpoint 6.5, the SVG WG wrote:

This one is even worse than 6.3 and 6.4. Here, the UA needs to
send notifications to external tools whenever anything happens,
whether it is changes to the Infoset or the state of the UA itself.
UAs that support DOM might be in a reasonable position to allow
external tools to manipulate the DOM. However, almost no UAs will
have logic to support notification to external tools when UI state
changes. This checkpoint would prove to be a large implementation
burden in support of the case where an external tool might exist
that might be interested in such information. The SVG group
recommends that this checkpoint be removed entirely.

Response:

Programmatic alerts to changes in the user interface are
required for users who do not make use of the native user interface
and who rely on interfaces provided by assistive technologies.

Different widely deployed APIs provide for this functionality
for UI controls (e.g., MSAA and Java Accessibility). These APIs
include information about changes to focus and selection (e.g.,
refer to information about WinEvents
in MSAA).

Note that animation is not a change to content (i.e., the DOM),
only to presentation. This checkpoint does not require alert of
changes to presentation, only content. Refer to
proposed clarification.

This checkpoint should say "text-only" links. CSS already has
facilities for styling text links. Note that links on top of images
or links within SVG graphics are not easy to highlight.

Response:

This requirement is not limited to text links because users
must also know about links with non-text content (e.g., images).
Most graphical browsers today highlight images in links via an
outline rectangle.

The UAAG 1.0 does not make requirements that the user agent's
selection include images as well as text. Thus, if the SVG
specification only requires a text selection for cut and paste
operations, then that selection mechanism is subject to the UAAG
requirements. The UAAG needs to clarify this point: for focus and
selection, developers should follow specifications first, then
compare with the requirements of UAAG 1.0. This would be consistent
with our content requirements.

The "image map" exception provision was designed for HTML image
maps. Refer to a
proposal to fix this provision so that it distinguishes
monolithic images from images composed of independent objects.

C.1. Too many Priority 1 checkpoints

In global comment 1, the SVG WG wrote:

We ask that the WAI-UA team consider a new priority level which
corresponds to "really, really important" and which contains a
restricted subset of the existing priority 1 checkpoints. For
example, the SVG group sees checkpoint 1.1 as "really, really
important", more so than the majority of the other priority 1
checkpoints. We think the WAI-UA team would agree that if everyone
only supported checkpoint 1.1, then there would be huge
accessibility gains. The SVG group does not believe that the lowest
defined conformance level must address every accessibility problem
and every accessibility constituency.

Response:

Addressing the last sentence first: The UAWG is chartered to
address cross-disability concerns and not to
isolate solutions for specific disabilities. From the section on deliverables:
"The UAAG 1.0 must address cross-disability considerations, be
consensus-based, technically sound, and reflect the most current
technology." It would be inappropriate, therefore, to design
guidelines that exclude some groups of users at a P1 level. Not
every checkpoint will benefit every user, but the sum of the
checkpoints is expected to benefit many users with disabilities.
For additional rationale about disabilities requirements, the UAWG
will add a reference to a document published by the WAI that
explains how people with disabilities use the Web.

About the number of requirements: The UAWG could either:

Reduce the number of P1 requirements. Should the WG simply
remove some checkpoints? I think that the argument "the spec is too
large" is not a persuasive one, though the UAWG is sensitive to the
burden of implementing some checkpoints (and the burden on
developers of assistive technologies when browser developers do not
implement accessibility features). The UAWG does not think that
implementability should be of primary concern when first
establishing requirements for meeting the needs of users with
disabilities, and proposing guidelines to satisfy those
requirements. As other WGs do, the UAWG will dedicate its Candidate
Recommendation period to demonstrating implementability. The UAWG
does not agree that the cost of implementation should be a
determining factor in the development of these guidelines.

Increasing the conformance "granularity". Conformance
granularity has been one of the most debated topics in the UAWG's
nearly four-year history. The current conformance scheme is already
quite complex, and has been designed to establish an equilibrium
between (1) ease of making and reading conformance claims and (2)
the diversity of user agents that we would like to be able to
conform to the document. Our many mechanisms that allow the
developer to reduce the number of checkpoints they must satisfy
include common sense exemptions ("applicability"), exemptions for
particular content types or input devices, and three conformance
levels (the same for other WAI Guidelines). Establishing a fourth
conformance level ("Really important Priority 1") would not add
substantially to the existing granularity.

Changing the priority of checkpoints is very difficult to do
based on (1) the definition of priority and (2) the substantial
amount of time the UAWG has already dedicated to establishing the
current priorities and priority system.

Even if developers cannot satisfy enough requirements to
conform, we encourage them to publicize which checkpoints they do
satisfy so that users with disabilities know what they can expect
in terms of accessibility support from a non-conforming product. We
expect that developers will gradually implement more accessibility
features, and that developers will prioritize checkpoints in
different ways depending on their own goals.

C.2. The UAAG 1.0 does not require the implementation of a
style sheet language.

In global comment 1, the SVG WG wrote:

Another favorite accessibility feature with the SVG group are
support for user agent style sheets and user style sheets. We
couldn't find a checkpoint that explicitly calls on support for
these particular features. Only the vaguely indirect "you must
support the accessibility features in supported specifications." It
would be good to point out user agent style sheets and user style
sheets explicitly.

Response:

The UAWG likes style sheets, too. However, a user agent can
provide access to the Web even though it doesn't support a style
sheet language. Style sheets are mostly interesting for
accessibility when the user can override the user agent default and
author supplied styles; style sheets benefit authors and all users
for other reasons (ease of management and authoring, faster
downloads, caching, reuse, etc.). The user override capability can
be provided independent of a style sheet language however, and
therefore, a requirement to implement style sheets does not pass
the priority 1 definition test.

The user override requirements are distributed in the rest of
the checkpoints. If the requirements are met through style sheets
where user control is part of the cascade, that's great.

Checkpoint 4.16 requires that when a style sheet language is
implemented, that user be able to choose from and apply user style
sheets. The assumption of that checkpoint is that user override is
built into the specification.

This checkpoint requires that UA provide an option to apply or
ignore user style sheets. This is second order control when first
order is sufficient. Just providing users with the ability to
define and control user style sheets is sufficient flexibility. The
SVG group recommends that this checkpoint be removed entirely.

Response:

Does this comment mean that as long as the user can edit a
single user style sheet (and delete all user rules, for example)
that this would suffice to meet the accessibility need? This would
mean that users might have to edit style sheets on a per-document
basis, making browsing extremely impractical. Hence the requirement
for a single switch: apply/don't apply.

Checkpoint 4.16 does not require that UAs support more than on
user style sheet, but a user agent might allow a user to select
from several available user style sheets.

CSS1 and CSS2 do not require that user agents support user
style sheets. Thus, while user style sheets are very important to
accessibility when style sheets are implemented, if the user agent
doesn't allow the user to specify user style sheets, there is no
accessibility benefit. Checkpoint 4.16 says: If you support style
sheets, you must allow the user to choose from and apply user style
sheets.

Similarly, the author may specify alternative style sheets to
provide accessible style alternatives (e.g., a large font version).
If the user cannot choose from among them, they are useless.

The SVG WG also wrote about checkpoint 10.2:

The ability to configure the highlight styles is already
available via CSS. Adding additional facilities beyond this is
overkill. We recommend removing this checkpoint entirely or lower
to priority 2 as this is moving in the direction of making a UA
into an authoring tool.

Response:

This is a functional requirement that may be satisfied by
implementing CSS, but CSS is not required.

C.3. The UAAG 1.0 requirements do not make sense for all
formats or types of user agents.

In global comment 3, the SVG WG wrote:

The specification seems to have taken specific cases and
situations (HTML commonly) and attempted to generalize to more
media types. The checkpoints are described generically, which leads
to various ambiguities about how a particular checkpoint might
relate to a particular language like SVG. The Techniques document
attempts to address some of these issues, but it is impractical for
the Techniques document to continually expand to include
supplemental notes for each checkpoint on XHTML 1.0, XHTML Basic,
XHTML 1.1, SMIL, SMIL Basic, SVG, MathML2, XForms -- the list goes
on. We suggest getting a core of truly general check points and
then coming up with specific check points for each media type
and/or W3C technology.

Response:

The UAAG 1.0, like other WAI Guidelines before it, is
technology-independent. As a result, some interpretation of what
each requirement means for a specific markup language will
always be necessary. The Techniques Document does provide
information to that end, and the UAWG has discussed developing test
suites to further clarify the binding between the abstract
checkpoints and some known technologies. In this regard, the UAWG
recognizes the value of the SVG WG's contributions for SVG.

It is also the nature of UAAG 1.0 that some requirements are
more "markup language-inspired" than others. Should the UAWG
categorize the checkpoints into "For HTML only", "For SVG only",
etc.? The UAWG believes that this would be unwise for a number of
reasons, the principal one being that UAWG cannot predict how
software developers will write software or combine software.
Consequently, the UAAG 1.0 has been designed intentionally to
include requirements for a variety of types of user agents, and to
allow claimants to choose (within well-defined bounds) which
requirements they wish to meet in order to conform.

The UAWG has discussed including informative profiles
in the Techniques document that would give developers a head-start
on which checkpoints are considered the most relevant for some
common types of software. However, developers should consider the
applicability of all the checkpoints as their
applicability is likely to vary widely from user agent to user
agent in ways the UAWG cannot predict.

Consider HTML tables: checkpoint 10.1 is clearly inspired by
HTML tables. Now there is a table module in XHTML
Modularization, so it's even more likely that you will find
tables in markup languages other than HTML 4.0 or XHTML 1.0.

As new format specifications are developed by W3C, the UAWG
hopes to coordinate with each W3C Working Group the "application"
of UAAG 1.0 requirements to these format specifications.

The SVG WG also wrote:

Regarding the UAAG spec, we suggest that the UAAG include a
statement indicating that some W3C working groups are encouraged
provide supplemental documents which describe how the UAAG apply to
particular W3C technologies.

Response:

This is a reasonable statement to include, although more
valuable still is actual coordination between the WGs as has been
undertaken here.

C.4. W3C specifications should not require implementation of
operating environment features for conformance

In global comment 5, and about checkpoints 6.4, 6.6, 6.7, and
7.1 the SVG WG wrote:

The SVG group feels strongly that requiring the use of platform
facilities cannot be required by any W3C specification. While we
agree that in many cases this is exactly what UAs should do, we
disagree strongly with the many statements in the UAAG draft that
state or imply that UAs must use operating environment standard
libraries and observe operating environment conventions in order to
be compliant.

then:

Bottom line: the UAAG should specify the "what" (i.e., the
accessibility features that need to be made available) and stay
away from the "how" (i.e., how software vendors write their tools
in order to provide the "what").

Response:

The UAAG 1.0 does not require the
implementation of operating environment (OE)
specific APIs in order to conform. This has been clarified /
emphasized in the 14 July
2001 draft.

Our OE requirements are important for interoperability with
assistive technologies in the real world. At a P1 level, UAAG 1.0
requires developers to follow operating environment conventions for
focus and selection (due to the importance for communication with
assistive technologies) and for input device configurations (e.g.,
because keyboard access is so important). Otherwise, the UAAG 1.0
only requires adherence to operating environment conventions at a
P2 level. Unlike most other W3C technical reports, UAAG 1.0 deals
with specifics about the user interface and the user's working
environment. For instance, consistency in the user interface is an
accessibility issue (e.g., for users with cognitive disabilities),
consistency with operating environment keyboard bindings is an
accessibility issue, etc. It is possible to conform to UAAG 1.0
without following operating environment conventions, but if the
user agent does not adhere to them at all, the disconnect from the
user's expectations about their working environment will cause
important accessibility barriers for some users. The reality today
is that many users require assistive technologies for access to the
Web, and consequently, UAAG 1.0 must promote communication between
conforming user agents and assistive technologies. Part of this
communication involves the operating environment in which browsers,
multimedia players, and assistive technologies run.

We have tried to be as OE-independent as we can, so we are very
aware of the issue.

Java-based SVG viewers can support the Java Accessibility
API.

C.5 UAAG 1.0 too hard to implement.

In global comment 6, the SVG WG wrote:

We believe there is a large implementation burden in satisfying
the many UAAG requirements. Even for Conformance Level A, the many
checkpoints will require large resource investments and processing
capabilities to achieve compliance. There is considerable concern
in the SVG group that even Conformance Level A is, from a practical
sense, unimplementable across the range of platforms that will be
common at the time UAAG are likely to become a W3C
Recommendation.

[and later on]

The SVG group has already recommended in GLOBAL COMMENT 1 that
there be many fewer priority 1 checkpoints. We also think the UAAG
needs to be reviewed against the implementation burden that the
checkpoints put on UA developers in terms of cost/benefit analysis.
Any checkpoints where the implementation cost is high and the
accessibility benefit is low-to-moderate should not be priority
1.

Response:

There is already substantial evidence that most of UAAG 1.0
requirements have been implemented by some user agents, or at least
implemented imperfectly (as with many specifications). Our
responsibility during CR is to show implementation of each
feature.

The SVG WG also wrote:

Which leads to a major question about the UAAG: what class of
devices is this specification supposed to address. Ian has told
some of us informally that the UAAG 1.0 are only meant to address
desktop devices. But in reading the UAAG draft literally, the
specification says "a mainstream user agent is one designed for the
general public to handle general-purpose content in ordinary
operation conditions". The SVG group feels that PDAs and cell
phones fall clearly into the definition of mainstream user agent.
We also want to point out that this year's PDA will have the same
processing power as the high-end standard desktop device of a few
years ago and that there is a continuum of devices from laptops
with huge screens, laptops with medium screens, notebooks,
notepads, eBook readers, PDAs with keyboards and PDAs with only
pointers. Compaq is selling PocketPCs, cell phone vendors are
adding PDA features, and PDA vendors are adding telephony. There is
no line that can be drawn.

Response:

The UAWG agrees that "mainstream" should be replaced by wording
that more clearly expresses expected device capabilities.
Section 1.4 of the 14 July 2001 draft states more clearly the
expected operating environment conditions.

The UAWG does not intend this document to apply to user agents
running on PDAs. The UAWG has drawn a line in practical terms by
imposing requirements that are not likely to be implemented by user
agents on small devices. And of course, UAAG 1.0 does not forbid
conformance by any combination of software components, so when
handheld devices do become more powerful (and assistive
technologies run on them as well as user agents), conformance
should be encouraged for software on these devices.

The SVG WG also wrote:

If the UAAG 1.0 is indeed only meant to address "desktop
devices", then the specification should say so directly. However,
the SVG group thinks it is inadvisable to totally ignore the new
classes of devices. There should be some amount of forward looking
before UAAG 1.0 goes to further stages.

One forward-looking option to consider is to add mobile device
notes in the Techniques document for each of the checkpoints. This
exercise will force the WAI-UA team to at least take a single pass
through the checkpoints to see how they might relate to the
wireless world. A fear which the SVG group has is that NOT
considering mobile devices with UAAG 1.0 might put the UAAG effort
in a bad situation if it turns out that major organizational
changes are needed to address mobile devices. We don't want UAAG
2.0 to have radically different organization and radically
different checkpoints that UAAG 1.0.

[further down]

If UAAG 1.0 is meant to cover all ranges of devices from desktop
to mobile, the SVG group recommends that the WAI-UA team consider
that the exit criteria from Candidate Recommendation for the UAAG
include the requirement that there is sufficient evidence that the
UAAG Conformance Level A is implementable on browsing-enabled,
low-end cell phones supporting limited text/image browsing (e.g.,
XHTML Basic) and limited animated graphics or multimedia (e.g.,
mobile profiles of SVG or SMIL).

Response:

The UAWG has explicitly chosen not to include requirements for
small devices. Therefore, our CR exit conditions will not likely
include documentation of implementation on small devices.

The UAWG should not design UAAG 2.0 before it has finished
UAAG. 1.0. Currently, we are not chartered to consider requirements
for UAAG 2.0.

The SVG WG also wrote:

Another option which was proposed was that if UAAG 1.0 could
described as being targeted at particular classes of language
specifications rather than particular classes of devices, whereas
some future UAAG-Basic specification might address other classes of
specification. Thus, UAAG might be appropriate to UAs that
implement the full languages XHTML, SMIL and SVG, whereas
UAAG-Basic might be appropriate for XHTML-Basic, SMIL-Basic and
SVG-Basic.

Response:

That makes sense as an informative comment about who is
expected to use this document, but would not change the
conformance requirements, for example.

It is not clear why UAAG-basic would exclude table requirements
just because XHTML Basic does. It's not obvious how UAAG 1.0 would
be designed to satisfy all of the modularization possibilities of
all other specifications that W3C will produce in the future. UAAG
1.0 is not for HTML/XHTML/SMIL/SVG alone.

While we agree with the overall intent of this checkpoint, we
believe some softening of the wording is appropriate here. Here is
a case which we worry about. Most SVG UAs allow for the pointer to
be used to drag out a zoom region or to drag out text selection.
These and other facilities are great conveniences for certain
classes of users. Some of the user interfaces conveniences just
cannot be provided in a reasonable manner without the user of a
pointer device. Perhaps the checkpoint could say "Ensure that the
user can have full access to the content through keyboard input
alone" or just remove the word "fully" from the original
wording.

Response:

UAAG 1.0 does not require user agents to abandon the pointing
device, only to make available the same functionalities through the
keyboard as well. The pointing device is clearly the preferred
input device for many users and many operations, but without
keyboard support, some users will not have access.

There is an interesting distinction that the UAWG will clarify
in the checkpoint:

Some users cannot rely on two-dimensional output for the input
device they are using (e.g., users with blindness). Therefore,
direct access (namely, keyboard shortcuts) is crucial to
accessibility, and the user should not be required to manipulate
the user interface by moving the pointing device through
space.

Some users can rely on two-dimensional output for their input
device, but still can't use the mouse. In this, case, keyboard
access is still important (e.g., using arrows to move the pointing
device).

Support through a keyboard API is important for users with
specialized input devices.

Checkpoint 1.1 does not distinguish points 1 and 2: Checkpoint
1.1 does not require that all functionalities be
available through keyboard shortcuts.

Someone who is blind may not be able to use a mouse, but the
converse is not true. E.g., someone with a physical disability may
not be able to use a mouse, but have perfect vision. This is a
cross-disability requirement.

In resolving its
issue 514, the UAWG decided that the requirement of checkpoint
1.1 was not that the user interface controls be keyboard
accessible, but that the functionalities they enabled be keyboard
accessible. In the 14 July 2001 draft,
checkpoint 1.1 has been edited to read:

"Ensure that the user can operate through keyboard input alone
any user agent functionality available through the user interface."
[The Note after the checkpoint makes additional remarks.]

Keyboard-driven selection is an inherent part of emacs (for
example) and is possible in some browsers (e.g., IE 5 for Windows
under certain conditions; see the 'content-editable' attribute that
is proprietary to MS).

C.7 Checkpoint 2.3 requires more for users with disabilities
than users without

For checkpoint 2.3, the SVG WG wrote:

This checkpoint as written provides more information via
accessibility than is available to normal users. In SMIL and SVG,
there is a test condition on system language. Only the content
corresponding to the user's language is presented. Why is it that a
French user using accessibility facilities must be allowed to
access the German text when other French users don't get access to
the German text?

Response:

In an ideal world, each specification would ensure the
necessary amount of accessibility. Since specifications do not, in
general, do so (notably in the absence of guidelines for doing so),
it should be expected that UAAG 1.0 will require more than what
some specifications offer themselves. Nonetheless, the UAWG has
been very cautious to say "Follow specifications first. If you
can't satisfy our requirements by doing so, do so as follows..."
Curb cuts and ramps in the physical world are extra requirements
beyond standard building regulations. Building codes do not suggest
that builders ignore other standards, only that they add pieces
that complete the accessibility picture. This is how UAAG 1.0 has
been designed. "Equal facilitation" may be used in regulatory
contexts to describe this.

The UAWG has been very cautious to limit its requirements to
accessibility requirements. Requirements that affect all users
uniformly are not part of UAAG 1.0, even if they would benefit
users with disabilities.

It is a fundamental principle of accessible user agent design
that the user have the final say over style and access to content.
UAAG 1.0 does not require infinite and arbitrary control in the
promotion of user control, however.

Here is an example scenario where a user with a disability
might want content in two languages: A native French speaker who
also reads German is watching a German film that has auditory
descriptions and captions in multiple languages (including in
German and French). The user has low vision and poor hearing.
Because the video may be enlarged significantly, and the user may
miss portions of the video track, the user may wish to listen to
auditory descriptions in French; this is the user's native language
and they want the facility of listening to French content. The
individual wishes to listen to the German sound track (which is
better than the dubbed version) and requires the German captions to
compensate for poor hearing.

Another example: a native German speaker who wishes to learn
French may very well wish to listen to the French audio track and
read German subtitles. This is a disability-independent scenario
but indicates that in general, flexibility in the selection of
conditional content is desirable.

The SVG WG also wrote:

The checkpoint description is ambiguous to the point of being
meaningless. What does "close relationship" mean? How can
conformance claims be made against this checkpoint?

Response:

This has been fixed in the 14 July 2001 draft.
Checkpoint 2.3 now reads (more specifically):

"When a specification does not explain how to provide access to
this content, do so as follows: If C is a summary, title,
alternative, description, or expansion of another piece of content
D..."

The SVG WG also wrote:

The SVG group believes that this checkpoint will add
unjustifiable major cost to SVG UA developers. The relatively
simple <switch> statement in SMIL and SVG might end up
becoming one of the more complicated features to implement. In many
cases, the test conditions are there to determine if particular
content is actually renderable. For example, SVG has tests
'requiredFeatures' and 'requiredExtensions'. If these tests
evaluate to false, then that means the UA cannot render that
content and then code needs to be written to determine "closeness",
to find "placeholders", to allow users to query elements for
attributes, and to find and follow any links.

In many languages, rendering conditional content will make the
document LESS accessible. In SVG and SMIL, the various alternatives
for conditional content typically gets rendered at the same place.
With SVG support for transparency, the various pieces will all
blend together, making none of them discernible.

Response:

Checkpoint 2.3 does not require that user
agents render conditional content in the same viewport or at the
same time as other content. Multiple views and viewports may be
used, and probably should be used in many cases.

The SVG WG also wrote:

Maybe we just don't understand what exact accessibility problem
this item is trying to solve. We'd appreciate more details on the
problem the checkpoint is attempting to address.

Response:

To satisfy WCAG 1.0, authors may provide equivalent content
available to ears, eyes, or fingers. This content may not be
rendered by default, and UAAG 1.0 requires that user agents provide
access to it.

C.8 Checkpoint 4.9: Anything besides on/off audio not
necessary

For checkpoint 4.9, the SVG WG wrote:

This checkpoint is either ambiguously worded or unnecessary or
both. We assume that volume control is meant to apply to user
agents that allow the playing of audio content such as you have
with SMIL or audio-enhanced SVG. But we aren't sure what "volume
control" means. Does it just mean the ability to turn audio off
(i.e., mute) or does it mean there must be a control equivalent to
a volume slider? We can understand the need for certain classes of
multimedia-capable UAs to turn off any content audio, but we think
anything other than an on/off feature is asking too much for a
priority 1 checkpoint. We also wonder whether the ability to mute
the sound might be better solved via a user agent style sheet or a
user style sheet.

Response:

Volume control via a style sheet is a sufficient but not
necessary technique.

This checkpoint requires more than on/off control for users who
are hard of hearing and need to raise the volume of content.

C.9 Checkpoints 6.1 and 6.2: DOM shouldn't be required for UAs
that don't support scripting.

For checkpoints 6.1 and 6.2, the SVG WG wrote:

This indicates that you must implement the DOM to be compliant,
but in many cases you can be compliant with a W3C spec without
supporting scripting. At a minimum, this guideline must be
qualified to say "for UAs that support the DOM"

Response:

UAAG 1.0 requires implementation of the DOM not for support of
scripting but as a platform-independent interface for communicating
information about content to assistive technologies.

This checkpoint requires something which is defined ambiguously
-- use the operating environment or maybe support some "standard
API", whatever that might be. The noble goal here is to provide
hooks such that certain classes of accessibility tools might be in
a position to hook in to the UA APIs. But there are many scenarios
when there is no such need for accessibility tools to hook in. The
UA itself might provide all necessary accessibility features.
Requiring UAs to provide such programmatic access when in many
cases the accessibility needs might be met in other ways cannot be
justified.

The real requirement is that the UA interoperate with assistive
technologies. That is the "what". This checkpoint is legislating
the "how".

Response:

These checkpoints have been clarified substantially as a result
of other last call comments. The following has been clarified:

To satisfy the API communication requirements, the user agent
must first use either a W3C Recommendation or an API designed for
interoperability with ATs. This is essentially what the SVG WG has
suggested.

Because such APIs may be broken or incomplete, or no
appropriate API may exist on the platform or cross-platform, the
next API (or set of APIs) "cascade" is an API that is publicly
documented.

The UAWG has deleted the term "standard API" from the
document.

C.11 Checkpoint 6.10 is too vague ("timely access")

For checkpoint, the SVG WG wrote:

This checkpoint is so vague as to be unuseful. From a standards
perspective, this one seems to be just useless handwaving. How does
one quantify "timely manner". Who is going to implement an API
which isn't meant to support programmatic exchanges in a timely
manner? The SVG group recommends that this checkpoint be removed
entirely.

Response:

The UAWG acknowledges that this the only performance
requirement in the document; the others are functional
requirements.

This checkpoint has long been debated because it is
acknowledged to be difficult to verify. Nonetheless, we have
received substantial input from assistive technology developers
stating that, unless communication takes place at a reasonable
speed, the user will be more confused than assisted.

The UAWG has included a large section in the techniques
document that explains how to load an assistive technology in
process. This is considered to be the best way to address this
checkpoint, though it is not the only way possible.

C.12 Is checkpoint 2.1 only about conformance to
standards?

For checkpoint 2.1, the SVG WG wrote:

Doesn't this one just say that the UA needs to be conformant to
the standard it supports? The current wording is confusing

"Render content according to specification. When a rendering
requirement of another specification contradicts a requirement of
the current document, the user agent may disregard the rendering
requirement of the other specification and still satisfy this
checkpoint. "

This is slightly different than the previous version (and
simpler)

This checkpoint is necessary for "enforcement" of WCAG 1.0. If
the user agents don't implement the features, authors won't use
those features.

UAAG 1.0 considers that proper implementation of specifications
is an accessibility issue for at least the
following reasons:

Fewer people need to make adjustments when specs are
implemented correctly. This follows the general accessibility
principle: "first, do no harm."

Specifications include accessibility features.

Poor implementations make life more difficult for developers of
assistive technologies.

C.13 Checkpoint 2.9: Doesn't make sense to render all content
at the same time.

For checkpoint 2.9, the SVG WG wrote:

We don't believe that it makes sense to ever render all content
at the same time.

Response:

In the 14 July draft,
checkpoint 2.9 has been modified to make clear that the
requirement is not that all content be rendered at the same time in
the same viewport.

C.14 Checkpoint 3.1 only applies for formats that distinguish
fg and bg

For checkpoint 3.1, the SVG WG wrote:

We suggest that this checkpoint only applies to language which
have a clearly distinct notion of background and foreground, such
as content styled with CSS which supports the 'background-image'
property. Note that there is a bullet in section 1.3 that talks
about this checkpoint. Why have the bullet at all? Wouldn't it be
better to just include the bullet text right there inside this
checkpoint?

Response:

The UAWG agrees that this checkpoint only applies in the
situation cited by the SVG WG, and believes that the checkpoint
says as much.

The information in section 1.3 of the document is about
limitations of UAAG 1.0 and is a summary of information found
elsewhere in the document as well.

C.15 Checkpoint 3.2 requires burdensome placeholder
requirement

For checkpoint 3.2, the SVG WG wrote:

Good software engineering attempts to separate UI logic as much
as possible from the code which implements the functionality
underneath that logic. This item attempts to put UI code where you
don't want it.

The requirement that for an option for a placeholder is too
burdensome on UAs. In some cases, significantly more code will be
necessary to render the placeholder than to implement the original
functionality. If audio is added to SVG, there is a significant
question of where the placeholder should be rendered. The SVG
canvas is infinite and scalable. Any choice for where the
placeholder might be would make the placeholder potentially
invisible. Placeholders for animations are problematic since motion
animations cause object locations to change over time. Having the
placeholder rendered as an overlay on the viewport will require a
code path which doesn't need to be supported currently by UAs. The
requirement to display both the original content and the
placeholder is even more objectionable. The SVG group recommends
that this checkpoint be removed or dropped down to priority 3 or
2.

Response:

In the 14 July 2001 draft, the checkpoints of guideline 3,
including
checkpoint 3.2, have been harmonized with
checkpoint 2.3. In particular, the placeholder requirement is
no longer mandatory for satisfying the checkpoint (and in turn is
not required for conformance). Access to content (audio, images,
etc.) can be provided through other means such as menus.

This means that there is no obligation to render placeholders
in the same viewport as the SVG image.

C.16 Checkpoint 3.3: For SVG, too much to ask a user agent to
turn off text animation distinctly.

For checkpoint 3.3, the SVG WG wrote:

It is too much to ask of an SVG user agent to turn off text
animation distinctly. Animations might affect a text element or the
container element containing the text. Animations might affect the
gradient which the text references. This checkpoint is impossible
to implement in SVG. Either the checkpoint needs to be reworded so
as to narrow its application clearly or the checkpoint should be
removed. (See related comments on CHECKPOINT 4.4.)

Response:

Refer to the applicability provision. If the user agent cannot
recognize what is causing the text to be animated, then it is not
responsible for satisfying this checkpoint for that content. For
example, if animation is caused by a script, and the user agent
cannot recognize that the script is causing the animation, then the
user agent is not responsible for knowing this. I note that this is
one reason we have a requirement to turn off scripting.

On the other hand, if animation is specified through markup
(the animate element) on the text or
textstream elements, then the user agent would be
expected to recognize this and allow the required control.

C.17 Checkpoints 3.5/3.6: Apply to languages such as HTML
only

For checkpoints 3.5 and 3.6, the SVG WG wrote:

The normative text needs to clarify that these checkpoints apply
only to particular languages such as HTML.

Response:

The document (and the Techniques document especially) should
clearly point to the HTML case, as this case motivated the
checkpoint.

This checkpoint does not only apply to HTML,
and as for other checkpoints in this document, the user agent
developer must determine (with the help of materials provided by
the UAWG) whether the requirement makes sense for the format they
are implementing.

This checkpoint should be reworded to make clear that this is
meant for text-oriented languages such as HTML or CSS-styled XML
with a well-defined notion of background and foreground.

Response:

This checkpoint is only about foreground and background colors
of visually rendered text, not all content.

This checkpoint does apply in the SVG case. For
instance, the user agent could set values for the fill
and stroke properties for one or more elements. Refer
to example in section
10.4 of the SVG specification.

A SMIL or SVG UA has no way of determining whether an animation
can be recognized as purely stylistic. In fact, in
presentation-oriented languages like SMIL and SVG, it is often
unclear where content ends and styling begins. It is meaningless to
talk about UA not being required to satisfy the checkpoint for
animations for purely stylistic effects as this is almost never
recognizable.

Response:

What cannot be recognized does not apply. If this cannot be
distinguished in the case of SVG (or SVG plus metadata), then SVG
user agents must provide control for all animations.

C.20 Checkpoint 6.8: Character encoding support
superfluous.

For checkpoint 6.8, the SVG WG wrote:

We wonder why this checkpoint is worded the way it is. What is
the problem that this checkpoint is trying to solve? It seems to
use that this checkpoint is unnecessary and redundant with
checkpoint 2.1 since any XML-based and DOM-based language already
require support for Unicode encodings. The SVG group recommends
that this checkpoint be removed entirely.

Response:

This checkpoint is noted to be an important special case of
other checkpoints in this document.

It was included as the result of a last call request from the
Internationalization Working Group (refer to
issue 327). Because text is so important to many users with
disabilities, it is important not to "break" text before it reaches
assistive technologies.

The SVG group fears that this checkpoint might motivate vendors
to do the opposite of what the W3C wants. Instead of promoting the
implementation of W3C standards, this checkpoint might discourage
some vendors from implementing W3C standards for fear of losing
their claim of UAAG conformance. For example, a vendor which has a
UAAG conformant implementation of HTML might balk at implementing
SVG because they feel they must implement not only SVG but
UAAG-conformant SVG. We recommend making this item a Priority 2 or
3 or removing this checkpoint entirely.

Response:

UAAG 1.0 distinguishes between conformance an implementation
(refer to the glossary entries, which are linked from this
checkpoint). This checkpoint does not require conformance to the
entire specification, just implementation of the accessibility
features.

A developer is not required to satisfy this checkpoint for
every specification it implements, only those that are cited as
being used to satisfy the requirements of the document. Thus, a
user agent developer could claim conformance for implementing HTML
and PNG (for images) and choose to exclude SVG (for images) from
its conformance claim.

The SVG WG also wrote:

The comment about needing to conform to the accessibility rules
for non-W3C specifications is particularly curious. Very open-ended
and thus dangerous.

Response:

The UAWG acknowledges that every time UAAG 1.0 refers to an
external resource (whether a non-W3C specification or a generic API
or an operating environment convention) there is some room for
interpretation. This is believed to be a necessary evil for this
type of specification as it is intended to apply cross-platform and
be format-independent.

The SVG WG also wrote:

We don't understand the clause that says "and those that satisfy
**all** of the requirements of the WCAG10". This clause doesn't
make sense in the context of its sentence. And why the emphasis on
the word **all**? It is impossible to evaluate this clause without
being able to understand what it means.

For the purposes of this checkpoint, an accessibility feature is
either (a) one identified as such, or (b) one that allows the
author to satisfy any requirement of the "Web Content Accessibility
Guidelines 1.0" [WCAG10].

The UAWG acknowledges that there is some interpretation
required to establish which features of a specification allow an
author to satisfy WCAG 1.0 requirements.

C.22 Checkpoint 9.1/9.2: State unambiguously that user agents
that support plug-ins must be able to pass focus to them.

For checkpoints 9.1 and 9.2, the SVG WG wrote:

It would be good to state unambiguously that UAs which support
plugins must support the ability to shift focus to content
controlled by a plugin and to accept focus back from that
plugin.

Response:

Adobe has already raised this issues with the UAWG. The UAWG
has decided not to include such a requirement for several reasons:

The situation that caused Adobe to raise this issue was
acknowledged by all parties to be a bug in a particular
implementation and not desired behavior. A user agent that is
designed to accept plug-ins would have no interest in preventing a
plug-in from taking focus.

This requirement is already addressed by checkpoint 9.1 when
the plug-in's viewport is included in the conformance claim.

This item is asking too much on existing implementation for
insufficient resulting gain in accessibility, particularly when
plugins are involved. We recommend making this item a Priority 2 or
3 or removing this checkpoint entirely.

Response:

In the 14 July 2001 version of UAAG 1.0,
checkpoint 9.4 has been clarified: this requirement only
applies to user agents that implement a history mechanism (it does
not require implementation of a history mechanism).

Plug-ins may maintain their own history. Current
implementations of browsers already behave the right way: they hand
off focus and when they are returned focus, they restore the
previous focus state.

Loss of focus is a significant accessibility issues for users
who are blind or have a physical disability and have to re-orient
themselves, or for some users with a cognitive disability who may
also be disoriented by finding themselves in unexpected places in
content.

C.24 Checkpoints 9.4/9.5: Content focus only applies to
languages that have a concept of content focus.

For checkpoints 9.4 and 9.5, the SVG WG wrote:

This item should mention that the comments about content focus
only applies to languages which have the concept of content focus
and that the comments about input device handlers only apply to
languages which have such a concept.

Response:

Since the last call draft, the UAWG has clarified that

Implementation of selection is optional

Implementation of content focus is required for any language
that enables interaction with content. This is very important to
users with blindness or anyone who requires a persistent bookmark
in content from which they can explore nearby context to understand
where they are.

Please note that focus is not just bound to the pointing
device. Focus in the UAAG 1.0 sense is not the
element that the pointing device is currently designating; this is
not focus because it is not persistent. Like focus, a pointing
mechanism may be used to designate an element to receive input
events, but a pointing mechanism is transient. UAAG 1.0 requires a
persistent focus. Refer to
proposal to clarify minimal requirements for focus behavior
(moving them from the glossary to the checkpoints).

If a markup language does not support input device handlers,
then the applicability provision may be invoked.

This checkpoint puts extraordinary additional burden on those
good soul UA developers who are attempting to provide accessibility
features by forcing them to conform to Level Double-A WCAG with
their documentation in order to be Single-A conformance as a UA.
Please observe that UA vendors document their software using the
same authoring tools as everyone else. It is very likely that
standard authoring tools available at the time UA developers are
shooting for Single-A UA conformance will support Single-A readily
but not Double-A. In order to conform to Double-A, it might mean
switching to whole new sets of authoring technologies (most likely
home-grown), involving huge expenses and extensive retraining.
Thus, we recommend that only Single-A conformance be required on
product documentation.

Response:

The UAWG will add your comment to the list of reviewers who
have objected to the priority level of this checkpoint.

C.26 Checkpoints 12.2 and 12.4: Almost the same; delete
12.4

For checkpoints 12.2 and 12.4, the SVG WG wrote:

Checkpoint 12.4 is almost entirely redundant with 12.2. We
recommend getting rid of 12.4 and just adding a suggestion to 12.2
that there be a separate section for accessibility features.

Response:

The following will be clarified in the next version of the
document.

To satisfy the P1 12.2 requirement that the information be
available "somewhere", the following techniques are sufficient
independently (though doing both is preferred): (1) provide a
centralized view of accessibility features (2) integrated
documentation of accessibility features with the rest of the
documentation.

To satisfy the P2 12.4 requirement, provide a centralized view
in the documentation. If this is the solution used to satisfy 12.2,
the developer is done.

We recommend that the word "major" be added, as in "In each
**major** software release". Bug fix updates or minor releases
might have no change in the accessibility features. Also, change
"document all changes" to "document the changes". The word "all"
might open up the possibility of dispute.

Response:

In the 14 July 2001 draft,
checkpoint 12.4 has been narrowed in scope; it only requires
documentation of changes to accessibility features.. It now reads:
" Document changes from the previous version of the user agent to
accessibility features, including accessibility features of the
user interface."

D.1. Granularity of checkpoints

In global comment 2, the SVG WG wrote:

Our specific recommendation is that the actual content of the
various checkpoints should be re-organized keeping in mind various
conformance claims scenarios such that, as much as possible,
organizations can make conformance claims on entire checkpoints,
not partial checkpoints. In particular, each checkpoint should be
evaluated to see if any parts of the checkpoint apply only to
particular "content label types" or particular "input modality
labels". If so, then that checkpoint should be divided into
multiple distinct checkpoints. A possible approach is to offer one
more level of checkpoint numbering. Thus, checkpoint 9.4 might
consist of subparts 9.4.1 through 9.4.7 so that each distinct part
has its own number and thus can be referenced in a claim
individually.

Response:

The latest versions of the document include "provision" numbers
in each checkpoint, per the SVG WG's suggestion.

Please note that the size of a document is already an issue for
the SVG WG (Refer to global comment 1: "due to the sheer size of
the UAAG document, we did not have time to review each checkpoint
against whether its priority was justified."). The current document
factors common requirements into a single checkpoint when there
would be minimal difference between a series of checkpoints
otherwise. For instance, since audio and video requirements are
often related, where they are related, they have been combined into
a single checkpoint. The UAWG does not think that splitting these
checkpoints into multiple checkpoints is a good idea for at least
two reasons:

It will increase the number of checkpoints, which will not help
in the promotion of the document.

The UAWG wants developers to think of these requirements as
related for a number of reasons: general solutions may work better
and cost less than specific solutions, developers should think
about cross-disability requirements and combined checkpoints help
promote this view, etc.

D.2. Not clear which text is normative / informative.

In global comment 4, the SVG WG wrote:

The checkpoints are each described in three parts: (a) the
normative formal text for the checkpoint (this is the text that
immediately follows the checkpoint number), (b) a supplemental
non-normative Note, and (c) a link to non-normative supplemental
details in the Techniques document. The problem is that the
normative formal text is often ambiguous and incomplete on its own.
For example, checkpoint 5.4. Just reading the formal text, the
reader could not determine unambiguously that the "user agent may
satisfy this checkpoint by prompting the user to confirm all form
submissions", which is stated in the Note. If the information in
the quote is true, then it should be part of the normative text,
not the informative Note. (This comment applies across many of the
checkpoints.)

Response:

The UAWG agrees that where the text is intended to be
normative, it must be included in the checkpoint. The UAWG will
review all of the Notes and ensure that sufficient techniques and
allowed exceptions appear in checkpoints, where normative
statements belong.

In many cases, Notes include suggested Techniques that are
not guaranteed to be sufficient techniques. These
are included as examples and hints only, but should not be part of
the checkpoint text.

D.3 Would structured view be sufficient technique for many
checkpoints?

In global comment 7, the SVG WG wrote:

Ian Jacobs has stated that many of the checkpoints would be
satisfied if the UA offered a structured view of the current
Infoset and allowed user modification of the Infoset from the
structured view. If this is true, then the UAAG or the Techniques
should explicitly mention which checkpoints could be satisfied via
Infoset viewing and modification from a structured view. In fact,
the UAAG already mandates a source view (checkpoint 2.2). One thing
to consider is whether mandating an editable structure view of the
Infoset might allow simplification of the guidelines.

Response:

Ian has suggested that a navigable structured view might be a
good way to satisfy a number of requirements, but such a statement
was not intended to indicate that this is a sufficient technique.
Unless indicated in the checkpoint text as a sufficient technique,
any technique would need to be evaluated to verify that it meets
the checkpoint requirements.

An editable, navigable structured view is not a required
technique and I doubt that the UAWG would want to make it one at
this point.

[Editorial] It would be useful to indicate in the Techniques
which checkpoints could be met, all at once, with a navigable
structured view.

D.4 UAAG 1.0 requires that a user agent be an authoring
tool.

In global comment 8, the SVG WG wrote:

Many of the requirements seem to force a UA into implementing
the same sorts of features that an authoring tool would support.
For example, the ability to select objects and query about the
attributes on the selected object. Another example is that the UA
is required to maintain information about the current type-in or
current selection. This is placing a significant additional
implementation burden on UAs that is unrealistic. We believe that
checkpoints that are sliding down the path of turning UAs into
authoring tools need to be no higher than priority 2.

Response:

The UAAG 1.0 does not require the user agent to be an editor as
well. Our "write" requirements (e.g., for the DOM) are limited to
that which the user can already do through the native user
interface; our requirements are to enable the user to perform the
same operations through an assistive technology.

Some of the suggested (but not
required) techniques may involve operations traditionally
associated with an editor. For instance, we do not require that the
user agent implement a query functionality in order to satisfy
checkpoint 2.3; that is one possibility among four to satisfy the
checkpoint. I would note that "right-clicking" to change the
properties of an object is a common metaphor for software in many
environments, and not only for editors.

On the bullet for Intellectual property, a link to "restricted
functionality and conformance" needs to be added just as for the
Security bullet as the section on the restricted functionality and
conformance mentions IP situations.

Response: Yes.

D.6 Checkpoint 9.9 (Techniques): Example style sheet is
broken.

For checkpoint 9.9, the SVG WG wrote:

There is an error in the example stylesheet. It turns off *all*
headings inside any children of body such as a div. it assumes all
headings are children of body, ie a totally flat structure.

Response:

The UAWG will either remove the example or fix it.

D.7 Checkpoint 12.2: Seems to contradict 12.4

For checkpoint 12.2, the SVG WG wrote:

12.2 says that the accessibility features should be "integrated
into the document as a whole" but then 12.4 says to have a
dedicated section. Some readers might think the two checkpoints are
saying totally opposite things.

Response:

The UAWG will clarify the checkpoints as described in point
C.26 above.

D.8 Conformance: Allow developers to claim conformance for
parts of a user agent

The SVG WG wrote:

An additional small issue is that we would like to see
additional language in the conformance section allowing claims to
identify which specific UA features are accessibility enabled. For
example, the Adobe Acrobat Reader version 5 has added many
accessibility features and satisfies many checkpoints across the
majority of its features, but certain facilities are not yet
accessibility enabled. Given Adobe's investment in accessibility in
this particular user agent, it makes sense that Adobe should be
able to make claims about the accessibility features in Adobe
Acrobat Reader version 5. Right now, however, these claims cannot
be made because not every part of the UA is fully accessible. While
we are focusing here on one particular UA, it seems likely that
many other full-featured UAs will run into the same conformance
dilemma. The dilemma would be solved if it were possible to make
claims against particular sets of features. One possible approach
would be to suggest a standard matrix/form which shows features vs.
applicable checkpoints vs. supported checkpoints with supporting
comments. In many cases, a UA might want to provide several sets of
matrices for various different configurations (e.g.,
Windows/IE/MSAA vs. Unix/NN vs. whatever).

Response:

If a user agent doesn't satisfy all of the requirements, it
doesn't conform and conformance claims should not be made.

If parts of a user agent satisfy the requirements sufficiently,
then make a claim about those components only. Note, however, that
the components must satisfy all of the requirements subject to the
"pick and choose" mechanisms that UAAG 1.0 defines (including
"applicability").

It is possible (and even encouraged) to refer to UAAG 1.0
requirements without claiming conformance. The UAWG hopes this
document will prove useful even when conformance has not yet been
achieved. Perhaps unlike other specifications, even an incompletely
implemented UAAG 1.0 is probably a good thing.