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.
Related
I'm facing a very weird (& blocking) issue using diagrams.net webapp.
I'm trying to add some nodes in the Format Panel. I created a new tab in this panel & added in it some new inputs.
There are text inputs, checkbox inputs & textarea.
But the behavior is absolutely not the expected one.
For text & cb inputs, everything works fine, but textareas behavior is... at least very weird:
The field can't get focus by mouse clicking (remember that click works on other inputs). The only way to set the focus on it is by using JS focus() method.
Text inside the tag can't be selected by mouse. If element has the focus, text can be updated. Moreover, even if text can be changed, text cursor cannot move from the end of the text.
Textarea box is not resizable. There is the bottom-right arrow to resize it & I added the "resize" value to be sure but the feature doesn't disable but I juste can't. BUT ! If I set the attribute "disabled" then I can resize the box. Unfortunately, I can't disable the textarea since I want to put it because I need to write in it.
I can't show you code for now (it's just a new node creation using document.createElement) but you can easily test this: go to drawio webapp & when the webapp is loaded, use the Inspector in the developer tools to add a new textarea node in the format panel (div with ".geFormatContainer" class) : element is not focusable with the mouse, text inside it is unselectable & box is not resizable as long as "disabled" attribute is not set.
I added a click listener in the component to check if click did something & it does, but it doesn't give the focus to the element (document.activeElement says that body is focused -_-) so I think there is something in mxgraph which avoids the element's classic behavior. But what ?
I have an autosuggest component (with a TextField from material-ui), my issue is that after selecting a value from the autosuggest (eg. with the mouse), the suggestion remains open since the input still has the focus
How do I navigate to the next focusable element programmatically?
There's a web page where I'm trying to use Tampermonkey to give focus to an element in an iframe which is cross-origin to the top document. Copious use of console.log() tells me that my script is executing, getting the proper element, and calling focus() or click() on it, but the component isn't scrolling when I press space; I have to manually click on the element for it to scroll from keyboard input (the page is otherwise responding to keyboard input just fine). I used "inspect" on the element I want and then entered $0 into the console to make sure that I referring to the correct element in my script. I even have my Tampermonkey script use the setTimeout() trick, with a timeout of 1 second, but that's of no help.
A few other things of note:
While the page is loading I can scroll up and down using the arrow keys, but as soon as it finishes loading it won't respond to those keys again until I click the element with my mouse.
If I click on the element, press Tab to give focus to the next element, then press Shift-Tab to cycle backwards,
the result is that there's that thin blue outline around my desired element, seeming to indicate that it has focus, yet pressing space or the arrow keys won't scroll it.
I'm using Chrome 68.0.3440.106
EDIT: The pages in question are rented books from VitalSource viewed with their in-browser book viewer. Unless you already have a book with them that's currently valid you won't be able to view the problem pages.
I am working on a ToDo list app wherein I keep the focus on the textbox input after the user adds a ToDo item.
Now, the problem is, when the user adds some text input and hits the add button, the focus on the textbox is lost so the keyboard disappears and then the focus gets back to the textbox. So, the keyboard disappears and appears again in a short interval. As you can imagine, this is bad UX.
How do I set the keyboard to be shown explicitly when the focus is on the input button?
I fixed it by setting the focus onto the textbox first when I click the add button then do the actual adding stuff.
I have a long HTML form that I am trying to make accessible to Voiceover. When I click into a field, interact with it, and then click Done on the keyboard, after a short delay Voiceover is focusing on what appears to be the field most centered on the screen rather than the next element. I tried adding explicit tabindex to all the fields and this did not help. It is not always reproducable, it sometimes works as expected.
Is this expected behavior for Voiceover? Would a user not expect "Done" to take them to the next field (seems like maybe a dumb question since there is also a "Next" button, which works fine)? But as a sighted user I know the "Done" button when I am interacting with a field just means I am done with that field and want to go on to the next action, field whatever.
"Done" dismisses editing mode on VoiceOver. A VoiceOver user would not expect that tapping "done" moves the VO cursor.