W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2000

UAAG 1.0: review comments from Adobe Systems

From: Dianna Callesen <dcallesen@Adobe.COM>
Date: Mon, 13 Nov 2000 16:13:15 -0800
Message-Id: <3.0.5.32.20001113161315.00933b80@mailsj-v1>
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 GMT

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