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

Thanks for your response

On Thu, Jan 10, 2019, 1:55 AM John Foliot <john.foliot@deque.com wrote:
>
> +1 to Matt's recommendation about filing a WCAG issue @ github.
>
> JF
>
> (Sent from my mobile, apologies for any spelling mistakes)
>
> On Wed, Jan 9, 2019, 2:29 PM Matt King <a11ythinker@gmail.com wrote:
>>
>> 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
>>
>>
>>
>>