On Tue, 22 May 2001, Ian Jacobs wrote:
> Dean Jackson wrote:
> >
> > Please find the SVG Working Group's feedback on
> > the UAAG last call:
> >
> > http://lists.w3.org/Archives/Member/w3c-svg-wg/2001AprJun/0245.html
> > [Member only link]
> >
> > We apologise for the delay. The SVG working group has
> > invested a large amount of time in this feedback (including
> > more than 4 1.5 hour teleconferences) and wanted to ensure
> > group consensus before making an official submission.
>
> Dean and the SVG WG,
>
> Thank you for taking the time for such a thorough review
> of the document.
>
> Before replying to your comments, please note that the
> UAWG has a publicly readable mailing list. Do I have
> permission to forward the text of your comments to the
> list? (If not, we cannot process them. Your choice :).
Seeing as you cannot process the feedback without
making it public, I can't see any other alternative.
Hoping I don't get into trouble for this :) .....
here is the feedback as text.
Dean
--
GLOBAL COMMENT 1 - We believe that there are too many Priority 1
checkpoints: 48 out of 89 are priority 1. We believe that the first step
(i.e., Level A Conformance) towards adding UA accessibility guidelines is
too big, which will discourage some developers from starting down the road
towards adding accessibility since even the lowest conformance level is
just too hard to pull off.
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", moreso 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.
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.
In some of the comments below, we recommend that specific checkpoints get
downgraded. However, due to the sheer size of the UAAG document, we did not
have time to review each checkpoint against whether its priority was
justified. We call on the authors to review the priority assignments and
look to move many of the priority 1 checkpoints to priority 2.
GLOBAL COMMENT 2 - We believe that the specification would benefit greatly
from a major editorial overhaul in the granularity of the various
checkpoints. A main reason for this recommendation is the need to establish
conformance claims (section 3). As the conformance section is now written,
the organization making accessibility claims not only has to determine
which checkpoints apply, but also has to specify which **parts** of
checkpoints apply.
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.
GLOBAL COMMENT 3 - 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. Also, it would be best if each separate working
group documented normatively how the UAAG guidelines apply to their
respective languages. In particular, the SVG group discussed the
desirability of having the SVG group define how UAAG guidelines apply to
user agents that render SVG and other graphical content.
Additionally, many of the checkpoints as written leave us scratching our
heads. It would help greatly in many cases if the checkpoint described
examples of the exact accessibility problem which the checkpoint is trying
to solve. For example, checkpoint 2.3. What sorts of "conditional content"
is this checkpoint trying to address.
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.
GLOBAL COMMENT 4 - 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.)
GLOBAL COMMENT 5 - Throughout the UAAG draft, the guidelines state that
facilities in the "operating environment" must be used in order to be
conformant. 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.
The SVG group has representatives from many companies involved in writing
UAs and end-user applications software packages. The experience among many
in the SVG group is that sometimes operating system facilities are the best
answer to solve a particular technical problem and other times not. We
expect that this will be true with accessibility features, also. While it
may be true that certain platform vendors today might be offering good
accessibility libraries, it is not guaranteed that from now to the end of
time that every platform vendor will offer the best accessibility libraries
for their particular platform. There is a definite possibility that
companies whose sole purpose in life is cross-platform accessibility tools
vendors might offer better solutions than particular platform vendors.
Also, how does this relate to Java-based tools? Java provides its own
virtual system, which usually works off an entirely different code base
than the underlying platform. Has Java been eliminated as a possible
development language for writing accessible UAs? We believe some of the
checkpoints are worded such that Java-based tools might be deemed
non-compliant.
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").
GLOBAL COMMENT 6 - 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. In particular, there
is considerable growth in the area of mobile devices such as PDAs and cell
phones with the ability to browse the Web. The devices do not have the
processing and storage capability of desktop computers, yet in many cases
accessibility features are likely to be used on these devices than on
desktop computers as voice browsing might be used by all users, not just
visually-impaired users.
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
cellphones 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.
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.
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.
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.
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).
GLOBAL COMMENT 7 - 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.
GLOBAL COMMENT 8 - 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.
SECTION 1.3: 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.
CHECKPOINT 1.1: 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.
CHECKPOINT 2.1: Doesn't this one just say that the UA needs to be
conformant to the standard it supports? The current wording is confusing.
CHECKPOINT 2.3: 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?
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?
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 discernable.
This checkpoint is too far-reaching, too hard to implement, will do the
wrong thing in too many cases, and cannot be justified in terms of user
benefit, especially as a Priority 1. We recommend modifying the wording and
changing this to a priority 2 or 3.
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.
CHECKPOINT 2.4: 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. In fact,
it is not possible to know whether user input is happening at all in many
cases. SVG in particular responds to low-level user events such as
keypresses and pointer device actions. It cannot distinguish keypresses
which operate a game console versus keypresses which are entries into a
simulated "form". In a general sense, the same is true for any language
that supports interactivity and animation.
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.
The only possible feature that a UA might be able to provide in this area
is the ability to pause the "root timeline" via keyboard action or to
accelerate/decelerate the root timeline, where the root timeline is the
clock maintained by the root time container element which starts at
"document begin". In SMIL, this would be the <smil> element. In a
stand-alone SVG document, this would be the outermost <svg> element. (There
is no feasible way to pause any of the subordinate timelines.)
CHECKPOINT 2.9: We don't believe that it makes sense to ever render all
content at the same time.
CHECKPOINT 3.1: 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?
CHECKPOINT 3.2: 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.
CHECKPOINT 3.3: 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.)
CHECKPOINT 3.4: 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.
CHECKPOINT 3.5/3.6: The normative text needs to clarify that these
checkpoints apply only to particular languages such as HTML.
CHECKPOINT 4.2: 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.
CHECKPOINT 4.3: 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.
CHECKPOINT 4.4: 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.
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.
The SVG group recommends that this checkpoint be removed or dropped down to
priority 3 or 2.
CHECKPOINT 4.5: Similar comments as 4.4. The SVG group recommends that this
checkpoint be removed or dropped down to priority 3 or 2.
CHECKPOINT 4.9: 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.
CHECKPOINT 4.16: 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.
GUIDELINE 6: 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"
CHECKPOINT 6.3: 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 accessbility 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".
The SVG group recommends that this checkpoint be removed entirely.
CHECKPOINT 6.4: Similar comments as 6.3. The SVG group recommends that this
checkpoint be removed entirely.
CHECKPOINT 6.5: 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.
CHECKPOINT 6.6: See GLOBAL COMMENT 5.
CHECKPOINT 6.7: See GLOBAL COMMENT 5.
CHECKPOINT 6.8: 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.
CHECKPOINT 6.10: 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.
CHECKPOINT 7.1: See GLOBAL COMMENT 5.
CHECKPOINT 8.1: 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.
The comment about needing to conform to the accessibility rules for non-W3C
specifications is particularly curious. Very open-ended and thus dangerous.
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.
CHECKPOINTS 9.1/9.2: 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.
CHECKPOINT 9.3: 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.
CHECKPOINTS 9.4/9.5: 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.
CHECKPOINT 9.9: 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
heading s are children of body, ie a totally flat structure.
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.
CHECKPOINT 10.3: 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.
CHECKPOINT 12.1: 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.
CHECKPOINT 12.2/12.4: 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.
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.
CHECKPOINT 12.5: 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.
SECTION 3 CONFORMANCE: The SVG group is happy with the main thrust of this
section but has strong reservations to the currently defined methodology
regarding conformance icons.
We feel that a conformance icon on a UA is likely to be a lightning rod for
disputes due to the extraordinary complexity in making claims and in
determining whether the claims are valid. In making a set of claims, a UA
must choose a conformance level, remove requirements for unsupported
content label types (note: in some cases this means removing **parts** of
checkpoints), remove requirements which do not apply for various other
reasons, and add requirements having to do with input modality labels
(again, possibly **parts** of checkpoints). This already complicated
process is documented in the UAAG draft.
But then there are real-world practical issues which real-world UA will
have to deal with. For a given UA, there are potentially multiple
platforms, and for each "platform", there are different versions of
operating systems, different system libraries per custom installation
options, and different bug fix updates (system patches). Sometimes
installation of application software overwrites system libraries or
otherwise affects how a platform operates. The user might customize his/her
system in various ways, such as the choice of background colors on windows
or font choice.
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?
With the UAAG, things are much more complicated than with WCAG. With WCAG,
there is actually some hope that an automated tool could potentially be
applied which can check a particular content type (e.g., HTML) and analyze
that content and prepare a report. Thus, a significant portion of WCAG can
be judged automatically and unambiguously. With UAAG, however, there are so
many complexities involved that any level of automated verificiation is out
of the question. Instead, a human would need to run the UA manually to
determine if conformance claims are met. In other situations where a human
is needed to verify conformance claims, a certifying organization such as
Underwriter Labs is established, and this organization distributes the seal
of approval, not the organization which defines the criteria.
The current wording states that a conformance claim is valid if (3.7 #2)
"It is verified that the user agent satisfies...". Later (3.8) it says
"Claimants are expected to modify or retract a claim if it may be
demonstrated that the claim is not valid." Notice the passive voice in both
of these quotes. Try turning them to active voice. Who is doing the
verifying that the UA satisfies the requirements of the claim and who is
doing the demonstrating that the claim is not valid? Suppose some zealot
sends email "demonstrating" that a particular UA does not support a
particular checkpoint and then demands that the software get re-released
without the conformance icon?
The SVG group's overall opinion is that conformance icons only make sense
in two main scenarios:
(1) 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
(2) 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.
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).