I want to make you aware that the way Alpha Anywhere generates a modal form is not truly modal. A user with a keyboard can easily Tab out of the form and activate controls on the underlying page. This problem is not unique to the way Alpha creates modal windows, as you can see with this CSS/JS example from w3schools.com.
There is a similar issue when using panels. A user can tab through the controls on the active panel and continue into panels that are not currently visible to the user. A user who has lost sight of the cursor, or who thinks they are active in another application could overwrite data or activate buttons without visibility to the changes. They may be able to access parts of your application they are not supposed to. Imagine the possibilities: Delete, Clear, Disable, Change Status, Print, Send Ballistic Missile Alert, etc.
I created a video so you can see what I'm talking about.
Is this important? Do you want your application to be "Accessible"? Do your users use the tab key? As a developer are you responsible to prevent user pitfalls that may impact data integrity?
The W3C recommendation for Access Rich Internet Application (WAI-ARIA) 1.1 provides some guidelines for an accessible modal dialog:
There are ways via code to capture the tab key to keep the focus in the window. Do you want to write that code for every window? Do you have the skills to write the code and avoid creating side effects? I think it would be great if the RAD tool would handle that for me. The best solution can come from Alpha. This way everyone can use it and it will be a breeze to implement. It will be tested in multiple browsers and we will receive updates to correct issues that arise.
My suggestions are:
In the meantime we can put our heads together in this forum and develop some standardized code and instructions on how to implement it. I'm sure we can come up with many different ways to solve the problem. I'm looking for something that is reusable and easy to implement, like a standardized function that I can make a single call to from each form.
(continued in next message...)
There is a similar issue when using panels. A user can tab through the controls on the active panel and continue into panels that are not currently visible to the user. A user who has lost sight of the cursor, or who thinks they are active in another application could overwrite data or activate buttons without visibility to the changes. They may be able to access parts of your application they are not supposed to. Imagine the possibilities: Delete, Clear, Disable, Change Status, Print, Send Ballistic Missile Alert, etc.
I created a video so you can see what I'm talking about.
Is this important? Do you want your application to be "Accessible"? Do your users use the tab key? As a developer are you responsible to prevent user pitfalls that may impact data integrity?
The W3C recommendation for Access Rich Internet Application (WAI-ARIA) 1.1 provides some guidelines for an accessible modal dialog:
- On Dialog Open, Set Focus to the first focusable element
- On Dialog Close, Return Focus to the Last Focused Element
- While Open, Prevent Mouse Clicks Outside the Dialog
- While Open, Prevent Tabbing to Outside the Dialog
- While Open, Allow the ESC Key to Close the Dialog
Sources:
Creating An Accessible Modal Dialog
https://bitsofco.de/accessible-modal-dialog/
https://www.w3.org/TR/wai-aria/#aria-modal
Creating An Accessible Modal Dialog
https://bitsofco.de/accessible-modal-dialog/
https://www.w3.org/TR/wai-aria/#aria-modal
There are ways via code to capture the tab key to keep the focus in the window. Do you want to write that code for every window? Do you have the skills to write the code and avoid creating side effects? I think it would be great if the RAD tool would handle that for me. The best solution can come from Alpha. This way everyone can use it and it will be a breeze to implement. It will be tested in multiple browsers and we will receive updates to correct issues that arise.
My suggestions are:
- For a modal pop-up dialog, provide a property to enable tab protection. When enabled, this generates additional code for you that will allow normal tab/shift+tab in the dialog but keep focus from leaving it. I suggest this as an optional property so it does not add overhead to your application if you don't want it, like for a mobile application.
- For panels, provide a similar property, or create a special container that you can wrap around areas where you want to "fence in" the tab focus.
In the meantime we can put our heads together in this forum and develop some standardized code and instructions on how to implement it. I'm sure we can come up with many different ways to solve the problem. I'm looking for something that is reusable and easy to implement, like a standardized function that I can make a single call to from each form.
(continued in next message...)
Comment