Warning that Modal Windows are not truly modal, and Panels have this issue too.

[Davidk]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

You may have something else going on which is affecting the behaviour.

Using a TabbedUI, opening a UX within a TabbedUI Tab, and then, from that UX, opening a UX as a Modal Popup, I cannot Tab out of that popup. The tabbing stops at the last control... no matter how many times I hit the Tab key.

I can Shift-Tab out of the modal popup UX... but I cannot Tab out.

[iRadiate]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

You may have something else going on which is affecting the behaviour.

Well, that's par for the course. I always have 'something else' going on, LOL.

Here's what I'm seeing. In the video, I am simply pressing the Tab key, nothing else. Even the TabbedUI navigation sidebar scrolling up and down is simply Tab key presses.

https://www.dropbox.com/s/41xyyn5ee4...lTabs.mp4?dl=0

[Davidk]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Using Build 5163 I'm not getting that behaviour. So odd... so Alpha.

http://youtu.be/wwuErpVOWSs?hd=1

[Ben S.]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

The fix only half works. Tabbing forward you're stopped at the last control. Tabbing back (Shift-Tab) you're still tabbed out the modal window.

I was informed this past week that the fix was coming in the next pre-release. I was skeptical if it was going to be a true fix meeting WAI-ARIA 1.1 compliance, or just a hacky work around. It sounds like we got the latter.
I asked if the fix was going to address the panel issue in this thread and I was told that the focus was only on windows. I provided a link to this thread (again) and I hope they read through it all and watch the videos.

Alpha Software, if you're reading this, please make sure you address the following items. In your release notes and documentation, please be specific and explain how the new behavior is different than the previous. If you want us to QA it for you please ask for input. We're happy to collaborate on this but disgruntled if you throw it back over the wall undocumented and incomplete.


For Modal Windows

1. On Dialog Open, Set Focus to the first focusable element
2. On Dialog Close, Return Focus to the Last Focused Element
3. While Open, Prevent Mouse Clicks Outside the Dialog
4. While Open, Prevent Tabbing to Outside the Dialog
5. While Open, Allow the ESC Key to Close the Dialog (or add this as a configurable property)
6. Tabbing after the last control should take you to the first focusable element and not stop at the last control
7. Shift-tab should be handled with a similar (but opposite) behavior as the tab key
   
   For Panels
8. Prevent Tabbing to controls on panels that are not visible
9. Tabbing after the last control should loop to the first visible focusable element and not stop at the last control
10. Shift-tab should be handled with a similar (but opposite) behavior as the tab key
    
    Additional concerns
11. Be aware that controls can be tabbable but not focusable, or focusable but not tabbable. Handle these appropriately for both tab and shift-tab.
    

[Davidk]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Pre-release 5168 attempts, again, to correct this. But Alpha can't quite seem to nail it. Shift-Tab takes you right out of the modal popup. I wonder why Alpha won't test their attempts? It's a fairly simple process.

[Selwyn Rabins]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

the pre-release does exactly what we said it would do - prevent the tab key from tabbing out of a modal. we never said anything about the shift-tab key. in the next pre-release we have now also added support for shift-tab.
we are looking into adding a general property for any container that would constrain tabbing to just that container, but have not yet committed to this.

[iRadiate]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

we are looking into adding a general property for any container that would constrain tabbing to just that container, but have not yet committed to this.

That would be awesome Selwyn, I would add my vote for adding this, if possible. Thanks.

[Davidk]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Yes... absolutely... it does specifically what it says it does... but you're kidding... right? It wasn't a deliberate release to look after half the issue.

[CharlesParker]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Thanks Selwyn for working on it! Good to see progress!

[Davidk]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

With today's pre-release the new "features" to handle Tab and Shift-Tab within a Modal popup are not consistent across current versions of Chrome, FireFox, IE, and Edge. These new features seem to work fully only under Edge. It's a mix for the other browsers.

[Ben S.]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

They didn't say it would work in all browsers....

