Closed Bug 303712 Opened 19 years ago Closed 13 years ago

Improve F6 navigation in Compose window

Categories

(Thunderbird :: Message Compose Window, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 682424

People

(Reporter: mcow, Unassigned)

References

Details

(Keywords: access)

TB 1.0.6, 1.0+0806, Win2K, Classic theme

Mozilla supports multiple sets of keystrokes to shift focus among fields.  The 
compose window is a special case because its main field is a text-entry field 
that must accept tab characters.

  Tab works to shift focus in order:
    From : { <addr select> : <addr> } : Subject : Body  (can't tab out of body)
  Shift+Tab works to shift in order:
    From : Body : Subject : { <addr> : <addr select> } : From  (cycles)

Note that the Attachment box, if visible, is *not* included in the tab order; 
and Tab/Shift+Tab shift focus between the various header fields and header-
selection buttons in the expected order.

The Mozilla 1.7 compose window uses F6/Shift+F6 and Ctrl+Tab/Shift+Ctrl+Tab to 
cycle thru all those fields and includes the attach box (but see bug 236219):
  F6 and Ctrl+Tab:
    <addr select>/<addr> : Subject : Attach : Body : From : <addr>
  Shift+F6 and Shift+Ctrl+Tab:
    <addr select>/<addr> : From : Body : Attach : Subject : <addr>

This alternate tabbling shifts entirely out of the address-widget complex to the 
next field, regardless of which subwidget has the focus (a good thing!). 
Shifting *into* the address complex, the focus is placed at the end of the last 
header.

Thunderbird works fine with shifting out of the address complex, but will not 
shift *into* the address field at all.

Steps to reproduce:
1) Open TB compose window (focus in first address field)
2) Type F6, Shift+F6; observe location of focus
3) Type Alt+R, F6; observe location of focus

Actual results:
2) Focus is on Subject field
3) Focus is on From field

Expected results:
2 and 3) Focus is on address field


In addition, TB exhibits the symptoms of bug 236219.
Depends on: 311217
I'm going to morph this bug a bit.  The expected results in the original report are actually now what's happening in 2b1 and 3a1, I think because of the patch at bug 236219.

Now, the Tab/Shift+Tab order is as described, and the F6/Shift+F6 order is as described for Moz 1.7.  But, unlike the suite, TB has the Contacts Sidebar.  When this is visible, focus can be shifted to it via the keyboard by starting at the Identity (From) dropdown and hitting Shift+Tab repeatedly to visit each of the controls:
  From : Add-to-CC : Add-to-To : contact-list : Search : AB-selector : 
    Body : Subject : { <addr> : <addr select> } : From  (cycles)

From any point in the sidebar, Tab will reverse the above order until the message body is reached, at which point Tab is accepted as input to the editor.

F6/Shift+F6 does not shift focus into the contacts sidebar.  If the focus is on any field in the Contacts Sidebar, F6 shift the focus to the Subject, and Shift+F6 shifts it to the Identity selector.

This seems confusing:
1) F6 is closely redundant with Tab -- compare to the function of F6 in the 3-pane which switches only across the panes (selecting a specific control in each pane as the target), while Tab visits every non-toolbar control that can take focus.

2) The Attachment panel is not part of the normal tab order, even tho it appears to be a regular control.

3) The Sidebar is limited in accessibility (altho less so with the patch for bug 364229).
Severity: minor → enhancement
OS: Windows 2000 → All
Hardware: PC → All
Summary: F6 navigation problem in Compose window → Improve F6 navigation in Compose window
QA Contact: message-compose
Assignee: mscott → nobody
So, the question remaining is, should (shift)f6 cycle through contact sidebar?

(comment 0 is WFM)
Blocks: tbattacha11y
(In reply to comment #1)
> This seems confusing:
> 1) F6 is closely redundant with Tab -- compare to the function of F6 in the
> 3-pane which switches only across the panes (selecting a specific control in
> each pane as the target), while Tab visits every non-toolbar control that
> can take focus.

The big difference between Tab and F6 is that tab will cycle through each and every recipient with 2 stops per recipient, potentially hundreds of stops depending on the number of recipients. Imho, F6 is very helpful here and I don't think it would be helpful to drop any of the existing F6 stops.
We currently have 4 to 5 stops for F6, which is still a very reasonable number.
From : Recipients : Subject : [Attachment panel if present] : Body 
 
> 2) The Attachment panel is not part of the normal tab order, even tho it
> appears to be a regular control.

Bug 473901 - Attachment(s) in compose window are poorly accessible via keyboard (implement Tab and Ctrl+Tab stop for composition's attachment pane)

> 3) The Sidebar is limited in accessibility (altho less so with the patch for
> bug 364229).

Very true. Especially, as mentioned by Wayne's comment 2, there should be an F6 stop at the contacts sidebar, for which I would recommend a new bug to avoid the outdated parts this bug.

There are a number of other bugs of interest for contacts sidebar keyboard accessibility.
Depends on: 473901
Depends on: 682424
(In reply to Wayne Mery (:wsmwk) from comment #2)
> So, the question remaining is, should (shift)f6 cycle through contact
> sidebar?
> (comment 0 is WFM)

Per comment 2 and as analysed in comment 3, all aspects of this bug, including the morphing of comment 1, are either fixed or covered by other bugs. For the remainder, I just filed

Followup Bug 682424 - Contacts sidebar excluded from Ctrl+Tab/F6 cycles in message compose window (implement Ctrl+Tab/F6 stop for keyboard accessibility).

So this bug is finally ripe for closure, not sure about the best resolution, some things are fixed by other bugs, some are wfm, otherwise, given the remainder, it now looks like a duplicate of bug 682424.
Iow, the bird is getting better bit by bit...
Status: NEW → RESOLVED
Closed: 13 years ago
No longer depends on: 682424
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.