Re: Fw: Updated Mozilla Keyboard Navigation spec.

Distribution note:

I am not following the addressing request in Peter's announcement
message because I can't find a public archive of the posts to that
list. We can send this to the requested list if it gets support here. A
second, not a consensus, would be my criterion.

Also because the nature of my comments has to do with general
patterns that should be supported in W3C formats and protocols, more
than with the coding that Sun is doing on Mozilla in the next release.

[end note.]

** summary

- quote item navigation unquote is a misnomer.  The term is misleading.
We should have a better term, such as quote markup navigation unquote.

- navigating recurring structures: lists, tables, and trees, is such 
an important
principle that we need to distinguish between navigating to recognizable
individual items from navigating around in a structured context.  This is
a different distinction from the one the document deals with, but they
get mixed together here because of an unfortunate choice of term.

- the document fails to recognize that the tabbing navigation already
supported in the browser is what the document calls item navigation and
that this is an important part of success both for the eyes-free user and
for the other mouse-free users.

- we need to get more of the navigation-methods work, currently known
by the item-oriented title of a dictionary of canonical page parts, on the
public Web.

- in the process I hope we can communicate that the navigation
structure proposals revolve around memes, recurring patterns, as much
as around discrete items.

** details

I got flipped out by the assertion that "table navigation falls in
the category of item navigation."

To me, header navigation and ACCESSKEY direct navigation are item
navigation, but list and table navigation are structure navigation.
The latter are driven by memes in the context, not items in the
content.

This distinction is important because a recurring pattern of
navigation method affordance becomes something that one can hold in
recall memory. A recurring pattern you can get your head into is one
that can be navigated eyes-free. So goes the pet theory.

This is not, however, the dotted line where the Sun Mozilla team is
drawing the line between "hard code now" and "script opportunity now."

What they are actually trying to do is distinguish between navigation
anchored in the layout and in the text that they are proposing to
implement in hard code and navigation anchored in the markup which
they are proposing to defer to the script domain.

I don't think that we are going to overturn the decisions about where
the hard code effort goes first. But I do think we can help them
clean up the model for what they are deferring at this time.

The idea that markup navigation per se is left to the script domain
is clearly false, however, because of the very important markup-aware
navigation already afforded through the [configurable] functions
bound to the tab and modifier-tab keystrokes.

Al

At 8:21 AM -0500 12/6/04, david poehlman wrote:
>Johnnie Apple Seed
>
>----- Original Message -----
>From: "Peter Korn" <Peter.Korn@sun.com>
>To: <mozilla-accessibility@mozilla.org>;
><gnome-accessibility-list@gnome.org>
>Sent: Monday, December 06, 2004 2:58 AM
>Subject: Updated Mozilla Keyboard Navigation spec.
>
>
>Greetings,
>
>After reviewing the many hundreds of comments and messages generated by the
>first Mozilla/Gecko Keyboard Navigation Proposal, I'm pleased to announced
>our
>second draft is available for review, at:
>
>    http://www.mozilla.org/access/keyboard/proposal
>
>After the huge volume of feedback, we carefully re-thought a number of
>things
>and especially took to heart the frequent request for configurability.  To
>that end we have decided to prune some of the commands from this second
>draft
>to cover only "core" navigation to be implemented directly in C in Gecko.
>Configurability is most easily done in JavaScript extensions, and that is
>where we feel all of the "item navigation" work is best done.  This is also
>where much of the "specialized for specific accessibility needs" navigation
>falls as well - blind users for example finding good table item navigation
>particularly important where a general keyboard user wouldn't benefit as
>much.
>
>Sun plans to implement all of the specific keyboard navigation items
>discussed
>in the specification (with exceptions clearly noted).  We believe that item
>navigation is important, but we don't propose to implement that
>immeidately -
>both because there is yet no clear concensus as to how it should be done,
>and
>because we feel that it is urgent that we have "core keyboard navigation"
>working well as quickly as possible.
>
>Sun's Mozilla engineering team has been posting source tarballs of Mozilla
>periodically containing all of Sun's changes to a Mozilla 1.7 branch, where
>our work is taking place toward a release we are working on.  This second
>draft notes which portions of the keyboard navigation proposal are
>implemented
>in Mozilla trunk, which have thus far only be implemented in the Sun Mozilla
>1.7 branch, and which have yet to be implemented anywhere.
>
>
>I encourage you to review this draft, and send your comments again only to
><mozilla-accessibility@mozilla.org>.  I also encourage you to try those
>portions of the keyboad navigation proposal which have been implemented.
>You
>can see Sun's most recent Mozilla 1.7 branch tarball at:
>http://ftp.mozilla.org/pub/mozilla.org/mozilla/accessibility/sun-mozilla-1.7/12-03-2004/
>
>
>Sincerely,
>
>
>Peter Korn
>Sun Accessibility team
>
>_______________________________________________
>mozilla-accessibility mailing list
>mozilla-accessibility@mozilla.org
>http://mail.mozilla.org/listinfo/mozilla-accessibility

Received on Monday, 6 December 2004 16:42:34 UTC