> *>What about a suggestion that ATs indicate by sound or announcement  
> that the user has come across a widget / application, at which point  
> the user can use a keystroke to switch modes.  This 1. makes the  
> user aware of applications / widgets and the associated mode, 2.  
> requires the user to decide to enter application mode, and 3. likely  
> means that the user will have a greater chance of knowing how to get  
> out of application mode.

> I think this makes sense, although both screen readers do voice an  
> announcement when they switch modes. I guess what they are lacking  
> is the key to switch back and forth. Jaws has insert+z and nvda has  
> insert+spaceBar, but they don't always seem to do the right thing.

> I think changing the definition of modal as I suggested in my last  
> message could help. This would allow:
> 1. pure virtual buffer mode (role="document" or no role at all);
> 2. pure app mode (role="widgit");
> 3. virtual modal (role="document" and aria-modal="true");
> 4. app modal (role="widgit" and aria-modal="true").

> For things like menus, I think the app modal paradigm makes sense.  
> For dialogs, I think the virtual modal paradigm might make more  
> sense and be more flexable.
> In the case of menus, you have a definate interaction flow:
> 1. you activate the menu (maybe with a keystroke);
> 2. you navigate to the item you want;
> 3. you execute that command or whatever.

> Now youre done with the menu and application modal mode is turned off.

> With a dialog, you may have many different paths of navigation  
> through the dialog. Maybe you want to set some controls, then go  
> back and re-read the dialog text, switch some more values, then say  
> ok. THis would require you to be able to navigate unrestricted  
> around the dialog; modal is helpful since you don't want to stray  
> outside the dialog, but app mode is much too restrictive.

> Maybe other people can think of more use cases?

> -- Rich

> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca>
> To: <jquery-a11y@googlegroups.com>
> Sent: Thursday, February 18, 2010 4:15 PM
> Subject: Re: Screen-readers and UI modal dialog - modified test page

>> Good afternoon Rich,

>> I completely agree with you that even after having spent time around
>> ARIA I get confused with using NVDA or JAWS in application mode.

>> What about a suggestion that ATs indicate by sound or announcement
>> that the user has come across a widget / application, at which point
>> the user can use a keystroke to switch modes.  This 1. makes the user
>> aware of applications / widgets and the associated mode, 2. requires
>> the user to decide to enter application mode, and 3. likely means  
>> that
>> the user will have a greater chance of knowing how to get out of
>> application mode.

>> Obviously these options could be customized, an advanced user may  
>> turn
>> off the warning and have application mode be automatic on each  
>> object,
>> a novice who is biased against ARIA like experiences may choose to
>> disable the announcements and to never enter application mode, even  
>> if
>> it means decreased functionality of a web app.

>> Thoughts?
>> Everett Zufelt
>> http://zufelt.ca

>> Follow me on Twitter
>> http://twitter.com/ezufelt

>> View my LinkedIn Profile
>> http://www.linkedin.com/in/ezufelt

>> On 2010-02-18, at 4:06 PM, Rich Caloggero wrote:

>>> http://www.mit.edu/~rjc/multipleAppRoles.html

>>> Jaws only switches modes if the body is the only element with
>>> role="application"; NVDA will
>>> switch modes each time you navigate into / out of a container with
>>> role="application". Although the NVDA behavior seems reasonable, I
>>> think there are some
>>> caveats to be aware of. Especially for inexperienced users, changing
>>> the rules on the fly (i.e. switching from virtual to nonvirtual mode
>>> automatically)
>>> could be very confusing.  I'm a screen reader user with lots of
>>> experience and I find it a bit confusing.

>>> The problem is that as soon as we move back into application mode,
>>> navigation will be limited to just tab and shift+tab. If we allow
>>> autoswitching and multiple
>>> application mode containers within the same document, then users
>>> could be inadvertently trapped within document sections.

>>> Imagine arrowing through this document. In virtual buffer mode this
>>> allows you to read the document one virtual line at a time. You'd
>>> first read the h1
>>> tag, then the first paragraph. Then, another press of the arrow key
>>> and app mode would kick in and you'd be stuck on the first button.
>>> If we now tab forward
>>> (since this is all we can do), we will eventually pop back into
>>> virtual mode when we hit the paragraph with tabindex=0 between the
>>> two div blocks. However,
>>> if we did not provide a focussable element in this section, then
>>> we'd never be able to access it at all.

>>> I believe this is why Jaws tags multiple role="application" blocks
>>> with a typical landmark type annotation, but refuses to switch modes
>>> unless there is
>>> one and only one role="application" on the body element itself; then
>>> we can safely assume that the entire webpage is to be navigated as
>>> an application
>>> and the user should be aware of said consequences.

>>> Interested to hear comments ...

>>> ----- Original Message ----- From: "Derek Featherstone" <feat...@furtherahead.com

>>> To: <jquery-a11y@googlegroups.com>
>>> Sent: Thursday, February 18, 2010 3:33 PM
>>> Subject: Re: Screen-readers and UI modal dialog

>>>> On Thu, Feb 18, 2010 at 3:22 PM, Rich Caloggero <r...@mit.edu>  
>>>> wrote:
>>>>> Here's a quick test page:
>>>>> http://www.mit.edu/~rjc/multipleAppRoles.html

>>>>> Jaws is behaving strangely in this circumstance.

>>>> I am not surprised. Would a better test be with NVDA?

>>>> Should this be some of an experimental use case where we should be
>>>> providing advice to AT vendors and feed this back into the ARIA  
>>>> spec
>>>> dev process? Particularly if we are saying that the current spec
>>>> allows for only one role="application" in a document?

>>>> Derek.

>>>> --
>>>> Derek Featherstone   feat...@furtherahead.com
>>>> tel: +1 613-599-9784  1-866-932-4878 (toll-free in North America)
>>>> Work:  http://www.furtherahead.com
>>>> Blog:  http://www.boxofchocolates.ca
>>>> Help: http://ironfeathers.ca/donate/

>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "jQuery Accessibility" group.
>>>> To post to this group, send email to jquery-a11y@googlegroups.com.
>>>> To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com
>>>> .
>>>> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en
>>>> .

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "jQuery Accessibility" group.
>>> To post to this group, send email to jquery-a11y@googlegroups.com.
>>> To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com
>>> .
>>> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en
>>> .

>> --
>> You received this message because you are subscribed to the Google  
>> Groups "jQuery Accessibility" group.
>> To post to this group, send email to jquery-a11y@googlegroups.com.
>> To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com
>> .
>> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en
>> .

> --
> You received this message because you are subscribed to the Google  
> Groups "jQuery Accessibility" group.
> To post to this group, send email to jquery-a11y@googlegroups.com.
> To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en
> .