This is from someone who does quality assurance related to accessibility at Mozilla. Jamal -----Forwarded Message----- From: dev-accessibility@xxxxxxxxxxxxxxxxx Sent: Wednesday, January 06, 2010 12:09 PM Subject: 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 _______________________________________________ dev-accessibility mailing list dev-accessibility@xxxxxxxxxxxxxxxxx https://lists.mozilla.org/listinfo/dev-accessibility __________ Visit and contribute to The JAWS Script Repository http://jawsscripts.com View the list's information and change your settings at //www.freelists.org/list/jawsscripts