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

Validity, Applicability, Native Support, etc.

From: Hansen, Eric <ehansen@ets.org>
Date: Thu, 17 Aug 2000 13:45:21 -0400
To: "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>
Cc: "Jon Gunderson (E-mail)" <jongund@ux1.cso.uiuc.edu>, "Ian Jacobs (E-mail)" <ijacobs@w3.org>
Message-id: <B49B36B1086DD41187DC000077893CFB8B426E@rosnt46.ets.org>
Date: 17 August 2000
To: UA List
From: Eric Hansen
Re: Validity, Applicability, Native Support, etc.

I have a number of suggestions that I think that solve some of the issues
that we are dealing with.

====

Suggestion 1: Acknowledge that no single user agent is likely to fulfill all
the capabilities.

New:

"Need for Composite User Agents"

"At least in the short term, any user agent that fully satisfies these
guidelines is likely to be composed of several other user agents. For
example, such a "composite" user agent might include: a general-purpose
graphical desktop browser, a multimedia player, and specialized user agents,
such as screen readers that are useful for controlling speech output and
refreshable braille display. Therefore conformance claims are required to
list not only the main subject of the claim (e.g., a general-purpose
graphical desktop Web browser) as well as other components of the claim
(e.g., multimedia player, assistive technologies, etc.)."

====

Suggestion 2: Delete references to native support and add a definition of
operating system.

With the change below I think that we may be able to delete all references
to "native support."

Old (UAAG 28 July 2000): 

"Native support"
"A user agent supports a feature natively if it does not require another
piece of software (e.g., plug-in or external program) for support. Operating
system features adopted by the user agent to meet the requirements of this
document are considered part of native support. User agents may, but are not
required to, provide access to adopted operating system features through the
user agent's user interface or programmatic means. For example, if the user
agent relies on the operating system's audio control features to meet some
requirements of this document, the user agent is not required to include
those controls in its native user interface. If an adopted operating system
feature is not accessible through the operating system's user interface,
then the user agent must provide an alternative accessible solution."

New:

"Operating system"

"[Define operating system.] For the purposes of this document, operating
system features adopted by the user agent are considered part of the user
agent. Therefore, if an adopted operating system feature is not accessible
through the operating system's user interface, then the user agent must
provide an alternative accessible solution. [per checkpoint XXX].

====

Suggestion 3: Consider making "Validity" a unifying concept.

I think that the current validity section is too narrow and may even be able
to encompass concepts like applicability, scope-and-limitations, etc.
Following is a bag of some of the major issues. I don't think that all need
to be mentioned, but some of them do.

1.	This document does not guarantee implicit claims that 'equivalents'
actually fulfill their function when presented to the user.
2.	Whether general or specific exceptions to requirements will be
granted in such cases systems used for national security-related systems.
3.	How responsibilities for compliance are to be divided among Web
content developers, user agents developers, organizations that procure
systems, etc.
4.	Whether the specific requirements of this document should be
augmented with general functional requirements (e.g., "The user agents shall
be provide a mode of operation that does not rely on user sight."). This
document focuses on specific design requirements rather than general
functional requirements.
5.	Whether specific assistive technologies are to be available on all
systems or just a few. For example, in public environments such as libraries
or public information kiosks, there is a greater need to have each system
equipped with assistive technologies. On the other hand, in private work
environments it may be more sensible to provide some of the more expensive
assistive technologies only on systems intended for employees with
disabilities. 
6.	Whether a requirement can be waived if it is deemed an 'undue
burden' on the responsible party.
7.	Whether it is to be a requirement for 'equivalent facilitation' if
some or all requirements of this document are not met, due for example, to
undue burden. For example, can some or all requirements of this document be
satisfied if responsible parties provide a solution with equivalent or
greater levels of access. Furthermore, are such options available at any
time or only as a last resort?
8.	Whether specific requirements must be met by a particular kind of
user agents (general-purpose graphical desktop browsers, telephone browsers,
text browsers, multimedia players, assistive technologies).
9.	Whether conformance claims such as those prescribed in this document
are satisfactory or whether independent certification is necessary.
10.	Whether implementation of the guidelines is deemed to require any
additional technological improvements prior to implementation, e.g.,
improved standards for communication with assistive technologies.
11.	Whether certain requirements can be waived or additional
requirements must be added when user agents are used in situations that
diverge significantly from the 'standard conditions' of this document.
12.	What measures need to be taken to deal with security, privacy, and
intellectual property right issues. This are important for many reason,
including because they can affect ease of installation and maintenance. 
13.	The length of time that the concerned parties have to implement the
requirements.
14.	Responsibilities for training users, computer-support personal, etc.
15.	Need to recognize that it is possible for primary capabilities to be
delivered via assistive technologies.
16.	How specific our definition of 'standard conditions' should be.
17.	Whether checkpoints that use the word "apply" should actually be
treated as applicability issues and, if so, whether they require the
presence of an "Applicability" section in the document.
18.	To what extent the checkpoints will be applicable in special
applications (instruction, testing, etc.).

====

Suggestion 4: Add a Priority 1 checkpoint that requires basic presentation
features.

The current guidelines miss out on requiring the basic presentation
capabilities of general-purpose graphical user agents. I think that this was
so obvious that it was missed. But I think that it is important. How can a
general-purpose graphical user agent be considered "accessible" or
conformant if it does not provide these capabilities? One can argue that
they are implied in other checkpoints, but I think that greater clarity is
warranted.

New:

"Provide capabilities for visual presentation of text, graphics, animation,
video, audio, and sound. [Priority 1]"

Comment 1:

I don't suppose that we need to specially mention "tables" since that is
like a form of "graphic". Does the above checkpoint cover it?

====
Suggestion 5: Consider adding  Priority 1 "general functional requirements"
for deaf, deaf-blind, and other group access.

This is a general "functional" requirement patterned after Trace R&D's
revision the section 508 proposed standards. By contrast our current
checkpoints would probably most be considered more of a design requirement.
If the concept of multi-modal output (visual-displayed text, synthesized
speech, Braille) is central to our model of accessibility, how can we not
require support for synthesized speech and refreshable Braille? Further
discussion is needed here.

New:

"Provide at least one mode of operation and information presentation that
does not require either user speech or user sight. [Priority 1]"

"Provide at least one mode of operation and information presentation that
does not require user sight. [Priority 1]"

<END OF MEMO>
====

===========================
Eric G. Hansen, Ph.D.
Development Scientist
Educational Testing Service
ETS 12-R
Princeton, NJ 08541
609-734-5615 (Voice)
E-mail: ehansen@ets.org
(W) 609-734-5615 (Voice)
FAX 609-734-1090
Received on Thursday, 17 August 2000 13:46:17 GMT

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