TR Checkpoint 5.4 - User Interfaces

We received a few comments regarding Checkpoint 5.4 User Interfaces.
Comment #1
This checkpoint requires conformance to UAAG 1.0 Level A, but that is an
incomplete profile. Please refer to sections 3.1 and 3.3 of UAAG 1.0 for
information about how to include a UAAG 1.0 conformance profile in a
You will have successfully met Checkpoint 5.4 at the Minimum Level if:

1.	any applications with custom user interfaces conform to at least
Level A of the User Agent Accessibility  <>
Guidelines 1.0. If the application cannot be made accessible, an
alternative, accessible solution is provided.

Rewrite to the following:
any applications with custom user interfaces must conform to UAAG 1.0
Guideline 2.0.  If the application cannot be made accessible, an
alternate, accessible solution must be provided (this does not have to
be a text-only version).  Note: The custom user interface could be a
result of a Flash application, a Java Applet, a Java Object or program,
or any other technology that is created that requires user input outside
of entering an input into a static or dynamically generated
cross-platform machine readable page complying with Checkpoint 5.2.
Comment #2
All content has a user interface, which makes this checkpoint redundant.
Should be "custom user interface".[2]
Checkpoint 5.4 Ensure that all custom user interfaces are accessible or
provide an accessible alternative.
This will ensure that we are speaking about application programming
interfaces and remove the confusion of individuals thinking this section
is regarding the HTML interfaces.
Comment #3
This checkpoint is about making the user interface operable and would be
better organized as part of guideline 2.
This seems to be taken care of when we apply the proposal from Comment
#2 because this Guideline is focusing more on the custom user interfaces
generated through application programming interfaces outside of the
normal HTML user interfaces.
Comment #4
a)  minimum level #1: This point needs to be clearer. We cannot tell if
we would need to follow these other guidelines. If a Web app runs in a
standard browser, does the interface still have to conform to the other
guidelines? What is considered an accessible alternative? A text-only
site? What would be an accessible alternative for a Web app page?
This is taken care of with the proposed rewrite under comment #1.
Comment #4
b)  level 2 #1: What does "or hidden within the page" mean? Variety of
assistive technologies" needs to be defined. Otherwise it's too vague.
Is it enough, for example, to target JAWS and MAGic?
"hidden within the page" should be directed to related to the metadata
included in the page.  "Variety of assistive technologies" should not be
defined as new technologies will probably emerge and if not mentioned
would lead people to think those new technologies are not suitable for
measurements.  We could, on the other hand, provide examples of
assistive technologies with a disclaimer that at the publication of this
document these are some of the known assistive technologies and should
only be referred to as an example base.
Comment #4
c)  level 2 reviewer's note: Not sure how it would be possible to comply
with the checkpoint without carrying out tests. The text specifically
says "the interface has been tested." Please clarify.
On the "Reviewers Note:" we should consider removing the first sentence
and include the second part.
It is possible to conduct tests, but still fail to meet the checkpoint
(with respect to assistive technologies that were not tested, for
example).  A list of the technologies used for the testing should be
included in the Accessibility Statement so people with technologies that
do not support the features of the site may find a reasonable
alternative to use the site.
Lee Roberts
Rose Rock Design, Inc.

Received on Sunday, 26 January 2003 14:31:26 UTC