KEYNAV Bugs and Accessibility



Calum,

I have started looking at the keynav bugs you have raised to assess their 
impact on Accessibility. The first one I have looked at 
53612: KEYNAV:GtkNoteBook whose description I have copied below. I have 
made some comments on the issues raised in the bug below. These are mostly
trying to understand which of the changes are usability requirements and
which are accessibility requirements. These comments are between <POB> and 
</POB>.

Padraig

NB I've used the term "page label" here to refer to the label on a notebook
page's tab control, to try and avoid using the word "tab" in different
contexts too much!

In containers such as the notebook control, the widget that has focus
should take priority over the container when processing navigation keys--
e.g. in a multi-line input field on a notebook page, the input field should
process the Ctrl+Tab shortcut, not the notebook.

Navigate out of noteboook:

- If last control on frontmost page of notebook has focus, pressing Tab
should move focus to the first control after the notebook.

<POB> This currently works. </POB>

- If the frontmost page label has focus, Shift+Tab should move focus to the
last control before the notebook.

<POB> This currently works. </POB>

- If any control on the frontmost page of the notebook (including its page
label) has focus, Ctrl+Tab (*) should move focus to the first control after
the notebook.

- If any control on the frontmost page of the notebook (including its page
label) has focus, Shift+Ctrl+Tab should move focus to the last control
before the notebook.


<POB> This currently does not work. This seems to me to be a usability 
requirement rather than an accessibility requirement in that an application
would still be accessible without this feature being implemented. </POB>

Navigate between page tabs:

- When any page label has focus, left and right arrow keys should move
focus to the previous/next page label without bringing that page to the
front.  (It's been suggested that this should *not* wrap around, I'm not
sure about this).  

<POB> This currently works but does wrap around. </POB>

- When any control in the notebook has focus (including any page label),
Ctrl+PgUp should bring the next tab to the front, and Ctrl+PgDn should
bring the previous tab to the front.  In either case, the control on the
new frontmost page that last had focus is given focus again.  (This should
also wrap around or not, depending on what we decide to do in the
left/right arrow key case above.)

<POB> This currently does not work. This seems to me to be a usability 
requirement rather than an accessibility requirement in that an application
would still be accessible without this feature being implemented. </POB>

Navigate between page labels and page content:

- When any page label has focus, pressing Enter should bring that page to
the front but leave focus on the page label

<POB> This currently works. </POB>

- When any page label has focus, pressing Tab or Ctrl+down arrow should
give focus to the first control on that page, bringing the selected page to
the front if necessary

<POB> This currently does not work. This seems to me to be a usability 
requirement rather than an accessibility requirement in that an application
would still be accessible without this feature being implemented. </POB>

- When any control on the frontmost page has focus, pressing Ctrl+up arrow
should give focus to that page's label.

<POB> This currently does not work. However pressing the up arrow gives
focus to that page's label. </POB>

(*) Latest build of Sawfish (0.38) defaults to Ctrl+Tab for
window-cycling-- we'd need to push back on this to support the proposed
keybindings, as Ctrl+Tab is suggested here and elsewhere as the "navigate
me out of this container" shortcut.

[Check http://developer.gnome.org/projects/gap/keyboardnav.html for any
later proposals that may not have filtered through to this bug report yet]






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]