Re: Confusion about role of dialog

On Jan 31, 2011, at 3:39 PM, Matthew King wrote:

> From the perspective of interpreting the ARIA spec, why would you think this is a bug?


The spec indicates that AT is supposed to automatically switch navigation modes when encountering the 'document' or 'application' roles. If the author needs the Windows-style screen readers to start passing events through, he should wrap any application controls (such as this dialog) in an node with a role of application.

http://www.w3.org/WAI/PF/aria/complete#application
http://www.w3.org/WAI/PF/aria/complete#document

If the AT vendors start doing different things, as Freedom Scientific has done here, then interoperability flies out the window and web developers will start hacking pages based on the non-standard behavior of a single screen reader. For example, one engineer may intend to use a dialog which contains only document content (a EULA, for example), and not understand way JAWS is automatically switching modes while other Windows screen readers (WE or NVDA, perhaps) are behaving as expected. As Victor mentioned, VoiceOver navigation does not rely on keyboard interception, so this requirement doesn't apply.

According to that style of application versus document navigation, once the AT switches to application-browsing mode, the web author is responsible for managing focus, which is why there is an explicit switch between the document and application roles. JAWS is expecting the web author to start managing focus at this random place, though according to the DOM structure, the author has promised nothing of the sort. This could result in an experience that will frustrate user and author alike.

> This is the behavior that Freedom Scientific interpreted as correct.

I'm not sure how they came to that conclusion, but I think I can speak for the rest of the PFWG in saying that Freedom Scientific would benefit from participating in the ARIA calls or the PFWG email list.

Received on Tuesday, 1 February 2011 20:05:10 UTC