Re: User Agent Last Call Period Extended to 14 May 2001

Hi Earl,

Thank you for sending comments about the document (and the
support for our progress). My comments and questions below
preceded by IJ:. To facilitate processing by the UAWG, I
have marked issues as either [Editorial] or [Issue], and
added issues to our issues list [1]. Please let me know
whether you (or anyone else) disputes these assessments.

[1] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3

> Sun Microsystems requests that you consider the comments
> below. Sun Microsystems supports the W3C's next step
> intentions for these guidelines.

Thank you!

[snip]

============= 
> Guideline 2
> 
> Nothing about enabling keyboard navigation of content is
> mentioned here. This is an important aspect of content
> access but it doesn't seem to be covered in this
> guideline. The suggestion here is to explicitly mention
> somewhere in this guideline that keyboard access to content
> is a part of "Ensure user access to all content."

IJ: [Editorial] Since this is covered by Guideline 1, I
think a note and cross reference from the Guideline 2 prose
should suffice.
 
> On a related note, the definition of the User Agent UI
> explicitly clumps the UA controls and the content
> together. 

IJ: Not quite. The glossary says that the term "user
interface" encompasses both "user agent user interface" and
"content user interface". Certain checkpoints refer
specifically to "user agent user interface", while others
refer to both.

> Then guideline 7 says in part "follow operating
> environment conventions." But operating environment
> conventions, with the exception to some extent of
> Java/Swing, only cover navigation thru and in standard UI
> toolkit components and in text. But the sum of web page
> content navigation and control is larger than the sum of
> what platform guidelines cover. Given this hole and
> opportunity to expand the usefulness of the UAAG, the
> recommendation here is that the UAAG committee produce a
> reference or suggestion document for key sequences for
> navigating content from the keyboard. Developers who follow
> what is in this suggested document should be able to feel
> that by following it they have accounted for all the content
> navigation oriented stated or suggested in the UAAG and WCAG
> in their UA design criteria.
> 
>         This recommendation applies to UAs targeted at
>         desktops and other systems powered by standard
>         keyboards such as QWERTY keyboards not to the broad
>         range of devices UAs are found today.

IJ: It is my opinion that we shouldn't do this for a couple
of reasons:

1) Integral to UAAG 1.0 is the idea that we can't dictate
what keyboard configuration will suit users the best. So as
a result:

 a) We require that the user be over to override default
    bindings (checkpoint 11.3). Configuration, rather than
    a fixed list, is our approach to this issue.

 b) We make requirements about the complexity of the
    keyboard shortcuts (checkpoint 11.4): Single key, etc.

 c) We have requirements about which functionalities must
    have bindings by default (checkpoint 11.5), but we do
    not specify what those bindings have to be.

 d) We also have requirements for documentation of bindings
    (11.1 and 11.2), and profiles for saving bindings
    (11.6).

2) UAAG 1.0 does not depend on a particular
platform. Therefore, we cannot specify key sequences for
content negotiation since we don't know (a) what all
keyboards will be like (b) what the standard
cross-application bindings will be on these platforms (and
thus the bindings we should not interfere with for content
navigation).
   
Perhaps I've misunderstood your suggestion. Do you have some
examples to illustrate your request?

Note: I need more information before considering this
editorial or an issue.
  
============= 
> Guideline 6
> 
> It is not clear where scripts fall in this guideline or what
> to do with scripts embedded in HTML content. If it causes the
> display of standard HTML elements in the same way as
> HTML/XML, what is it considered - another markup language or
> something that should use platform APIs? How about if the
> script is on a server but it causes things to happen to the
> content - is it another markup language or something that
> should use platform APIs? The recommendation here is the
> UAAG provide a discussion of answers to the above and other
> relevant script related questions off this guideline
> somewhere.

IJ: Scripts are mentioned explicitly in section 3.5
Checkpoint applicability. 

UAAG 1.0 in essence states: if there is a requirement
related to X, and the user agent is capable of recognizing
or controlling X, then it must satisfy the requirement. The
applicability exceptions are listed in section 3.5. 

We expect that any functionality controlled by the server is
not therefore subject to control by the user agent. [Again,
if the UA can do it, it must, but almost by definition,
"controlled by the server" implies that the UA doesn't
have control.] So, for example, the Note in checkpoint 2.4
says:

    "This checkpoint does not apply when the user agent
    cannot recognize the time interval in the presentation
    format, or when the user agent cannot control the timing
    (e.g., because it is controlled by the server)."

