RE: strange reader behaviour in form elements

The IBM Software Accessibility Testing Checkpoint (see Note 1) on testing 
gives some guidance here:


Test using accessibility test tools such as Inspect Objects. Inspect can 
be used to determine whether there is an accessibility problem with your 
application or with the screen reader. If your application is coded 
correctly, but the screen reader does not read the application, use 
Inspect to verify that the right information is available to the screen 
reader. If Inspect provides accurate information in the Name, Value, Role 
and State fields, but the screen reader does not read the information, it 
is probably a screen reader issue and not a problem with your application. 


"Inspect Objects" comes as a utility with MSAA from Microsoft (see note 
2).  But as Jim and others have said, screen readers (for example JAWs) 
may be looking at the DOM and not MSAA at this instance.  I've heard that 
Window Eyes (see note 3) uses MSAA more frequently than others.

What I've found NOT possible is to tell the screen reader where to get 
information via a profile or script.  For example, scripting functions in 
JAWs are where the script writer ask JAWs a question and gets a response. 
JAWs internally determines where to look for the answer, which may or may 
not be MSAA.  But the script writer has no way to tell JAWs where to look, 
only to use the exposed list of function calls that are available.  Which 
only makes sense, cause if I tell a screen reader to look for the 
information in MSAA, but it doesn't have the support coded to do that yet, 
how would it answer? 


Note 1: IBM Software Accessibility Testing 
http://www-306.ibm.com/able/guidelines/software/swtest.html
Note 2: Microsoft Active Accessibility SDK 2.0 
http://www.microsoft.com/downloads/details.aspx?FamilyId=3755582A-A707-460A-BF21-1373316E13F0&displaylang=en
Note 3: Evaluation version of Window Eyes: 
http://www.gwmicro.com/products/

Regards,
Phill Jenkins
IBM Research - Accessibility Center
ibm.com/able