Re: Proposal for Changes to Keyboard Navigation

On 4/14/04 11:53 AM, "Doug Schepers" <doug@schepers.cc> wrote:

> 
> Hi, folks-
> 
> I realize that this comes too late

Unfortunately, yes.


> since Last Call for CSS3 was quite some
> time ago, but there are a couple of considerations for keyboard navigation
> that would enhance their use in SVG(+XBL) applications. I have made a page
> which addresses these issues, discusses them in detail, and provides use
> cases and demos. [0]
> 
> The first is relatively minor: for directional navigation [1], in addition
> to URIs, nav-index values of elements in the current document should be
> valid values for nav-up, nav-down, nav-left, and nav-right.

This fails as soon as you have multiple elements with the same nav-index
value, which is allowed, just as it was allowed for the tabindex.


> My rationale is
> that this is more consistent with the nav-index system, is less verbose,
> does not require that the focus target have an "id" attribute, and would be
> easier to assign and track programmatically.

You're simply using nav-index values as IDs.  There is no real difference in
your proposal.  Except that your proposal fails because multiple elements
can have the same nav-index value whereas multiple elements cannot have the
same 'id' value.


> I recognize that this is not
> necessarily the initial intent on directional navigation --that directional
> navigation was partly intended for inter-document navigation-- but this use
> case is particularly pertinent in SVG, at least (and probably in other host
> languages like HTML, sometimes).

No.  There is no difference in the use case you present.

> This aspect of it, admittedly, is a bit
> muddled... when does a directional nav key move to another document, and
> when does it stay in the same document?

See the <target-name> value parameter for the directional navigation
properties.


> The second is that currently, there is currently no provision for
> hierarchical navigation [2] within a document. I propose that nav-index
> allows, as an optional value, a parameterized list of integers rather than a
> single integer. Each parameter would act as a local index for that
> heirarchical "level," and would require a special key sequence for
> navigation up or down levels. This is just one possible solution, of course,
> but it outlines the problem domain.

This seems far more complex than necessary, both for the author and the
user.

Directional navigation solves this problem handily by flattening the
navigation into 2d space of the rendering, so the user does not have to
think of going "into" or coming back "out of" any particular area -- they
just navigate right through it.


> In addition, a special cue (visual,
> and/or aural, and/or whatever) should be given when hierarchical options
> exists.

I can see this possibly making sense for "CSS-VR" styling scenario, but
since such features have yet to be defined/designed, it seems premature to
discuss 3D navigation details, though I can see it eventually being
interesting to talk about.


Tantek

Received on Thursday, 1 July 2004 20:07:23 UTC