- From: Fred Esch <fesch@us.ibm.com>
- Date: Thu, 16 Apr 2015 13:23:21 -0400
- To: Matthew King <mattking@us.ibm.com>
- Cc: Birkir Gunnarsson <birkir.gunnarsson@deque.com>, "WAI Protocols & Formats" <public-pfwg@w3.org>
- Message-ID: <OF1BB90BE0.30CE17D9-ON85257E29.005E9959-85257E29.005F86BD@us.ibm.com>
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
Attachments
- image/gif attachment: 29955431.gif
- image/jpeg attachment: 29770141.jpg
- image/gif attachment: graycol.gif
Received on Thursday, 16 April 2015 17:23:55 UTC