If we do this we could override the live region hot keys in thunderbird as I wouldn't think we'd ever have live regions in a mail message.  

Mike, that's a cool idea.  I'll play around with this some.

Created attachment 114463 [details] [review]
revision 1: Proof of concept

This adds the bindings Orca+F1 through Orca+F9 to read headers 1 through 9. You can get additional headers by choosing to view all headers.

If you try the command someplace you shouldn't, Orca speaks and brailles the fact that the headers couldn't be found.

If you try to ask for a header that doesn't exist (e.g. the 5th header when you're not displaying full headers), Orca speaks and brailles the fact that header number whatever couldn't be found.

If you luck out and find a header, Orca speaks and brailles it. <smile>

Note: I didn't yet implement this for messages you are composing. The hierarchy is totally different in that case.  How badly do you want that functionality as well?

Question: If we speak and braille the header, we are no longer displaying the current line (this patch doesn't move you to that header; Orca just speaks and brailles it, but you stay put). Orca doesn't have the equivalent of "flash"/or temporary braille messages.  I'm not sure if this is an issue or not.

Finally: This is a super quick and dirty patch which works for me on the one box I've tested it on.  Hopefully it works for y'all.  If so, let me know what I should change.

Will, if you're seeing this, please don't look at the patch yet. <grin>  I had to add a hack in the Thunderbird.py getKeyBindings() because the Gecko live region stuff was stomping on them.  I think we should do something differently, but I haven't done it yet. I just wanted to get something working for Dave and Mike to play with.

Thanks all.

Hi, Joanie,

As far as it goes, this appears to be working.  My problem is that, three Linux installations ago, I bound F2 and F3 to start some programs I was frequently using in Fedora. At least two full Ubuntu installs later, these bindings are still present.  It is worth noting that the use of the Orca modifier (keypad-Insert) is not viewed as modifying the function keys as far as gnome is concerned.  I don't have the time right now to figure out how to unbind these function keys, but I'll get to it later today.

One thing about this test case that I don't like is that, depending on the message, the keys aren't consistently bound to the same element of the header.  For instance, if the message has an attachment, the To: field moves from F3 to F4. I think it would be better to have a consistent behavior so that, every time you hit Orca mod-F3, you hear the To" field.  If there is no information in that field, indicate it-- something like "To: field is empty". If I'm interested in finding out the sender of the message or who will receive copies in a reply to all, I would like to hit a key and get that information immediately--I don't want to have to keep hitting keys until I get the info I'm after. Make sense?

I can't speak to braille issues, since I'm not a braille user.

As for having these hot keys when composing a message, it would be nice but a much lower priority.  Most of the time when I am writing a message, I know the contents of the header fields.  The exception is when I am replying to all, and then it would be nice to be able to find out who is also receiving the message I'm sending... without having to tab around through the header fields.

Thanks!

(Warning, uber-comment follows *smile*)

Thanks for testing this Dave.

> One thing about this test case that I don't like is that, depending on the
> message, the keys aren't consistently bound to the same element of the header. 

Understood.  The question is how to get the desired behavior you want.

Here's the situation:

As you pointed out, if the message has an attachment, the To: field moves.  But it gets more interesting than that. Last night I looked at a variety of messages.  Here's what I found:

1. It seems we can count on there being a subject, from, and date.
2. There may be a to field; there may not.
3. There may be a cc field; there may not.
4. There may be an attachment field; there may not.
5. While less likely, there may be a reply to field; or not
6. Less likely, but possible, there may be a sender field; or not
7. If you collapse the headers, you see fewer of them.
8. If you show all headers, what "all" is can vary.
9. In the "may not" cases, the field is not empty; it ain't there.

If the to field were always present, and the attachment field were the only thing that might be there or might not, we could presumably do some checking to identify which condition we have and adjust accordingly.  But given that we've got the potential for this much variety, what heuristics should we use to figure out which fields we have and don't have?  I don't think we can do that heuristically, but if you have a clever suggestion I'm certainly open to it.

So what non-heuristic things could we do?  I suppose we could make a list of all of the possible fields and look at strings. We'd assign the most common ones to the top, so maybe:

Orca+F1: Subject
Orca+F2: From
Orca+F3: Date
Orca+F4: To
Orca+F5: Attachment
Orca+F6: CC
Orca+F7: Sender
Orca+F8: Reply to
Orca+F9: BCC (for reading messages you sent)

(That order could be re-arranged, this is just for the sake of discussion right now.)

Assuming we go this route, it would be easy enough to create a dictionary of headers by looking for those specific strings. ***For English users*** Those fields have entirely different names in other locales of course.  

So how would we make the dictionary for Spanish?  We'd have to know how to say "Subject" and "From" and "Date", etc. in Spanish.  Our very excellent GNOME i18n team could do that for Orca, but here's the kicker: the string would have to match whatever it is in Thunderbird.  If it doesn't, the feature falls apart completely. :-(

That's all a long (okay, very, very long) way of saying the following: I totally hear what you're saying Dave, and I gave it a lot of thought last night for the very reason you say: It's a drag to have to play, guess where the header is. But given what we currently have exposed to us, I'm at a loss. :-(

So how badly do you want this feature to have predictable/stable field keybindings?  If you really want it badly, by all means say so. In that case, rather than attempt a string-based hack, I would approach the Mozilla team, explain the situation, and file an RFE requesting that the field name be added as an attribute of the accessible. Attributes don't get localized (afaik) so using them should prove reliable.

If your answer is to file the RFE, then I will do so and block this RFE against the one I file. In the meantime, while this RFE is still fresh in our minds, it would be excellent if you and Mike could spec out which field goes with which keybinding. That way, once the Mozilla guys do their thing, I'll be good to go.

Thanks (and sorry for being long-winded, but I felt it was worth explaining the situation rather than just saying "don't think I can do it.")

Hi, Joanie,

Sorry, I was assuming (always a bad idea ;-) that you had access to the Thunderbird data structure which contained this information. Since you don't, let me suggest a compromise (or, should I say, let's do everything... :-):

I suggest that the RFE be filed with Mozilla to provide the data you would need to do this "the easy way".

In the meantime, I suggest that the "press keys until you find what you want" model be implemented so that something is available now.

I'm good at laying burdens on others, aren't I? :-) 

