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

Re: Proposed changes to UAGL to address conformance issues.

From: Kitch Barnicle <barnicle@trace.wisc.edu>
Date: Tue, 21 Sep 1999 17:55:08 -0500
Message-Id: <199909212256.RAA17897@trace.wisc.edu>
To: w3c-wai-ua@w3.org
My comments follow KB

At 10:32 AM 9/15/99 -0400, Ian Jacobs wrote:
>Please consider the following changes to the UAGL 
>(27 August version [1]). This proposal attempts to resolve
>various questions (e.g., [2]) about how different types of user
>agents will conform to the document. The proposed changes
>remove the need (I hope) for a graphical/dependent split
>while keeping the goals of the checkpoints intact. The
>last change suggests a split of a different sort to
>address interoperability.
>PROPOSAL 1) Checkpoint 1.1. The current text:
>      Ensure that all functionalities offered through 
>      the user interface may be operated through standard 
>      input device APIs supported by the operating system. 
>  I propose that we split this checkpoint into two:
>     a)  Ensure that all functionalities offered through 
>         the user interface are available through all supported
>         input devices. Note: The device-independence
>         required by this checkpoint applies to functionalities
>         described by the other checkpoints in this document
>         unless otherwise stated by individual checkpoints.
>     b)  Use standard input device APIs provided by the 
>         operating system. 

KB  Is there any meaning behind the switch in terms from 
"may be operated through" to "available" through? Could
the guideline say "may be operated through standard 
 input devices."  The word operated just seems clearer to me.

>    The text of (a) comes from previous versions of the
>    guidelines. However, I think checkpoint 1.1 in [1] mixes
>    two very important points: all functionalities must be available
>    AND use standard input device APIs. Thus, I propose the split.
>    I have noted that while reviewing Netscape Navigator, that verifying
>    (a) is near impossible unless you are a developer or have access to
>    details about how the tool's internal APIs connect to the interface.
>    I propose that we include a note in the document that informs users
>    that it may be difficult to verify certain checkpoints without
>    detailed software documentation.

>PROPOSAL 2) Checkpoint 3.2. The current text:
>     Ensure that the user has access to the content of
>     an element selected by the user.
>   This checkpoint is the evolution of a requirement for access 
>   to individual cells, list items, etc. However, I think some
>   of the intent is lost in the current wording. I propose 
>   the following:
>     Ensure that the user has access to the document
>     structure expressed by markup in an output 
>     device-independent manner.
>       For example, ensure that the user can clearly 
>       understand the content of a table cell, the
>       content of a list item, the content of a header,
>       etc.
>     Techniques:
>     a) Provide a view of the document structure (e.g.,
>        a tree view of all elements).
>    Note that "output device-independent manner" means
>    for output devices supported by the software.

KB  I agree with Mark Novak in that I don't think we can
say that users must understand the content. Are we trying
to suggest that the user should be able to move through
a document element by element? When I see the words
"access to the document structure" I think you mean
something like "allow the user to get an overview of the 
structure of the document."  But are what we really 
trying to say is "Ensure the user can access the
document structure one element at a time?" or "Ensure
that the user has access to the content of each element
in a document (e.g table cells, list items)

>PROPOSAL 3) Checkpoint 3.3. This checkpoint should not be 
>   for dependent user agents only. Refer to issue 84.
>   [2]
>PROPOSAL 4) Checkpoint 8.3. The current text:
>       Allow the user to navigate just among table cells of
>       a table (notably left and right within a row and up 
>       and down within a column).
>    I propose that this checkpoint be for all users agents, with
>    the following note afterwards:

KB I'd like to see this for all user agents too if possible

>       Navigation techniques include keyboard navigation from
>       cell to cell (e.g., using the arrow keys) and scrolling.
>       Note, however, that users must be able to navigate in
>       an input-device independent manner. 
>PROPOSAL 5) Checkpoint 9.2. The current text:
>       Provide the user with information about the number
>       of viewports.
>    I suggest that the principle of this checkpoint applies to
>    all user agents. I suggest that it be rewritten:
>       List all viewports (including frames).
>    Netscape 4.6 lists windows and frames, Lynx
>    lists frames, Opera 3.51 lists windows and allows keyboard
>    navigation of frames, IE 4 lists windows (but I don't see
>    how to list frames). All of NN, IE, and Opera allow you to
>    view the HTML source, which is a clunky way to find the
>    frame structure.

>PROPOSAL 6) Checkpoint 9.3. The current text:
>     Allow the user to view a document outline
>     constructed from its structural elements 
>     (e.g., from header and list elements). [Priority 2]
>   I don't think this should be for dependent user agents only.
>   My question is this: does a view of the markup count? It is
>   not navigable, but it is searchable. I realize that this forces
>   users to read markup, which is not desirable.
>PROPOSAL 7) I propose that we move checkpoint 6.6 (operating system 
>  conventions) to Guideline 7 and rename Guideline 7 as
>  "Support standard interfaces, conventions, and languages".

KB I like the idea of removing the words W3C from guideline 7
to make it more generic since checkpoint 7.1 is not specific to
W3C technologies

>PROPOSAL 8) Having removed checkpoint 6.6, Guideline six is only
>  about communication among software. This guideline is
>  meant to make general purpose browsers accessible by
>  having them communicate with assistive technologies
>  that are taking advantage of work already done by
>  the browser (or other user software). While it would
>  be good if assistive technologies communicated through
>  standard means, I don't believe that was the original
>  intent of this guideline. 
>  To avoid definitions like "graphical desktop
>  browser" and "dependent user agent", I propose that
>  we allow two other types of conformance:
>   a) Conformance as a stand-alone user agent:
>           You don't have to satisfy any checkpoints
>           in Guideline 6.
>   b) Conformance as an interoperable user agent.
>           You have to satisfy all the checkpoints
>           in Guideline 6.
>  This split is natural - it is precisely about interoperability
>  and not other user agent functionalities.
>  This proposal may seem to undermine the goal 
>  of interoperability. I don't think it does. If a user
>  agent developer doesn't care about interoperability,
>  they won't satisfy these checkpoints anyway, even if the
>  the software highly accessible in other ways or to
>  targetted users. We are still saying
>  that interoperability is important and also "If you
>  want to ensure interoperability, you must do these things."
>  However, interoperability is not the only element of 
>  accessibility. That's why there are other guidelines.

KB I am sure we will discuss the implications of
"allowing" developers to not conform to guideline 6 
because as you say Ian, the proposal does "seem to undermine 
the goal of interoperability" and it scares me a bit.

>OPEN ISSUE: There are two remaining checkpoints currently listed
>as being for dependent UAs only: 9.8 and 9.9: access to cell headers
>and table dimensions. Checkpoint 9.9 is Priority 3, and it might
>be simplest just to make it apply to all user agents. Checkpoint
>9.8 is priority 1. I haven't figured out yet how to modify these

KB  In summary, I would love to remove the
distinction between graphical and dependent
user agents if at all possible as long as we
don't loose leverage with developers.
Easier said that done, right? 

Thanks Ian
Received on Tuesday, 21 September 1999 18:56:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:23 UTC