Re: Updated Mozilla Keyboard Navigation spec.

["david poehlman" <david poehlman handsontechnologeyes com>]

no op can also be not used which is quite common.

Johnnie Apple Seed

----- Original Message ----- 
From: "Norman B. Robinson" <norman_b_robinson yahoo com>
To: <mozilla-accessibility mozilla org>
Cc: <gnome-accessibility-list gnome org>
Sent: Tuesday, December 07, 2004 5:49 PM
Subject: Re: Updated Mozilla Keyboard Navigation spec.


Peter and Team:

1. I would remove the I. Introduction, first sentence qualifier "(with
exceptions made for things like painting programs)", as there is no such
exception. Please refer to my previous posting on the first draft
<news://news.mozilla.org:119/mailman 1095365221 19702 mozilla-accessibility mozilla org>
(Date: Thu, 16 Sep 2004 16:05:41 -0400 From: Norman B. Robinson
<norman_b_robinson yahoo com, To:     Peter Korn Cc:
mozilla-accessibility <mozilla-accessibility mozilla org> Subject: Re:
RESEND: Mozilla content keyboard navigation proposal - feedback sought
ASAP!). I have tried to make this idea clear in documents such as the
USPS AS-508-A Section 508 Technical Reference Guide
<http://www.usps.com/cpim/ftp/hand/as508a/>
(http://www.usps.com/cpim/ftp/hand/as508a/), Section 5, Software
Applications and Operating Systems, Subsection 5-2.2.5 Provide Keyboard
Access to Commonly Used Functions.

2. For clarity, I would expand 'no-op' to 'have no operation'.

3. For clarity, I would change the first introduction of a caret, the
first bullet under "Continuous Navigation" to read "...moves the cared
(as indicated by the ^ symbol) one character left."

4. "VIII. Unresolved Issues #1. How to access fixed/floating widget
using keyboard?"  I suggest relabeling this "Accessing CSS positioned
widgets through keyboard navigation".

    Unless I misunderstand your intent of this issue, you might want to
also change "Their physical position may be very different from their
logical position" to "Their physical position may be very different from
their coded position".  The web content (document object model) in
either case is rendered and should be used as-is. A scenario of a left
side navigation bar using CSS, where the code is the last part of the
HTML document, might be of use as a test case. I would imagine that I
would want to navigate the left hand navigation pane just as I would any
other object, left to right, top to bottom. (Given that one cannot see
left, right, top, or bottom, that is still the *linearization* of the
content). The document should (under Section 508 anyway) have a skipnav.
In addition to that, in this scenario, if the user turned off style
sheets the content would display the 'left hand navigation' last, after
the main content. Keyboard navigation would still (correctly) follow the
document when style sheets are off, reading the left navigation pane
last. Also, I think WCAG Guideline 1.3 and Guideline 2.4 might apply.

5. I would love to see a more organized reference to the keyboard
commands, all inclusive of modality if possible. My apologies for not
taking the time to tag and linearize the table for those of you with
screen-readers but I wanted to post something immediately.

*key bindings*



*caret browsing mode*



*non caret browsing mode*

*Continuous Navigation*



* *



* *

left arrow key <left>



<left> moves the caret one character left. Especially, if the* *caret is
at the beginning of a line, <left> will move it to the end of the
previous line. If caret is already at the beginning of the current
frame, <left> will be no-op.



scroll page left (if there is content outside the window view pane as
indicated by a horizontal scrollbar)

right arrow key <right>



<right> moves caret one character right. Especially, when the* *caret is
at the end of a line, <right> will move it to the beginning of the next
line. If the* *caret is already at the end of the current frame, <right>
will be no-op.



scroll page right (if there is content outside the window view pane as
indicated by a horizontal scrollbar)

up arrow key <up>



<up/down> moves the caret one line up/down. Browser keeps the horizontal
distance change of the caret as small as possible. If the target line is
not long enough to keep the the caret's horizontal distance, browser
will remember the original horizontal distance and will return the caret
to that position when possible, see example below. If the caret is
already at the first/last line of the current frame, <up/down> will be
no-op.



scroll page up/down (if the content has vertical scrollbar)

 down arrow key <down>


/the below items need to be separated into individual keys/



<home/end>



move the caret to the beginning/end of the current line.



scroll to the beginning/end of the content.

Ctrl key and left arrow key <ctrl+left>



<ctrl+left> if the previous character is a part of a word, <ctrl+left>
moves the caret to the beginning of that word; if the previous character
is blank (spaces, tabs), <ctrl+left> moves the caret skip those blank
spaces and to beginning of the previous word.



no operation

Ctrl key and left arrow key <ctrl+left>



Behavior depends on a preferences setting
layout.word_select.eat_space_to_next_word and setting
layout.word_select.stop_at_punctuation.





Ctrl key and right arrow key <ctrl+right> with preferences setting
layout.word_select.eat_space_to_next_word=false. Current caret position
inside a word. GTK default setting.



Moves the caret to the end of that word. Exception for HTML listing
elements <ul>, <ol>, <li>, where the caret will ignore the leading
numbers/bullets of the <li> element.





Ctrl key and right arrow key <ctrl+right> with preferences setting
layout.word_select.eat_space_to_next_word=false. Current caret position
before blank (spaces, tabs). GTK default setting.



Moves the caret skip those blank spaces and to end of the next word.
Exception for HTML listing elements <ul>, <ol>, <li>, where the caret
will ignore the leading numbers/bullets of the <li> element.





Ctrl key and right arrow key <ctrl+right> with preferences setting
layout.word_select.eat_space_to_next_word=true. Windows default setting.



Moves the caret to the beginning of the next word





*Discontinuous Navigation*









<pgup/pgdn>



scrolls the content one page up/down. The browser keeps the horizontal
and vertical distance change of the caret as small as possible. As the
browser will automatically scroll the page when the caret is about to
move out of the visible area, there is no key binding for horizontal
scrolling.





<home/end>



moves the caret to the beginning/end of the current line. If the caret
is already at the beginning/end of the current line, <home/end> will be
no-op.





<ctrl+home/end>



moves the caret to the beginning/end of the current frame. If the caret
is already at the beginning/end of the current frame, <ctrl+home/end>
will be no-op.





<tab>



moves the caret to the next focusable widget.



moves the caret to the next focusable widget.

<shift+tab>



moves the caret to the previous focusable widget.



moves the caret to the previous focusable widget.

*Text Selection*









<shift>+any the caret movement keys listed above



will move the caret from the current position (A) to the destination
position (B) and select the text between A and B.











<alt+[/]>



put the caret out of form control



no operation

    And since your audience is frequently programmer-centric you may
wish to formally define terms such as "widget: link, form control etc."

6. Since you mentioned WCAG in unresolved issues, and opened with a
comment about Section 508, I just wanted to clarify they are not the
same beasts. More intelligent conversation on the matter is out on the
Internet to be found, but my point is that perhaps you want to focus on
one or the other to set your 'standard'. As an aside, the Mozilla
Section 508 Compliance page says the VPAT provided it is "..not a
legally binding VPAT". It can never be - only the *Government Agency* is
responsible for ensuring compliance. The vendor is never legally
accountable (except through contracting negotiations), Section 508
requires each agency to be accountable and cannot delegate that
responsibility contractually.

7. I really want to understand the model for how accessibility through
keyboard navigation is enhanced by this proposal. I would like to see a
reference - not in this document, but provided for review - of commands
that were 'pruned' or depreciated for this version. It would probably
also allow more constructive feedback from the community (rather than us
trying to compare documents).

I can't test the newest version yet - I have a CD on the way - but don't
expect any proposal feedback, just bug reports (smiles). Please let me
know if there are any other issues I can help address in my spare time.

Warm regards,

Norman Robinson


Peter Korn wrote:

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