As for the key map (of sorts)... my suggestion is:

1. Subject 
2. Date 
3. From 
4. To
5. Cc 
6. BCc 
7. attachment 

I don't think any of the others need be used. My rationale for this ordering is to keep the addresses together. The order could also be changed so that numbers 3 through 6 above slide up to be 1 through 4, and Subject and Date move down to be 5 and 6.

Thanks for all the effort!

Okie dokie.  The Mozilla bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=445062

Before I jump on implementing the first approach, I want to see what the reaction is from the Mozilla guys.  If they jump on implementing it, then we might as well wait.  

My other concern is a consistent experience for the end user.  If we do it one way and then change it, that might prove confusing.  But I'll leave that decision up to Mike and Will.

(In reply to comment #7)
> My other concern is a consistent experience for the end user.  If we do it one
> way and then change it, that might prove confusing.  But I'll leave that
> decision up to Mike and Will.

If we do it, it should be what we intend for it to be (i.e., don't do it one way and then change it if we expect to be changing it in the near future, especially since T-bird 3.0 is still in flux).

Blocking this bug for now and setting its target to FUTURE.

Obsoleting my patch as it is not the approach we've decided to take.

I'm going to unblock this one for now. On the blocking bug, Marco asked:

> Well turns out converting those to textboxes wasn't doable, but bug 449560 will
> make the accessible names for each header field contain both the actual
> name/address and the type ("from:" etc.). Does that help?

I should probably answer him, which means I need to install t-bird and revisit this bug. :-) I'll do that this weekend.

I took a look. I have a question/concern about what we are getting in the new object attribute and we're still missing object attributes for at least the subject and date fields. We need reliable attributes for all fields. Therefore, reblocking and re-FUTUREing.

To save folks a trip to the Mozilla bug, here is my latest comment:

~~~~~~~~~~~~~~~~
(In reply to comment #8)
> Well turns out converting those to textboxes wasn't doable, but bug 449560 will
> make the accessible names for each header field contain both the actual
> name/address and the type ("from:" etc.). Does that help?

Accessible names are, as I understand it, localized (or potentially localizable), so I'm afraid it does not.

I do see that objects of ROLE_LABEL now expose an object attribute called label which contains both the accessible name for the header field and the address. e.g.:

     to : joanmarie.diggs@gmail.com

Question/concern #1: What is in the object attribute called label coincides with the accessible name of that label. Is that attribute's value independent of the label name or is it taken from the label name? In other words, in a localized version of Thunderbird, is the label object attribute in danger of being localized, or can I count on things like "To", "From", etc. being present regardless of what the accessible name becomes?

Question #2: This is present for the labels which contain the addresses. I am not seeing any object attributes for fields whose contents is presented in objects of ROLE_ENTRY. (e.g. subject and date)
~~~~~~~~~~~~~~~~

Planning spam. Sorry!

Closing blocked bugs because we need the issue fixed in the blocker.