Strictly speaking, the sentence isn't necessary because it's
just about applicability (which covers all the
checkpoints). But enough readers have said "what about
server-side timing?" that we added this (redundant) note.

The same applies to scripts: There is a general problem
recognizing what a script is doing. In some cases, the UA
can know what a script will do (for example, that a
particular library function call will open a viewport) while
in others the UA cannot (for example, that a script
calculates a factorial). UAAG 1.0 is relying on developers
to make a judgment about what can be "recognized". We
provide some information and examples in the Techniques
document about what should be recognized.

[Editorial] So, I think UAAG 1.0 already addresses your
comment, but we could add a statement along the lines of
what I've just written, for further clarification. This
might be added to the definition of "script" (since scripts
are mentioned in more than one Guideline).
 
> We recommend the definition of applet be added to this
> document and that it be referred to somewhere in guideline #6
> (somewhere in 6.4-6.7 or in the general discussion on he
> guideline).

[Issue]
IJ: Ok. Do you have a good one for us?

I've added this as issue 511
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#511

=============  
> Guideline 8
> 
> The bullet points under "While developers should implement
> the accessibility features of any specification, this
> document recommends conformance to W3C specifications in
> particular for several reasons:" in guideline #8's general
> discussion suggest what is meant here is "We recommend you
> use W3C technologies covered by W3C guidelines in UAs as
> opposed to using platform specific technology whenever
> possible for the following reasons:" What is there now
> currently suggests what is being said is "make sure your UA
> at least conforms with all W3C specs because:" What is
> really meant by the statement "While developers should
> implement the accessibility features of any specification,
> this document recommends conformance to W3C specifications
> in particular for several reasons:"?

IJ: The checkpoints in Guideline 8 say:

 - Implement the accessibility features of any specification.
 - Conform to specifications:
     a) Conform to W3C specification (reasons given above), or
     b) Conform to non-W3C specification that support
        accessible authoring.

Hence this statement has two parts:

  "While developers should implement the accessibility
  features of any specification (checkpoint 8.1), this
  document recommends conformance to W3C specifications in
  particular (checkpoint 8.2) for several reasons:..."

We don't actually say "Conform to *at least* W3C
specifications" because both 8.1 and 8.2 allow conformance
to non-W3C specifications as part of conformance to UAAG
1.0.

Can you state a little more of what you wish clarified?

Note: I need more information before considering this
editorial or an issue.
 
==============
> Guideline 10
> 
> Is this guideline covering both the visual and programmatic
> aspects of orienting the user? Right now it seems to focus
> on the visual aspects of orientation. We recommend
> clarification on this point be placed in the general
> description for this guideline.

IJ: [Editorial]. The answer is:

 a) It's not just visual orientation.
 b) It's not programmatic orientation.

Your question applies to every Guideline: Must these
requirements be met through the user interface (whether
visual or other), or does making information available
through an API suffice? Section 3.7 states (under
Requirements for content, user agent features, or both):

   "The user agent must satisfy all requirements involving
   user interaction (both user input and output to the user)
   through the user interface of the subject of the
   claim. This includes not only the requirements that
   directly refer to to user control, configuration, etc.,
   but also requirements that indirectly involve the user
   interface (e.g., system conventions pertaining to the
   user interface)."

Let me know if this is a sufficient answer to your comment.
 
==============
> Guideline 12
> 
> We recommend specifically saying that the online help
> documentation provided with the UA must include discussion
> of all user agent features that benefit accessibility. It is
> typically where people start when they need to find out more
> about the workings of a product.

IJ: [Editorial] This is already covered by checkpoint 12.2.
The claimant may include any source of documentation they
wish in the claim. We have not made any requirements about
document delivery mechanisms: it doesn't matter in UAAG 1.0
whether the help information is available separately on CD,
on the Web, or is integrated upon installation. 

I propose that we recommend that online help include
discussion of accessibility features, but for the purposes
of satisfying checkpoint 12.2, it isn't required that this
information be on the Web.

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 831 457-2842
Cell:                    +1 917 450-8783

Received on Monday, 14 May 2001 16:00:18 UTC