RE: Focus order behaviour for Non-Modal mentioned in ARIA 1.1

The behavior described by the text you quoted from WCAG is more commonly associated with a disclosure, i.e., collapsible section, not a non-modal dialog. A dialog in ARIA is defined to be a window, and a primary distinguishing characteristic intended to be communicated by the dialog role is that the window container contains the tab ring.

The difference between a modal dialog and a non-modal dialog is that the background of a modal is inert, i.e., it is not usable by anyone where as the background of a non-modal dialog is not inert. A non-modal dialog may thus provide ways of moving focus between the dialog and the content outside the dialog, including other non-modal dialogs.

The Tab key could be enabled as a mechanism for moving outside of a non-modal dialog, but as soon as you do that, there is almost no point in using the dialog role. It would be better to wrap that same content in a region or group labeled by a child heading rather than a dialog. It would likely be more accessible that way.

As of today, we do not have consensus on conventions for moving focus in and out of non-modal dialogs. F6 is common in some native apps, but it comes with implementation challenges due to the way F6 is used by browsers. Buttons assigned to shortcut keys are another approach. For instance, if a non-modal dialog were a floating spell check window, it could have a button for "edit text" that moves focus outside the dialog to the spelling error in the main window. And, in the main window, it could have a button for "Resume spell check" that continues the checking and moves focus back inside the spell check dialog. Users could focus and activate those buttons to move focus, but the experience could be significantly enhanced if each button had a shortcut key that works when focus is in the relevant context, e.g., opt-E in the dialog and opt-R in the main window.

Thank you for calling attention to this discrepancy. I think it would be good to raise a WCAG issue in GitHub to modify the guidance.

Matt King

-----Original Message-----
From: Ramakrishnan Subramanian <ram.eict2013@gmail.com> 
Sent: Wednesday, January 9, 2019 5:49 AM
To: public-aria@w3.org
Subject: Focus order behaviour for Non-Modal mentioned in ARIA 1.1

Hi Team,

I feel that there is inconsistency between the point mentioned in aria
1.1 and the point in wcag  2.0 regarding the focus order behavior for Non-modal dialog.  From WCAG 2.0 I understand  that, From the last interactive control within the Non-modal, the tab focus can go to the next  interactive control in the page which is out of the non-modal dialog.
If there is any change in the behavioral pattern updated in aria 1.1.
or, if I had mis  interpreted the points, please kindly help me understand.
Below I have given the relevant points and their links.

WAI-ARIA Authoring Practices 1.1
https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal

Under the heading: 3.8 Dialog (Modal)
(Like non-modal dialogs, modal dialogs contain their tab sequence.
That is, Tab and Shift + Tab

do not move focus outside the dialog)

Understanding Success Criterion 2.4.3 | Understanding WCAG 2.0 https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html

Point 2 below the heading: Examples of Success Criterion 2.4.3 (2. A Web page implements modeless dialogs via scripting. When the trigger button is activated, a

dialog opens. The interactive elements in the dialog are inserted in the focus order immediately after the button. When the dialog is open, the focus

order goes from the button to the elements of the dialog, then to the interactive element following the button. When the dialog is closed, the focus order

goes from the button to the following element.)


-- 

Thanks and Regards
Ramakrishnan

Received on Wednesday, 9 January 2019 19:28:55 UTC