RE: JAWS behavior with the dialog role preventing access to dialog content

This is a brilliant example where non-defined or non-exact defined behavior is taken as an opportunity for a vendor to fill the gap with his own interpretation how things are to be handled. 

I see these "interpretations" quite often. What lacks to me is a transparent and common consensus how things *should* be because the majority of users want this exactly so. I think you cannot get these answers easily, so this encourages the AT developers to code their own interpretation. 

What I heard is that many users are used to switch between screen reader modes permanently, so these defaults may or not may harm expected behaviours - I cannot judge on that.

- Stefan

-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Montag, 15. April 2013 22:32
To: wai-xtech@w3.org WAI-XTECH
Subject: JAWS behavior with the dialog role preventing access to dialog content

Freedom Scientific JAWS triggers "application mode" behavior when you use a simple dialog role, preventing access to any static content inside that dialog, such as a static table of results. The spec is pretty clear that this mode should be triggered when encountering the "application" role, but JAWS appears to be doing so implicitly on several of the other roles. Removing the dialog role causes the static content to become navigable again, but results in negative behavior for all screen readers (including JAWS) in that the user no longer knows this content is displayed in a dialog. Also, if a field is focused by default when the dialog is shown, the dialog label and description is not spoken.

Do the rest of you agree that this is a "bug" or would you consider it outside the purview of W3C jurisdiction, since it's AT behavior rather than UA behavior? Do any of you know if Freedom Scientific is aware that this is potentially harmful behavior? Do any of you know workarounds to this problem?

Thanks,
James Craig

Received on Tuesday, 16 April 2013 07:28:50 UTC