Closed Bug 635350 Opened 13 years ago Closed 13 years ago

The AccFocus property of MSAA is not being set.

Categories

(Thunderbird :: Folder and Message Lists, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: jamal, Unassigned)

Details

(Keywords: access)

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; MathPlayer 2.10b; TheFreeDictionary.com; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Build Identifier: 3.1.7

Microsoft Active Accessibilty (MSAA)is an API that Thunderbird implements under Windows in order to expose user interface information to assistive technologies for people with disabilities, eg, the JAWS screen reader from FreedomScientific.com. In a message or folder list, the AccFocus property of the accessible object for the list should be updated to an integer value corresponding to the index of the list item that currently has keyboard focus. This would allow, for example, a JAWS script to read selective information about the focused item. At present, however, AccFocus always returns a zero value.

Reproducible: Always

Steps to Reproduce:
1. Use an MSAA testing tool such as MSAA Object Inspector or Event Watcher.
2. Down arrow through a message list and examine the AccFocus Property.
Actual Results:  
The AccFocus property remains at zero.

Expected Results:  
The AccFocus value increases as the index of the focused item increases.

I have developed JAWS scripts to increase the accessibility and usability of Thunderbird for blind persons. An executable installer for the scripts is available at:
http://empowermentzone.com/tb_scr.exe
A zip archive for manual installation is available at:
http://empowermentzone.com/tb_scr.zip

The scripts currently try to work around the bug by iterating from the top of a message list until a message is found with an MSAA state that has the focsed bit set. The further down the list the focused item is, the more inefficient this technique is. The delay is unacceptable with an index above 100 or so, so the scripts give up then. If the AccFocus bug is fixed, the scripts could immediately determine which list item has focus, resulting in a more efficient and complete user experience.
accFocus returns an accessible rather than number, I don't know if MSAA tools converts it into number. I checked it on crossplatform level and I see it this property return focused treeitem accessible when called on tree accessible. But you failed to get focused child from accFocus from a script?
IAccessible::accFocus can return an object or an integer (via a VARIANT). See here, in particular the part about VT_DISPATCH:
http://msdn.microsoft.com/en-us/library/dd318479%28v=vs.85%29.aspx

Gecko doesn't have MSAA simple elements; every object is a real object, including list items. (List items are often simple elements in other frameworks, which is why you are most familiar with this.) Therefore, when you call IAccessible::accFocus on a list object, you get a list item object.

I can confirm that Gecko definitely returns the correct list item object when IAccessible::accFocus is called on the list object.

Btw, there is an undocumented (at least, it was a few years ago) variant type in the JAWS scripting language. I don't remember the details, but it may be of use to you.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Keywords: access
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.