- From: Dianna Callesen <dcallesen@Adobe.COM>
- Date: Mon, 13 Nov 2000 16:13:15 -0800
- To: w3c-wai-ua@w3.org
- Cc: ij@w3.org, lguarino@Adobe.COM, rgordon@Adobe.COM, palewis@Adobe.COM, ribrown@Adobe.COM, mbierman@Adobe.COM
Adobe Systems thanks the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) User Agent Accessibility Guidelines working group members for the opportunity to review and provide comment on the User Agent Accessibility Guidelines v 1.0 W3C Working Draft 23 Oct 2000. Adobe is fully supportive of the intent of the working draft and the WAI. In its review of the working draft, Adobe has drawn on experiences in implementation of accessibility features in those Adobe products defined as User Agents - Adobe Acrobat Reader and the Adobe SVG Viewer. In addition, Adobe has drawn on its experience developing software for the graphic arts and publishing markets, and market research into accessibility needs and requirements. In commenting on the draft document, Adobe seeks changes or clarifications that would provide end users with a meaningful accessible content experience while preserving whenever possible, the intent of the content author. The structure of the comments is as follows: 1. General comments 2. Specific comments on select parts of the User Agent Accessibility Guidelines General comments Recognition of limitations due to file formats supported In general the working draft does a very good job of providing guidance for those user agents that support simple, structured file formats such as HTML. However, there is a growing class of user agents that support more complex file formats. While these formats can be made accessible, they do not lend themselves to the same guidelines as HTML. For this reason, some Priority 1 requirements should not apply to some specialized user agents. For example, a background image is easily identified in HTML, and user agents supporting HTML can and should allow users the option not to view the background image. However, in the cases of PDF, SVG and SWF, the notion of background image does not manifest itself in a way that allows the user agent to consistently distinguish the background from the foreground. Adobe encourages the working group to consider, where appropriate, wording to acknowledge and permit implementations most appropriate to the file format the user agent supports. Recognition of limitations of standard APIs Several of the requirements refer to interoperability with standard APIs. However, there are many cases where the standard API is not sufficient to preserve the content author's intent. For example, text on a path cannot be adequately represented using standard APIs. In such a case, the author's intent can be preserved by rasterizing the text, and accessibility provided by associating an alternative text description of that element. Adobe encourages the working group to consider, where appropriate, wording to acknowledge limitations of standard APIs and permit implementations that can preserve the author's intent as well as provide an accessible alternative. Support of plug-ins dependent on user agents for access Although the User Agent Accessibility Guidelines provide a means for a developer to insure that a single user agent can be certified as accessible, the reality of the Web viewing experience is that the majority of user agents operate within the context of other user agents developed by other vendors. Because of this factor, the entire user agent ecosystem must be accessible for the end user to derive a benefit from the work done to make any single user agent accessible. For example, a plug-in such as the Adobe SVG Viewer could conform with all the requirements outlined in the User Agent Accessibility Guidelines, but unless the host user agent (ie. Microsoft Internet Explorer or Netscape Navigator) provides appropriate support (ie. providing focus) for the accessibility features implemented by the Viewer, the Viewer is rendered inaccessible. Adobe encourages the working group to consider guidelines or wording in existing guidelines specifically addressing the responsibility of the host user agent to allow end users to fully benefit from the accessibility features of user agents operating within the context of the host user agent. Security considerations Adobe would like to raise awareness of the issue that the current state of the art of accessibility is insecure with regards to digital content. Common techniques used to make digital content accessible to assistive technologies expose that content to extraction re-use and manipulation by other, potentially nefarious technologies. There are no established standards for differentiating between a trusted assistive technology and an untrusted technology seeking access. Adobe strongly encourages the WAI to educate its constituency and end-users of its guidelines on this current limitation, making it clear that there will be cases in which a user agent may have to deny access to content in the interest of security. It is Adobe's assertion that user agents must respect the security intentions of content authors and owners. Adobe also encourages the WAI to work toward developing solutions that simultaneously would permit security and accessibility. Simplification of wording for non-technical audiences Adobe recognizes that the User Agent Guidelines are written for an audience of varying degrees of technical expertise. Additionally, WAI standards are a key component of guidelines and legal requirements dictating purchasing and technology decisions made by non-technical individuals. For this reason Adobe strongly encourages the working group to provide examples and clarifications that can assist a non-technical individual who is tasked with making a purchase or usage decision to fairly and accurately evaluate the options the market provides. Specifically, Adobe asks the working group to clearly state exemptions in those instances in which limitations of a file format, standard API, or other technology outside the purview of the user agent in question prevents that user agent from effectively implementing the accessibility feature as described. Specific comments Guideline 1.2 Use the standard input and output APIs of the operating system. Do not bypass the standard APIs when rendering information Adobe comment: It is not possible for user agent vendors to meet this requirement in cases where the primary output is graphical data that cannot be handled by the platform. For example, there are cases in which the output supported by the user agent is not text but a graphic rendering, and to provide an optimum experience for users, user agent vendors must use their own APIs. In the case of SVG and PDF, the content author has the ability to use equivalents, which Adobe believes are the appropriate place to provide data through assistive technologies using the platform APIs. Adobe encourages the working group to consider the addition of wording that communicates this alternative. Guideline 1.3 Implement the operating system's standard API for the keyboard to ensure that every functionality available through the user interface is available through this API. Adobe comment: Standard operating system APIs are not always adequate when providing certain levels of functionality, and not all user interface elements can be meaningfully replaced with keyboard equivalents. For example, pen and brush tools used for freehand drawing cannot be adequately replaced by keystrokes. Guideline 2.3 Provide easy access to each equivalent and each equivalency target through at least one of the following mechanisms: (1) allowing configuration to render the equivalent instead of the equivalency target; (2) allowing configuration to render the equivalent in addition to the equivalency target; (3) allowing the user to select the equivalency target and then inspect its equivalents; (4) providing a direct link to the equivalent in content, just before or after the equivalency target in document order. Adobe comment: There is an underlying assumption that the user agent is providing access to HTML or a similarly simple structured markup language. In cases of non-structured content, providing access to equivalents as described in this guideline is very difficult. For example, recent versions of Adobe PDF allow text equivalents for elements. These equivalents are accessible to screen readers and other assistive technologies. However, when a page is rendered on the screen, it is extremely difficult to identify the coordinates at which an equivalency target will be represented and to provide human-readable access to the equivalent in an accurate context. Guideline 2.5 For non-text content that has no recognized text equivalent, allow configuration to generate repair text. If the non-text content is included by URI reference, base the repair text on the URI reference and content type of the Web resource. Otherwise, base the repair text on the name of the element that includes the non-text content. Adobe comment: This guideline is difficult to interpret as written. Guideline 3.1 Allow the user to configure the user agent not to render background images. In this configuration, provide and option to alert the user when a background image is available but has not been rendered. Adobe comment: There is an underlying assumption that the user agent is providing access to a format that supports the notion of a background image. There are cases in which a user agent cannot know a background image exists. Adobe requests the addition of a note acknowledging that this checkpoint be limited to those user agents supporting file formats that have the specific notion of a background and foreground images. Guideline 3.2 Allow the user to configure the user agent not to render audio, video, or animated images except on explicit request from the user. In this configuration, provide an option to render a substitute placeholder in context for each unrendered source of audio, video, or animated image. When placeholders are rendered, allow user to activate each placeholder individually and replace it with the original author-supplied content. Adobe comment: In practice this requirement would be extremely difficult to meet. With the prevalence of scripting and the evolution of design techniques that intentionally separate the user interface from the underlying functionality of web content applications, there are increasing instances where implementing Guideline 3.2 would be impossible. Adobe strongly urges the working group to reconsider this guideline or alternatively demote its priority ranking. Guideline 4.2 Allow user to configure the font family of all text, with an option to override author-specified, and user agent default, font families. Allow the user to select from among the range of system font families. Adobe comment: The working group has underestimated the complexity of font usage. This guideline assumes a simplistic model of font usage that is adequate for simple documents, but does not take into account more complex documents and content forms. For example, there are many cases where substitute fonts would not have equivalent representations for specific characters. In these cases, the resulting content would be significantly less accessible than the original content. Guideline 4.3 Allow the user to configure the foreground color of all text with an option to override author-specified, and user agent default, foreground colors. Allow the user to select from among the range of system colors. Adobe comment: Same issues as identified in Guideline 3.1 Guideline 4.4 Allow user to configure the background color of all text with an option to override author-specified and user agent default background colors. Allow the user to select from among the range of system colors. Adobe comment: Same issues as identified in Guideline 3.1 Guideline 5.1 Provide programmatic read access to HTML and XML content by conforming to the W3C Document Object Model (DOM) Level 2 Core and HTML Specifications and exporting the interfaces they define. Adobe comment: Fulfillment of this requirement is dependent on the ability of a single user agent or assistive technology to function within the ecosystem of a host user agent. Adobe strongly encourages the working group to consider requirements that reward host user agent vendors for providing adequate support for user agents reliant on those host user agents to provide a positive accessible experience for end users. Thank you for your consideration of these comments. Sincerely ------------------------------------- Dianna Callesen Sr. Product Manager, Accessibility, Asset Management, Web Workflow Product and Technology Integration Adobe Systems, Inc. voice: 408-536-4111 fax: 408-537-4618 dcallesen@adobe.com
Received on Monday, 13 November 2000 22:13:50 UTC