Re: Proposed changes to UAGL to address conformance issues.

follow up comments per the short discussion
on the teleconf. call Wed 15th.  see below at MN:


At 10:32 AM 9/15/99, Ian Jacobs wrote:
>Hello,
>
>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.
>
>[1] http://www.w3.org/WAI/UA/WAI-USERAGENT-19990827
>[2] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#79
>
>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.

MN:  my first question would be, who determines what are
"supported" input devices.  Is it the user agent developer, is
it the user, is it the operating system, etc...follow below


>
>     b)  Use standard input device APIs provided by the
>         operating system.
>
>    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.

MN:  Yes there are two important points in 1.1, but the second point (b),
as you say
is near impossible to determine unless you are a developer.  However,
the user ought to be able to use, on a graphical desktop user agent
designed for an operating system that fully supports the keyboard
and mouse, either the keyboard and/or the mouse to operate the graphical
desktop user agent (which isn't saying anything not already stated
in numerous design guidelines for accessible software...)

What I'm trying to point out, is that the "supported input devices"
from 1.1 above would seem to be those input device APIs supported by the
"operating system/platform", and thus I don't see any good reason to split
1.1 into
two checkpoints.




>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.

MN:  I'm not disagreeing that some of the "intent" is lost
in the current wording for checkpoint 3.2, but I actually
am more confused with the wording proposed.  I don't think
we can ensure the "user can clearly understand the content
of a table cell", for example.  I think we can provide access
to the content, but understanding the content is an entirely
different issue.  Maybe just minor word smithing here, but
important non the less.  I'm also not clear as to how the technique
of "Provide a view of the document structure (e.g., a tree view
of all elements)" satisfies the access to the content of
an element.   I think this is a good technique, but maybe in the
wrong place?




>PROPOSAL 3) Checkpoint 3.3. This checkpoint should not be
>   for dependent user agents only. Refer to issue 84.
>
>   [2] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#84




>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:
>
>       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.

MN:  Suggest the following rewording instead ?

Allow the user to navigate while staying within the cells
of a table (notably left and right within a row and up
and down within a column).

For example, keyboard navigation from cell to cell
might be accomplished using the using the arrow keys
where as voice navigation from cell to cell might be
with voice commands like up, down, right, and left.

I'd like to see this be a checkpoint for *all* users agents
as well, since it is certainly a needed function, however
reality tells me that it won't fly as a P1 for all user
agents, but it is certainly something to shoot for.



>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.

MN:  "Clunky" is a polite way of saying, their user agent is broke!

I would not even think about the idea to "suggest" a user have
to look at the HTML source to understand something about a web page
in the context of these guidelines...which is not to say that we
all don't do this at some time or another, just that it doesn't belong
here.




>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.

MN:  Are we saying we'd like to allow the user to "view" a
particular element, or set of elements in an outline form? For
example, a list of headers, a list of forms, etc..  If so, I don't
understand why a user would have to read the markup, or are
you implying the UA would?

Or are we saying we'd like to allow the user to "view" the
entire document in an outline form, built using the structural
elements of the document ( i think Amaya does this)?



>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".

MN:  I'd rather see checkpoint 6.6 left alone and combine
checkpoints 6.1 and 6.5, something to the effect of "use
???? technology which provides access to all the *information*
in a timely manner."  This needs work, but you get the idea.

I'd also propose moving checkpoint 6.4, which talks about complying
with the W3C DOM model into Guideline 7, and then leave Guideline 7
as the catch-all for the W3C technologies, kind of like it is now.





>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.

MN:  first off, I've not removed checkpoint 6.6 out of
guideline 6, so you have to maybe backup a bit to understand
what follows.

Next, I won't disagree that the more inter-operable the user agent
and any technology working with or around them can be, the better
tailored the product and probably the access can become for users.

However, I think you make a very important point above, and if we really
agree on this, I don't understand why we'd propose changing the
UA guidelines from our current split of graphical desktop UA and
dependent UA.   As I read this.....

""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. ""

...is a decision the developer has made, and we should not change the
guidelines, in the area of conformance for such decisions.  If I'm
developing a product for a GUI that supports a keyboard and a
mouse as the standard input devices, and I as the developer choose
to not support one or the other standard input device, I've already
choosen not to be interoperable.  That in no way implies that I
as a developer have a good or bad product, etc. , or that I don't
care about accessibility, etc., I've made a development
decision, based on whatever reasons that developer has.



>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
>checkpoints.
>
> - Ian

MN:  More reasons why I think the method we've used to date to
develop the guidelines along the two classes has been the best
way to create a set of guidelines applicable across the intended
audience which sets obtainable goals for user agent and dependent
user agent developers while also raising the bar for providing
improved accessibility to web based information for users.

glad to discuss anything I've missed/mis-understood further.

mark

Received on Friday, 17 September 1999 13:36:12 UTC