There are TextBox and custom keyboard. I need to disable the input pane when TextBox has to get focus. I tried the TryHide method for show and focus events.
InputPane.GetForCurrentView().TryHide();
But it is a very bad worked solution because InputPane is blinking when a user is taping on TextBox. Then I found a possibility of changing input policy in documentation CoreTextInputPaneDisplayPolicy But the documentation does not explain how to apply this policy.
Using TextBlock is not suitable for me because I need to manipulate with the cursor and select text. Is there a nice solution for this problem?
Microsoft has code sample demonstrated here.
// Create a CoreTextEditContext for our custom edit control.
CoreTextServicesManager manager = CoreTextServicesManager.GetForCurrentView();
_editContext = manager.CreateEditContext();
// Get the Input Pane so we can programmatically hide and show it.
_inputPane = InputPane.GetForCurrentView();
// For demonstration purposes, this sample sets the Input Pane display policy to Manual
// so that it can manually show the software keyboard when the control gains focus and
// dismiss it when the control loses focus. If you leave the policy as Automatic, then
// the system will hide and show the Input Pane for you. Note that on Desktop, you will
// need to implement the UIA text pattern to get expected automatic behavior.
_editContext.InputPaneDisplayPolicy = CoreTextInputPaneDisplayPolicy.Manual;
Related
I tried and understood what could be the purpose of the accessibilityActivationPoint but in vain.
When a focused accessible element is activated, that property should indicate VoiceOver the specific area it's going to activate when a user double-taps the element (Apple reference) : for me, it's always the selected element itself.
I understood the selected element is considered as a block by VoiceOver, whatever the other elements inside. Once a double tap occurs to activate this block, VoiceOver calls accessibilityActivate to know what to perform (Apple reference).
1/. I've written many tests by creating a custom view including a switch control. Whatever the value of accessibilityActivationPoint inside (or outside on another switch control), the value of the switch control never changes. Is it a proper use case or am I totally wrong ?
2/. When we gather many elements inside one accessible element, how is VoiceOver able to activate one of them while they aren't accessible by definition ? Pointing one of them thanks to the accessibilityActivationPoint should work ?
Personally, I couldn't make it work and think that I'm really confusing accessibilityActivationPoint and accessibilityActivate.
Any help would be appreciated, thanks in advance.
Yes, you have the right idea with accessibilityActivate and accessibilityActivationPoint. Note that, in order for it to work, the accessibilityActivationPoint needs to be a point within the Control that you are trying to activate in on-screen coordinates (use the convert function!).
I think the short answer is "yes" to answer your second question, but, just to clear up confusion about when Accessibility Activation Point is useful, I'll go into more detail about it.
By default (aka, the default behavior for AcessibilityActivate()), when any view is activated by VoiceOver, VoiceOver will send a "tap gesture" to the center of the view. The position of this "tap gesture" can be changed by updating the accessibilityActivationPoint attribute on a view. Below, I have an example for how this property can be used.
Let's say you have a blank button (in the image below, the button is the gray box) next to some text:
For the purpose of accessibility, you may want to make the entire view that holds the button and text an Accessibility Element (so that VoiceOver users can easily understand that the button is associated with the text "Worldspace Attest"). In the image below, I am using Accessibility Inspector to show that the view holding both of these elements is an Accessibility Element.
Notice in these images that the button is not in the center of the view, but rather, it is to the right. When you activate this view using VoiceOver, the view will not select the button; instead, it will send a "tap" to the center of the view (which is the same as tapping the text, which does not do anything). In order to select the button, you have to set the view's accessibilityActivationPoint to be the on-screen coordinates of the button:
view.accessibilityActivationPoint = self.convert(button.center, to: UIApplication.shared.windows.first)
This should make it so that this button is usable by a VoiceOver user.
I hope this information clears up any confusion about the Accessibility Activation Point property. The example I used above can be found in this repository in the "Active Control Name" demo.
Typically a combobox widget is an input field that launches an associated popup with a bunch of suggestions in the popup. In desktop browsers using keyboard, while the focus stays with the input field, pressing Up/Down arrow keys, the selection within the popup can be changed. Pressing ENTER key populates the input field with current selection in the popup and closes the popup.
For accessibility purpose, the input field is marked role="combobox", the popup is linked with the input field via aria-owns. The AT are indicated the current selection via aria-activedescendant.
While this setup works great in desktop browsers with tools like JAWS/NVDA etc., there seems to be a major issue with voiceover on iOS. On swiping the finger, the virtual cursor moves to the next element in the page from the input field, though I would expect with aria-owns set, the focus to move to the first suggestion item or to the popup.
Any suggestions on how such a combobox widget can be made accessible in iOS with voiceover?
PS: The popup and input field are not siblings in the DOM order.
It sounds like you are creating a custom combobox. If you use the native <select>/<option> elements, the combobox works correctly on ios/voiceover. If you are creating your own, follow the guidance on https://www.w3.org/TR/wai-aria-practices/#combobox. You mentioned several ARIA attributes so perhaps you're already following the advice on that page.
Swiping right with voiceover will move the focus to the next element in the DOM. If your dropdown list is hidden, then focus won't move to it. Double tapping on your <input> should display the dropdown list.
The datepicker is managed by knockout-jqueryui in a Durandal view presented as a modal dialog. The calendar pops up when the corresponding INPUT is focussed, and hides when it is blurred. Data-binding works fine.
But when the user selects a value, the calendar closes, the INPUT updates and the calendar re-displays. It works, but it's annoying my users because they are mouse obsessed and the calendar obscures the control below, making it hard to click on it. Yes, I know they could press tab. I have pointed this out.
How can I stop the re-display? Ideally, triggers for display would be focus and keydown. I have no problem with configuring it to manual control and switching with data-bind="change: showCalendar, ..." or similar, if that's how one does this.
So, what's the usual way to go about this? If it's manual control as I describe above, what are some keywords to expedite finding the relevant section(s) in the documentation? (How to set it to manual and how to hide/show it manually.)
(I found show() and hide())
The showOn option for jQuery UI Datepicker is passed through by knockout-jqueryui.
It defines only two values, 'focus' and 'button'.
There is no explicitly defined mechanism to disable auto-display, but I found that a value other than the defined values has the desired effect. I am passing 'click'.
Manual control methods are show and hide.
I want to achieve the same effect as in Visual Studio 2010+, where if you float an editor on top of the main form, clicking on a main form menu or toolbar button doesn't cause the main form to steal focus; instead the floating window retains focus.
Without this it becomes impossible to invoke any main menu command that operates on a focused control when the focused control is in a floating window - because the control you wanted to operate on loses focus just as the command is invoked.
(Ironically, if you look closely at this image you'll see that the selection in the editor is muted, indicating that the editor control doesn't have focus. Visual Studio seems to be doing something slightly devious to achieve the illusion that the floating window is still focused.)
The solution is very easy if you are using TActionMainMenuBar and TActionToolBar.
First the menu bar: TActionMainMenuBar has a property AutoFocus, which is True by default. Set this to False and then clicking on the menu won't automatically give focus to the form containing the menu. Instead, the form that previously had focus will retain it.
Now the tool bar: TActionToolBar doesn't have an AutoFocus property. Instead you need to handle its OnMouseActivate event and return maNoActivate.
Note that returning maNoActivate from an OnMouseActivate handler doesn't work for all controls. Some controls such as TButton will give themselves the focus when clicked regardless of the return result from the OnMouseActivate handler. But in the case of TActionToolBar we do get the effect we are after.
It took me a while to find this though, and even searching Google for a page containing both 'AutoFocus' and 'OnMouseActivate' elicits no useful results (other than, presumably, this page once it gets indexed). So I hope this answer will help someone else.
I created a form in Delphi.
Say I have a Form with a speedbutton with label "&Add" (underline A, as a keyboard shortcut), and a dbgrid (read-only state) (or other control like TButton).
Then I changed the focus to Dbgrid (dbgrid got a focus) (or to TButton).
Every time I press the a key on the dbgrid, the onClick method on the speedbutton triggers.
Sometime I need to disable it for a while for a reason, and then i enable it again.
How to disable the speedbutton shortcut?
And then how to enable it again?
The form is pressing the button when you press A because the button has expressed interest in that key, and nothing else on your form is accepting keystrokes. If you had an edit box on your form, and it had the input focus, then the button would not be triggered.
You can make a control indicate that it wants to receive keystrokes when it has the focus, but that generally happens when writing a custom control, where you have some idea of what the new control class should do when it receives keyboard input.
If you don't want the button to be triggered, you can disable it. Another option is to alter the OnClick event handler to check other conditions (such as whether the grid has focus) before performing the usual click-handling code.
You could disable the shortcut by changing the speed button's label from &Add to Add. Change it back when you need to enable the shortcut again.
Please note that specifying an accelerator character like that enables two shortcuts, one is just the key prefaced with the & and the other the same key with Alt. So, in your case they would be A and Alt+A. In the same way, eliminating the accelerator disables both shortcuts. So, keep in mind that with this method of disabling the shortcut you would be unable to trigger the button neither with A nor with Alt+A.