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

SVG last call comments | Last call UAAG 1.0 (9 April 2001) | Issues list | UAWG home page | Mailing list archive

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.

The UAWG tracks issues on their issues list.

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.

Last modified: $Date: 2001/07/14 18:20:47 $

Contents

General comments

After reading the comments, it seems that:

A. Substantial issues addressed by the UAWG

The following issues have been added to the issues list.

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

For checkpoint 2.4, the SVG WG wrote:

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:

This is issue 516.

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:

This is issue 517.

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:

The SVG WG wrote:

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.

Response:

This is issue 518.

B. Issues for which the UAWG requested more information

B.1 Checkpoint 3.4: Requirement to alert users to presence of scripts too burdensome / utility not clear

For checkpoint 3.4, the SVG WG wrote:

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:

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:

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:

B.4 Checkpoint 10.3: Highlight requirement should refer to text links only.

About checkpoint 10.3, the SVG WG wrote:

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:

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:

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 SVG WG also wrote about 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.

Response:

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:

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 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:

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:

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:

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 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 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:

C.6: Checkpoint 1.1: Don't require keyboard access for all functionalities (e.g., text selection, region positioning)

For checkpoint 1.1, the SVG WG wrote:

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:

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:

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:

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:

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:

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:

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:

C.10 Checkpoints 6.3 and 6.4: Delete since too operating environment specific.

For checkpoints 6.3 and 6.4, the SVG WG wrote:

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:

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:

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

Response:

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:

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:

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:

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:

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:

C.18 Checkpoint 4.3: Applies to text-oriented languages with clear notions of fg and bg

For checkpoint 4.3, the SVG WG wrote:

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:

C.19 Checkpoint 4.4: Cannot recognize an animation as purely stylistic

For checkpoint 4.4, the SVG WG wrote:

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:

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:

C.21 Checkpoint 8.1: Will scare off implementation of specifications / checkpoint unclear.

For checkpoint 8.1, the SVG WG wrote:

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:

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 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.

Response:

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:

C.23 Checkpoint 9.3: History requirement burdensome, notably for plug-ins.

About checkpoint 9.3, the SVG WG wrote:

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:

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:

C.25 Checkpoint 12.1: Accessible documentation requirement is burdensome

For checkpoint 12.1, the SVG WG wrote:

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:

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:

C.27 Checkpoint 12.5: Only for major software releases; don't say "all"

For checkpoint 12.5, the SVG WG wrote:

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:

D. Editorial, errors, and communication issues

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:

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:

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:

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:

D.5 Add cross reference from section 1.3/IPR to "restricted functionality" section.

In the comment on section 1.3, the SVG WG wrote:

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:

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:

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: