Suggestions for developers of Thunderbird and other Mozilla apps

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Suggestions for developers of Thunderbird and other Mozilla apps

Jamal Mazrui
I have learned as much as possible about Thunderbird 3.0 from various
sources on the web, and have developed a set of JAWS scripts to improve
its usability for people who operate with that screen reader, available
with an executable installer at
http://EmpowermentZone.com/tb_scr.exe

or with a zip archive for a manual install (currently needed for Win64)
at
http://EmpowermentZone.com/tb_scr.zip


The following is a set of suggestions that I hope Mozilla developers can
implement in the next version of Thunderbird.  If it is better to
include such suggestions within the Bugzilla tracking system, I hope
someone familiar with that system can help transfer them accordingly.

In general, TB3 meets a minimum baseline of accessibility in terms of
keyboard operability and screen reader output via MSAA.  Much can be
done, however, to make the screen reader experience more efficient and
smooth.

* 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.

* 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.

  * 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.

* 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.

* 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.

* 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.

* 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.

* 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).

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

Regards,
Jamal
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for developers of Thunderbird and other Mozilla apps

Marco Zehe-3
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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for developers of Thunderbird and other Mozilla apps

Wayne Mery
good stuff.
followups set to mozilla.dev.apps.thunderbird

On 1/6/2010 12:09 PM, Marco Zehe wrote:

> 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.

Thunderbird 3.1 will ship with Gecko 1.9.2


>> * 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


--
http://wiki.mozilla.org/Thunderbird:Testing
http://www.spreadthunderbird.com/aff/165/
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for developers of Thunderbird and other Mozilla apps

Onno Ekker-2
On 7-1-2010 19:27, Wayne Mery wrote:

> On 1/6/2010 12:09 PM, Marco Zehe wrote:
>> Am 04.01.2010 17:58, schrieb Jamal Mazrui:
>>> * 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.

You can disable this by going to about:config and set the preference
mail.tabs.closeWindowWithLastTab to false.

Onno

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility