RE: @inert and @aria-inert for disambiguating modal states

Bryan,

The guidance says the application needs to provide a keyboard function for 
moving focus between the non-modal dialog and the main application window. 
It suggest F6 as a possibility. This can also be done with buttons in each 
window. F6 may be a shortcut for operating those buttons that is revealed 
when the button has focus or on hover.

We definitely want the tab ring for the non-modal dialog to be separate 
from the tab ring for the main application. That is 99% of the UX benefit 
of having the a-modal dialog instead of just another region on the page. 

For example, picture a sidebar window in a rich text editor for listing 
comments and revisions. It may have a list of comments and revisions that 
can be ordered in different ways with a sorting menu. It may have buttons 
for adding and deleting comments. The tab ring (and screen reader browsing 
function) should be isolated to the comment and revisions experience so 
the user can discover and use comment and revision related tasks more 
efficiently.

The application could provide the user with several ways of moving focus 
to the main editor window from the comment and revisions dialog. It could 
allow the user to select a comment in the comment list and press enter to 
move the editing cursor to the point in the text where the comment appears 
and place the focus there. It could also let the user press F6 or a 
"return to editor" button to move back to the main application window 
without changing the location of the editing cursor. It might also allow 
the user to press escape or a close button to close the comment and 
revisions dialog and return focus to the current location of the editing 
cursor. This type of experience would be similar to the MMS Word styles 
pane). 

The point is that tab and shift tab would not return focus to the main 
window. The application would provide other ways of moving focus back and 
forth between the two windows precisely so that the non-modal dialog can 
have its own tab ring.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To:     Matthew King/Fishkill/IBM@IBMUS, 
Cc:     W3C WAI Protocols & Formats <public-pfwg@w3.org>
Date:   11/07/2014 04:24 PM
Subject:        RE: @inert and @aria-inert for disambiguating modal states



I just ran some tests, and it actually does work well in FF if you don’t 
follow the APG. Specifically where it states:
 
“A non-modal dialog is one which is displayed and focusable at the same 
time   as the application which invoked it. Also like the modal dialog, 
focus via the   tab and shift-tab key must be maintained within the 
dialog. However, a non-modal   dialog should have a keyboard mechanism to 
return focus to the application while   leaving the dialog open.”
 
If you ignore the part about the tab and shift+tab keys, you can navigate 
out of a non-modal dialog, but if you do follow the guide, then you 
cannot; being trapped within the container using JAWS.
 
Granted Escape can close a dialog and return focus, but if this is the 
only mechanism for achieving this, then it negates the guidance
“a non-modal   dialog should have a keyboard mechanism to return focus to 
the application while   leaving the dialog open”
 
I guess this should probably be clarified further while we work on the 
guide.
 
From: Matthew King [mailto:mattking@us.ibm.com] 
Sent: Friday, November 07, 2014 3:53 PM
To: Bryan Garaventa
Cc: W3C WAI Protocols & Formats
Subject: RE: @inert and @aria-inert for disambiguating modal states
 
Which JAWS behavior is inconsistent with the APG guidance on non-modal 
dialogs? 

The guidance does not say what AT should do. But, it does say: 
"Also like the modal dialog, focus via the tab and shift-tab key must be 
maintained within the dialog. However, a non-modal dialog should have a 
keyboard mechanism to return focus to the application while leaving the 
dialog open.  " 

Assuming such keyboard function is provided by the application, when it is 
invoked, I assume JAWS would switch between 2 different virtual buffers: 
one containing the dialog content and one containing other application 
content. Of course, whether or not the screen reader operates in this 
manner or some other is the prerogative of the screen reader vendor. I 
would personally find such behavior very beneficial and analogous to 
comparable desktop experiences. 

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com 



From:        Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> 
To:        Matthew King/Fishkill/IBM@IBMUS, 
Cc:        W3C WAI Protocols & Formats <public-pfwg@w3.org> 
Date:        11/07/2014 03:18 PM 
Subject:        RE: @inert and @aria-inert for disambiguating modal states 





Matt, would it be worth filing a bug with FS regarding the handling of 
role=dialog in FF? This functionality goes against the guidance at 
http://www.w3.org/TR/wai-aria-practices/#dialog_nonmodal 
  
From: James Nurthen [mailto:james.nurthen@oracle.com] 
Sent: Thursday, November 06, 2014 12:40 PM
To: public-pfwg@w3.org
Subject: Re: @inert and @aria-inert for disambiguating modal states 
 
I see the need for a developer to state whether their dialogs are modal or 
not.

In the Modal case, for AT which uses a virtual buffer model, it would 
allow the AT to prevent the user from interacting with the base page using 
the virtual buffer when a modal dialog is open. If the dialog is not modal 
then AT should allow interaction with the base page.

JAWS does this today for the dialog role but IMO this is not correct 
because dialogs do not have to be modal.

I don't care how this problem is solved. aria-inert seems like one 
possible solution, but alternatively there could be an aria-modal property 
on the dialog role - or even a new role entirely for modal dialogs.

Regards,
James 
On 11/6/2014 10:08 AM, Dominic Mazzoni wrote: 
On Thu, Nov 6, 2014 at 10:01 AM, James Craig <jcraig@apple.com> wrote: 
On Nov 5, 2014, at 11:17 AM, Richard Schwerdtfeger <schwer@us.ibm.com> 
wrote:

> Dominic, @inert is an indicator of state - like aria states and 
properties. It does not have to do the actual function.

This is a false statement. @inert is useless if it does not provide the 
function. By the same logic, I can see no possible way that @aria-inert 
would be useful or even possible to implement. 
 
Exactly, I don't see any purpose in @aria-inert that reports to AT and 
doesn't actually do anything. What is the AT supposed to do if events fire 
on nodes that have aria-inert=true? 
 
 
-- 
Regards, James 

James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 | Mobile: +1 415 987 1918 
Oracle Corporate Architecture
500 Oracle Parkway | Redwood City, CA 94065 
Oracle is committed to developing practices and products that help protect 
the environment