But seriously...this would be an excellent situation to use automated testing. Dion demonstrated in a Wednesday webinar the use of Ghost Inspector to test a web application. We could build a few modal windows and see if they pass the test in all browsers. Maybe Alpha could use it to test this feature before the next pre-release.

[mikeallenbrown]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

They didn't say it would work in all browsers....

[Davidk]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

In pre-release 5173 Alpha has taken their ball and gone home regarding this issue.

If you don't mind to adding code to your model popup UX you can try this. Seems to work ok for Tab and Shift-Tab, and in the main browsers. There's a couple of lines of code which allows looping of controls. Turn them off if you want to stick on the first or last control. Some controls mess things up for tabbing... e.g. RadioButtons, ButtonLists... because you can't set Focus to these controls. Regular Button Controls don't seem to cause any issues. Regardless, as far as I can see, this code does not allow tabbing out of the model popup.

If you find it doesn't work the way you want, zip and post a simple, unbound UX showing the issue.

In Javascript Functions...

if (document.addEventListener){ 
	document.addEventListener("keydown",keyCaptDown,false); //code for Moz
	document.addEventListener("keyup",keyCaptUp,false); //code for Moz
}
else {
	document.attachEvent("onkeydown",keyCaptDown); //code for IE
	document.attachEvent("onkeyup",keyCaptUp); //code for IE
}

function keyCaptDown(e){
	var currCtrl = e.target.name.substr(e.target.name.lastIndexOf(".") + 1);
	//debugger;
	if(e.keyCode === 9){
		debugger;
		if({dialog.Object}.__tabOrderInfo.shiftKey){
			if(currCtrl == {dialog.Object}.__tabOrderInfo.firstCtrl || currCtrl == ''){
			
				//include this next line if you want to loop through the controls
				{dialog.Object}.setFocus({dialog.Object}.__tabOrderInfo.lastCtrl);
				
				
		 		e.preventDefault();
		 	}
		}else{
			if(currCtrl == {dialog.Object}.__tabOrderInfo.lastCtrl || currCtrl == ''){
			
				//include this next line if you want to loop through the controls
				{dialog.Object}.setFocus({dialog.Object}.__tabOrderInfo.firstCtrl);
				
		 		e.preventDefault();
	 		}
	 	}
	}else{
		if(e.keyCode === 16){
			{dialog.Object}.__tabOrderInfo.shiftKey = true;
		}else{
			{dialog.Object}.__tabOrderInfo.shiftKey = false;
		}
	}
}

function keyCaptUp(e){
	//debugger;
	if(e.keyCode === 16){
		{dialog.Object}.__tabOrderInfo.shiftKey = false;
	}	

}

In Client-side, onRenderComplete...

var thisUX = {dialog.object};
var controls = thisUX.columnInfo;
var ctrlArray = [];
	
for (var key in controls) {
	if (!controls.hasOwnProperty(key)) continue;
	ctrlArray.push(key);
}
var firstCtrl = ctrlArray[0];
var lastCtrl = ctrlArray[ctrlArray.length-1];
{dialog.Object}.__tabOrderInfo = {};
{dialog.Object}.__tabOrderInfo.ctrlArray = ctrlArray;
{dialog.Object}.__tabOrderInfo.firstCtrl = firstCtrl;
{dialog.Object}.__tabOrderInfo.lastCtrl = lastCtrl;
{dialog.Object}.__tabOrderInfo.shiftKey = false;

[Ben S.]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Thanks for sharing this solution. I'd like to do some testing with it to see how it handles special controls.

If you find it doesn't work the way you want, zip and post a simple, unbound UX showing the issue.

Can you share a sample UX for us to start with? This will help in case we (in this thread) want to pass it back and forth with various test cases.

When the code identifies the first and last control, is it possible to have it log the control name or type to the console? I'm not sure I know how to do that.

[Davidk]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Attached is a zip file containing 2 UX Components. The Parent component has a button which opens the Popup Modal Test UX. The first and last control names are written to the console.