W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2001

Re: SVG Working Group Last Call Feedback on UAAG

From: Dean Jackson <dean@w3.org>
Date: Wed, 23 May 2001 04:16:27 +1000
To: Ian Jacobs <ij@w3.org>
Cc: w3c-wai-ua@w3.org, w3c-svg-wg@w3.org
Message-ID: <20010523041627.C31336@act.cmis.csiro.au>
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).
Received on Tuesday, 22 May 2001 14:18:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:50 GMT