When I use JAWS 'find' to locate some terms on a web page, I use F3 and Shift+F3 to to move to next and previous instances of search term occurrences. The terms get read by JAWS however the focus doesn't move to each search term by default.
What I want to know is whether there's a shortcut to shift focus to the occurrence like for example, browser native 'find' starts highlighting the search term occurrences and pressing Esc shifts focus to the first occurrence.
That depends on your definition of "focus". When you use F3, JAWS will read the result of the find and its surrounding context. The JAWS virtual focus is moved to the search result. If you use the up/down arrow keys after hitting F3, you'll hear the next or previous element (respectively) in the DOM relative to the search result, so the "focus" is moved.
However, if you're talking about the focus as in the keyboard focus, no, that is not changed. If the search result were in a paragraph (<p>), the keyboard focus would not be able to move to that element unless it had tabindex="0" or tabindex="-1".
Related
Just as the title says.
I cant find ANYTHING for this particular usecase Online.
This is in context of a website aiming to be AA WCAG 2.0 conform.
I have non-focussable text alongside focussable textinputs inside of a single view.
I can TAB through the focussable textinputs, but I cant read out the textfields inbetween. When I press "arrow down" while having the focus on the textinput I get "empty field" from NVDA. Most shortcuts also unfortunately produce text in the textinputfield instead of executing the associated behavior in NVDA.
Is there any way have the keystrokes being recognized as commands instead of input for the textfield? Is there any keyboard shortcut telling NVDA to behave like this?
Under the hood, NVDA auto switches to Forms mode, so what you're getting is the correct behaviour. if that text is related to the field, then you should use aria-describedby="[id of text]", on the form element.
I wouldn't be looking at anything that changes the default behaviour of how it works, as this will undoubtedly cause issues, for end users.
Could you not put that text in a tooltip, that is only shown when a user tabs to an interactive icon, next to the input (using the aria-describedby attribute too)?
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}
I'm running a Tmux session inside a MobaXTerm SSH connection. Now if I want to select some text to be copied to the system clipboard (by holding shift pressed while dragging the mouse over the text) the selection does not work as expected.
Assume I select one word. I press and hold shift, press and hold the mouse button over the first character of the word, move the mouse to the end of the word and release the mouse button. The word gets highlighted and copied to the clipboard. This works fine.
However, now I change my mind, or discover that I selected the wrong word, and want to select a different word. Again I do the same sequence as before, but on the other word. Strangely, when I press and hold the mouse on the new word, the highlighting is not reset, but continued from the initial highlighting of the previous selection.
This is extremely annoying. I can only reset the selection by temporarily switching to a different window. It seems this problem only occurs with MobaXTerm. If I use Putty instead, the selection works fine. I checked all settings of MobaXterm, but can't find anything related to mouse events.
To clear a selected region (after selecting with shift + drag) you can either:
Right click anywhere, then left click anywhere
Shift + right click anywhere, then left click (without shift) anywhere
I think (1) sometimes does not work when I have vim in my tmux pane, but (2) works regardless.
After clearing the selection, you should be able to start another from a new location.
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.
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.