373996 - Attachment panel in message reader is not focusable / accessible with the keyboard (needs [TAB] stop)

Status: RESOLVED FIXED

(Thunderbird :: Message Reader UI, defect, P3)

Description

[Thomas D. (:thomas8)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Version 1.5.0.10 (20070221)

In TB 1.5, when using <tab>-key to move focus around between components of the UI, attachment pane will be skipped, i. e. you cannot place focus in attachment pane using <tab>. Furthermore, I could not find keyboard shortcut to place focus on attachment pane. Which means, in the TB's main win, attachment pane if it exists will be inaccessable via keyboard. Has this changed with the new attachment pane implementation for TB2?


Reproducible: Always

Steps to Reproduce:
1. In TB's main win, move around focus using <tab> on a msg with attachments
2. When focus is on msg preview pane (dotted borders), press <tab> once more
3.
Actual Results:  
Focus skips the attachment pane (below preview pane) and jumps straight to folder list on the left

Expected Results:  
Focus should move into the attachment pane (first file attachment should have dotted border)

Comment 1

[Mike Cowperthwaite]

Not just the 3-pane; standalone mail windows show this as well.

This is true in the 2.0pre builds as well, after the reworking done to the attachment panel.

Comment 2

[Wayne Woods]

(In reply to comment #1)
> after the reworking done to the attachment panel.

Can you confirm that this used to work before the attachment panel reworking? I tried Mac builds from 2007, 2006 and 2004 (1.0) and haven't seen a time point at which it ever worked. Maybe it did on Windows, though.

But regression or not, I agree this would be a very useful addition.

Comment 3

[Mike Cowperthwaite]

Wayne, you misunderstand; this bug is reported against 1.5, I was just pointing out that it *continues* to exist in 2.0.

Comment 4

[Wayne Woods]

Cool. The wording made it sound like it was a regression from the attachment changes, and I was racking my brain wondering what could have done it.

Question: Once the attachment pane is focussed, do we want subsequent tabbing to iterate the focus over each individual attachment (similar to behaviour in the header pane, where it iterates over every header), or just jump to a different pane? I think I'd favour the former.

Comment 5

[Thomas D. (:thomas8)]

(In reply to comment #4)
> Question: Once the attachment pane is focussed, do we want subsequent tabbing
> to iterate the focus over each individual attachment (similar to behaviour in
> the header pane, where it iterates over every header), or just jump to a
> different pane? I think I'd favour the former.

Two remarks on this:

1) "behaviour in the header pane, where [tab] iterates over every header"
- oh, does it really? As for me, NOT in TB 1.5, where <tab> only focuses SUBJECT and DATE header in header pane and skips FROM and TO! (Although the latter would be far more important/useful to be focusable via keyboard...) Has this been fixed in TB 2?

2) @Wayne: "do we want focus to iterate over each indiv. attachment or just jump to a different pane?"
I would prefer/recommend that when <tab>ing, focus should jump straight from the first attachment to the next pane in the cycle. Although I am aware of the possible advantage/comfort of simply <tab>ing iteratively through attachments, there are good reasons against attachment iteration:

a) if there are many attachments, having to iterate through all of them just to get to the next pane will be very annoying, especially for keyboard users (including disabled), who want to get things done with as few steps as possible. So what might seem comfortable with 2 or 3 attachments will turn out a nuisance if you have to <tab> through 10+ attachments just to get to the next pane! (you can try out the effect with a mail containing a lot of links, when tb 1.5 forces you to iterate through every single link before you can actually <tab> into the attachment pane!)

b) I can't tell for unix or mac, but for Windows users, <tab>ing through a set of individual file objects within a pane will be very unusual - just have a look at the respective behaviour in Windows Explorer or in fact any simple File-Open-Dialog: <tab>ing ALWAYS gets you quickly to the NEXT PANE (or another UI-object within a dialogue), but NEVER iterates through file objects. To iterate, users will find it very normal that when the focus is on the first attachment file object inside the attachment pane, they will have to press cursor keys to move focus to another file attachment. Considering that your attachment pane, esp. in TB 2, looks more and more like a normal file explorer view, users will expect the respective behaviour...

c)Confusion about attachment selection: In case of <tab>-iteration through att/, seeing that <tab>ing focuses AND selects the next attachments, and knowing that within object lists, I can ALWAYS use <shift> to select a sequence of objects, why should I not use <shift+tab> to select subsequent attachments? Oh, you ALWAYS do THAT using <shift+CURSOR>? Yeah, 'cause <cursor> alone ALWAYS selects next (file/attachment etc.) object in the list (whereas <tab> moves me around the screen)... ;-)

What do you think?

