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

Re: "Checkpoint applicability", "Native support", etc.

From: Hansen, Eric <ehansen@ets.org>
Date: Wed, 16 Aug 2000 12:55:05 -0400
To: "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>
Cc: "Hansen, Eric" <ehansen@ets.org>
Message-id: <B49B36B1086DD41187DC000077893CFB8B425D@rosnt46.ets.org>
This memo is my response to Jon Gunderson's comments [1] on my comments on
my comments [2]. Jon Gunderson's comments [1] are snipped and then also
included in the Appendix in a slightly reformatted form.

1. How Does It Help?

Jon wrote:

"I am not sure about the topic of "features for people disabilities versus
features for people without disabilities" in this section.   What does this
add to the discussion of applicability?"

I am still thinking through the implications of emphasizing the distinction
between primary capabilities and secondary capabilities. I now see that
following my suggestion of a few days ago in [2] without making other
adjustments in the document may allow too much of a loop-hole. The essential
piece of my Applicability section in [2] was:

"A checkpoint is applicable if it requires capabilities that are intended
for users without any disability who using the user agent under 'standard
conditions'."

I plan to return to this issue in another memo.

2. "Applicability Issues"

Jon wrote "In general I think there are several main issues that
applicability needs to address" and then listed several issues (see
Appendix).

As I look at the "Applicability Issues" that you have cited, I think that
they all look like UAAG checkpoints, not applicability issues. Please let me
know if I am mistaken in this.

Applicability rules should not replicate what is in checkpoints but rather
should indicate when a checkpoint is in force for a given user agent.

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0227.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0225.html


Appendix: Document [1] -- Jon Gunderson wrote:

I think we need to review the applicability section in more detail.  I am
not sure I agree with all of Eric's comments.  I am not sure about the topic
of "features for people disabilities versus features for people without
disabilities" in this section.   What does this add to the discussion of
applicability?

I think examples of common questions and edge issues are useful to
developers to help them understand the applicability issue.

In general I think there are several main issues that applicability needs to
address:

Applicability Issues
1. You must implement and export the DOM for compatibility with Assistive
Technologies

2. You must support a keyboard API, even if you do not have a physical
keyboard as part of your product (KIOSK)

3. If you render a content type to anyone, you must provide access to that
content type in an accessible way and provide access to author specified
alternative equivalents through the user interface.  If you do not provide a
content type to anyone, then you do not need to provide access to author
specified alternative equivalents for that content.

4. If you support a particular output device for rendering content you must
support the device in an accessible way.  If you don't support a particular
output device you do not need to support the accessibility features
associated with that device.

5. Supporting a keyboard input API is the only input device requirement,
other input devices must be supported in an accessible way.  Capabilities of
the user agent must be available through all supported input devices, except
certain functions that are specific to a particular device like generating
characters for a text entry field with a keyboard or dragging a graphical
object with a pointing device.

6. User agents that use helper applications for rendering certain types of
content are not responsible for rendering the sent to the helper application
in an accessible way.  The host user agent though is responsible for making
available alternative equivalents of content sent to the helper application
available through the output devices it supports.

===========================
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 Wednesday, 16 August 2000 12:55:46 GMT

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