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

+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
>
>
>
>
>