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