BTW: For the same reason, I would not have been surprised that when focus sits on Subject header in header pane, <tab> would get me to the message text pane, whereas cursor keys would get me to the next headers (from, date, to) inside the header pane. But since there are usually only four headers visible (unless view-all-headers is on), the effect is more transparent and less surprising/annoying compared to attachment iteration with <tab>. Furthermore, <tab>ing through ALL headers view makes more sense than cursoring, since cursors might be needed for text/value selection.

Comment 6

[Thomas D. (:thomas8)]

(In reply to comment #5)
"<tab> does NOT iterate through every header in header pane" is being worked on in bug 364376

Comment 7

[Thomas D. (:thomas8)]

Should this be "blocking-thunderbird3?"

Due to this bug, currently (TB2) there is no way at all to access the attachment panel via keyboard. The only way to focus attachment (panel) is using mouse.
In other words, keyboard users and users with disabilities cannot perform ANY action on attachments at all (like opening, saving, deleting, etc.)

Comment 8

[Marco Zehe (:MarcoZ)]

Still a problem in Shredder Alpha 2. Requesting blocking on this one.

Comment 9

[David Ascher (:davida)]

Tweaking summary to describe the core problem (tabs may be a way to get there).

Comment 10

[David Ascher (:davida)]

message reader bugs to dmose for later processing.

Comment 11

[Mark Banner (:standard8)]

The Thunderbird drivers wish to release Thunderbird 3 as soon as possible. As a result, we feel that this bug shouldn't stand in the way of all the other good work getting into the hands of users sooner rather than later. Therefore we are retargeting it for 3.1. See http://ccgi.standard8.plus.com/blog/archives/242 for more details. The 3.1 release is expected to be a quick release soon after Thunderbird 3.

Comment 12

[Thomas D. (:thomas8)]

Let's make this more actionable by clarifying the needed UI.

Bryan, this is basically the same issue as in bug 473901 (attachment panel not keyboard focusable /when composing/). So can we have ui-review+ for the following changes (adapted from bug 473901 which you already UI-reviewed)? :

-> Add a single <tab> stop and <F6> stop for attachment pane in msg preview and msg standalone window (effective only when it's visible = has attachments)

Note: We should only have a /single/ <tab> stop in attachment pane even if there are multiple attachments, for the following reasons 
- UI consistency, e.g. with OS-wide UI principles: collections/lists of multiple objects or files are more appropriately focused/navigated using cursor keys.
- speed up the <tab> sequence (especially now that we've lost fast-track <ctrl+tab> which is used for switching tabs)

This is a trivial change to ensure attachment pane keyboard accessibility while viewing messages (detailed reasons in bug 473901, comment #5).

Comment 13

[Thomas D. (:thomas8)]

CC'ing Bryan for UI review as per comment 12.

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

Removing myself as the assignee, as I'm not actively working on this bug at the moment.

If this were the last bug for tb 3.1, I don't think we'd hold for it.  That said, we'd love to see this make it.  Adding the new, non-versioned wanted-thunderbird+ flag so that we don't lose track of this.

Comment 15

[Thomas D. (:thomas8)]

Attachment: Add tab stop and F6 stop at message reader's attachment pane (consistency with composition stops as ui-reviewd+ in )

to put this into Bryan's ui-review queue

Comment 16

[Mike Cowperthwaite]

Please do not put an F6 stop on the attachment panel.  In the message-reading window, F6 should have exactly three stops: folder pane, thread pane, preview pane.

Comment 17

[Thomas D. (:thomas8)]

Mike, there will still be three stops with what I propose in comment 15 if you don't have any attachments. If you *do* have attachments, I don't see why we shouldn't have an F6 stop there. Four stops still isn't a lot. Tab alone can be problematic, e.g. if there's lot's of links in the mail, you'd have to tab along all of them just to get to attachments pane, which adds a lot of unnecessary complexity to the process.
Could you elaborate on the reasons why you want only three stops for F6 even when there are attachments in the mail?

Comment 18

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 432009 [details]
Add tab stop and F6 stop at message reader's attachment pane (consistency with composition stops as ui-reviewd+ in )

Adding a tab stop sounds like a reasonable plan however I'm minusing because I don't think we want to add the F6 stop as well.  The F6 was meant to give a way to change focus around the main panes (like ctrl-tab did) and that never had access to the attachments previously so I'm not sure it should now.

To move this forward I'd suggest keeping this just to the <tab> stop and opening a new bug for the F6 so we can separate out the discussion.

Comment 19

[Thomas D. (:thomas8)]

Attachment: Accessibility: Add *single* [tab] stop at message reader's attachment pane (already ui-reviewed+, seperate bug for F6 stop)

Bryan, as you requested in your ui-review comment 18, I have removed my request for F6 stop from this bug (so that it can be discussed seperately in new bug).

Please set ui-review+ for the remainder - adding the [tab] stop only - which you have already ui-reviewed+ in comment 18. Thanks!

Comment 20

[Jim Porter (:squib)]

Attachment: Fix this

This is a relatively simple patch. The treetwisty on the attachment bar is now focusable, and I improved the focusing when you click on it: expanding the attachment pane will put the focus in the attachment list; collapsing it will move focus to the message pane (but only if the attachment list was already focused).

I'm pretty sure the Mac and Linux themes are good here; not sure about Windows, since it's weird. What *should* happen is clicking on the twisty works like before (no focus ring), but tabbing to it should show a focus ring.

Also, pulling forward ui-r+. :)

Comment 21

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 550944 [details] [diff] [review]
Fix this

Review of attachment 550944 [details] [diff] [review]:
-----------------------------------------------------------------

Okay, this took me a while to test, but I finally got the try server builds running on my Windows box, and I like the new way it works.

The code seems fine, and while the try-server had some issues (http://arbpl.visophyte.org/?tree=ThunderbirdTry&pushid=888), I don't think those were related to your patch.

So, to sum up, r=me.

Thanks,
Blake.

Comment 22

[Jim Porter (:squib)]

Checked in: http://hg.mozilla.org/comm-central/rev/5be353843ead

Comment 23

[Jim Porter (:squib)]

Comment on attachment 550944 [details] [diff] [review]
Fix this

Should we try to get this on aurora? It's an accessibility bug, and it would be nice to have this in the same version as the other accessibility fixes to the attachment pane (specifically, bug 630759).

Comment 24

[Jim Porter (:squib)]

Attachment: Don't scroll when hitting space while the twisty is focused

Whoops, of course right after pushing this, I noticed a problem: if the message can be scrolled (or if there are unread messages after the current one), hitting space on the twisty to expand the attachment bar doesn't work. Here's a fix for this. I tried to write a Mozmill test for it, but it didn't seem to want to respond to the space bar at all...

Comment 25

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 554278 [details] [diff] [review]
Don't scroll when hitting space while the twisty is focused

Review of attachment 554278 [details] [diff] [review]:
-----------------------------------------------------------------

Yep, looks good.  My comment below was more idle curiousity, and doesn't affect the r=me.  :)

Thanks,
Blake.

::: mail/base/content/mailWindowOverlay.js
@@ +2305,2 @@
>      contentWindow = window.content;
> +    if (focusedElement && importantElements.indexOf(focusedElement.id) != -1)

I suspect it doesn't matter at this scale, but if there were a lot of these, I wonder if using "focusedElement.id in importantElements" would be better…

Comment 26

[Jim Porter (:squib)]

Checked in: http://hg.mozilla.org/comm-central/rev/bddcd2fad0df

Comment 27

[Mark Banner (:standard8)]

Comment on attachment 550944 [details] [diff] [review]
Fix this

Given this is an enhancement, I don't think we need/want to rush it into 8, I'd rather let it have the full amount of testing on aurora and beta.

Comment 28

[Thomas D. (:thomas8)]

(In reply to Mark Banner (:standard8) from comment #27)
> Comment on attachment 550944 [details] [diff] [review] [diff] [details] [review]
> Fix this
> Given this is an enhancement, I don't think we need/want to rush it into 8,
> I'd rather let it have the full amount of testing on aurora and beta.

Mark, fwiw, I'd think that main UI parts that are inaccessible via keyboard is a major design bug, even though it's so old a bug that one might be inclined to think of it as an enhancement now that it finally has been fixed. For the good of relase notes and PR, I'd much agree with Jim's comment 23:

> Should we try to get this on aurora? It's an accessibility bug, and it would
> be nice to have this in the same version as the other accessibility fixes to
> the attachment pane (specifically, bug 630759).

Just my 2 cents, but if it's avoidable, and assuming this is low-risk, I'd think that it's a bit awkward having to say that we have fixed some, but not all of the accessibility bugs of attachment pane...

Comment 29

[Mark Banner (:standard8)]

Comment on attachment 550944 [details] [diff] [review]
Fix this

I've had a discussion with bwinton and he's convinced me we should take this.

Comment 30

[Mark Banner (:standard8)]

Checked in both patches on aurora:

http://hg.mozilla.org/releases/comm-aurora/rev/61e68359839b
http://hg.mozilla.org/releases/comm-aurora/rev/69f72be98a48

Comment 31

[Thomas D. (:thomas8)]

Mark and Blake, thank you!

Comment 32

[Thomas D. (:thomas8)]

...and Jim, thank you!

Comment 33

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #31)
Weird, I didn't even touch the flags, why did they change?
Target Milestone is now 8, where this was checked in, right?

Comment 34

[Mark Banner (:standard8)]

Nope, milestone is 9 because that's where this landed on trunk (and the status-thunderbird8 indicates the fixed status for 8).