How can I force the Tab to focus the element I want, is it possible to give my software a list of elements to cycle focus ?
I remember once using a property called tabindex, but I can't find it anymore.
Maybe, preventing Tab to focus an element could also work ?
Yes, you can set the order of focusing for each widget in a container, using the function container.set_focus_chain().
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 have a form with <p:inputText> and <p:selectOneMenu> components next to each other. When the focus is on the input text and I press the tab key in order to navigate to select one menu by keyboard, then the focus is lost. I don't see which component is focused.
How can I get the focus on the select one menu when I tab into it?
You need to use the tabindex property of <p:inputText> and <p:selectOneMenu>, as explained in the documentation.
Using the tabindex property makes it possible to navigate between <p:inputText> and <p:selectOneMenu>. What worked for me was to see set the tabindex in <p:inputText> to n and n+1 in <p:selectOneMenu>. I used n = 90.