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 (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/), 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
|
