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)
Thunderbird
Message Reader UI
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)
806 bytes,
patch
|
Bienvenu
:
review+
mscott
:
superreview+
|
Details | Diff | Splinter Review |
814 bytes,
patch
|
mscott
:
review-
|
Details | Diff | Splinter Review |
896 bytes,
patch
|
neil
:
superreview-
|
Details | Diff | Splinter Review |
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•18 years ago
|
||
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?
Reporter | ||
Comment 2•18 years ago
|
||
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•18 years ago
|
||
Thanks Victor, I don't think the Date and Subject rows are even tabbable in fact. I'll dig a little deeper.
Comment 4•18 years ago
|
||
(BTW I would confirm this bug but I don't have confirm privileges yet)
Updated•18 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•18 years ago
|
||
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•18 years ago
|
||
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.
Reporter | ||
Comment 7•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
To clarify... the fact that we can tab to the non-actionable non-editable fields "Subject" and "Date" is odd to me.
Comment 10•18 years ago
|
||
I think it's actionable in that you can select and copy text, no?
Comment 11•18 years ago
|
||
Good point! Thanks Aaron.
Comment 12•18 years ago
|
||
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...
Updated•18 years ago
|
Attachment #252481 -
Attachment is patch: true
Attachment #252481 -
Attachment mime type: text/x-patch → text/plain
Comment 13•18 years ago
|
||
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?
Reporter | ||
Comment 14•18 years ago
|
||
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.
Reporter | ||
Comment 15•18 years ago
|
||
You can observe similar behavior in Microsoft Outlook, for example.
Comment 16•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
-moz-user-focus is only deprecated for use in HTML. Use tabindex in HTML and -moz-user-focus in XUL.
Comment 19•18 years ago
|
||
(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•18 years ago
|
||
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.
Reporter | ||
Comment 21•18 years ago
|
||
David, how can I review your updates? I.E. what Thunderbird should I be testing?
Comment 22•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
(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
Reporter | ||
Comment 25•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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)
Updated•18 years ago
|
Attachment #254055 -
Flags: superreview?(mscott)
Attachment #254055 -
Flags: review?(bienvenu)
Attachment #254055 -
Flags: review+
Updated•18 years ago
|
Attachment #254055 -
Flags: superreview?(mscott) → superreview+
Updated•18 years ago
|
Status: NEW → ASSIGNED
Updated•18 years ago
|
Summary: Not all Message fields text labels are communicated to accessibility API → Not all Message fields are tab navigable
Comment 28•18 years ago
|
||
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
Comment 29•18 years ago
|
||
(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•18 years ago
|
||
Mike, I agree it isn't slick. Will post an improvement...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 31•18 years ago
|
||
Attachment #254055 -
Attachment is obsolete: true
Comment 32•18 years ago
|
||
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)
Updated•18 years ago
|
Status: REOPENED → ASSIGNED
Comment 33•18 years ago
|
||
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 34•18 years ago
|
||
Comment 35•18 years ago
|
||
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)
Comment 36•18 years ago
|
||
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.
Updated•18 years ago
|
Attachment #254055 -
Attachment is obsolete: false
Comment 37•18 years ago
|
||
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?
Updated•18 years ago
|
Assignee: david.bolter → mscott
Status: ASSIGNED → NEW
Component: Message Compose Window → Mail Window Front End
QA Contact: message-compose → front-end
Comment 38•18 years ago
|
||
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 40•18 years ago
|
||
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•18 years ago
|
||
Mike, thanks for the shift-f10 tip.
Updated•18 years ago
|
Status: NEW → ASSIGNED
Comment 42•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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)
Comment 45•18 years ago
|
||
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•18 years ago
|
||
(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•18 years ago
|
||
Comment on attachment 255340 [details] [diff] [review] suite version Karsten and Neil should review this suite change.
Attachment #255340 -
Flags: review?(mscott)
Updated•18 years ago
|
Attachment #255340 -
Flags: superreview?(neil)
Attachment #255340 -
Flags: review?(mnyromyr)
Comment 48•18 years ago
|
||
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-
Comment 49•18 years ago
|
||
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•18 years ago
|
||
Comment on attachment 255340 [details] [diff] [review] suite version Clearing r?, because Neil already denied sr.
Attachment #255340 -
Flags: review?(mnyromyr)
Comment 51•18 years ago
|
||
Comment on attachment 255166 [details] [diff] [review] border no longer offsets. minusing based on Neil's comments.
Comment 52•18 years ago
|
||
Comment on attachment 255166 [details] [diff] [review] border no longer offsets. minusing based on Neil's comments.
Attachment #255166 -
Flags: review?(mscott) → review-
Comment 53•17 years ago
|
||
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).
Updated•17 years ago
|
Blocks: tbird3access
Comment 54•17 years ago
|
||
(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•17 years ago
|
||
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•17 years ago
|
||
(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•17 years ago
|
||
> 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•17 years ago
|
||
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 ago → 17 years ago
Resolution: --- → FIXED
Comment 59•17 years ago
|
||
Hmmm. I don't think the suite version ever made it in. Reopening and marking 397652 as a dependency. Sorry for noise.
Comment 60•17 years ago
|
||
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.
Updated•17 years ago
|
Whiteboard: orca:high
Comment 61•17 years ago
|
||
(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
Updated•17 years ago
|
Flags: blocking-thunderbird3?
Comment 62•17 years ago
|
||
(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.
Updated•17 years ago
|
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Comment 63•16 years ago
|
||
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•16 years ago
|
||
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
Comment 66•16 years ago
|
||
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
Comment 67•16 years ago
|
||
(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
Comment 68•16 years ago
|
||
message reader bugs to dmose for later processing.
Assignee: nobody → dmose
Updated•16 years ago
|
Component: Mail Window Front End → Message Reader UI
QA Contact: front-end → message-reader
Hardware: x86 → All
Version: unspecified → Trunk
Updated•16 years ago
|
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0rc1
Comment 69•15 years ago
|
||
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 → ---
Comment 70•15 years ago
|
||
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•15 years ago
|
||
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 ago → 15 years ago
Resolution: --- → FIXED
Comment 72•15 years ago
|
||
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
Updated•13 years ago
|
Blocks: tb-keyboard-tracker
You need to log in
before you can comment on or make changes to this bug.
Description
•