Re: Suggestions for developers of Thunderbird and other Mozilla apps

Hi Jamal,

thank you for your feedback! It is very valuable to receive feedback 
like this, which helps us improve our support for screen reader vendors 
(and scripters).

Let me address a few issues you raise below.

Am 04.01.2010 17:58, schrieb Jamal Mazrui:
> * Include all relevant controls in the navigation sequence of dialogs.
> In particular, make the Add button focusable in the subdialog of Account
> Settings after one chooses the Actions button.

This is a menu button which drops down a list of available actions when 
pressed. You can imagine this to be a combobox which drops down after 
the buttons is pressed. Unfortunately, JAWS does not announce that this 
is a button menu. Other screen readers such as NVDA, do announce this fact.

> * Include a keyboard way of changing the sequence of columns in the
> message list.  Currently, this can only be done with mouse drag-and-drop
> operations.

Yes, this is on our list of requests for this widget type.

>    * Include hotkeys to go directly to common folders, including Inbox,
> Sent, Trash, and Junk.  My scripts try to implement Control+Shift+Letter
> combinations for this, e.g., Control+Shift+I for Inbox.  The scripts use
> the JAWS off screen model (OSM) to find the folder name, route the mouse
> pointer to it, and then click.  This works sometimes but is not reliable
> because the folder name is not always visible, or the word appears in
> another context than being the clickable folder name.

This is a suggestion that should be posted to the 
mozilla.apps.thunderbird newsgroup. This is interesting for a wider 
variety of users than just those in need of accessibility. I do, 
however, see a problem with the fact that Thunderbird can include 
multiple Inbox, Sent etc., folders depending on how many IMAP etc. 
accounts are set up. But I'm sure there are great minds at work at both 
ends who could work out a great solution!

> * Use a delimiter character other than a space to seperate columnar data
> in the MSAA AccName property of a message list item.  It is difficult to
> reliably parse out, say, the subject from the sender from the recipient
> of a message when only spaces seperate each data item.  I suggest a Tab
> character as a delimiter (\t).
>
>
>
> * Ensure that all relevant message status information is available in
> MSAA properties.  For example, attachment data is not currently
> available via MSAA.

These two will be addressed in a different way once Thunderbird switches 
to the Gecko 1.9.2 (or newer) version of the platform. The version 
Thunderbird 3.0 uses does not include richer features for evaluating 
columnar data. In Gecko 1.9.2 and above, this message list will no 
longer be a ListView, but a table that can be queried for each column. 
That table will then also include only one piece of information, and it 
will include all relevant status flags for a message.

I also noted this as a known limitation in the current Thunderbird 3.0 
version in my blog post.

> * In message composition mode, use seperate edit controls for the To,
> CC, and BCC fields.  Currently, one control is used with a preceding
> ComboBox to select whether To, CC, or BCC, is applicable.  This
> arrangement is quite inefficient from a keyboard standpoint.  Much
> better would be seperate controls with initial letter hotkeys, e.g.,
> Alt+T for the To field, Alt+C for the CC field, and Alt+B for the BCC
> field.  Alt+S does currently work for focusing on the Subject field.  My
> scripts also try to implement Alt+M for the message body.

Again, this is a suggestion for the Thunderbird team since it involves 
the UI, not accessibility specifically.  From an accessibility 
standpoint, each address has its own edit control (MSAA-wise). The 
widget is basically a table which gets rows added the moment you add a 
new e-mail address by pressing ENTER on the last one.

Personally, I think of this particular layout as a feature rather than a 
bug, since it gives me much more flexibility than trying to navigate a 
long, comma-delimited list in a multiline edit field like in Outlook or 
Outlook Express. I found that particular one very inefficient for me. 
With the layout in Thunderbird, I can quickly arrow up and down and skim 
the addresses I have entered, and can, on the fly, change the type of 
addressing (to: cc: etc), without having to copy and paste the address 
from one field to another.

> * Avoid using the same hotke for completely different tasks.  For
> example, F7 is currently used for caret-browsing mode when reading a
> message, and for the spell checker when writing a message.

Yes, this is a good point. Caret Browsing is inherited from the Gecko 
platform (it is also available in Firefox), whereas the spell checker is 
a feature of Thunderbird (well at least the full-blown dialog is).

> * Prevent Control+W from exiting the application.  Currently, one can
> inadvertently exit Thunderbird by pressing Control+W to close a message
> when only one tab is open.

I ran into that trap myself. This is again something specifically for 
the Thunderbird team. For a web browser, closing the last window or tab 
with Ctrl+W might be desirable, for an e-mail application, it is most 
likely not.

> * Include quality documentation with Thunderbird, e.g., available from
> the Help menu and with the F1 key.  The lack of TB documentation is a
> usability barrier generally, and an accessibility barrier to people with
> disabilities.  A visually obvious behavior of the application may be
> completely unknown to us without documentation that describes how the
> program responds in a given context to input events or setting changes.
> Also include a Help button in the Account Settings and Options dialogs
> (like Firefox has).

Again something for the Thunderbird team, and I know the documentation 
part has been raised by others not in the accessibility field. However, 
as with Firefox, I believe Thunderbird will be switching to a wiki-style 
help system where users can add or edit content as well, and this may or 
may not yet be fully implemented, I'm not sure.

> I hope these suggestions are helpful in a team effort to make
> Thunderbird and other Mozilla applications more productive to users with
> disabilities.

Again, thank you for raising these issues and bringing them to our 
attention!

I hope my feedback will help keep the discussion going, and don't be shy 
to bring up the suggestions I pointed out above in the 
mozilla.apps.thunderbird newsgroup and spike some discussion there as well!

Marco