In the 1001st implementation of carousel I would like to "properly" handle the focus.
A few quick questions related to UI/UX of this component:
the arrows and the page navigation can accept focus if the TAB key is used. Should I keep the focus on the arrow button after a click event? Is it possible to do it wo calling element.focus() method - like pure HTML/CSS solution?
the page navigation area is suppose to handle the arrow keys inputs - the same question for it: Should I keep the focus once a page navigation button is pressed? Is it doable wo element.focus()? What should be ARIA role for this component?
the design requires 4px height navigation buttons - really hard to click on mobile. In order to make them useable, a div is added as a child of a navigation button so the height of click zone is extended to +20px. Is there better way to extend the "hot zone"?
how can I exclude the additional divs so as not to contribute to area of focus rectangle
Regarding focus, you ask if the focus can be kept on the buttons without using focus(). Absolutely. In fact, when you click on a button, the focus will not move unless you specifically move it or if the element you clicked on gets hidden. So if your desire is to leave the focus on the button, then you don't have to do anything.
That's the preferred behavior - leave the focus on the button. If I'm exploring the carousel slides and I'm a keyboard user, I will navigate/tab to the "next" button and press enter. I'll review the slide and if it's not what I want, I'll press enter again (assuming my focus remained on the "next" button) to see the next slide. If you force the focus to move away from the button and to the carousel content, then I have to navigate back to the "next" button before I can view the next slide. It can be annoying to have to keep navigating back to the element I just selected.
I don't understand your third or fourth questions.
Have you looked at the two W3.org references regarding carousels?
https://www.w3.org/TR/wai-aria-practices/#carousel
https://www.w3.org/WAI/tutorials/carousels/
Related
I am trying to work with the Bootstrap 5 Toggle Button (using the Outline Style for a more evident visual emphasis). However, the UX experience is not quite what I'm hoping for.
(See https://getbootstrap.com/docs/5.0/forms/checks-radios/#outlined-styles)
The toggle per se works well, its the focus (or after the click focus I should say) that's the problem. When the button is in an unchecked state, the visual clue is prominent since the button is outlined. When the button is in an checked state, again the visual clue is prominent because the button is filled. When the button transitions from an unchecked to checked state, the change is evident as it transitions from outlined to filled.
The problem is when unchecking. When the button transitions from a checked to unchecked state, the button remains filled until a) the mouse is moved on device with a cursor, or b) another location on the page is touched on a touch device. The user obviously believes that they have not unchecked the button when it has in fact been unchecked and then proceeds to continue to attempt to uncheck the button.
The problem is even more evident when dealing with multiple checkboxes in a button group.
(See https://getbootstrap.com/docs/5.0/components/button-group/#checkbox-and-radio-button-groups)
I have tried using javascript to call blur on the checkbox's click event, and although that approach has a limited degree of success, it does nothing on touch devices as the virtual pointer for the device remains hovering over the button. I also tried calling focus on a different element on the page with the same result.
Does anyone have any suggestions?
Was submitted for bugfix here: https://github.com/twbs/bootstrap/issues/34664
Steps to reproduce:
Set-up a select2 dropdown in Tags mode.
Start typing a tag.
With the focus still in the drop down, using the mouse wheel, scroll to a different part of the page.
Now click somewhere.
Observed results:
You are scrolled back so the tagging drop down is in the viewport.
You can see this behavior in action on the projects demo page.
Expected results:
Clicking away from the tags dropdown should not affect scroll position.
This is particularly annoying in an app I'm working on because the Save button of a form is off screen. If the user enters a tag, then scrolls with the mouse wheel to the Save button (which IMHO a very intuitive flow when adding a new tag to an otherwise filled out form) and clicks the Save button, the click won't register on the button. Instead the user is auto-scrolled back to the dropdown with focus no longer in the drop down. Now, they could scroll again and click the actual button.
Anybody know how to fix this issue? I have no qualms with updating the source (already had to do so to fix other select2 quirks).
(FWIW, as of now I haven't logged a bug in the Select2 repo, since it seems questionable to me how actively it's being maintained)
I'm trying to dismiss the keyboard via JS in response to a button press, but I'm not having any luck.
Setup:
I have a textarea with accept and cancel buttons tied to it.
Upon clicking the cancel button, my view object will call textAreaElement.blur().
It will then remove the accept and cancel buttons.
Expected:
Field loses focus (visually and otherwise).
Keyboard is dismissed.
Actual:
Field appears to lose focus (visually, no cursor is displayed), and programmatically.
Keyboard is still presented.
I've already tried the usual Google but they all seem to think that calling blur on the focused element should be sufficient. One user even suggested calling $('input').blur() to ensure that all fields were blurred, but that didn't seem to make a difference.
... and I just figured out why this was happening.
I mentioned that I was removing the Accept and Cancel buttons for this field. Specifically the following was taking place:
Call textAreaElement.blur().
Animate the buttons disappearing.
Upon completion of the animation, buttons.remove().
When the Cancel button received the click, it gained focus (the keyboard remained active). When the Cancel button was subsequently removed in the animation completion callback, focus was applied to the previous focusable element, which is the textarea.
So I had the effect of doing:
textarea.blur() # Already doesn't have focus.
buttons.remove() # Removes buttons, applies their focus back to the textarea.
The solution was to instead:
Animate the buttons disappearing.
Wait for completion of the animation, buttons.remove().
Call textAreaElement.blur().
Right now Tab is disabled in Impress.js and just moves to the next slide.
Even if I delete that code and let it behave normally and focus on links it kinda crashes impress.js
Has anyone found a solution to this?
Thank you!
(I maintain a current fork of impress.js, as bartaz has not worked on it for years now, so I'm familiar with the keybindings code as well.)
The answer is that making Tab move to the next slide is the solution, not the problem :-)
More specifically, the problem is that in a browser, the tab key will jump to the "next" link or form field. If the link is outside the current slide, the browser will scroll to wherever the link is, completely breaking the presentation flow. So impress.js needs to disable the tab key.
Instead of disabling it, bartaz then just tied it to the next() function. If you don't want the Tab key to move to the next slide, you can of course remove that code, but you would still have to call event.preventDefault() to avoid the browser from receiving the Tab key.
In my fork of impress.js, I improved the support for using form fields, so that for example if the cursor is in a text input field, and you press left arrow, the presentation will not move to the next slide, rather it will move the cursor in your text field, as normal. But even in this case I've preserved the functionality of the Tab field: it will move to the next slide rather than next form field (or link).
It would be possible, but hard to try to figure out whether the next form field is still on the same slide or not, and then try to decide whether moving to that form field is the right thing to do.
UPDATE: This is the impress.js issue where Tab key is discussed.
My implementation have the following components on a modal screen.
A form that will be used for searching.
A table where the user will see the results
The user will be able to search and then scroll through the result list using the keyboard (using upward arrow or downward arrow).
When the user hits enter to search, I blur the focused field...
When I blur the focused field the user loses the ability to scroll the browser window using upward arrow or downward arrow...
In order to re-enable this default browser behavior the user should hit tab once on his keyboard...
My Question is:
How can I programmatically re-able browser navigation?
PS.: The default browser navigation that I'm mentioning here is the behavior that happens when you hit upward or downward arrows on your keyboard.
Any help is really appreciated.
Thank you in advance
Edited:
The following snippet of code describes my scenario
http://plnkr.co/edit/YCvfQt?p=preview
$scope.onSubmit = function() {
$scope.dataSource.push({ name: $scope.personName });
$('#personNameField').blur();
};
Scenario(You should use only your keyboard to replicate):
In the Live Preview click on 'Open' Using the keyboard you should
write something and hit enter (don't click on screen)
After clicking on enter try scrolling through the list
You will notice that it is not possible (You are able to scroll
again if you hit tab once)
What I want to do here is enabling scrolling again after the user hits enter...
Please let me know if you need more context.
Thank you
It turns out that we only need to give focus on the main element on screen... In this case the modal....
For my example that would be:
$('#myModal').focus();
Thanks for the comments