March 9 Draft of UAAG

Some comments on the current draft, in preparation for the meeting:

Abstract:
By following these guidelines, developers will create more usable
software for all Web users. [DA: Actually, only for users of the browser
in question.  Web authoring guidelines improve access for anyone who
accesses a page, but UA guidelines only help those using a specific user
agent.  What we really mean is that following the guidelines will
improve access for all uses of the user agent, including those with
disabilities.]

In Section 1.1:

.	UAAG 1.0 includes several repair requirements (e.g., checkpoints
checkpoint 2.7 and checkpoint 2.10) for cases where content does not
conform to WCAG 1.0. Furthermore, some requirements in this document
support authoring practices that may be widely deployed but that are
discouraged because they cause accessibility or usability problems
(e.g., some uses of HTML frames).[DA: This seems to be saying that this
document is supporting practices that cause access problems!  Surely
that isn't what we mean.] 

Guideline 1:

People who cannot or do not use a mouse have to be able to operate the
user interface with the keyboard, through voice input, a head wand,
touch screen, or other device. [DA: In this context, a head-wand is a
means of accessing the keyboard, and a touch screen is generally a mouse
emulator, so these examples are actually just restating mouse and
keyboard.  Why not consider input methods there that do not rely on
standard mouse and keyboard presence: such as Morse Code or
single-switch scanning. ] 

Checkpoints 1.1 through 1.3

[DA: As written, this seems to say that you can choose to implement
mouse only, keyboard only, or voice input only interfaces, and claim
such conformance.  I understood us to intend that you must provide
keyboard interface, and may provide mouse and voice interfaces.  Even
devices that do not have keyboards should have an API that supports
keyboard control to facilitate use of AT. ]

Guideline 2 text include:

.	Local control of rendering is important; global configuration of

.	Local control of rendering is important; global configuration of
rendering preferences is convenient for access. 

Checkpoint 2.2

2.2 For all text formats that the user agent implements, provide a view
of the text source. [Priority 1] 
Note: The user agent should provide a source view for any text format,
not just implemented text formats. Text formats include all of the
following: 
[DA:The note here sets a different standard than the checkpoint. The
checkpoint says that source view is required for formats that are
implemented.  The note says that source view is required whether or not
the format is implemented!]

2.3 Allow configuration so that, for each piece of unrendered
conditional content "C" the user agent alerts the user to the existence
of the content and provides access to it. Provide access to this content
according to format specifications or where unspecified, as follows. If
C has a close relationship (e.g., C is a summary, title, alternative,
description, expansion, etc.) with another piece of rendered content D,
do at least one of the following: (1) render C in place of D, (2) render
C in addition to D, (3) provide access C by querying D, or (4) allow the
user to follow a link to C from the context of D. Otherwise, do at least
one of the following: (1) render a placeholder for C that may be
replaced by C, (2) provide access to C by query (e.g., allow the user to
query an element for its attributes), or (3) allow the user to follow
link in context to C. [Priority 1] 

[DA: Does this include the option of notifying an external AT, via an
API, of the existence of C, so that the AT can access and render C
outside of the user agent itself?]

2.4 For content where user input is only possible within a finite time
interval controlled by the user agent, allow configuration to make the
time interval "infinite". Do this by pausing automatically at the end of
each time interval where user input is possible, and resuming
automatically after the user has explicitly completed input. In this
configuration, alert the user when the session has been paused and which
enabled elements are time-sensitive. [Priority 1] 

DA: Does this include the condition where there are embedded links
inside a QuickTime movie, for example, that allow a user to further
explore building shown in the movie?  There, input is only possible when
the particular building is on the screen, but when following 2.4, the
user would have to explicitly say whether or not to follow each link
that appeared.  Would such a decision be persistent across frames?  It
looks like the movie would have to pause just before each link passed
"out of view."

2.7 Allow configuration to generate repair text when the user agent
recognizes that the author has failed to provide conditional content
that was required by the format specification. If the missing
conditional content is included by URI reference, base the repair text
on the URI reference and content type. Otherwise, base the repair text
on element type information. [Priority 2] 

DA: I agree with Ian here that the information in the URI is a minimal,
but certainly not optimal repair text.  This might be the minimum
implementation, but other solutions should be supported.

2.9 Allow configuration to create the conditions under which conditional
content is rendered. [Priority 3] 
Note: 

DA: I'm not sure what this means.  Doesn't conditional text, by
definition, have attached conditions?  Perhaps we mean that the user
agent should allow configuration to modify the conditions under which
conditional text is rendered?

3.1 Allow configuration not to render background images. In this
configuration, provide an option to alert the user when a background
image is available (but has not been rendered). [Priority 1] 
Content type labels: Image. 
Note: This checkpoint only requires control of background images for
"two-layered renderings", i.e., one rendered background image with all
other content rendered "above it". When background images are not
rendered, user agents should render a solid background color (see
checkpoint 4.3). In this configuration, the user agent is not required
to retrieve background images from the Web. 
Techniques for checkpoint 3.1 

DA: Would a background image in a table that overlies a background image
on a page still meet this standard?  We now have at least 3 layers of
rendering.

3.3 Allow configuration to render animated or blinking text as
motionless, unblinking text. [Priority 1] 
Content type labels: VisualText. 
Note: This checkpoint does not apply for blinking and animation effects
that are caused by mechanisms that the user agent cannot recognize. This
checkpoint requires configuration because blinking effects may be
disorienting to some users but useful to others, for example users who
are deaf or hard of hearing. 

[DA: If a <marquee> contained more text than would fit in the allotted
space, would the user agent have to rerender the page to make the text
visible?]

3.5 Allow configuration so that client-side content refreshes (i.e.,
those initiated by the user agent, not the server) do not change content
except on explicit user request. Allow the user to request the new
content on demand (e.g., by following a link or confirming a prompt).
Alert the user, according to the schedule specified by the author,
whenever fresh content is available (to be obtained on explicit user
request). [Priority 1] 

DA: Consider this scenario: The user is informed via a dialog that
refresh content is available, and is asked whether or not to render it.
Because s/he is not ready yet, s/he responds "NO," which dismisses the
dialog.  How do you get the dialog back when it's time for a refresh?
There would have to be a keyboard equivalent, yes?

3.7 Allow configuration not to render images. In this configuration,
provide an option to render a placeholder in context for each unrendered
image. When placeholders are rendered, allow the user to activate each
placeholder individually and replace it with the original
author-supplied content. [Priority 2] 

DA: For this, part of the configuration should be to render the content
serially on demand.  If the reason for suppression of the images is that
a complex screen overwhelms the user, then sequentially activating
images would eventually reach the level at which the user is
overwhelmed.  If the images were activated serially, then activating one
image would suppress images that had previously been rendered,
maintaining the level of complexity of the page.


I'll continue and send more.




Denis Anson, MS, OTR/L
Assistant Professor
College Misericordia
301 Lake St.
Dallas, PA 18612

Received on Thursday, 15 March 2001 13:37:22 UTC