634909 - JAWS 12 does not read dialog content intermittently. (seems wrong role returned by FF)

Status: RESOLVED INCOMPLETE

(Firefox :: Disability Access, defect)

Description

[Nitin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

We have some dialogs used in one of our Web based product. We use the Dojo toolkit to generate dialogs in our web client. Some of the dialogs have static text (like a paragraph of text) followed by an OK and cancel button. The static text is marked with an aria role of document. The dialogs are created from a DialogTemplate as follows :

	<div id="DialogID" dojoType="DialogTemplate" title="<fmt:message key='SomeTitle'></fmt:message>" draggable="true">
		<p>"This is my paragraph content</p>
	</div>	


The DialogTemplate has a containerNode as follows, This node contains the static text :

	<div dojoAttachPoint="containerNode" class="dijitDialogPaneContent"></div>


Now this containerNode is attached a role as follows :

	dijit.setWaiRole(this.containerNode, "document");

This causes the containerNode to have a role="document". Now as the role is set to document, JAWS 12 needs read out the dialogs content when the focus in set on the containerNode. But intermittently (especially when the dialog is loaded for the first time), JAWS 12 fails to read the content.

On further analysis, I observed that JAWS 12 fails to read it when inspect32 shows the role as follows :

	Role:	"document" [ BUG? State/Role should not be a string ]

JAWS 12 reads out the content properly when  inspect32 shows the Role like this :
	
	Role:	document

Reproducible: Sometimes

Steps to Reproduce:
Refer the Details section.
Actual Results:  
Refer the Details section.

Expected Results:  
role=document should consistently returned by FF causing JAWS to read the content properly

Comment 1

[Nitin]

Also I would I like to add another weird behavior that I observe with the dialogs. Intermittently it reads out the elements on the background page even when the dialog is in the front. When I press tab to switch focus between the containerNode and OK button on the dialog, I observe that inspect32 showing  focus sometimes moving to the elements on the background page and this seems to be the cause of JAWS intermittenly reading the elements on background page. I tried to reproduce this issue with IE8 but it works good. Which makes me suspect that this is a Firefox specific issue.

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Marco, can you confirm this with Jaws 12? What happens with NVDA?

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Nitin, we'll need test cases. Preferably, if you can reduce the problem to a simple test case and attach to this bug report we can move fastest to a resolution.

Comment 4

[Marco Zehe (:MarcoZ)]

Also, it would be good if you could test with Firefox 4 Beta 11 if this is still an issue. 3.6 and 4 are two totally different pairs of shoes.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #3)
> Nitin, we'll need test cases. Preferably, if you can reduce the problem to a
> simple test case and attach to this bug report we can move fastest to a
> resolution.

(In reply to comment #4)
> Also, it would be good if you could test with Firefox 4 Beta 11 if this is
> still an issue. 3.6 and 4 are two totally different pairs of shoes.

Right, we definitely need a link or testcase so it can be tested against Firefox 4.

Comment 6

[Nitin]

Attachment: Sample Code that reproduces the issue

I have created a sample code to reproduce the issue. This Sample code should help you identify the issue easily. Please read the "Read Me.txt" to know how to get the sample running. You will required to set the path for (dojo.js) Dojo 1.5 (I am suing Dojo 1.5 src).

Comment 7

[alexander :surkov (:asurkov)]

Nitin, just to make sure, you can reproduce it on Firefox 4?

Comment 8

[Nitin]

Alex, I cannot test our product with FF 4.0, as one of plugin does not support it as yet but I am able to test the sample code (attached above). The issue reproduces with Firefox 4.0 release using the sample code. You should be able to use the sample code and reproduce the issue as well. It would be great if you could verify the issue with sample code and mark this bug as confirmed.

Comment 9

[Marco Zehe (:MarcoZ)]

This test case no longer works, we haven't heard from the reporter in over 9 years if this ever worked with an updated version of Firefox or not. Closing as INCOMPLETE.