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