- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 27 Sep 1999 12:11:59 -0400
- To: mark novak <menovak@facstaff.wisc.edu>
- CC: w3c-wai-ua@w3.org
Hi Mark,
My comments preceded by IJ: below.
- Ian
mark novak wrote:
> 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
IJ: That's a good question I also asked myself during my review
of NN [1]. There are a number of checkpoints, in fact, where
finding the answer requires intimate knowledge of the
software's specs. That's an issue I'd like to discuss
elsewhere. However, to answer this specific question,
in my opinion, the developer
must make claims (somewhere) about what APIs are supported.
[1] http://www.w3.org/WAI/UA/uagl-checklist-nn4.60
> >
> > 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.
IJ: Yes, I agree.
> 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.
IJ: So should all UAs be required to support all input-device
APIs available for the operating system?
I don't think so, even though we hope that mainstream
browsers support at least mouse
and keyboard APIs. That's why I think in the end it's not
the available APIs that matters, but the available APIs that
the software developers claim to support.
> >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.
IJ: I agree.
> Maybe just minor word smithing here, but
> important non the less.
IJ: So I'd change to something like "For example, ensure that
the user has access to the content of a table cell, the
content of a list item, the content of a header, etc."
IJ: However, Thatch doesn't like the change from "content"
to "structure" in the proposal, so I don't think we're settled here yet.
Refer to his email [2].
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0375.html
> 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?
IJ: The idea would be that by respecting the structure in the view, the
user would have easier access to content. This needs clarification.
> >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).
IJ: I don't understand "staying within". The problem is that
navigation and access are intimately linked here. Navigation
is just a technique for more efficient access to cell content
(just as tabbing navigation provides efficient access to links
and form controls). One day I want to delete this checkpoint
and make it a technique, another I think it's important as
a checkpoint in its own right. Can we shorten to "Allow the
user to navigate the cells of a table" along with the good
examples you provide below?
> 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.
IJ: Sounds good.
> I'd like to see this be a checkpoint for *all* users agents
> as well, since it is certainly a needed function,
IJ: That's the kind of comment that makes me shift towards
favoring this as a checkpoint, not a technique...
> however
> reality tells me that it won't fly as a P1 for all user
> agents, but it is certainly something to shoot for.
IJ: So P2?
> >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.
IJ: But is the proposed checkpoint text ok?
> >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)?
IJ: In my opinion, we're talking about the latter: A
generated table of contents (of sorts). Furthermore, the
outline should be navigable, which is not expressed in the
current wording.
> >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.
IJ: I don't object to this proposal. I'd like to hear from
developers.
> 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.
IJ: I guess it depends on which slice you're interested in. I'm more
interested in slicing along functional lines (communication
v. stand-alone) than W3C lines.
> >PROPOSAL 8)
[snip]
> > 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.
>
[snip]
>
> 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.
IJ: I'll respond to this in a separate email.
> >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.
Thanks for the comments Mark!
- Ian
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel/Fax: +1 212 684-1814
Cell: +1 917 450-8783
Received on Monday, 27 September 1999 12:12:21 UTC