Re: Is there an html or WCAG definition of "modality" as it relates to keyboard behavior in a modeal dialog?

Fred
ctrl-f4 in FF/IE/Chrome .. or I think so, (or similar browser key to
close the tab) would close the modal .. admittedly with the effect
that you would also close the application. If the modal was part of a
process you would have to start said process from scratch.
And the close button should never be out of the focus order, I would
call that a violation of WCAG 2.1.1 in a heartbeat.
Sure, if the modal is compliant to pc users it should enable the
escape key to close the modal, but that leaves out users of
touch-screen devices with no keyboard.
But, yes, my original question, in essence, is whether any W3C
specification had something normative to say about keyboard focus
control or focus management within modal dialogs.
If user is able to tab out of a modal into the background content on a
webpage, I have failed that under 2.4.3, because the tab order should
not take the user there and is not logical.
But e.g. if user gets to the last focusable element in a modal dialog
and the use of the tab key is disabled .. would that be a failure,
because the focus does not wrap back up to the first focusable
element?
I would say no, user can shift-tab back up.
But there is the gray area where user is able to tab out of the modal
into the address bar of the browser, and from there back into the
modal.
Should that be allowed, the address bar is not part of the modal or
the application, and users can use the f6 key to get to the address
bar.
That being said, users can tab into the address bar from a normal
webpage as well, so why should we restrict that possibility in a
modal. Well, because it is distracting to the user, who can get his
focus wondering off into la la land.
Still, if I had my back up against the wall I would not fail this
under 2.4.3, though I will point it out as a possible usability
problem.
I think from this discussion I can definitely sense that this is not a
widely recognized or documented violation, which is what I was looking
for.
Thanks guys.





On 4/16/15, Fred Esch <fesch@us.ibm.com> wrote:
>
> Matt,
>
> This response makes your position more clear. You only want to restrict the
> behavior of tab and whatever other keys are used within the webapp for
> navigation.  That makes sense. Would putting tabindex=-1 on the only button
> that closes a modal dialog cause a keyboard trap that you could never get
> out of?
>
>
>
>                     Regards,                     Fred
>
>                    Fred Esch
>        Accessibility, Watson Innovations
>     AARB Complex Visualization Working Group
>                      Chair
>         W3C SVG Accessibility Task Force
>                    IBM Watson
>
>
>
>
>
>
>
>
> From:	Matthew King/Fishkill/IBM
> To:	Fred Esch/Arlington/IBM@IBMUS
> Cc:	Birkir Gunnarsson <birkir.gunnarsson@deque.com>, "WAI Protocols
>             & Formats" <public-pfwg@w3.org>
> Date:	04/16/2015 12:48 PM
> Subject:	Re: Is there an html or WCAG definition of "modality" as it
>             relates to   keyboard behavior in a modeal dialog?
>
>
> Fred,
>
> I am saying apps in browsers should work like apps on the desktop. On
> desktop, you can easily navigate to other apps from a modal but only using
> keys that are specifically dedicated to that purpose. You can not tab out
> of a modal on the desktop. You should not be able to tab out of a modal in
> a browser tab. Of course, if the focus is in a modal in a web app, you
> should be able to use browser keys for getting to other tabs in the browser
> or to the browser chrome. And, you should be able to use op sys keys to
> get to other applications on the desktop. But, it is extremely problematic
> if tab or arrows exit the modal.
>
> With my analogy, I was trying to point out just how extremely weird it
> would be if desktop apps worked the way that some web apps do. If they
> worked that way, where you could tab out of the modal to a completely
> different context, I think everyone would agree that such behavior should
> be branded as an accessibility defect.
>
> To me, it is just as obvious that web app modals should work like desktop
> modals; the reasons that behavior is good on the desktop all apply to the
> web app context. The web 1.0 paradigm that says everything must be
> tabbable, creating  massive tab rings that jump off cliffs and throw focus
> off into far away lands, is a tired and problematic paradigm that is
> actually a huge disservice to PwD.
>
> 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:	Fred Esch/Arlington/IBM
> To:	Matthew King/Fishkill/IBM@IBMUS,
> Cc:	Birkir Gunnarsson <birkir.gunnarsson@deque.com>, "WAI Protocols
>             & Formats" <public-pfwg@w3.org>
> Date:	04/16/2015 09:23 AM
> Subject:	Re: Is there an html or WCAG definition of "modality" as it
>             relates to   keyboard behavior in a modeal dialog?
>
>
> Matt,
>
> I am confused by your point. Are you saying a desktop app with a modal
> dialog open should prevent a user from getting to other applications on the
> desktop? If not, they why should one app in a browser prevent you from
> going to another app in another browser tab?
>
>
>
>                     Regards,                     Fred
>
>                    Fred Esch
>        Accessibility, Watson Innovations
>     AARB Complex Visualization Working Group
>                      Chair
>         W3C SVG Accessibility Task Force
>                    IBM Watson
>
>
>
>
>
>
>
>
>
> From:	Matthew King/Fishkill/IBM@IBMUS
> To:	Birkir Gunnarsson <birkir.gunnarsson@deque.com>
> Cc:	"WAI Protocols & Formats" <public-pfwg@w3.org>
> Date:	04/16/2015 12:17 PM
> Subject:	Re: Is there an html or WCAG definition of "modality" as it
>             relates to   keyboard behavior in a modeal dialog?
>
>
>
> Birkir,
>
> I have been involved in similar discussions and agree that focus should not
> leave a modal dialog.
>
> There are some who argue that inside the browser context, that this
> behavior should be platform dependent. I strongly disagree with such a
> position as I think it clings to an out-of-date notion that the browser is
> THE application and stuff inside is browser rendered content rather than
> the idea that a browser can render applications in the same way that a
> desktop OS renders desktop applications.
>
> Now that we have a modal property in ARIA 1.1, perhaps we could advocate
> for a normative "author SHOULD" requirement along these lines related to
> that property.
>
> 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:        Birkir Gunnarsson <birkir.gunnarsson@deque.com>
> To:        "WAI Protocols & Formats" <public-pfwg@w3.org>,
> Date:        04/15/2015 12:33 PM
> Subject:        Is there an html or WCAG definition of "modality" as it
> relates to  keyboard behavior in a modeal dialog?
>
>
>
> Greetings
>
> At a meeting with a big client today we had exhaustive discussions on
> whether it is a failure if user focus is allowed to go out of a modal
> dialog, into the address bar of the browser, then back into the modal.
> The big issue discussed is that no one was able to find a W3C
> definition of modality. The ARIA Authoring Guide describes expected
> behavior when navigating a modal dialog using the keyboard, but that
> specification, though excellent, is not normative.
> It is not clear to me that allowing user to get to the address bar is
> a definitely violation of 2.4.3 (I would like to find something that
> enabled me to definitely call it as such).
> Apologies if this is off-topic, but is there anywhere in WCAG specs or
> the html spec where modal is clearly defined with regard to keyboard
> navigation, something that can be referenced when calling keyboard
> navigation that enables user to leave a modal, if only for a single
> tabstop, a WCAG failure?
> Thanks
> -Birkir
>
>
>

Received on Thursday, 16 April 2015 17:39:27 UTC