364376 - Not all Message header fields are focusable by <tab> (Keyboard accessability)

Status: VERIFIED FIXED

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

Description

[Victor Tsaran]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

When tabbing through the message fields (from, to, date, subject etc), not all of the text labels, if any, are communicated to the accessibility API.

Reproducible: Always

Steps to Reproduce:
1. Launch your favorite screen reader or use Microsoft's tools such as AccExplorer or Object Inspector.
2. Open a new message and start tabbing through the message fields.
Actual Results:  
Only some of the text labels are spoken, such as "subject and from.

Expected Results:  
All of the fields should speak their labels, e.g. "from", "to", "date" etc.

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Victor,

Thanks for the report. Are the labels that are spoken consistently spoken? Always the same ones? And the same ones that are not, and consistently not?

Comment 2

[Victor Tsaran]

Yes to both.
For example, when you open a message that you received, the following fields are not spoken:
1. Date.
2. Subject.

Also, the "From" field is not in thetab order.

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks Victor, I don't think the Date and Subject rows are even tabbable in fact. I'll dig a little deeper.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

(BTW I would confirm this bug but I don't have confirm privileges yet)

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

I'm looking through the css -moz-user-focus rules to see if I can figure out what might be happening. Sorry for the play-by-play but I'm juggling tasks and I don't want to lose context on this bug.

Note that Date and Subject values appear to be links. This might be relevant.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

Victor, I've miscommunicated. Let me restate what I experience:
Subject: can tab to this.
From: can not tab to this, appears to be a link.
Date: can tab to this.
To: can not tab to this, appears to be a link.

Comment 7

[Victor Tsaran]

Yes, the tabbing order you experience is correct. However, even though the "from" and "to" fields are links, they still should be tabbable, in my opinion. Otherwise, the user has no way of reviewing who the message came from or its date, once the message has been opened.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

I agree.  The tabbing of each of the four fields should be consistent. It doesn't make sense that we can tab to the "Subject" and "Date", but neither the "To" nor "From".  I have to admit I'm not used to being able to tab to things that are not editable or actionable (i.e. Subject and Date of existing email messages) so while I might be able to fix this and make them all tab-able... I'm a bit nervous as to whether that is expected behaviour.

What is the non-tab way to access those fields?  (Or is there one?)

Comment 9

[David Bolter [:davidb] (NeedInfo me for attention)]

To clarify... the fact that we can tab to the non-actionable non-editable fields "Subject" and "Date" is odd to me.

Comment 10

[Aaron Leventhal]

I think it's actionable in that you can select and copy text, no?

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

Good point!  Thanks Aaron.

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

Attachment: a partial solution?

This has been a bit like looking for a needle in a haystack (for me). This minimal patch *seems* to make the additional fields tab accessible but visually there is no focus border...

Comment 13

[David Bolter [:davidb] (NeedInfo me for attention)]

Also, FWIW, I was able to use DOM Inspector to discover that the things we are trying to be able to tab to are xul:label (within xul:mail-emailaddress) with class: emailDisplayButton plain, and xbl:inherits is "value-label,crop" but I'm guessing we need something like xbl:inherits value=label,crop,tabindex,accesskey?

Comment 14

[Victor Tsaran]

Just to clarify: it is important to be able to tab through all the fields because the user may want to arrow through the information placed in the read-only fields or copy the "from" address, for example.

Comment 15

[Victor Tsaran]

You can observe similar behavior in Microsoft Outlook, for example.

Comment 16

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks Victor. I agree it is important to be able to tab through all the fields and I'm pretty sure I understand the desired behavior. Right now with my patch I think we can additionally tab to the From and To fields instead of just Subject and Date as before but I haven't confirmed 100%. Also my patch is still a work in progress I'm afraid as I want to visually indicate focus and automatically select the text (email addresses) in the From and To and other fields.

Comment 17

[alexander :surkov (:asurkov)]

Comment on attachment 252481 [details] [diff] [review]
a partial solution?


> mail-emailaddress {
>   -moz-binding: url("chrome://messenger/content/mailWidgets.xml#mail-emailaddress");
>+  -moz-user-focus: normal;
> }

IIRC -moz-user-focus is deprecated, use @tabindex instead.

Comment 18

[Aaron Leventhal]

-moz-user-focus is only deprecated for use in HTML.
Use tabindex in HTML and -moz-user-focus in XUL.

Comment 19

[alexander :surkov (:asurkov)]

(In reply to comment #18)
> -moz-user-focus is only deprecated for use in HTML.
> Use tabindex in HTML and -moz-user-focus in XUL.
> 

It is deprecated because CSS shouldn't define behaviour of element. I think since tabindex works in XUL then it's better to use it.

Comment 20

[Aaron Leventhal]

It's only deprecated by W3C official CSS spec. This isn't official CSS since it starts with "-moz".

Mozilla uses lots of -moz CSS internally to define behavior of all it's widgets. See xul.css. We even point to XBL behavior files that way.

Comment 21

[Victor Tsaran]

David, how can I review your updates? I.E. what Thunderbird should I be testing?

Comment 22

[David Bolter [:davidb] (NeedInfo me for attention)]

Victor, my changes are not going to be in a distributed build of thunderbird (yet).  Are you set up to patch and build Mozilla source?  Feel free to email me if you want to discuss, it would be great to get you set up.

Comment 23

[Aaron Leventhal]

Actually, the day after a fix is checked in, the changes show up in automated test builds here:
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/
So Victor doesn't have to build from source.

Comment 24

[alexander :surkov (:asurkov)]

(In reply to comment #20)
> It's only deprecated by W3C official CSS spec. This isn't official CSS since it
> starts with "-moz".

Ok, it's clear enough and moreover via your post https://bugzilla.mozilla.org/show_bug.cgi?id=313088#c9 :)

Comment 25

[Victor Tsaran]

I see that the nightly builds have Thunderbird versioned at 3.0A. Does this mean that accessibility-related changes will not see the light in Thunderbird 2.0?

Comment 26

[Aaron Leventhal]

That's unfortunately correct. We can move possibly some critical fixes to Thunderbird 2 but I think it's in the shutdown/release phase. So we have to wait for Thunderbird 3 for most accessibility fixes. It's already in beta 2 and release candidates will be coming soon.

We can try to get some changes in and see what they say, but I'm not optimistic.

Comment 27

[David Bolter [:davidb] (NeedInfo me for attention)]

Attachment: allow user to tab to email fields in header

I've added a border style for when an email field has focus. This should fix the bug as described. One thing we might want to add is keyboard invoke-ability of the popup menu you get when you click on an emailAddressNodes although that could be reported as a separate bug.

Comment 28

[:Gijs (he/him)]

Checking in mozilla/mail/base/content/messenger.css;
/cvsroot/mozilla/mail/base/content/messenger.css,v  <--  messenger.css
new revision: 1.18; previous revision: 1.17
done

Comment 29

[Mike Cowperthwaite]

(In reply to comment #27)
> I've added a border style for when an email field has focus. This should fix
> the bug as described.

I'm not real happy with this fix, because it causes the address to shift 1px down and right when it gets the focus, because the unfocused version has no border.  A way to solve this is to have a 1px border of the background color when not focused, or maybe to use CSS 'outline' instead of border.

Comment 30

[David Bolter [:davidb] (NeedInfo me for attention)]

Mike,
I agree it isn't slick. Will post an improvement...

Comment 31

[David Bolter [:davidb] (NeedInfo me for attention)]

Attachment: border no longer offsets.

Comment 32

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 255166 [details] [diff] [review]
border no longer offsets.

Hi David, I wasn't sure to take this straight to sr or not. Thought it best to run it by you just in case. The original fix caused an offset effect on focus. This patch follows existing similar, but better, focus styling css techniques found elsewhere in the code base.

Comment 33

[David :Bienvenu]

Comment on attachment 255166 [details] [diff] [review]
border no longer offsets.

switching review to Scott -he's much more of a UI expert.

Comment 34

[David Bolter [:davidb] (NeedInfo me for attention)]

Attachment: suite version

Comment 35

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 255340 [details] [diff] [review]
suite version

Scott, I'm not experiences with mozilla styling and the styling I used here was taken from existing styles. I wonder if we should use some kind of "select" style, since the date and subject fields appear selected when focused.

Comment 36

[Mike Cowperthwaite]

See bug 242468 comment 2; that bug is filed because the user doesn't like tab going into the envelope at all.  I see his point, to a degree, altho the other comments in that bug are noise.

I also notice that the Attachments panel is not navigable; I guess we need a new bug for that.

(xref for Seamonkey: bug 165999, bug 217770, bug 205666.)

David, the new patch doesn't obsolete the previous one; it builds on it.

Comment 37

[David Bolter [:davidb] (NeedInfo me for attention)]

Mike,

Great info thanks. It kind of puts this all into question. Certainly if we are going to allow users to use the mouse to click on the email address fields (which causes a popup), and to select text from the subject and date fields, it could be argued that we should provide keyboard access to the same functionality. My patch does not yet provide a keyboard solution for invoking the email address popup.

What do you think?

Comment 38

[Mike Cowperthwaite]

You can invoke the popup (at least under windows) with Shift+F10 -- that's the equivalent of the 'menu' key on 106-key keyboards for Windows.  In Mozilla, dropdowns on listboxes can be opened using Alt+Down; that might be an option here.

For the static fields, it's possible to select subsets of the string using Right/left/up/down with (and without) Shift, but with no selection the caret is not visible, which makes it tricky.

I don't know if it's worth introducing a preference for "full accessibility" so that full keyboard nav is not in place for people comfortable with the mouse.

Another option for the envelope navigation is to not shift focus to the envelope without a special accessor, say F5: this would move the focus to the first header in the envelope (if a message is displayed), at which point tabbing moves across those fields normally.  Tabbing from the end shifts focus to the message body (which is its own can of worms due to focusable subelements), and Shift+Tab from the From: heaer field moves back to the thread pane -- but a simple Tab from the Thread pane skips directly to the message body, and Shift+Tab from body returns focus to thread pane.

Comment 39

[Mike Cowperthwaite]

Sorry, didn't mean to reassign.

Comment 40

[Mike Cowperthwaite]

An RSS feed item has an additional active "Website" header, which is in tab-order now now but does not show focus -- 3a1-0226.  When it has the focus, you can press Shift+F10 and get the popup with "Copy link location".

Comment 41

[David Bolter [:davidb] (NeedInfo me for attention)]

Mike, thanks for the shift-f10 tip.

Comment 42

[Thomas D. (:thomas8)]

With the present summary ("Not all Message fields are tab navigable"), this bug will be hard to find, esp. because it should be  message *header* fields rather than just message fields, and the word focus is missing. Perhaps this bug should be renamed to something like
"Not all Message header fields are focusable by <tab> (Keyboard accessability)"
(Similar bug 373996 - "Attachment panel is not focusable by <tab> (Keyboard accessibility)" - was renamed in this way by admins to make the summary more precise and find-friendly)

Comment 43

[Thomas D. (:thomas8)]

Since the main discussion and proposed patch seems to be here in this bug, the following bugs might be considered duplicates of this bug (though with opposite request, namely to exclude/relocate all headers in tab sequence)?:
bug 374206, bug 242468 (or at least one of those is a duplicate of the other)

I only just realized that you can use <Ctrl+Tab> to get directly from Message
List (ML) to Message Preview (MP) and then straight to Folder List (FL). Attachment pane (AP) is going to be included in the tab sequence when bug 373996 will be fixed. Not sure whether tabbed messages as of TB 2 will have an influence on this?

In view of this, I think that the patch proposed in this bug will be a good and viable solution for both, those who advocate for all or no headers to be included in the tab sequence:

<tab> focuses everything on the way (for full keyboard access, left-right, top-down as prescribed in xul-accessability guidelines)

<ctrl+tab> switches focus "fast-track" between the four main parts of the main window (after fix for bug 373996) for those who want to skip the details:
FL > ML > MP > AP > FL

Comment 44

[David Bolter [:davidb] (NeedInfo me for attention)]

Thomas, I've updated the summary as per your comment 43. Thanks. 

Do you approve of the patch on this bug as is?

Comment 45

[David Bolter [:davidb] (NeedInfo me for attention)]

Thomas, I've updated the summary as per your comment 42. Thanks. 

Do you approve of the patch on this bug as is?

Comment 46

[Thomas D. (:thomas8)]

(In reply to comment #45)
> Thomas, I've updated the summary as per your comment 42. Thanks. 
> Do you approve of the patch on this bug as is?

Is that a question to ME? Still new here, and I'm not fluent enough (or at all) in moz code to understand your patch from just reading the source code. Any way I can see your patch in action?
But I do agree with the underlying principle (which I think is what your patch does) as described in #43, and also your plans to automatically highlight email addresses like from & to (for copy) when these get focus. Sounds good to me!

Comment 47

[Scott MacGregor]

Comment on attachment 255340 [details] [diff] [review]
suite version

Karsten and Neil should review this suite change.

Comment 48

[[e-mail]]

Comment on attachment 255340 [details] [diff] [review]
suite version

The -moz-user-focus looks fine (although I haven't tried it) but the outline is wrong because it belongs in the theme (and invert doesn't work in trunk?)

Comment 49

[Thomas D. (:thomas8)]

Perhaps Bug 376486 should be taken into consideration when fixing this bug: missing cursor inside header fields with focus makes selective highlighting a blind game. To allow focusing on subject & date makes sense only for copying, copying needs proper highlighting, and proper highlighting needs a visible cursor. When user <tab>s into from & to, these should be highlighted automatically as has been suggested for the patch and as is the case with subject now, and at the end of blue highlighting, the cursor should blink.

Comment 50

[Karsten Düsterloh]

Comment on attachment 255340 [details] [diff] [review]
suite version

Clearing r?, because Neil already denied sr.

Comment 51

[Scott MacGregor]

Comment on attachment 255166 [details] [diff] [review]
border no longer offsets.

minusing based on Neil's comments.

Comment 52

[Scott MacGregor]

Comment on attachment 255166 [details] [diff] [review]
border no longer offsets.

minusing based on Neil's comments.

Comment 53

[Joanmarie Diggs]

Using the latest trunk build in Linux, I can Tab among all of the fields in the message header, but Shift+Tab only moves focus to the To: and From: fields. (i.e. it skips Date and Subject).

Comment 54

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #53)
> Using the latest trunk build in Linux, I can Tab among all of the fields in the
> message header, but Shift+Tab only moves focus to the To: and From: fields.
> (i.e. it skips Date and Subject).
> 

This seems to have been resolved.

The css still isn't quite right and tabbing among these fields seems to cause a slight reflow.

Note I've created a separate bug 397576 for a related issue with expanders.

Comment 55

[Joanmarie Diggs]

I can confirm they're in the Tab order now.  However, we are not getting any focus (or other) events for the To and From fields. Should we create a separate bug for that as well?

Comment 56

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #55)
> I can confirm they're in the Tab order now.  However, we are not getting any
> focus (or other) events for the To and From fields. Should we create a separate
> bug for that as well?
> 

I think you might have captured the focus issue here: bug 387838; but please add to that bug if there is additional concern. We'll want to confirm the events for the preview area as well as when the message is opened.

Comment 57

[Joanmarie Diggs]

> I think you might have captured the focus issue here: bug 387838

Yup, you're right.  My bad! Premature senility is a... a... I don't remember... I'm sorry, what were we talking about? ;-)

Thank you for the reminder!

Comment 58

[David Bolter [:davidb] (NeedInfo me for attention)]

Closing as fixed via the patches that made it in.

I've opened bug 397652 for the styling work; so that it isn't lost in this lengthy  bug discussion.

Comment 59

[David Bolter [:davidb] (NeedInfo me for attention)]

Hmmm. I don't think the suite version ever made it in. Reopening and marking 397652 as a dependency. Sorry for noise.

Comment 60

[Lothar]

Agent version 3.0a1pre (2007112704).
As "main discussion" I report here not at Bug 242468.

The "+" for expanding headers should be included in tab sequence.

The "Message-ID" field is omitted, if "view all headers" is activated. The "+" for expanding the ID should be included, too.

Comment 61

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #60)
> Agent version 3.0a1pre (2007112704).
> As "main discussion" I report here not at Bug 242468.
> 
> The "+" for expanding headers should be included in tab sequence.
> 
> The "Message-ID" field is omitted, if "view all headers" is activated. The "+"
> for expanding the ID should be included, too.
> 

Lothar, thanks for bringing this up here. Note there is specific bug 397576.

Adding helpwanted keyword to this bug since I can't commit time to this right now, and it is a high orca priority.

Comment 62

[Mike Cowperthwaite]

(In reply to comment #58)
> Closing as fixed via the patches that made it in.

Note that the behavior described in comment 40 persists -- not sure if that's styling or something else, and not sure whether that's technically part of this bug.


(In reply to comment #60)
> The "+" for expanding headers should be included in tab sequence.

I don't agree with that; see my comment at bug 397576.


> The "Message-ID" field is omitted, if "view all headers" is activated.

In-Reply-To and Message-ID have both changed since I last looked at these, to be twisty enabled.  In my somewhat old build (3.0pre-0123), neither field is in the tab order at all, which definitely falls under the scope of this bug.

Comment 63

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

Watchers of this bug might want to keep an eye on bug 449691 to make sure that any new changes are done correctly for accessibility

Comment 64

[Mark Banner (:standard8)]

Retriaging according to new policy for flags.
https://wiki.mozilla.org/Thunderbird:Release_Driving
(bugs marked wanted- don't indicate we wouldn't accept patches, but that they're not going to be the focus for release drivers)

Comment 65

[David :Bienvenu]

moving to b2

Comment 66

[David Ascher (:davida)]

Would bug 449560 provide the same level of accessability?  That approach makes more sense to me in providing the data that screen readers need while not resulting in hugely long tab loops.

Shifting to b3 because I don't think anyone is likely to get to this by b2.

Comment 67

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #66)
> Would bug 449560 provide the same level of accessability?  That approach makes
> more sense to me in providing the data that screen readers need while not
> resulting in hugely long tab loops.

Yep, the ARIA bug work will help (and might be really simple).

Note that if there are actions that a user can perform on these fields only via the mouse (probably via right-click), then we should consider what the keyboard interaction should be for accessing the same functionality. Perhaps having equivalent functionality in a menu would suffice.

[Aside: as you might have guessed, I'm not focusing on tbird bugs these days]

Comment 68

[David Ascher (:davida)]

message reader bugs to dmose for later processing.

Comment 69

[Dan Mosedale (:dmosedale, :dmose)]

Since bug 449560 has been fixed, we definitely won't block Tb3 on this.

Comment 70

[Thomas D. (:thomas8)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3pre) Gecko/20090818 Shredder/3.0b4pre

This bug should be closed "worksforme", as the two main problems covered have been solved (in the current nightly as above):

1.) "from" and "to" headers are now included in the tab sequence (cf. current summary: Not all Message header fields are focusable by <tab>)
2.) I assume text labels should now be communicated correctly to the accessibility API, since bug 449560 has been fixed (Accessibility: Give header email labels (From/To/CC) ARIA label properties in message reading window/pane.)

Most of the outstanding minor issues are covered by other bugs (twisty not in the tab sequence etc.).

The following two minor issues should go into follow-up bugs, if there aren't any such bugs yet:
- comment #40: "Website" header for RSS feed items doesn't indicate focus
(this isn't part of this bug as per its current summary)
- comment #62, bottom: With View > headers > all, In-Reply-To and Message-ID header fields aren't focusable by <tab> (keyboard accessability)
(this might be part of this bug as per its current summary, but then the description in comment #0 covers a completely different problem and so a new bug for these minor issues would be better and easier to find)

Comment 71

[Marco Zehe (:MarcoZ)]

This bug is obviously fixed, with a few minor issues that can be dealt with in follow-up bugs.

Comment 72

[Marco Zehe (:MarcoZ)]

Verified in Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.5) Gecko/20091112 Thunderbird/3.0