Closed Bug 364376 Opened 18 years ago Closed 15 years ago

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

Categories

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

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: vtsaran, Unassigned)

References

(Depends on 2 open bugs, Blocks 2 open bugs)

Details

(Keywords: access, helpwanted, Whiteboard: orca:high)

Attachments

(3 files, 1 obsolete file)

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.
Keywords: access
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?
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.
Thanks Victor, I don't think the Date and Subject rows are even tabbable in fact. I'll dig a little deeper.
(BTW I would confirm this bug but I don't have confirm privileges yet)
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.

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.
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?)
To clarify... the fact that we can tab to the non-actionable non-editable fields "Subject" and "Date" is odd to me.
I think it's actionable in that you can select and copy text, no?
Good point!  Thanks Aaron.
Attached patch a partial solution? (obsolete) — Splinter Review
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...
Attachment #252481 - Attachment is patch: true
Attachment #252481 - Attachment mime type: text/x-patch → text/plain
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?
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.
You can observe similar behavior in Microsoft Outlook, for example.
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 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.
-moz-user-focus is only deprecated for use in HTML.
Use tabindex in HTML and -moz-user-focus in XUL.
(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.
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.
David, how can I review your updates? I.E. what Thunderbird should I be testing?
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.
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.
(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 :)
Assignee: mscott → david.bolter
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?
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.
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.
Attachment #252481 - Attachment is obsolete: true
Attachment #254055 - Flags: review?(bienvenu)
Attachment #254055 - Flags: superreview?(mscott)
Attachment #254055 - Flags: review?(bienvenu)
Attachment #254055 - Flags: review+
Attachment #254055 - Flags: superreview?(mscott) → superreview+
Status: NEW → ASSIGNED
Summary: Not all Message fields text labels are communicated to accessibility API → Not all Message fields are tab navigable
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
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
(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.
Mike,
I agree it isn't slick. Will post an improvement...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Attachment #255166 - Flags: review?(bienvenu)
Status: REOPENED → ASSIGNED
Comment on attachment 255166 [details] [diff] [review]
border no longer offsets.

switching review to Scott -he's much more of a UI expert.
Attachment #255166 - Flags: review?(bienvenu) → review?(mscott)
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.
Attachment #255340 - Flags: review?(mscott)
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.
Attachment #254055 - Attachment is obsolete: false
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?
Assignee: david.bolter → mscott
Status: ASSIGNED → NEW
Component: Message Compose Window → Mail Window Front End
QA Contact: message-compose → front-end
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.
Sorry, didn't mean to reassign.
Assignee: mscott → david.bolter
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".
Mike, thanks for the shift-f10 tip.
Status: NEW → ASSIGNED
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)
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
Thomas, I've updated the summary as per your comment 43. Thanks. 

Do you approve of the patch on this bug as is?
Summary: Not all Message fields are tab navigable → Not all Message header fields are focusable by <tab> (Keyboard accessability)
Thomas, I've updated the summary as per your comment 42. Thanks. 

Do you approve of the patch on this bug as is?
(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 on attachment 255340 [details] [diff] [review]
suite version

Karsten and Neil should review this suite change.
Attachment #255340 - Flags: review?(mscott)
Attachment #255340 - Flags: superreview?(neil)
Attachment #255340 - Flags: review?(mnyromyr)
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?)
Attachment #255340 - Flags: superreview?(neil) → superreview-
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 on attachment 255340 [details] [diff] [review]
suite version

Clearing r?, because Neil already denied sr.
Attachment #255340 - Flags: review?(mnyromyr)
Comment on attachment 255166 [details] [diff] [review]
border no longer offsets.

minusing based on Neil's comments.
Comment on attachment 255166 [details] [diff] [review]
border no longer offsets.

minusing based on Neil's comments.
Attachment #255166 - Flags: review?(mscott) → review-
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).
Blocks: orca
OS: Windows XP → All
Blocks: tbird3access
(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.
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?
(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.
> 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!
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.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago17 years ago
Resolution: --- → FIXED
Hmmm. I don't think the suite version ever made it in. Reopening and marking 397652 as a dependency. Sorry for noise.
Status: RESOLVED → REOPENED
Depends on: 397652
Resolution: FIXED → ---
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.
Whiteboard: orca:high
(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.
Keywords: helpwanted
Flags: blocking-thunderbird3?
(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.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
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
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)
Priority: -- → P2
Target Milestone: --- → Thunderbird 3.0b2
moving to b2
Target Milestone: Thunderbird 3.0b1 → Thunderbird 3.0b2
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.
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0b3
(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]
Assignee: david.bolter → nobody
message reader bugs to dmose for later processing.
Assignee: nobody → dmose
Component: Mail Window Front End → Message Reader UI
QA Contact: front-end → message-reader
Hardware: x86 → All
Version: unspecified → Trunk
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0rc1
Since bug 449560 has been fixed, we definitely won't block Tb3 on this.
Assignee: dmose → nobody
Flags: blocking-thunderbird3+ → blocking-thunderbird3-
Target Milestone: Thunderbird 3.0rc1 → ---
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)
This bug is obviously fixed, with a few minor issues that can be dealt with in follow-up bugs.
Status: REOPENED → RESOLVED
Closed: 17 years ago15 years ago
Resolution: --- → FIXED
Verified in Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.5) Gecko/20091112 Thunderbird/3.0
Status: RESOLVED → VERIFIED
Depends on: 529762
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: