In my Flex 4.9.1 application, at a particular point I put up a "sheet of glass" over the entire stage. It's purpose is to trap all mouse clicks until the user presses the escape key, which removes it. That part is easy and works well. It's just a FlexSprite, parented by the systemManager, which paints transparent pixels over the entire screen.
The problem is that, regardless of where the focus is before the glass is put up, or even if stage.focus is set to null, the user can press the tab key and focus text inputs beneath the glass, and enter text into them.
I tried listening for KEY_UP and KEY_DOWN events on the systemManager, with useCapture=true, and the highest possible priority (0x7FFFFF). When I get the events, I call stopPropagation(), stopImmediatePropagation(), and preventDefault() (even though the events are not cancelable) on them. Nothing works. No matter what, hitting the tab key several times will bring a textfield into focus, and typing letters will enter text into the fields.
So it appears that the text fields are not actually controlled by the key events they dispatch, as if the text is entered before the event is actually dispatched. Because presumably, if they were, they would listen at the target phase of the event flow. And as for the tab key, I have no idea why stopping its propagation doesn't prevent the focus switching.
Has anyone accomplished what I'm trying to accomplish before? If so, what worked?
You can use Application.application.enabled = false; to disable all the controls beneath the top-level Application while the "sheet of glass" is up.
See this answer for more details.
Related
Since I remapped XButton1 and XButton2 to ctrl+shift+tab and ctrl+tab
I wanted to set the right mouse button + XButton1/2 combos as forward&backward.
It works, but I don't have right click now...
I tried writing it as {RButton&XButton1}, needless to say that didn't help, but back/forward still works.
XButton1::Send ^+{Tab}
XButton2::Send ^{Tab}
RButton&XButton1::Send !{Left}
RButton&XButton2::Send !{Right}
I expect the right mouse button to work still as it is intended.
The prefix key in a custom combination (in this case RButton) loses its native function,
unless you add
RButton:: Send {RButton}
Where would the first focus be on when a modal window opens? Some say the focus order should be sequential, so the first tab stop should be on the close button and some say, it should be on the first logically actionable element.
According to me, it should be on the first actionable item. Let's say if a modal window is opened to Search something, then the focus should be on the search edit box.
What are your thoughts? Which is better and what are the reasons?
The answer is, it depends®.
In fact it's mostly a question of good sense. You should put the focus where the user is the most likely to do his first action in the modal. Therefore:
If you are prompting for input, the most logical is to put the focus on the first required field
If you are asking a yes-no or multiple choice question, the focus should go on the most probable or recommanded answer
Exception to the previous one: if you are asking a question about whether or not to proceed on a unrecoverable action such as "are you sure to delete ?", the focus should be set to the no button eventhough the most probable answer is yes, so that the user has a last chance to cancel something triggered by misstake
If the modal dialog is just showing a message, it's logical to put the focus on the OK or close button, since it's the only possible action
Putting the focus on the close button when something else is expected is kind of weird, especially for screen reader users, who don't necessarily know what the dialog is for immediately.
I always put it on the first heading or label, so blind users can confirm where they are after clicking the link or button which opened the modal. Then focus can move to the close button as the next item in sequence - if opening the modal was a mistake (happens often when you can't see the layout or with ambiguously labelled links) this makes it easy to correct.
Jumping to the first focusable item isn't technically wrong but gives poor usability for screenreader users while only saving one click for sighted keyboard users.
There are recipes on how to change focus on mouse move or client change.
But what I want, is to prevent any window from stealing focus. E.g. I open a new terminal via the default meta-Enter shortcut, and when it opens it immediately steals focus. Is there any way to prevent it?
Yes, it's possible. Focus events can happen in many ways. In the case of the new clients, just comment the focus line in your rules.
For the focus follow mouse, remove the client.focus = c in the mouse::enter section of rc.lua
For specific clients, you can add focus filters:
https://awesomewm.org/apidoc/libraries/awful.ewmh.html#add_activate_filter
For the deepest and most advanced focus control, you can disconnect the default focus handler (awful.ewmh.activate) from the request::activate (Awesome 4.0+) signal and implement your own. In that case, you will have absolute control over every focus events.
I need to capture the current time each time a spacebar is pressed on the browser while using JAWS Screen reader. I am able to capture the spacebar if I am not using JAWS, however, the system cannot capture any spacebar once JAWS is on.
Here is my code:
$(document).keypress(function(event) {
var chCode = ('charCode' in event) ? event.charCode : event.keyCode;
if (chCode == 32){ //32 is keyCode for spacebar
addTime = addTime + Number(new Date()) + ",";
var x = document.getElementById("spacebar");
alert("spacebars!!!");
}
});
I would like to know what to do so that I can capture the current time each time a spacebar is pressed.
Funny enough, each time a spacebar is pressed, JAWS reads out "space" but the event is not captured at the code level.
OR - Since JAWS reads out "Space" when I press the spacebar, does anyone know how I can capture JAWS event? Since it recognizes it when I press spacebar, I am wondering if I can capture the event directly from JAWS. Any thoughts?
This happens because most screen readers, and namely JAWS, provide so-called virtual cursor in browsers. This is needed for quick navigation on web pages and alike documents.
To test this, try pressing a letter on a web page while JAWS is on. For instance, if you press b, JAWS will say "No buttons" because b moves to the next button (if any). To type text, you need to enter the forms mode.
The spacebar, on the other side, works only when you are on a clickable element (link, button, check box or just an element with onClick event attached), then it activates the element; or in forms mode, then it types the space into an edit field.
In order to accomplish what you want to do, you need to declare a part of your web page as role="application" (more on this here):
When the user navigates an element assigned the role of application, assistive technologies that typically intercept standard keyboard events SHOULD switch to an application browsing mode, and pass keyboard events through to the web application.
The intent is to hint to certain assistive technologies to switch from normal browsing mode into a mode more appropriate for interacting with a web application; some user agents have a browse navigation mode where keys, such as up and down arrows, are used to browse the document, and this native behavior prevents the use of these keys by a web application.
So, in order to be able to count your time, just declare a parent div as role="application", and your Spacebar will be passed directly to the application and not intercepted by JAWS.
In GUI dialogs, most applications provide for keyboard control as follows:
Enter key - presses the default button. (Default is usually indicated with a bold button border.)
Esc key - presses the Cancel or close button.
Space key - presses widget that currently has keyboard focus.
Tab key - advances focus to next widget.
Question is, when keyboard focus is on a widget that is a button, should the default button be changed to be the one with focus?
I see some issues with this behavior:
The display noise of redrawing buttons to unbold the outline of original default button and rebold the button under focus as being new default.
The Space key is now somewhat redundant with Enter key.
There is no keyboard accelerator to get the normal default button now (Usually the OK button).
However, it seems the trend has been in this direction to change the default button with focus change to another button. What is the rationale for this departure from the early GUIs? It would seem to provide less functionality given there is no way to press the original default button. Did people find that the original model was too complicated for users to understand? I would think keyboard control of dialogs would be a task for advanced users who would have no trouble understanding the model and prefer to have accelerator for current button (Space) and original default button (Enter) at all times.
Note that Qt for one is supporting the change: QPushButton's autoDefault property is responsible for the behavior of changing the default button. By default its value is true. Therefore, you must take extra action to set it to false for all buttons, to prevent them from becoming the default button when focused.
This is not a "departure from the early GUIs", at least not if by "early GUIs", you mean Windows 1.0. The behavior that you describe has been this way since the beginning.
The focused button is always "pushed" when the Enter key is pressed. The default button is only triggered in the following two situations:
The default button has the focus (which it does by default), or
The focus is on a control that does not process Enter key presses (such as a static control, or a single-line textbox that does not have the ES_WANTRETURN style flag set).
The famous Win32 blogger Raymond Chen has a post explaining this behavior (focus specifically on the last two quoted paragraphs):
A dialog box maintains the concept of a "default button" (which is always a pushbutton). The default button is typically drawn with a distinctive look (a heavy outline or a different color) and indicates what action the dialog box will take when you hit Enter. Note that this is not the same as the control that has the focus.
For example, open the Run dialog from the Start menu. Observe that the OK button is the default button; it has a different look from the other buttons. But focus is on the edit control. Your typing goes to the edit control, until you hit Enter; the Enter activates the default button, which is OK.
As you tab through the dialog, observe what happens to the default button. When the dialog box moves focus to a pushbutton, that pushbutton becomes the new default button. But when the dialog box moves focus to something that isn't a pushbutton at all, the OK button resumes its position as the default button.
The dialog manager remebers which control was the default button when the dialog was initially created, and when it moves focus to something that isn't a button, it restores that original button as the default button.
The behavior that I would expect is:
If I press enter when the window just pop up, it should press the default button
If I press tab, I start navigating through the widgets. In this case there are two options:
2.1 I press enter - this event should be delivered to the focused widget. There's no need to change the default button - simply hand the event to the focused widget.
2.2 I press escape. In this case, everything should go back to the state after the window is created.
Notes:
I come from a mixed background - I don't know if I learned this in windows, linux or Mobile OSes! This is just how I expect things to work out.
I don't use the space key (didn't know it's functionality)